前言

為了優化代碼設計，業界先后提出了 MVC、MVP、MVVM 和 MVI 等架構設計。這四個模式討論是 “如何管理 UI” 這個話題，采用的手段都是 “關注點分離”，只是實現的細節不同。最開始是沒有采用任何模式的狀態，不管是視圖代碼還是表現邏輯全都寫在 Activity 里面，很明顯這樣的代碼耦合度非常高，難以進行維護和測試，可讀性也不好。

提示：耦合度高是現象，關注點分離是手段，易維護性和易測試性是結果，模式是可復用的經驗。

1. MVC

MVC 其實是 Android 默認的設計，MVC 里將代碼分為三個部分：

• View： Layout XML 文件；
• Model： 負責管理業務數據邏輯，如網絡請求、數據庫處理；
• Controller： Activity 負責處理表現邏輯。

MVC 初步解決了 Activity 代碼太多的問題，但也有缺點：我們的初衷 Activity / Fragment 是只處理表現邏輯的部分 ，但現實是 Activity 天然不可避免要處理 UI，也要處理用戶交互，說明 Activity 本身天然承擔了 View 的角色。那么這個架構就會造成 Activity 里糅合了視圖和業務的代碼，分離程度不夠。

2. MVP

為了將 Activity 中的表現邏輯徹底分離出來，業界提出了 MVP 的設計。MVP 同樣將代碼劃分為三個部分：

• View： Activity 和 Layout XML 文件；
• Model： 負責管理業務數據邏輯，如網絡請求、數據庫處理；
• Presenter： 負責處理表現邏輯。

在實現細節上，View 和 Presenter 中間會定義一個協議接口 Contract，這個接口會約定 View 如何向 Presenter 發指令和 Presenter 如何 Callback 給 View。這樣的架構里 Activity 不再有表現邏輯的部分，Activity 作為 View 的角色只處理和 UI 有關的事情。但還是存在一些缺點：

• 雙向依賴： View 和 Presenter 是雙向依賴的，一旦 View 層做出改變，相應地 Presenter 也需要做出調整。在業務語境下，View 層變化是大概率事件；
• 內存泄漏風險： Presenter 持有 View 層的引用，當用戶關閉了 View 層，但 Model 層仍然在進行耗時操作，就會有內存泄漏風險。雖然有解決辦法，但還是存在風險點和復雜度（弱引用 / onDestroy() 回收 Presenter）。
• 協議接口類膨脹： View 層和 Presenter 層的交互需要定義接口方法，當交互非常復雜時，需要定義很多接口方法和回調方法，也不好維護。

3. MVVM

MVVM 模式改動在于中間的 Presenter 改為 ViewModel，MVVM 同樣將代碼劃分為三個部分：

• View： Activity 和 Layout XML 文件，與 MVP 中 View 的概念相同；
• Model： 負責管理業務數據邏輯，如網絡請求、數據庫處理，與 MVP 中 Model 的概念相同；
• ViewModel： 存儲視圖狀態，負責處理表現邏輯，并將數據設置給可觀察數據容器。

在實現細節上，View 和 Presenter 從雙向依賴變成 View 可以向 ViewModel 發指令，但 ViewModel 不會直接向 View 回調，而是讓 View 通過觀察者的模式去監聽數據的變化，有效規避了 MVP 雙向依賴的缺點。但 MVVM 本身也存在一些缺點：

• 多數據流： View 與 ViewModel 的交互分散，缺少唯一修改源，不易于追蹤；
• LiveData 膨脹： 復雜的頁面需要定義多個 MutableLiveData，并且都需要暴露為不可變的 LiveData。

DataBinding、ViewModel 和 LiveData 等組件是 Google 為了幫助我們實現 MVVM 模式提供的架構組件，它們并不是 MVVM 的本質，只是實現上的工具。

• Lifecycle： 生命周期狀態回調；
• LiveData： 可觀察的數據存儲類；
• databinding： 可以自動同步 UI 和 data，不用再 findviewById()；
• ViewModel： 存儲界面相關的數據，這些數據不會在手機旋轉等配置改變時丟失。

4. MVI

MVI 模式的改動在于將 View 和 ViewModel 之間的多數據流改為基于 ViewState 的單數據流。MVI 將代碼分為以下四個部分：

• View： Activity 和 Layout XML 文件，與 MVVM 中 View 的概念相同；
• Intent： 定義數據操作，是將數據傳到 Model 的唯一來源，相比 MVVM 是新的概念；
• ViewModel： 存儲視圖狀態，負責處理表現邏輯，并將 ViewState 設置給可觀察數據容器；
• ViewState： 一個數據類，包含頁面狀態和對應的數據。

在實現細節上，View 和 ViewModel 之間的多個交互（多 LiveData 數據流）變成了單數據流。無論 View 有多少個視圖狀態，只需要訂閱一個 ViewState 便可以獲取所有狀態，再根據 ViewState 去響應。當然，實踐中應該根據狀態之間的關聯程度來決定數據流的個數，不應該為了使用 MVI 模式而強行將多個無關的狀態壓縮在同一個數據流中。

• 唯一可信源： 數據只有一個來源（ViewModel），與 MVVM 的思想相同；
• 單數據流： View 和 ViewModel 之間只有一個數據流，只有一個地方可以修改數據，確保數據是安全穩定的。并且 View 只需要訂閱一個 ViewState 就可以獲取所有狀態和數據，相比 MVVM 是新的特性；
• 響應式： ViewState 包含頁面當前的狀態和數據，View 通過訂閱 ViewState 就可以完成頁面刷新，相比于 MVVM 是新的特性。

但 MVI 本身也存在一些缺點：

• State 膨脹： 所有視圖變化都轉換為 ViewState，還需要管理不同狀態下對應的數據。實踐中應該根據狀態之間的關聯程度來決定使用單流還是多流；
• 內存開銷： ViewState 是不可變類，狀態變更時需要創建新的對象，存在一定內存開銷；
• 局部刷新： View 根據 ViewState 響應，不易實現局部 Diff 刷新，可以使用 Flow#distinctUntilChanged() 來刷新來減少不必要的刷新。

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

• 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
    }
}
復制代碼

5. MVP、MVVM 和 MVI 的對比

MVVM 和 MVP 的思想是相同的，最本質的概念就是 Activity 里做的事情太多了，所以要把 Activity 中與 UI 無關的部分抽離出來，交給別人做。這個 “別人” 在 MVP 里叫作 Presenter，在 MVVM 里叫作 ViewModel。而不論是 MVP 中的約定接口，還是 ViewModel 里的觀察者模式，這些都是實現上的細節而已。

MVI 與前者的主要區別不在于強調嚴格的單向數據流，而在于從命令式的開發模式，轉變為響應式的開發模式。我們并不是說越新潮，越復雜的架構就是最好的，只有合適的架構才是最好的。但是不可否認，從 React 到 Flutter，從 MVI 到 Compose，響應式編程似乎有一統天下的趨勢。未來會怎么樣，我們拭目以待。

參考資料

• iPlayground 2019 | 漫談 iOS 架構：MVC / MVVM / VIPER 與 Redux —— Nelson 著
• 關于MVC/MVP/MVVM的一些錯誤認識 —— wfwf 著
• MVVM 進階版：MVI 架構了解一下~ - 掘金 —— 程序員江同學 著
• MVI 架構更佳實踐：支持 LiveData 屬性監聽 - 掘金 —— 程序員江同學 著