MVVM 迁移到 MVI：复杂页面状态如何收敛

$Android 从零到一$ MVVM 迁移到 MVI：复杂页面状态如何收敛

当页面同时包含筛选、分页、刷新和错误恢复时，单纯增加 ViewModel 字段往往会让状态彼此打架。本文用一个列表页面说明何时需要从 MVVM 的多状态更新迁移到单向数据流，以及如何控制迁移范围。

问题不是架构名字，而是状态组合

假设一个商品列表页有关键词、分类、排序、分页、加载状态和错误提示。若 ViewModel 分别暴露 items、loading、error、page、filter，页面可能收到互相矛盾的组合：旧列表配新筛选、加载结束却仍显示旧错误，或刷新和加载更多同时发生。

MVVM 本身并不要求状态散落。问题通常出在状态没有明确的单一所有者，以及异步结果没有验证其所属请求。迁移到 MVI 的价值，是把用户意图、状态转移和渲染结果串成可追踪的单向链路，而不是为了给类改名。

先定义页面状态

将页面可见信息聚合成一个不可变状态。筛选条件和列表数据属于稳定状态，正在执行的动作属于加载状态，错误则作为可恢复的界面结果表达。

kotlin 复制代码

data class ProductUiState(
    val query: String = "",
    val categoryId: String? = null,
    val sort: Sort = Sort.Recommended,
    val items: List<Product> = emptyList(),
    val nextPage: Int = 1,
    val isRefreshing: Boolean = false,
    val isAppending: Boolean = false,
    val endReached: Boolean = false,
    val message: String? = null,
)

sealed interface ProductIntent {
    data class QueryChanged(val value: String) : ProductIntent
    data class CategorySelected(val id: String?) : ProductIntent
    data class SortSelected(val sort: Sort) : ProductIntent
    data object Refresh : ProductIntent
    data object LoadNextPage : ProductIntent
    data object MessageConsumed : ProductIntent
}

UI 只订阅一个 StateFlow<ProductUiState> 并发送意图。状态更新始终基于旧状态生成新值，不从 View 层反向修改数据。一次性提示可以用有明确消费动作的状态字段，也可以用独立事件流；选择哪种方式要看是否需要在配置变更或进程重建后重放。

用请求代次处理竞态

仅靠单向数据流不能自动解决网络竞态。用户快速切换筛选时，较早发出的请求可能较晚返回并覆盖新结果。让每次查询变更取消前一任务，并在更新状态时确保任务仍然有效：

kotlin 复制代码

private var searchJob: Job? = null

private fun search(query: String, categoryId: String?, sort: Sort) {
    searchJob?.cancel()
    searchJob = viewModelScope.launch {
        _uiState.update { it.copy(isRefreshing = true, message = null) }
        runCatching { repository.search(query, categoryId, sort) }
            .onSuccess { result ->
                _uiState.update {
                    it.copy(
                        items = result.items,
                        nextPage = result.nextPage,
                        endReached = result.endReached,
                        isRefreshing = false,
                        isAppending = false,
                    )
                }
            }
            .onFailure { error ->
                if (error is CancellationException) throw error
                _uiState.update {
                    it.copy(isRefreshing = false, isAppending = false, message = error.toUserMessage())
                }
            }
    }
}

生产代码还应确保 Repository 的取消能够传递到底层请求；如果数据源不支持取消，可给每次查询分配递增序号，只允许最新序号提交结果。不要吞掉 CancellationException，否则上游取消可能被错误地当作普通失败。

将分页规则集中在状态所有者

LoadNextPage 应在正在刷新、正在追加或已经到末页时忽略。追加成功后合并数据并推进页码；失败时保留已有列表，避免一次网络错误清空用户正在看的内容。相同商品是否去重、刷新期间旧数据是否继续展示，也应作为明确的产品规则，而非散落在 Adapter 中的补丁。

这一点体现了 MVI 的实际收益：状态转移可以围绕意图集中实现并单测，而不必在多个回调中猜测当前组合是否合理。但如果页面只有简单加载和空态，使用一个清晰的 UiState 的 MVVM 也完全足够，不需要额外引入 reducer 框架。

渐进迁移，不重写整个模块

迁移可分成三步：先把 ViewModel 的多个可变字段收敛成一个不可变 UI 状态；再把页面回调整理成有限的意图入口；最后把重复的异步转移抽成私有函数或 reducer，并补上并发与失败测试。Repository、导航和现有列表组件通常无需同时改造。

测试优先覆盖状态转移边界：快速变更筛选时旧请求不能覆盖新结果；刷新失败时旧列表仍然存在；追加失败不会推进页码；末页之后不会继续请求；重复点击加载不会并发发出重复任务。使用协程测试工具控制调度和请求完成顺序，比依赖真实网络更稳定。

什么时候值得采用

当多个异步动作会互相影响、状态组合难以推理、线上问题无法还原具体转移路径时，单向数据流通常能降低维护成本。若页面状态简单、团队已经有成熟且一致的 MVVM 约定，先完善状态建模和并发控制即可。架构选择的判断标准应是状态变化能否被解释、测试和恢复，而不是模式名称是否流行。