#首先：

大家可以看下官网的简介：

应用架构指南  |  Android 开发者  |  Android Developers (google.cn)

###再说下其他架构模式：

一．mvc

MVC的目的就是为了M和V代码分离，降低耦合性。

Model：数据来源，网络请求数据和数据库数据。

View：对应xml布局文件和动态的布局部分。

Controller：逻辑控制部分。主要起到协调M层和V层的关系，起承上启下的作用。

优点：一定程度上实现了代码分离，降低代码的耦合性。

缺点：

1.Controller和View层难以完全解耦，而且随着业务逻辑增多

2.Controller会变的越来越臃肿。在Android中Activity充当Controller的角色，后面Activity会变成GadActivity。

3. M层和V层还有交互，没有做到完全分离

二．mvp

MVP是在MVC的基础上发展过来的，实现了M层和V层的完全分离，进一步代码解耦。

Model：数据来源，网络请求数据和数据库数据。

View：对应xml布局文件和动态的布局部分。对应Activity。

Presenter：逻辑控制部分。通过接口连接M层和V层。

优点：

1.V层对应Activity，只负责UI的展示和P层直接通信，和M层没有任何交互。

2.V层没有和M层有交互，可以抽成单独的组件，方便复用。

3.代码结构清晰，P层可以用于多个视图，而不需要改变P层的逻辑。

4.V层和M层完全分离，方便协同工作，只需要专注做视图或者逻辑控制部分，不用关系对方的逻辑。比如负责逻辑控制部分不用等设计出图，就可以直接写代码，并进行单元测试。

5.代码复用率高，方便单元测试。

缺点：

1.M层和V层都需要和P层进行通许，会导致P层代码很复杂，而且都是通过接口通讯，如果一个P层用于多个Activity，所有Activity都要实现全部都接口，无论能不能用得到。修改P层接口，往往会涉及到很多个界面，很麻烦。

2.P层和V层通过接口通讯，会持有View的引用，容易造成内存泄露。

3.随着业务增多，P层即使只对应一个视图，接口也会越来越多。

三．mvvm

MVVM在MVP的基础上进一步解耦，VM层不在持有View的引用。

引入响应式编程、Lifecycle生命周期感知、LiveData数据存储、DataBinding数据绑定概念。配合Goole提供的Jetpack组件能节省很多代码。

Model：数据来源，网络请求数据和数据库数据。

View：对应xml布局文件和动态的布局部分。对应Activity。向比较MVP这里的View是通过DataBinding来进行双向绑定数据。

ViewModel：逻辑控制部分。作为桥梁，通知M层处理数据，并将结果回调到V层处理UI。Activity持有ViewModel引用，ViewModel不持有View的引用。

优点：

1.进一步解耦，ViewModel不持有View的引用，当V层改遍，只要V层绑定的数据不变，ViewModel就不需要修改。

2.不需要写很多样板代码，省略findViewById()，Activity变得很简介。

3.通过DataBinding实现View和Model的实时改变，一方改变就会同步到对方。

缺点：

1.DataBinding双向绑定采用异步更新数据，对ListView这样的列表，效率比较低。而且在实际开发中，设计出的Ui效果比较复杂，数据绑定不能完全实现，往往只使用到DataBinding一半的功能，数据更新部分还是手动实现。

2.DataBinding会自动生成大量的代码和属性字段。

3.复杂的页面要定义多个LiveData，并且都要暴露为不可变的LiveData。

4.LiveData是粘性事件，数据倒灌等问题。解决方法：使用第三方 UnPeekLiveData

四．MVI（Model-View-Intent）

出现的目的是为了解决MVVM中双向绑定数据的不足。把双向绑定变成单向数据流。使用Flow代替LiveData存储数据。

Model：这里的Model不是其他框架中的Model层，在MVI框架中表示存储UI的状态。

View：在MVI中View层主要是接口，负责相应UI的状态。

Intent：在MVI中Intent(和Android中的Intent不是同一个)主要负责传递UI状态。使用sealed关键字，形成一个封闭类，类似枚举。主要用于V层通知ViewModel处理数据。

State：和Intent一样是一个封闭类，主要用于ViewModel回调数据修改UI。

##个人理解：

MVI在架构分层上和MVP没有本质区别，但区别主要体现在架构风格和编程思想上。

MVI 是 Model-View-Intent 的缩写，它也是一种响应式 + 流式处理思想的架构。

MVI 的 Model 代表一种可订阅的状态模型的概念，添加了 Intent 概念来代表用户行为，采用单向数据流来控制数据流动和各层依赖关系。

• 在代码的层面上它分为三层：
  UI Layer（界面层） ：在屏幕上展示应用界面和数据
  Domian Layer（网域层） ：封装复杂或可复用的业务逻辑
  Data Layer（数据层） ：获取可公开应用数据和完成业务逻辑

• MVI 中的单项数据流工作流程如下：
  用户操作以 Intent 的形式通知 Model
  Model 基于 Intent 更新 State
  View 接收到 State 变化刷新 UI

• MVI - Model-View-Intent
• MVI是一种响应式和流式的处理思想，将意图事件（用户操作），通过函数转换为特定Model（状态），将其结果反馈给用户（渲染界面）。
• 抽象下来得到intent()，model()，view() 三个方法
• intent() 即意图，接收用户的输入（即UI事件，如点击事件）把意图和相关参数封装为数据结构，传递给model()方法。传递意图的接口是统一的，而不像MVP持有Presenter，并调用Presenter的多个接口。
• model() 不同于一般的model，这里说的model相当于状态模型里的一种状态，model内部的逻辑是不可变的，这能保证状态逻辑的一致性，同时降低系统的复杂性。
• view() 接收model传来的state渲染UI