Android:漫谈MVC、MVP、MVVM、MVI设计架构

前言

学习Android，笔者仍然在路上

一、MVC架构

组成

MVC由Model、View、Controller组成

逻辑

Role

• 模型（Model)层，我们针对业务模型所建立的数据结构和相关类，可以被理解为Model，一般与View无关，与业务有关
• 视图（View)层，一般采用XML文件和Java代码进行编写
• 控制（Controller)层，Android的控制层一般由Activity、Fragment和其他控制类构成

Mission

• View接受用户的交互请求。
• View将请求转交给Controller。
• Controller操作Model进行数据更新。
• 数据更新之后，Model通知View数据变化。
• View显示更新之后的数据。

优缺点分析

优点

• 业务逻辑简单，比较经典的架构，适合新人上手

缺点

• Activity并不是标准的Controller，要负责加载应用的布局和初始化用户界面，接收并处理来自用户的操作请求，当业务逻辑不断复杂时，Activity的体积会变得过度臃肿
• View层和Model相互耦合，不易于开发和维护

笔者第一次接触Android就是上手写了一个MVC的项目，确实代码量一大，后期维护起来很烦…

二、MVP架构

组成

逻辑

Role

• Model层，主要提供数据存储功能，Presenter通过Model来存储、获取数据
• View层，负责处理用户事件和控制页面显示，通常为Activity、Fragment或某个类控件
• Presenter层，作为View层和Model层的控制桥梁，向Model层索取数据和写入数据；向View层更新Ui，它扮演的角色使得Model层和View层解耦合

Mission

• View 接收用户交互请求
• View 将请求转交给 Presenter(V调用P接口)
• Presenter 操作Model进行数据更新(P调用M接口)
• Model 通知Presenter数据发生变化(M调用P接口)
• Presenter 更新View数据(P执行接口,V相应回调)

优缺点分析

优点

• 复杂的逻辑处理放在Presenter进行处理，减少了Activity的臃肿。
• 解耦。Model层与View层完全分离，修改V层不会影响M层，降低了耦合性。
• 可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。
• Presenter层与View层的交互是通过接口来进行的，便于单元测试。

缺点

• 维护困难。Presenter中除了业务逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。
• 伴随业务逻辑的增长，后期接口回调过多，会产生回调陷阱，接口膨胀等问题

笔者也写过MVP架构的项目，刚开始上手的时候相较MVC确实逻辑清晰，但是后期伴随业务逻辑的增大，处理器bug要定位原因确实需要大量的搜寻

三、MVVM架构

MVVM与MVP的结构很相似的，就是将Presenter升级为ViewModel。在MVVM中，View层和Model层进行了双向绑定(即Data Binding)，所以Model数据的更改会表现在View上，反之亦然。ViewModel就是用来根据具体情况处理View或Model的变化。
相比较MVP，笔者认为，DataBinding更多的是隐藏了Presenter层的回调细节，MVVM其实有很多细节可以挖掘，如绑定的实现机制，是如何避免内存泄漏等问题。

Role

• Model：实体类(数据的获取、存储、数据状态变化)。
• View：布局文件+Activity。
• ViewModel： 关联层，将Model和View进行绑定，Model或View更改时，实时刷新对方

Mission

• View 接收用户交互请求
• View 将请求转交给ViewModel
• ViewModel 操作Model数据更新
• Model 更新完数据，通知ViewModel数据发生变化
• ViewModel 更新View数据

优缺点分析

优点

• 提高可维护性。Data Binding可以实现双向的交互，使得视图和控制层之间的耦合程度进一步降低，分离更为彻底，同时减轻了Activity的压力。
• 简化测试。因为同步逻辑是交由Binder做的，View跟着Model同时变更，所以只需要保证Model的正确性，View就正确。大大减少了对View同步更新的测试。
• ViewModle易于单元测试。

缺点

• 对于简单的项目，使用MVVM有点大材小用。
• 对于过大的项目，数据绑定会导致内存开销大，影响性能。
• ViewModel和View的绑定，使页面异常追踪变得不方便。有可能是View出错，也有可能是ViewModel的业务逻辑有问题，也有可能是Model的数据出错。

笔者曾经书写过一些练习MVVM的小项目，同时也在重构原来书写的项目，迁移一些业务逻辑复杂的部分到MVVM上，在这一过程中，充分体会到MVVM其实debug真的很不容易，相对于MVP MVC打断点的方式进行debug，MVVMdebug定位View层or控制层变得困难

四、MVI架构

MVI 与 MVVM 很相似，其借鉴了前端框架的思想，更加强调数据的单向流动和唯一数据源,最近Google也是推荐MVI架构，强调数据的单项流通+状态集中管理，这应该也是未来的大势所趋吧

Role

• Model: 与MVVM中的Model不同的是，MVI的Model主要指UI状态（State）。例如页面加载状态、控件位置等都是一种UI状态
• View: 与其他MVX中的View一致，可能是一个Activity或者任意UI承载单元。MVI中的View通过订阅Model的变化实现界面刷新
• Intent: 此Intent不是Activity的Intent，用户的任何操作都被包装成Intent后发送给Model层进行数据请求

MVI强调数据的单向流动，主要分为以下几步：

• 用户操作以Intent的形式通知Model
• Model基于Intent更新State
• View接收到State变化刷新UI。

优缺点分析

优点

• 强调数据单向流动，很容易对状态变化进行跟踪和回溯
• 使用ViewState对State集中管理，只需要订阅一个 ViewState 便可获取页面的所有状态，相对 MVVM 减少了不少模板代码
• ViewModel通过ViewState与Action通信，通过浏览ViewState 和 Aciton 定义就可以理清 ViewModel 的职责，可以直接拿来作为接口文档使用。

缺点

• 所有的操作最终都会转换成State，所以当复杂页面的State容易膨胀
• state是不变的，因此每当state需要更新时都要创建新对象替代老对象，这会带来一定内存开销

总结

软件开发没有最好的架构，只有最合适的架构；小型项目开发的Demo，MVC架构的快速上手的特点就体现出来了，而不是说MVC架构已经过时；总体而言，每个人都有自己的理解，一句话：适合的自己的才是做好的

参考博客
MVC MVP MVVM MVI架构优缺点
MVVM 进阶版：MVI 架构了解一下