MVC

MVC 其实是 Android 默认的设计，MVC 里将代码分为三个部分：

• View：Layout XML 文件
• Model：负责网络请求、数据库操作、文件操作等
• Controller：Activity / Fragment 负责 UI 操作和业务逻辑

MVC 初步解决了 Activity 代码太多的问题，但也有缺点：

• 我们的初衷 Activity 是只处理 UI 逻辑的部分 ，但现实是 Activity 天然不可避免要处理 UI，也要处理用户交互，说明 Activity 本身天然承担了 View 的角色。那么这个架构就会造成 Activity 里糅合了视图和业务的代码，分离程度不够
• 业务逻辑由 Activity 承担，不方便单元测试
• 业务逻辑代码没有抽象出接口（目录），既不能清晰明了地梳理业务方法/需求，也不方便做业务的重构和问题排查

MVP

为了将 Android Component (Activity / Fragment / View) 中的业务逻辑彻底分离出来，业界提出了 MVP 的设计。MVP 同样将代码划分为三个部分：

• View：Activity / Fragment 和 Layout XML 文件
• Model：负责网络请求、数据库操作、文件操作等，与 MVC 中的 Model 一致
• Presenter：包含业务逻辑

在实现细节上，View 和 Presenter 中间会定义一个协议接口 Contract，这个接口会约定 View 如何向 Presenter 发指令和 Presenter 如何 Callback 给 View。这样的架构里 Activity 不再有表现逻辑的部分，Activity 作为 View 的角色只处理和 UI 有关的事情。但还是存在一些缺点：

• 双向依赖： View 和 Presenter 是双向依赖的，一旦 View 层做出改变，相应地 Presenter 也需要做出调整。在业务语境下，View 层变化是大概率事件
• 内存泄漏风险： Presenter 持有 View 层的引用，当用户关闭了 View 层，但 Model 层仍然在进行耗时操作，就会有内存泄漏风险。虽然有解决办法，但还是存在风险点和复杂度（弱引用 / onDestroy() 回收 Presenter）
• 协议接口类膨胀： View 层和 Presenter 层的交互需要定义接口方法，当交互非常复杂时，需要定义很多接口方法和回调方法，也不好维护

MVVM

MVVM 模式改动在于 Presenter 改为 ViewModel，MVVM 同样将代码划分为三个部分：