這是 MVI 架構(gòu)的第三篇，系列文章目錄如下：

Android 架構(gòu)之 MVI 雛形 | 響應(yīng)式編程 + 單向數(shù)據(jù)流 + 唯一可信數(shù)據(jù)源

Android 架構(gòu)之 MVI 初級體 | Flow 替換 LiveData 重構(gòu)數(shù)據(jù)鏈路

Android 架構(gòu)之 MVI 完全體 | 重新審視 MVVM 之殤，PartialChange & Reducer 來拯救

Android 架構(gòu)之 MVI 究極體 | 狀態(tài)和事件分道揚鑣，粘性不再是問題其中第一篇剖析了 MVI 的概念，第二篇是 MVI 在項目實戰(zhàn)中的初級應(yīng)用，而這一篇將重構(gòu)上篇的代碼，以展示 MVI 的完全體。

MVI 架構(gòu)有三大關(guān)鍵詞：“唯一可信數(shù)據(jù)源”+“單向數(shù)據(jù)流”+“響應(yīng)式編程”，以及一些關(guān)鍵概念，比如Intent,State。理解這些概念之后，能更輕松地閱讀本文。（強烈建議從第一篇開始閱讀）

引子

在上一篇中，用 MVI 重構(gòu)了“新聞流”這個業(yè)務(wù)場景。本篇在此基礎(chǔ)上進一步拓展，引入 MVI 中兩個重要的概念PartialChange和Reducer。

假設(shè)“新聞流”這個業(yè)務(wù)場景，用戶可以觸發(fā)如下行為：

初始化新聞流

上拉加載更多新聞

舉報某條新聞

在 MVVM 中，這些行為被表達為 ViewModel 的一個方法調(diào)用。在 MVI 中被稱為意圖Intent，它們不再是一個方法調(diào)用，而是一個數(shù)據(jù)。通?？杀贿@樣定義：

sealedclassFeedsIntent{dataclassInit(valtype:Int,valcount:Int):FeedsIntent()dataclassMore(valtimestamp:Long,valcount:Int):FeedsIntent()dataclassReport(valid:Long):FeedsIntent()}

這樣做使得界面意圖都以數(shù)據(jù)的形式流入到一個流中，好處是，可以用流的方式統(tǒng)一管理所有意圖。更詳細的講解可以點擊Android 架構(gòu)之 MVI | 響應(yīng)式編程 + 單向數(shù)據(jù)流 + 唯一可信數(shù)據(jù)源。

產(chǎn)品文檔定義了所有的用戶意圖Intent，而設(shè)計稿定義了所有的界面狀態(tài)State：

dataclassNewsState(valdata:List<News>,// 新聞列表valisLoading:Boolean,// 是否正在首次加載valisLoadingMore:Boolean,// 是否正在上拉加載更多valerrorMessage:String,// 加載錯誤信息 toastvalreportToast:String,// 舉報結(jié)果 toast){companionobject{// 新聞流的初始狀態(tài)valinitial=NewsState(data=emptyList(),isLoading=true,isLoadingMore=false,errorMessage="",reportToast="")}}

在 MVI 中，把界面的一次展示理解為單個 State 的一次渲染。相較于 MVVM 中一個界面可能被分拆為多個 LiveData，State 這種唯一數(shù)據(jù)源降低了復(fù)雜度，使得代碼容易維護。

有了 Intent 和 State，整個界面刷新的過程就形成了一條單向數(shù)據(jù)流，如下圖所示：

MVI 就是用“響應(yīng)式編程”的方式將這條數(shù)據(jù)流中的若干 Intent 轉(zhuǎn)換成唯一 State。初級的轉(zhuǎn)換方式是直接將 Intent 映射成 State，詳細分析可以點擊如何把業(yè)務(wù)代碼越寫越復(fù)雜？（二）| Flow 替換 LiveData 重構(gòu)數(shù)據(jù)鏈路，更加 MVI。

PartialChange

理論上 Intent 是無法直接轉(zhuǎn)換為 State 的。因為 Intent 只表達了用戶觸發(fā)的行為，而行為產(chǎn)生的結(jié)果才對應(yīng)一個 State。更具體的說，“上拉加載更多新聞”可能產(chǎn)生三個結(jié)果：

正在加載更多新聞。

加載更多新聞成功。

加載更多新聞失敗。

其中每一個結(jié)果都對應(yīng)一個 State?！皢蜗驍?shù)據(jù)流”內(nèi)部的數(shù)據(jù)變換詳情如下：

每一個意圖會產(chǎn)生若干個結(jié)果，每個結(jié)果對應(yīng)一個界面狀態(tài)。

上圖看著有“很多條”數(shù)據(jù)流，但同一時間只可能有一條起作用。上圖看著會在 ViewModel 內(nèi)部形成各種 State，但暴露給界面的還是唯一 State。

因為所有意圖產(chǎn)生的所有可能的結(jié)果都對應(yīng)于一個唯一 State 實例，所以每個意圖產(chǎn)生的結(jié)果只引起 State 部分字段的變化。比如 Init.Success 只會影響 NewsState.data 和 NewsState.isLoading。

在 MVI 框架中，意圖 Intent 產(chǎn)生的結(jié)果稱為部分變化PartialChange。

總結(jié)一下：

MVI 框架中用數(shù)據(jù)流來理解界面刷新。

數(shù)據(jù)流的起點是界面發(fā)出的意圖（Intent），一個意圖會產(chǎn)生若干結(jié)果，它們稱為 PartialChange，一個 PartialChange 對應(yīng)一個 State 實例。

數(shù)據(jù)流的終點是界面對 State 的觀察而進行的一次渲染。

連續(xù)的狀態(tài)

界面展示的變化是“連續(xù)的”，即界面新狀態(tài)總是由上一次狀態(tài)變化而來。就像連環(huán)畫一樣，下一幀是基于上一幀的偏移量。

這種基于老狀態(tài)產(chǎn)生新狀態(tài)的行為稱為Reduce，用一個 lambda 表達即是(oldState: State) -> State。

界面發(fā)出的不同意圖會生成不同的結(jié)果，每種結(jié)果都有各自的方法進行新老狀態(tài)的變換。比如“上拉加載更多新聞”和“舉報新聞”，前者在老狀態(tài)的尾部追加數(shù)據(jù)，而后者是在老狀態(tài)中刪除數(shù)據(jù)。

基于此，Reduce 的 lambda 可作如下表達：(oldState: State, change: PartialChange) -> State，即新狀態(tài)由老狀態(tài)和 PartialChange 共同決定。

通常 PartialChange 被定義成密封接口，而 Reduce 定義為內(nèi)部方法：

// 新聞流的部分變化sealedinterfaceFeedsPartialChange{// 描述如何從老狀態(tài)變化為新狀態(tài)funreduce(oldState:NewsState):NewsState}

這是 PartialChange 的抽象定義，新聞流場景中，它應(yīng)該有三個實現(xiàn)類，分別是 Init，More，Report。其中 Init 的實現(xiàn)如下：

sealedclassInit:FeedsPartialChange{// 在初始化新聞流流場景下，老狀態(tài)如何變化成新狀態(tài)overridefunreduce(oldState:NewsState):NewsState=// 對初始化新聞流能產(chǎn)生的所有結(jié)果分類討論，并基于老狀態(tài)拷貝構(gòu)建新狀態(tài)when(this){Loading->oldState.copy(isLoading=true)isSuccess->oldState.copy(data=news,//方便地訪問Success攜帶的數(shù)據(jù)isLoading=false,isLoadingMore=false,errorMessage="")isFail->oldState.copy(data=emptyList(),isLoading=false,isLoadingMore=false,errorMessage=error)}// 加載中objectLoading:Init()// 加載成功dataclassSuccess(valnews:List<News>):Init()// 加載失敗dataclassFail(valerror:String):Init()}

初始化新聞流的 PartialChange 也被實現(xiàn)為密封的，密封產(chǎn)生的效果是，在編譯時，其子類的全集就已經(jīng)全部確定，不允許在運行時動態(tài)新增子類，且所有子類必須內(nèi)聚在一個包名下。

這樣做的好處是降低界面刷新的復(fù)雜度，即有限個 Intent 會產(chǎn)生有限個 PartialChange，且它們唯一對應(yīng)一個 State。出 bug 的時候只需從三處找問題：1. Intent 是否發(fā)射？ 2. 是否生成了既定的 PartialChange？ 3. reduce 算法是否有問題？

將 reduce 算法定義在 PartialChange 內(nèi)部，就能很方便地獲取 PartialChange 攜帶的數(shù)據(jù)，并基于它構(gòu)建新狀態(tài)。

用同樣的思路，More 和 Report 的定義如下：

sealedclassMore:FeedsPartialChange{overridefunreduce(oldState:NewsState):NewsState=when(this){Loading->oldState.copy(isLoading=false,isLoadingMore=true,errorMessage="")isSuccess->oldState.copy(data=oldState.data+news,// 新數(shù)據(jù)追加在老數(shù)據(jù)后isLoading=false,isLoadingMore=false,errorMessage="")isFail->oldState.copy(isLoadingMore=false,isLoading=false,errorMessage=error)}objectLoading:More()dataclassSuccess(valnews:List<News>):More()dataclassFail(valerror:String):More()}sealedclassReport:FeedsPartialChange{overridefunreduce(oldState:NewsState):NewsState=when(this){isSuccess->oldState.copy(// 在老數(shù)據(jù)中刪除舉報新聞data=oldState.data.filterNot{it.id==id},reportToast="舉報成功")Fail->oldState.copy(reportToast="舉報失敗")}classSuccess(valid:Long):Report()objectFail:Report()}

狀態(tài)的變換

Intent，PartialChange，Reduce，State 定義好了，是時候看看如何用流的方式把它們串聯(lián)起來！

總體來說，狀態(tài)是這樣變換的：Intent -> PartialChange -(Reduce)-> State

1. Intent 流入，State 流出

classStateFlowActivity:AppCompatActivity(){privatevalnewsViewModelbylazy{ViewModelProvider(this,NewsViewModelFactory(NewsRepo(this)))[NewsViewModel::class.java]}// 將所有意圖通過 merge 進行合流privatevalintentsbylazy{merge(flowOf(FeedsIntent.Init(1,5)),// 初始化新聞loadMoreFlow(),// 加載更多新聞reportFlow()// 舉報新聞)}// 將上拉加載更多轉(zhuǎn)換成數(shù)據(jù)流privatefunloadMoreFlow()=callbackFlow{recyclerView.setOnLoadMoreListener{trySend(FeedsIntent.More(111L,2))}awaitClose{recyclerView.removeOnLoadMoreListener(null)}}// 將舉報新聞轉(zhuǎn)換成數(shù)據(jù)流privatefunreportFlow()=callbackFlow{reportView.setOnClickListener{valnews=newsAdapter.dataList[i]as?News? ? ? ? ? ? news?.id?.let{trySend(FeedsIntent.Report(it))}}awaitClose{reportView.setOnClickListener(null)}}overridefunonCreate(savedInstanceState:Bundle?){super.onCreate(savedInstanceState)setContentView(contentView)// 訂閱意圖流intents// Intent 流入 ViewModel.onEach(newsViewModel::send).launchIn(lifecycleScope)// 訂閱狀態(tài)流newsViewModel.newState// State 流出 ViewModel，并繪制界面.collectIn(this){showNews(it)}}}classNewsViewModel(privatevalnewsRepo:NewsRepo):ViewModel(){// 用于接收意圖的 SharedFlowprivateval_feedsIntent=MutableSharedFlow<FeedsIntent>()// 意圖被變換為狀態(tài)valnewState=_feedsIntent.map{}// 偽代碼，省略了 將 Intent 變換為 State 的細節(jié)// 將意圖發(fā)送到流funsend(intent:FeedsIntent){viewModelScope.launch{_feedsIntent.emit(intent)}}}

界面可以發(fā)出的所有意圖都被組織到一個流中，并且羅列在一起。intents流可以作為理解業(yè)務(wù)邏輯的入口。同時 ViewModel 提供了一個 State 流，供界面訂閱。

2. Intent -> PartialChange

classNewsViewModel(privatevalnewsRepo:NewsRepo):ViewModel(){privateval_feedsIntent=MutableSharedFlow<FeedsIntent>()// 供界面觀察的唯一狀態(tài)valnewState=_feedsIntent.toPartialChangeFlow().flowOn(Dispatchers.IO).stateIn(viewModelScope,SharingStarted.Eagerly,NewsState.initial))}

各種 Intent 轉(zhuǎn)換為 PartialChange 的邏輯被封裝在toPartialChangeFlow()中：

// NewsViewModel.kt// 將 Intent 流變換為 PartialChange 流privatefunFlow<FeedsIntent>.toPartialChangeFlow():Flow<FeedsPartialChange>=merge(// 過濾出初始化新聞意圖并將其變換為對應(yīng)的 PartialChangefilterIsInstance<FeedsIntent.Init>().flatMapConcat{it.toPartialChangeFlow()},// 過濾出上拉加載更多意圖并將其變換為對應(yīng)的 PartialChangefilterIsInstance<FeedsIntent.More>().flatMapConcat{it.toPartialChangeFlow()},// 過濾出舉報新聞意圖并將其變換為對應(yīng)的 PartialChangefilterIsInstance<FeedsIntent.Report>().flatMapConcat{it.toPartialChangeFlow()},)

toPartialChangeFlow() 被定義為擴展方法。

filterIsInstance() 用于過濾出Flow<FeedsIntent>中的子類型并分類討論，因為每種 Intent 變換為 PartialChange 的方式有所不同。

最后用 merge 進行合流，它會將每個 Flow 中的數(shù)據(jù)合起來并發(fā)地轉(zhuǎn)發(fā)到一個新的流上。merge + filterIsInstance的組合相當(dāng)于流中的 if-else。

其中的 toPartialChangeFlow() 是各種意圖的擴展方法：

// NewsViewModel.ktprivatefunFeedsIntent.Init.toPartialChangeFlow()=flowOf(// 本地數(shù)據(jù)庫新聞newsRepo.localNewsOneShotFlow,// 網(wǎng)絡(luò)新聞newsRepo.remoteNewsFlow(this.type.toString(),this.count.toString()))// 并發(fā)合流.flattenMerge().transformWhile{emit(it.news)!it.abort}// 將新聞數(shù)據(jù)變換為成功或失敗的 PartialChange.map{news->if(news.isEmpty())Init.Fail("no news")elseInit.Success(news)}// 發(fā)射展示 Loading 的 PartialChange.onStart{emit(Init.Loading)}

該擴展方法描述了如何將 FeedsIntent.Init 變換為對應(yīng)的 PartialChange。同樣地，F(xiàn)eedsIntent.More 和 FeedsIntent.Report 的變換邏輯如下：

// NewsViewModel.ktprivatefunFeedsIntent.More.toPartialChangeFlow()=newsRepo.remoteNewsFlow("news","10").map{news->if(it.news.isEmpty())More.Fail("no more news")elseMore.Success(it.news)}.onStart{emit(More.Loading)}.catch{emit(More.Fail("load more failed by xxx"))}privatefunFeedsIntent.Report.toPartialChangeFlow()=newsRepo.reportNews(id).map{if(it>=0L)Report.Success(it)elseReport.Fail}.catch{emit((Report.Fail))}

3. PartialChange -(Reduce)-> State

經(jīng)過 toPartialChangeFlow() 的變換，現(xiàn)在流中流動的數(shù)據(jù)是各種類型的 PartialChange。接下來就要將其變換為 State：

// NewsViewModel.ktvalnewState=_feedsIntent.toPartialChangeFlow()// 將 PartialChange 變換為 State.scan(NewsState.initial){oldState,partialChange->partialChange.reduce(oldState)}.flowOn(Dispatchers.IO).stateIn(viewModelScope,SharingStarted.Eagerly,NewsState.initial))

使用scan()進行變換：

// 從 Flow<T> 變換為 Flow<R>publicfun<T,R>Flow<T>.scan(initial:R,// 初始值operation:suspend(accumulator:R,value:T)->R// 累加算法):Flow<R>=runningFold(initial,operation)publicfun<T,R>Flow<T>.runningFold(initial:R,operation:suspend(accumulator:R,value:T)->R):Flow<R>=flow{// 累加器varaccumulator:R=initialemit(accumulator)collect{value->// 進行累加accumulator=operation(accumulator,value)// 向下游發(fā)射累加值emit(accumulator)}}

從 scan() 的簽名看，是將一個流變換為另一個流，看似和 map() 相似。但它的變換算法是帶累加的。用 lambda 表達為(accumulator: R, value: T) -> R。

這不正好就是上面提到的 Reduce 嗎！即基于老狀態(tài)和新 PartialChange 生成新狀態(tài)。

MVVM 和 MVI 復(fù)雜度比拼

就新聞流這個場景，用圖來對比下 MVVM 和 MVI 復(fù)雜度的區(qū)別。

這張圖表達了三種復(fù)雜度：

View 發(fā)起請求的復(fù)雜度：ViewModel 的各種方法調(diào)用會散落在界面不同地方。即界面向 ViewModel 發(fā)起請求沒有統(tǒng)一入口。

View 觀察數(shù)據(jù)的復(fù)雜度：界面需要觀察多個 ViewModel 提供的數(shù)據(jù)，這導(dǎo)致界面狀態(tài)的一致性難以維護。

ViewModel 內(nèi)部請求和數(shù)據(jù)關(guān)系的復(fù)雜度：數(shù)據(jù)被定義為 ViewModel 的成員變量。成員變量是增加復(fù)雜度的利器，因為它可以被任何成員方法訪問。也就是說，新增業(yè)務(wù)對成員變量的修改可能影響老業(yè)務(wù)的界面展示。同理，當(dāng)界面展示出錯時，也很難一下子定位到是哪個請求造成的。

再來看一下讓人耳目一新的 MVI 吧：

完美化解上述三個沒有必要的復(fù)雜度。

總之，用上 MVI 后，新需求不再破壞老邏輯，出 bug 了能更快速定位到問題。

敬請期待

還有一個問題有待解決，那就是 MVI 框架下，刷新界面時持久性狀態(tài) State 和 一次性事件 Event 的區(qū)別對待。

在 MVVM 中，因為 LiveData 的粘性，導(dǎo)致一次性事件被界面多次消費。對此有多種解決方案。詳情可點擊LiveData 面試題庫、解答、源碼分析

但 MVI 的解題思路略有不同，限于篇幅原因，只能下回分析，歡迎持續(xù)關(guān)注~

總結(jié)

MVI 框架中用單向數(shù)據(jù)流來理解界面刷新。整個數(shù)據(jù)流中包含的數(shù)據(jù)依次如下：Intent，PartialChange，State

數(shù)據(jù)流的起點是界面發(fā)出的意圖（Intent），一個意圖會產(chǎn)生若干結(jié)果，它們稱為 PartialChange，一個 PartialChange 對應(yīng)一個 State 實例。

數(shù)據(jù)流的終點是界面對 State 的觀察而進行的一次渲染。

MVI 就是用“響應(yīng)式編程”的方式將單向數(shù)據(jù)流中的若干 Intent 轉(zhuǎn)換成唯一 State。

MVI 強調(diào)的單向數(shù)據(jù)流表現(xiàn)在兩個層面：

View 和 ViewModel 交互過程中的單向數(shù)據(jù)流：單個Intent流流入 ViewModel，單個State流流出 ViewModel。

ViewModel 內(nèi)部數(shù)據(jù)變換的單向數(shù)據(jù)流：Intent 變換為多個 PartialChange，一個 PartialChange 對應(yīng)一個 State。

Talk is cheap, show me the code

完整代碼可以從這個地址克隆。