MVC（Model-View-Controller）
MVC 的三大组成部分：模型、视图和控制器。
Model：模型层，对接数据库，包含所有数据逻辑的后端，数据存储的位置。模型将数据层与应用程序隔离。
View：视图层，“前端或图形用户界面 （GUI）”视图仅包含如何更新自身，创建模型并将其显示给用户的业务。可以有多个视图对不同的平台使用相同的控制器，因为视图不包含任何与应用程序相关的逻辑。控制器必须更新模型才能更新视图。
Controller：控制层，操作 Model 获取/处理数据。满足用户的输入，并根据用户的输入对模型进行更改。它还管理整个流程并做出有关 UI 的决策。控制器对 View 一无所知，但 View 知道控制器。一个控制器可由多个视图使用。
在 MVC 中，Model 获得数据后，通知 View 去更新数据。View 既是展示页面，又要处理展示的数据，耦合度高。理想情况中，View 层只做展示，这样就要把处理数据的功能拿出去，给 Controller 层，因为 Controller 多了向 View 层提供数据的功能，改名叫 Presenter 以示区分。这就是 MVP 架构。
MVP （Model-View-Presenter）
Model：操作，处理数据。
View：用户界面。
Presenter：操作 Model 处理数据，获得数据提供给 View。
MVP 是很好的架构，很多项目都在使用 MVP 架构。但是因为 Presenter 做为 View 和 Model 中间的桥梁，沟通两边，工作量很大，逻辑非常负载，当 View 交互多时，就会有非常多接口，写起来麻烦。
对 Presenter 层继续改动，改为 ViewModel 层。就得到了 MVVM 架构。MVVM 与 MVP 的区别是，将 View 与 Model 进行了绑定，这样 View 需要更新数据时，就不需要很多的接口，因为和 Model 绑定了。
MVVM （Model-View-ViewModel）
Model：操作，处理数据。
View：用户界面。
ViewModel：将 View 与 Model 进行双向绑定（这就是ViewModel名字的由来）。
MVVM 看起来很好，理论上简化了接口。但是实际中，交互少时，用 MVVM 给人一种大材小用的感觉：用 MVP 也没有太多的“额外”工作；交互多时，因为引入 DataBinding，内存开销很大。继续针对数据做改动，出现了 MVI。
MVI （Model-View-Intent）
Model：操作，处理数据。
View：用户界面。
Intent：并不是 Activity 中的 Intent，而一种新的用户操作封装。
MVI强调数据的单向流动，主要分为以下几步：
用户操作以Intent的形式通知Model
Model基于Intent更新State
View接收到State变化刷新UI。
数据永远在一个环形结构中单向流动，不能反向流动：
VIPER （View-Interactor-Presenter-Entity-Router）
View：展示演示者提供的数据，不执行任何其他操作。
Interactor：我们可以说它充当 MVVM 设计模式中的 VM。它是应用程序中我们称之为Bussines Logic的部分。此处不执行 UI 操作。获取，更新等操作在此处进行。
Presenter：视图和交互器之间的桥梁。此层不应包含 UI 或总线逻辑操作。
Entity：应用程序的模型部分。可在此处找到与应用程序相关的数据模型。这部分只与交互器合作。
Router：此层是允许我们确定何时显示应用程序页面的层。
