Android 架构之 MVI 究极体 | 状态和事件分道扬镳，粘性不再是问题

这是 MVI 架构的第四篇，系列文章目录如下：

1. Android 架构之 MVI 雏形 | 响应式编程 + 单向数据流 + 唯一可信数据源

2. Android 架构之 MVI 初级体 | Flow 替换 LiveData 重构数据链路

3. Android 架构之 MVI 完全体 | 重新审视 MVVM 之殇（PartialChange & Reducer）

4. Android 架构之 MVI 究极体 | 分道扬镳的状态和事件

引子

该系列基于“新闻流”进行 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 一样，也是粘性的。

事件 & 状态

为了解决粘性数据持有者的问题，需要将界面渲染的数据来源做一个区分：

1. 事件 Event
2. 状态 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 是正的还是负的？热烈欢迎留言~~