主流 Android 架构十年演化史——我们到底在解决什么问题？ A Decade of Android Architecture Evolution: What Problem Are We Really Solving?

Android 架构系列博文（共4篇）

第一篇：主流 Android 架构十年演化史——我们到底在解决什么问题？

系列导航：第二篇：Lego架构——分治思想的极致实践 | 第三篇：用 Lego 架构重构商品详情页

前言：学会了所有架构，代码真的变好了吗？

从 2010 年 Android 诞生至今，主流架构至少经历了五次行业级迭代。我们背熟了 MVC 的分层，掌握了 MVP 的接口解耦，拥抱了 MVVM 的数据绑定，推崇 Clean Architecture 的依赖倒置，现在又全员转向 MVI 的单向数据流。

但一个扎心的问题是：当我们把这些架构都学了一遍、重构了一遍之后，代码就真的变好了吗？

如果你的回答是“没有”，甚至“只是换了个地方写垃圾代码”——那么这篇文章，就是为你准备的。

一、架构演化的本质：一场“减少连线”的革命

理解所有架构的演化，只需要一个极其简单的模型：强引用连线的数量，决定了系统的复杂度。

连线越多，模块间牵制越深，改动越容易引发连锁反应。历代架构，都在做同一件事——尽可能地减少连线，让依赖关系单向、清晰。

1. MVC：混乱三角（6 根连线）

作为现代架构的鼻祖，MVC 首次提出分层思想：

Model：数据
View：UI
Controller：逻辑

然而三者在经典实现中是两两互交的，形成了一个闭环三角形，总共产生 6 根强引用连线：

View ←→ Controller ←→ Model
↑                       ↑
└───────────────────────┘

在 Android 中，Activity/Fragment 更是同时充当 View 和 Controller，导致上千行的"Massive View Controller"成为常态。一次数据变动可能牵动所有层，根本理不清。

2. MVP：切断直连（4 根连线）

MVP 做出了一项革命性简化：彻底禁止 View 与 Model 直接交互。

所有跨层通信必须经过 Presenter，三角形被打破，变成了线性依赖：

View ←→ Presenter ←→ Model

连线数从 6 降到 4，复杂度立降 33%。View 只做展示，Model 只做数据，业务逻辑全在 Presenter。2015-2018 年间，这几乎拯救了整个 Android 开发社区。

3. MVVM：依赖反转（3 根连线）

MVVM 在 MVP 的基础上更进一步，引入数据绑定和可观测状态，实现依赖反转：

View → ViewModel ←→ Model

View 仍持有 ViewModel 引用，但 ViewModel 不再持有任何 View 引用。
ViewModel 完成任务后，只更新一个可观察的数据状态，完全不知道、也不关心谁在观察。

连线数降到 3，View 与 ViewModel 之间变为单向，省去了手动 UI 更新代码和繁琐的接口定义。

这次改变的更深层价值是：ViewModel 成为了可复用的中介者（或视为服务提供者），可被任意视图观察和复用；同时，一个视图使用多个 ViewModel 为其提供服务也成为自然。ViewModel 和 Presenter 相比，粒度更小、复用性更高。

这些改善之处，让 MVVM 迅速取代 MVP 成为主流。

4. MVI：单向闭环（3 根连线 + 严格单向流）

MVI 是最新的进化，它在 MVVM 的基础上，把数据流也彻底拉直：

所有用户操作汇总为单一 Intent
所有 UI 状态聚合为一个不可变的 State
数据流形成严格的单向循环：用户操作 → Intent → ViewModel → Model → 新 State → View 渲染

从引用关系看，MVI 和 MVVM 都是 3 根连线。但 MVI 强制规定：任何状态变化都必须经过 ViewModel 处理，View 不得直接篡改数据。

这带来了巨大的工程红利：

状态集中管理，可鸟瞰整个页面行为
状态不可变，杜绝意外篡改
行为完全可预测，易于调试和埋点
支持时间旅行调试、统一日志等高级功能

然而 MVI 也有致命的实施门槛。 它对开发者的抽象能力要求极高。当思维混乱、缺乏拆分意识的程序员使用 MVI 时，就会掉入三个典型陷阱：

Intent 爆炸：一个复杂页面定义出 200+ 个 Intent，命名又臭又长，职责重叠，反而比原来更难维护。
God State：一个 State 对象塞进 30 个互不相关的字段，更新时牵一发动全身。
网状依赖：多个 Intent 相互调用，形成新的混乱调用链，让单向流名存实亡。

本该严谨的有限状态机，就这样被用成了"无限状态机"——这正是 MVI 被一部分人视为灾难的根源。

二、架构只是"术"：它无法阻止你写出垃圾代码

我亲眼见过许多荒谬的项目：

用着先进的 MVVM，却写出 5000 行的 ViewModel（架构管不到 ViewModel 内部的臃肿）
严格遵循 Clean Architecture，却在 Domain 层塞满业务耦合（架构管不到 UseCase 之间的边界）
坚持 MVI 单向流，却在一个 State 里混杂了轮播图、推荐列表和用户信息（架构管不到 State 的粒度）

糟糕的编程习惯制造出来的垃圾，不会因为换了一个架构就自动消失。我们只不过是把垃圾从 Activity 搬到了 Presenter，又从 Presenter 搬到了 ViewModel，再从 ViewModel 搬到了 UseCase。我们只是把垃圾从一个房间搬到了另一个房间，并没有真正把它清理掉。

就像同一段登录逻辑：