承接上一篇《性能阶段通关地图：五个阶段怎么递进》，那一篇是性能系列的收口，这一篇开启新的主题：架构。前两百多篇讲的是「怎么把某件事做好」，这一篇开始讲「代码组织方式如何影响可维护性」。
结论先行：MVC → MVP → MVVM → MVI 的演进不是「新架构比旧架构好」的替换过程，而是对同一个问题的持续再回答——状态如何管理、生命周期如何绑定、副作用如何收敛。每一种架构都是对上一代暴露出的问题的修正。理解这条演进链，比记住每个架构的组件定义更有价值。
一、演进的核心驱动：三个老问题
四种架构的差异可以归到三个反复出现的问题上。
| 问题 | 表现 | 演进中的修正手段 |
|---|---|---|
| 状态管理 | 界面状态分散在控件和回调里，无法集中表达 | ViewModel 集中状态 → StateFlow 声明式状态 |
| 生命周期绑定 | 逻辑与 Activity/Fragment 生命周期耦合，泄漏或错乱 | Presenter/ViewModel 脱离 View 生命周期 → 单向数据流 |
| 副作用治理 | 网络、数据库、剪贴板散落在 UI 层 | Repository 封装数据源 → Intent/Effect 显式表达 |
