Android 设计架构演进历程

前言

Android 设计架构的演进历程： MVC -> MVP -> MVVM -> MVI

在演进的过程中具备如下特征：

1. 降低业务逻辑与 UI 层的耦合
2. 数据驱动
3. 单项数据流

一、MVC

1. M：Model 层，通常负责发起网络请求，数据处理
2. V：View 层，指 Activity/Fragment 等
3. C：Controller 层，处理业务逻辑，用户行为，通常来说，这一层的执行的逻辑也是放在了Activity/Fragment 中，导致 UI 层耦合严重

Model 和 Controller 相互持有，Controller 层负责接收用户的行为，Model 处理网络数据，完成之后，通过 Callback 更新 UI。

二、MVP

1. M：Model 层，通常负责发起网络请求，数据处理
2. V：View 层，指 Activity/Fragment 等
3. C：Presenter 层，负责处理用户发起的行为，这里的逻辑不再写在 Activity/Fragment 中

和 MVC 的区别是，这里的业务逻辑不再写在Activity/Fragment中，另外 View 层所依赖的不再是某个具体的 Presenter 实例，而是 Presenter 抽象接口。

相对于 MVC，MVP 把繁重的业务逻辑从 View 层抽离出去了，同时解决了 View 层和 Model 层的直接依赖。但是由于 View 依赖了 Presenter 的大量接口，会造成后续接口冗余，大量未使用到的接口也需要实现。

1. 为什么是依赖 Presenter 接口？

依赖抽象，符合设计模式的要求，在后续的扩展中，如果 View 层的 Presenter 发生变动，不需要修改 View 层原有的逻辑。

3. 为什么会出现接口冗余？

现假设，PresenterV1 和 PresenterV2 都实现了 IPresenter，在 V2 改版中新增的了一个接口方法，原来的 V1 版本是不是也得实现？或者是，在 V2 版本的中，已经没有 V1 中的某个逻辑了，但是由于实现了 IPresenter，在 V2 版本中就不得不实现。

三、MVVM

1. M：Model 层，通常负责发起网络请求，数据处理
2. V：View 层，指 Activity/Fragment 等
3. VM：ViewModel 层，响应用户行为，通过观察者模式更新 UI

彻底解耦了 View 层和逻辑层的双向持有问题，降低了内存泄漏的机率，ViewModel 层不再持有 UI 层，而是通过 LiveData 自动通知 UI 自动更新。它最大的特点便是数据驱动。

四、MVI

在 MVI 的设计架构中，

1. V：Activity/ Fragment
2. I：指Intent，View 通过 Intent 和 ViewModel 交互，ViewModel 持有 Domain Layer（非必须），后者持有 Data Layer（Model 层）
3. M：指 Data Layer，数据层

MVI 架构具有的特点是：单项数据流、Intent 驱动

参考文章：

1. 「架构篇 1」认识 MVC / MVP / MVVM / MVI

2. 「架构篇 2」认识 MVC / MVP / MVVM / MVI