轻量 MVI 实践的一些思考
从工程角度出发，为什么我更倾向于一套轻量、可读、可维护的 MVI 实现方式。
标签：Android / MVI / 架构
预计阅读：8 分钟 Pulse 项目地址：https://github.com/Magic-Xu/pulse
背景
在过去的 Android 项目里，我经历过 MVC、MVP、MVVM 到 MVI 的迭代。随着业务复杂度上升，我越来越关注一件事：架构是否真的在降低长期维护成本。
回头看很多项目问题，并不是“架构方向错了”，而是实现方式过重。代码层级越来越多、模板越来越厚，团队理解成本和改动成本都在上升。
为什么我仍然选择 MVI
MVI 对复杂页面的价值很明确：
- 单向数据流，状态变化路径清晰
- 状态可追踪，问题定位更直接
- 行为可预测，跨人协作时更稳定
在高交互页面中，这种可预测性比“短期写得快”更重要。它直接影响线上问题处理效率和后续重构风险。
常见问题：MVI 很容易越写越重
我看过不少开源实现，常见负担主要来自几个方面：
- 状态对象承载过多职责，边界不清晰
- Intent / Action / Event 体系拆分过细，沟通成本高
- 模板代码重复，业务逻辑被样板淹没
- 阅读路径过长，新同学很难快速进入上下文
这些问题会让 MVI 从“组织复杂度的工具”，变成“制造复杂度的来源”。
在 Pulse 里的实践取向
我在 Pulse 里更关注的是工程可落地，而不是概念完整性。核心方向有三点。
1. 降低心智负担
希望开发者在阅读一段业务代码时，能快速回答三个问题：
- 当前状态是什么
- 用户触发了什么
- 状态如何被更新
如果这三个问题不能快速回答，说明抽象还不够好。
2. 控制抽象层级
我会尽量避免为了“架构完整”引入过多中间层。
抽象本身不是目标，稳定交付才是。只有当某一层真正降低重复劳动、明确边界时，它才值得保留。
3. 强调可读性优先
代码首先是团队协作的文本，其次才是执行单元。
在 Pulse 里，我更偏向让状态流和副作用处理在代码结构上可直读，而不是依赖“约定俗成”去猜测行为。
适用边界
轻量 MVI 并不意味着适合所有场景。对于非常简单、状态单一的页面，过早引入完整 MVI 反而会增加成本。
我的做法通常是：
- 先用最小结构跑通业务
- 当状态复杂度和协作复杂度上升，再引入更明确的状态模型
这样能让架构投入和业务阶段保持一致。
小结
我现在对架构的判断标准更务实：
架构的价值，不在于看起来多优雅，而在于能否让团队持续、高质量地解决问题。
如果你也在做 Android 状态管理或 MVI 工程化实践，欢迎交流你踩过的坑和有效做法。