引子
该系列基于“新闻流”进行 MVI 架构改造。在该业务场景中，界面可以发出 3 种意图，分别是1. 初始化新闻流 2.上拉加载更多新闻 3. 举报新闻。
MVI 框架中用“单向数据流”来理解界面刷新。
- 数据流的起点是界面发出的意图（Intent），意图流入 ViewModel 持有的 Flow。
- 数据流的终点是界面观察的状态（State），ViewModel 会提供一个“唯一数据源”供界面观察。 这样就形成如下的图景：
其中的“唯一数据源”是关键。即用一个 State 实例表达整个界面的状态。而不是像 MVVM 中用 N 个 LiveData 拼凑出完整的界面。
上图省略了 Intent 变换成 State 的中间过程。因为 Intent 只表达了意图，而意图产生的结果才唯一对应一个 State：
意图产生的结果称为 PartialChange，它是 Intent 变换为 State 的纽带。
每一个新状态的产生都基于 PartialChange 和 老状态，即(oldState: State, change: PartialChange) -> State，这称为 Reduce。
所以 MVI 中“单向数据流”的完整表述如下：
界面的意图被抽象为数据
Intent，它是数据流的起点，从界面发出并流入 ViewModel 持有的 Flow。Intent 被变换成PartialChange，并借助于Reduce基于老状态生成新状态。数据流的终点是界面对 唯一 State 的观察而进行的一次渲染。
这是前三篇内容的归纳总结。若觉得云里雾里，或者对 Intent，PartialChange，Reduce，State 这些关键概念不甚理解，强烈建议从第一篇开始阅读，将有助于理解本文。
本篇将用分道扬镳的方式解决“粘性数据支持者”所带来的界面刷新问题。
粘性数据持有者之殇
在 MVVM 中，当使用 LiveData 控制 Toast 展示的时候，可能会发生 Toast 展示次数多于预期的情况。这是由于 LiveData 的粘性导致的，即“老值分发给新观察者”。关于这点的详细场景分析及解决方案可以点击LiveData 面试题库、解答、源码分析。
这个问题不是 MVVM 中独有的，MVI 中通常使用stateIn()将供界面观察的流转换为StateFlow：
class NewsViewModel: ViewModel() { val newState = // 意图流 _feedsIntent // 将意图流变换为 PartialChange 流 .toPartialChangeFlow() // 运用 Reduce 计算出新状态 .scan(NewsState.initial){oldState,change -> change.reduce(oldState)} .flowOn(Dispatchers.IO) // 将流转换为 StateFlow .stateIn(viewModelScope, SharingStarted.Eagerly, NewsState.initial) }
StateFlow 会将流中最新的一个数据缓存起来，若有新的观察者，缓存值会分发给它。所以它的语义和 LiveData 一样，也是粘性的。
事件 & 状态
为了解决粘性数据持有者的问题，需要将界面渲染的数据来源做一个区分：
- 事件 Event
- 状态 State
被称为状态的数据，生命周期会更长一点，只要界面还在展示，该类数据就该一直存在。因为界面需要多次消费它，比如下一次界面的刷新就得基于老状态生成新状态。
而被称为事件的数据，生命周期相对短一些，界面只需要消费它们一次就完了，比如 toast。
在新闻流的业务场景中，举报新闻的结果会以 toast 的形式展现。上一篇中，将该 toast 的内容表达为唯一数据源 NewsState 的成员变量：
data class NewsState( val data: List<News> = emptyList(), val isLoading: Boolean = false, val isLoadingMore: Boolean = false, val errorMessage: String = "", val reportToast: String = "", // 举报结果 ) { companion object { val initial = NewsState(isLoading = true) } }
界面通过观察唯一数据源进行渲染：
class StateFlowActivity : AppCompatActivity() { private val newsViewModel by lazy { ViewModelProvider( this, NewsViewModelFactory(NewsRepo(this)) )[NewsViewModel::class.java] } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(contentView) // 观察唯一数据源 newsViewModel.newState .collectIn(this) { showNews(it) } } private fun showNews(state: NewsState) { state.apply { if (isLoading) showLoading() else dismissLoading() if (isLoadingMore) showLoadingMore() else dismissLoadingMore() // 展示举报结果 if (reportToast.isNotEmpty()) Toast.makeText( this@StateFlowActivity, state.reportToast, Toast.LENGTH_SHORT ).show() if (errorMessage.isNotEmpty()) tv.text = state.errorMessage if (data.isNotEmpty()) newsAdapter2.dataList = state.data } } }
举报一条新闻，然后点击 Home，再次启动 App 时，toast 会再次展示。因为 StateFlow 将缓存的最新的 State 分发给了新的观察者。
举报新闻结果是一个事件，所以得把它从状态中去掉：
data class NewsState( val data: List<News> = emptyList(), val isLoading: Boolean = false, val isLoadingMore: Boolean = false, val errorMessage: String = "", // val reportToast: String = "", ) { companion object { val initial = NewsState(isLoading = true) } } class StateFlowActivity : AppCompatActivity() { private fun showNews(state: NewsState) { state.apply { if (isLoading) showLoading() else dismissLoading() if (isLoadingMore) showLoadingMore() else dismissLoadingMore() // if (reportToast.isNotEmpty()) Toast.makeText( // this@StateFlowActivity, // state.reportToast, // Toast.LENGTH_SHORT // ).show() if (errorMessage.isNotEmpty()) tv.text = state.errorMessage if (data.isNotEmpty()) newsAdapter2.dataList = state.data } } }
把举报新闻结果定义为事件：
sealed interface FeedsEvent { sealed interface Report : FeedsEvent { data class Result(val reportToast: String) : Report } }
FeedsIntent 表示新闻流中事件的超类型。目前它有一个子类 Report，表示举报新闻这个业务场景，该场景中的 Result 对应一次 toast 提示。
事件分流
原本的数据流是这样的：
现在期望实现这样的效果：
为此需要一个新的容器来承载 Event：
class NewsViewModel : ViewModel() { // 事件通道 private val eventChannel = Channel<FeedsEvent>() // 使界面可用流的方式消费事件通道的内容 val eventFlow = eventChannel.receiveAsFlow() }
Channel 是一个阻塞队列，其生产者和消费者都是协程。所以生产和消费的方法都是 suspend 的，而非阻塞的。
新闻流场景中，阻塞队列的生产者即是原先的数据流，而消费者是界面。
使用响应式编程的方式，可以非常方便地进行分流：
class NewsViewModel(private val newsRepo: NewsRepo) : ViewModel() { private val eventChannel = Channel<FeedsEvent>() val eventFlow = eventChannel.receiveAsFlow() val newState = _feedsIntent .toPartialChangeFlow() .sendEvent() // 分流 .scan(NewsState.initial) { oldState, partialChange -> partialChange.reduce(oldState) } .flowOn(Dispatchers.IO) .stateIn(viewModelScope, SharingStarted.Eagerly, NewsState.initial) // 对 PartialChange 流拦截并转发 private fun Flow<FeedsPartialChange>.sendEvent(): Flow<FeedsPartialChange> = onEach { partialChange -> // 只拦截和举报有关的数据，并变换为对应Event再转发 val event = when (partialChange) { is Report.Fail -> FeedsEvent.Report.Result("举报失败") is Report.Success -> FeedsEvent.Report.Result("举报成功") else -> return@onEach // 忽略和举报无关的数据 } // 转发 eventChannel.send(event) } }
使用onEach()方法可以方便地获取流上的每一个数据，此时流上的 Intent 已经被变换为 PartialChange，遂对其分类讨论，其中举报对应的 PartialChange 定义如下：
sealed interface FeedsPartialChange { fun reduce(oldState: NewsState): NewsState } sealed class Report : FeedsPartialChange { override fun reduce(oldState: NewsState): NewsState = when (this) { // 举报成功时，从新闻列表中删除举报新闻 is Success -> oldState.copy( data = oldState.data.filterNot { it.id == id }, ) // 举报失败后，保留原样 Fail -> oldState } // 举报成功 class Success(val id: Long) : Report() // 举报失败 object Fail : Report() }
并不是所有的 PartialChange 都对应一个事件，当前业务场景中只有一个事件，那就是举报结果的 toast 提示。所以在 onEach() 中只过滤出和举报相关的 PartialChange 并将其变换为对应的 FeedsEvent，最后将其转发到通道。
界面通过观察通道来进行 toast 的展示：
class StateFlowActivity : AppCompatActivity() { private val newsViewModel by lazy { ViewModelProvider( this, NewsViewModelFactory(NewsRepo(this)) )[NewsViewModel::class.java] } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(contentView) newsViewModel.eventFlow.collectIn(this) { showEvent(it) } } private fun showEvent(event: FeedsEvent) { when (event) { is FeedsEvent.Report.Result -> Toast.makeText( this@StateFlowActivity, event.reportToast, Toast.LENGTH_SHORT ).show() } } }
总结
将界面渲染的数据区分为状态是和事件，并以响应式编程的方式对事件类型的数据进行拦截，变换，转发以实现状态和事件的区别对待，最终解决粘性数据持有者引起的界面刷新问题。
就新闻流这个业务场景来说，其对应的 MVI 究极形态如下图所示：
举报新闻这个意图会产生两个结果，其中举报成功会同时产生一个 State 和 一个 Event，分别对应删除举报新闻，和 toast 提示。
不得不承认，该图比上一篇，又稍稍复杂了一点。
MVI 的确引入了一些新的复杂度，包括 Intent，PartialChange，Reduce，State，Event。若使用 MVVM 架构都不需要手写这些类。
就好比设计模式，通常是通过增加一层抽象来进行解耦，提供扩展性。
评判一种架构好坏的指标，是不是可以像ROI一样，看投入产出比，即新增的复杂度，是否带来了与之匹配的收益。在架构层面，收益可以有“解耦”，“增加扩展性”，“增加复用性”，“降低总体复杂度”，“增加可读性”，“增加可维护性”。
你觉得 MVI 的 ROI 是正的还是负的？热烈欢迎留言~~
