前言

為了優(yōu)化代碼設(shè)計(jì)娜膘，業(yè)界先后提出了 MVC舷手、MVP、MVVM 和 MVI 等架構(gòu)設(shè)計(jì)劲绪。這四個(gè)模式討論是 “如何管理 UI” 這個(gè)話題男窟，采用的手段都是 “關(guān)注點(diǎn)分離”，只是實(shí)現(xiàn)的細(xì)節(jié)不同贾富。最開始是沒有采用任何模式的狀態(tài)歉眷，不管是視圖代碼還是表現(xiàn)邏輯全都寫在 Activity 里面，很明顯這樣的代碼耦合度非常高颤枪，難以進(jìn)行維護(hù)和測試汗捡，可讀性也不好。

提示：耦合度高是現(xiàn)象畏纲，關(guān)注點(diǎn)分離是手段扇住，易維護(hù)性和易測試性是結(jié)果，模式是可復(fù)用的經(jīng)驗(yàn)盗胀。

1. MVC

MVC 其實(shí)是 Android 默認(rèn)的設(shè)計(jì)艘蹋，MVC 里將代碼分為三個(gè)部分：

• View： Layout XML 文件；
• Model： 負(fù)責(zé)管理業(yè)務(wù)數(shù)據(jù)邏輯票灰，如網(wǎng)絡(luò)請求女阀、數(shù)據(jù)庫處理宅荤；
• Controller： Activity 負(fù)責(zé)處理表現(xiàn)邏輯。

MVC 初步解決了 Activity 代碼太多的問題浸策，但也有缺點(diǎn)：我們的初衷 Activity / Fragment 是只處理表現(xiàn)邏輯的部分 冯键，但現(xiàn)實(shí)是 Activity 天然不可避免要處理 UI，也要處理用戶交互庸汗，說明 Activity 本身天然承擔(dān)了 View 的角色惫确。那么這個(gè)架構(gòu)就會造成 Activity 里糅合了視圖和業(yè)務(wù)的代碼，分離程度不夠蚯舱。

2. MVP

為了將 Activity 中的表現(xiàn)邏輯徹底分離出來雕薪，業(yè)界提出了 MVP 的設(shè)計(jì)。MVP 同樣將代碼劃分為三個(gè)部分：

• View： Activity 和 Layout XML 文件晓淀；
• Model： 負(fù)責(zé)管理業(yè)務(wù)數(shù)據(jù)邏輯所袁，如網(wǎng)絡(luò)請求、數(shù)據(jù)庫處理凶掰；
• Presenter： 負(fù)責(zé)處理表現(xiàn)邏輯燥爷。

在實(shí)現(xiàn)細(xì)節(jié)上，View 和 Presenter 中間會定義一個(gè)協(xié)議接口 Contract懦窘，這個(gè)接口會約定 View 如何向 Presenter 發(fā)指令和 Presenter 如何 Callback 給 View前翎。這樣的架構(gòu)里 Activity 不再有表現(xiàn)邏輯的部分，Activity 作為 View 的角色只處理和 UI 有關(guān)的事情畅涂。但還是存在一些缺點(diǎn)：

• 雙向依賴： View 和 Presenter 是雙向依賴的港华，一旦 View 層做出改變，相應(yīng)地 Presenter 也需要做出調(diào)整午衰。在業(yè)務(wù)語境下立宜，View 層變化是大概率事件；
• 內(nèi)存泄漏風(fēng)險(xiǎn)： Presenter 持有 View 層的引用臊岸，當(dāng)用戶關(guān)閉了 View 層橙数，但 Model 層仍然在進(jìn)行耗時(shí)操作，就會有內(nèi)存泄漏風(fēng)險(xiǎn)帅戒。雖然有解決辦法灯帮，但還是存在風(fēng)險(xiǎn)點(diǎn)和復(fù)雜度（弱引用 / onDestroy() 回收 Presenter）。
• 協(xié)議接口類膨脹： View 層和 Presenter 層的交互需要定義接口方法逻住，當(dāng)交互非常復(fù)雜時(shí)钟哥，需要定義很多接口方法和回調(diào)方法，也不好維護(hù)瞎访。

3. MVVM

MVVM 模式改動(dòng)在于中間的 Presenter 改為 ViewModel腻贰，MVVM 同樣將代碼劃分為三個(gè)部分：

• View： Activity 和 Layout XML 文件，與 MVP 中 View 的概念相同装诡；
• Model： 負(fù)責(zé)管理業(yè)務(wù)數(shù)據(jù)邏輯银受，如網(wǎng)絡(luò)請求践盼、數(shù)據(jù)庫處理鸦采，與 MVP 中 Model 的概念相同宾巍；
• ViewModel： 存儲視圖狀態(tài)，負(fù)責(zé)處理表現(xiàn)邏輯渔伯，并將數(shù)據(jù)設(shè)置給可觀察數(shù)據(jù)容器顶霞。

在實(shí)現(xiàn)細(xì)節(jié)上，View 和 Presenter 從雙向依賴變成 View 可以向 ViewModel 發(fā)指令锣吼，但 ViewModel 不會直接向 View 回調(diào)选浑，而是讓 View 通過觀察者的模式去監(jiān)聽數(shù)據(jù)的變化，有效規(guī)避了 MVP 雙向依賴的缺點(diǎn)玄叠。但 MVVM 本身也存在一些缺點(diǎn)：

• 多數(shù)據(jù)流： View 與 ViewModel 的交互分散古徒，缺少唯一修改源，不易于追蹤读恃；
• LiveData 膨脹： 復(fù)雜的頁面需要定義多個(gè) MutableLiveData隧膘，并且都需要暴露為不可變的 LiveData。

DataBinding寺惫、ViewModel 和 LiveData 等組件是 Google 為了幫助我們實(shí)現(xiàn) MVVM 模式提供的架構(gòu)組件疹吃，它們并不是 MVVM 的本質(zhì)，只是實(shí)現(xiàn)上的工具西雀。

• Lifecycle： 生命周期狀態(tài)回調(diào)萨驶；
• LiveData： 可觀察的數(shù)據(jù)存儲類；
• databinding： 可以自動(dòng)同步 UI 和 data艇肴，不用再 findviewById()腔呜；
• ViewModel： 存儲界面相關(guān)的數(shù)據(jù)，這些數(shù)據(jù)不會在手機(jī)旋轉(zhuǎn)等配置改變時(shí)丟失再悼。

4. MVI

MVI 模式的改動(dòng)在于將 View 和 ViewModel 之間的多數(shù)據(jù)流改為基于 ViewState 的單數(shù)據(jù)流育谬。MVI 將代碼分為以下四個(gè)部分：

• View： Activity 和 Layout XML 文件，與 MVVM 中 View 的概念相同帮哈；
• Intent： 定義數(shù)據(jù)操作膛檀，是將數(shù)據(jù)傳到 Model 的唯一來源，相比 MVVM 是新的概念娘侍；
• ViewModel： 存儲視圖狀態(tài)咖刃，負(fù)責(zé)處理表現(xiàn)邏輯，并將 ViewState 設(shè)置給可觀察數(shù)據(jù)容器憾筏；
• ViewState： 一個(gè)數(shù)據(jù)類嚎杨，包含頁面狀態(tài)和對應(yīng)的數(shù)據(jù)。

在實(shí)現(xiàn)細(xì)節(jié)上氧腰，View 和 ViewModel 之間的多個(gè)交互（多 LiveData 數(shù)據(jù)流）變成了單數(shù)據(jù)流枫浙。無論 View 有多少個(gè)視圖狀態(tài)刨肃，只需要訂閱一個(gè) ViewState 便可以獲取所有狀態(tài)，再根據(jù) ViewState 去響應(yīng)箩帚。當(dāng)然真友，實(shí)踐中應(yīng)該根據(jù)狀態(tài)之間的關(guān)聯(lián)程度來決定數(shù)據(jù)流的個(gè)數(shù)，不應(yīng)該為了使用 MVI 模式而強(qiáng)行將多個(gè)無關(guān)的狀態(tài)壓縮在同一個(gè)數(shù)據(jù)流中紧帕。

• 唯一可信源： 數(shù)據(jù)只有一個(gè)來源（ViewModel）盔然，與 MVVM 的思想相同；
• 單數(shù)據(jù)流： View 和 ViewModel 之間只有一個(gè)數(shù)據(jù)流是嗜，只有一個(gè)地方可以修改數(shù)據(jù)愈案，確保數(shù)據(jù)是安全穩(wěn)定的。并且 View 只需要訂閱一個(gè) ViewState 就可以獲取所有狀態(tài)和數(shù)據(jù)鹅搪，相比 MVVM 是新的特性站绪；
• 響應(yīng)式： ViewState 包含頁面當(dāng)前的狀態(tài)和數(shù)據(jù)，View 通過訂閱 ViewState 就可以完成頁面刷新丽柿，相比于 MVVM 是新的特性恢准。

但 MVI 本身也存在一些缺點(diǎn)：

• State 膨脹： 所有視圖變化都轉(zhuǎn)換為 ViewState，還需要管理不同狀態(tài)下對應(yīng)的數(shù)據(jù)航厚。實(shí)踐中應(yīng)該根據(jù)狀態(tài)之間的關(guān)聯(lián)程度來決定使用單流還是多流顷歌；
• 內(nèi)存開銷： ViewState 是不可變類，狀態(tài)變更時(shí)需要?jiǎng)?chuàng)建新的對象幔睬，存在一定內(nèi)存開銷眯漩；
• 局部刷新： View 根據(jù) ViewState 響應(yīng)，不易實(shí)現(xiàn)局部 Diff 刷新麻顶，可以使用 Flow#distinctUntilChanged() 來刷新來減少不必要的刷新赦抖。

不過，MVI 并不是一個(gè)全新的設(shè)計(jì)模式辅肾，其背后設(shè)計(jì)理念與 Redux 模式如出一轍队萤。在 Redux 里完全可以找到與 MVI 相同的各個(gè)要素，而且明顯 Redux 的命名方式更加清晰無歧義矫钓，小伙伴們知道 Model - View - Intent 這個(gè)命名方式的原始出處的話要尔，可以告訴我一聲。

• View - View
• Action - Intent
• Store - ViewModel
• State - ViewState
• Reducer - Model

// 1新娜、ViewModel
class MainViewModel: ViewModel() {

    private val mModel = MainModel()

    val mIntent = Channel<MainIntent>(Channel.UNLIMITED)

    private val _state = MutableStateFlow<MainViewState>(MainViewState.Idle)
    val state: StateFlow<MainViewState>
        get() = _state

    init {
        viewModelScope.launch {
            mIntent.consumeAsFlow().collect {
                when (it) {
                    is MainIntent.FetchNew -> fetchNews()
                }
            }
        }
    }

    private fun fetchNews() {
        viewModelScope.launch {
            _state.value = MainViewState.Loading
            _state.value = try {
                MainViewState.News(mModel.fetchNews())
            } catch (e: Exception) {
                MainViewState.Error(e.localizedMessage)
            }
        }
    }
}

// 2赵辕、ViewState
sealed class MainViewState {
    object Idle : MainViewState()
    object Loading : MainViewState()
    data class News(val news: List<New>) : MainViewState()
    data class Error(val error: String?) : MainViewState()

}
// 3、Intent
sealed class MainIntent {
    object FetchNew : MainIntent()
}
// 4概龄、View
class MainActivity : AppCompatActivity() {

    private lateinit var mainViewModel: MainViewModel

    private fun observeViewModel() {
        lifecycleScope.launch {
            mainViewModel.state.collect {
                when (it) {
                    is MainViewState.Idle -> {

                    }
                    is MainViewState.Loading -> {
                    }

                    is MainViewState.News -> {
                        renderList(it.news)
                    }
                    is MainViewState.Error -> {
                    }
                }
            }
        }
    }

    private fun renderList(news: List<New>) {
        // do something
    }
}
復(fù)制代碼

5. MVP还惠、MVVM 和 MVI 的對比

MVVM 和 MVP 的思想是相同的，最本質(zhì)的概念就是 Activity 里做的事情太多了私杜，所以要把 Activity 中與 UI 無關(guān)的部分抽離出來蚕键，交給別人做救欧。這個(gè) “別人” 在 MVP 里叫作 Presenter，在 MVVM 里叫作 ViewModel锣光。而不論是 MVP 中的約定接口笆怠，還是 ViewModel 里的觀察者模式，這些都是實(shí)現(xiàn)上的細(xì)節(jié)而已嫉晶。

MVI 與前者的主要區(qū)別不在于強(qiáng)調(diào)嚴(yán)格的單向數(shù)據(jù)流皂岔，而在于從命令式的開發(fā)模式兜蠕，轉(zhuǎn)變?yōu)轫憫?yīng)式的開發(fā)模式恶座。我們并不是說越新潮罚屋，越復(fù)雜的架構(gòu)就是最好的商蕴，只有合適的架構(gòu)才是最好的汤功。但是不可否認(rèn)艺晴，從 React 到 Flutter庶艾，從 MVI 到 Compose兽赁，響應(yīng)式編程似乎有一統(tǒng)天下的趨勢状答。未來會怎么樣，我們拭目以待刀崖。

參考資料

• iPlayground 2019 | 漫談 iOS 架構(gòu)：MVC / MVVM / VIPER 與 Redux —— Nelson 著
• 關(guān)于MVC/MVP/MVVM的一些錯(cuò)誤認(rèn)識 —— wfwf 著
• MVVM 進(jìn)階版：MVI 架構(gòu)了解一下~ - 掘金 —— 程序員江同學(xué) 著
• MVI 架構(gòu)更佳實(shí)踐：支持 LiveData 屬性監(jiān)聽 - 掘金 —— 程序員江同學(xué) 著