欢迎阅读这篇文章！我的目标是帮助你真正理解 MVI 模式的本质。解释我为何对自己的观点充满信心，还有该模式的起源。但在你深入阅读之前，请先思考：

📝 这篇文章包含对 MVI 架构模式的历史和演变的广泛而深入的研究，还有作者的观点。请做好区分事实和观点的准备 😉

1️⃣ 目录

1️⃣ ：超越流行语

MVI 已成为 Android 开发中一种强大的架构模式，它在管理状态和 UI 复杂性方面提供了清晰性和可预测性。如果运用得当，它可以提供一个强大的思维模型。帮助开发者建立可维护和可 的应用程序。

只是你可能已经听说过“MVI 警察”——他们坚持认为只有严格遵循 MVU 或 Redux 风格才能算真正的 MVI，并把其他实现斥为贴错标签。这种狭隘观点忽略了 MVI 的真正起源还有它如何在保持主要原则的前提下灵活适应不同场景。

2️⃣ 架构先驱：MVI 的雏形

模型-视图-控制器 — 20 世纪80年代末期

• 模型: 管理数据和业务逻辑。
• 视图: 渲染 UI 元素。
• 控制器: 处理使用者输入并更新模型。怎么说呢，

MVC 是最早且最具影响力的架构之一。但它在单向数据流方面存在局限。随后出现了更适合响应式编程需求的新版本。

Flux — 2014 年左右

• 动作: 描述发生了什么。
• 调度器: 将动作路由到商店。怎么说呢，
• 商店: 保存状态并响应动作。
• 视图: 侦听商店变化并重新渲染。

Flux 引入了单向数据流，但常被批评混合命令式与响应式范例。其主要思想——不可变状态 + 单向流——深深影响了后来的 MVI 设计。不过，

MVC 改造为 MIV — André Staltz

Ade Staltz 在《Reactive MVC》一文中。将 MVC 重塑为 MVC → 意图→模型→视图 ,用“意图”取代控制器，用 RxJS 等观察者实现单向流。这是第一次正式提及 “MIV”，随后演变为我们今天熟知的 MVI 模式。

3️⃣ MVI 的起源：模式如何形成

MVI 最初在 JavaScript 框架 Cycle.js 中提出，早于 Redux 成名。怎么说呢，它不是 Redux 或 Elm 的直接衍生，而是对 Flux 单向流与 MVC 响应式重构后的产物。旨在为 UI 程序提供更清晰、更可预测的数据管理方式。

MIV 在 Cycle.js 中实现示例

// Intent stream
const intent$ = fromEvent.pipe=>));// Reducer
function reducer{
switch{
case 'CLICK': return {...state,count:state.count+1};
}
}
// Model stream
const model$ = intent$.pipe);// View rendering
model$.subscribe);按理说，

This snippet illustrates core flow: Intent → Reducer → Model → View.

4️⃣ 问题：MVI 的误解与痛点解析

• ❗️ 痛点① – “必须完全遵循 MVU/Redux 才能叫做 MVI” : 关键问题是你是否能够通过单一不可变状态 + Intent + Reducer 实现单向流。而不是字面上的框架或库依赖。许多开发者因过度严格而放弃了实用性。
• ❗️ 痛点② – “MVVM 就等同于 MVI” : 虽然两者都支持单向数据绑定。但 MVVM 通常没有统一 Intent 概念，也缺少纯函数型 Reducer；这导致 MVVM 更倾向于双向绑定，而非纯粹的一次性更新链路。
• ❗️ 痛点③ – “全局 Store 必须存在” : 在 Android 上使用 ViewModel 时只需把状态放进 ViewModel 内即可。无需全局持久化存储，否则会失去本地化优势与测试便利性。
• ❗️ 痛点④ – “副作用处理难以统一” : 把副作用拆成独立 Flow 或 Channel。可让测试更简单，也避免了 UI 与业务逻辑耦合过深的问题。按理说，

样子？

Mvi 在 Kotlin + Jetpack Compose 环境下通常采用以下结构：

• UserUiState : 不可变的数据类，公开给 UI 使用；

class UserViewModel(
private val repository : UserRepository,private val ioDispatcher : CoroutineDispatcher = Dispatchers.IO
): ViewModel {

// 单一不可变状态
private val _uiState = MutableStateFlow)
val uiState : StateFlow@JvmField get = _uiState
// 副作用通道
private val _sideEffect = Channel
val sideEffect : Flow@JvmField get = _sideEffect.receiveAsFlow
fun handleIntent {
when{
is UserIntent.LoadData -> loadData
is UserIntent.SubmitForm -> submitForm
// …}
}
private fun loadData{
viewModelScope.launch{
_uiState.update{ it.copy }
try{
val data = repository.getUser
_uiState.update{ it.copy }
_sideEffect.send)
}catch{
_uiState.update{ it.copy }
}
}
}

// …同理 submitForm ... }

6️⃣ 最终想法 —— 我的个人见解 & 使用者痛点回顾

I 意识到“真正有效”的实现不必严格复制任何库。仅需保留以下关键特征： - 单一不可变状态对象，在 ViewModel 层持有；- Intent 表示所有 UI 操作，并通过 pure 函数 reducer 更新状态；- 副作用独立 Channel / Flow，可被外部消费；按理说，- 严格遵循意图→模型→视图 单向链路。从而提高可测性与可维护性。- 不要把全局 Store 当成必须，“只要满足需求即可”；- 对错误与边界情况进行细粒度建模，以防止 UI 冻结或闪退。其实，

​

来源