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

8,607 阅读7分钟

这是 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 会提供一个“唯一数据源”供界面观察。 这样就形成如下的图景:

微信截图_20220416144128.png

其中的“唯一数据源”是关键。即用一个 State 实例表达整个界面的状态。而不是像 MVVM 中用 N 个 LiveData 拼凑出完整的界面。

上图省略了 Intent 变换成 State 的中间过程。因为 Intent 只表达了意图,而意图产生的结果才唯一对应一个 State:

微信截图_20220604200133.png

意图产生的结果称为 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 提示。

事件分流

原本的数据流是这样的:

微信截图_20220618153023.png

现在期望实现这样的效果:

微信截图_20220618153131.png

为此需要一个新的容器来承载 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 究极形态如下图所示:

微信截图_20220618160601.png 举报新闻这个意图会产生两个结果,其中举报成功会同时产生一个 State 和 一个 Event,分别对应删除举报新闻,和 toast 提示。

不得不承认,该图比上一篇,又稍稍复杂了一点。

MVI 的确引入了一些新的复杂度,包括 Intent,PartialChange,Reduce,State,Event。若使用 MVVM 架构都不需要手写这些类。

就好比设计模式,通常是通过增加一层抽象来进行解耦,提供扩展性。

评判一种架构好坏的指标,是不是可以像ROI一样,看投入产出比,即新增的复杂度,是否带来了与之匹配的收益。在架构层面,收益可以有“解耦”,“增加扩展性”,“增加复用性”,“降低总体复杂度”,“增加可读性”,“增加可维护性”。

你觉得 MVI 的 ROI 是正的还是负的?热烈欢迎留言~~