先设计项目的技术框架，再写第一行代码。
引言
- 模块功能化（高内聚、低耦合）
- 提高开发效率（分工明确、业务聚焦）
- 提高测试效率（方便测试、问题定位）
MVC
数据流向描述
- 粉色：仅 UI 需要变化（比如动画的处理）
- 蓝色：View 修改 Model 的数据通过 Controller
- 黄色：Model 数据变化引起 UI 变化，通过 Controller
- 灰色：View 层可以直接修改 Model 数据，或者 View 注册 Model 的监听器，可以直接监听回调处理
小结
- 优点：一定程度上实现了 Model 与 View 的分离，降低了代码的耦合度
- 缺点：Controller 与 View 难以完全解耦，并且随着项目的复杂度的提升，Controller 将会越来越臃肿
MVP
数据流向描述
- 蓝色：View 修改 Model 的数据，必须通过 Presenter
- 黄色：Model 数据变化引起 UI 变化，必须通过 Presenter
小结
- 优点：解决了 MVC 中 Controller 与 View 过渡耦合的缺点，职责划分明显，更加易于维护
- 缺点：接口数量众多，项目复杂度高。随着项目复杂度的提升，Presenter 层将会越来越臃肿
MVVM
数据流向描述
- 蓝色：View 修改 Model 的数据，必须通过 ViewModel
- 黄色：Model 数据变化引起 UI 变化，必须通过 ViewModel
- View 和 ViewModel 之间交互通过 DataBinding 完成（DataBinding 可以实现双向绑定）
- MVVM 是一种思想，DataBinding 是谷歌推出的方便实现 MVVM 的工具。
小结
- 优点：实现了视图和数据的双向绑定，极大简化了代码
- 缺点：Bug 难以调试，出现问题时不太好定位来源，有可能数据问题导致，也有可能是业务逻辑中对视图属性的修改导致
总结
设计初衷
- MVC：为解决程序模块化问题。将业务逻辑、数据处理与界面显示进行分离来组织代码，即分成M、V、C层
- MVP：MVC中的M、V层还是有相互交叉、隔离度不够，同时写到Activity上使得Activity代码臃肿。MVP隔离了MVC中的 M 与 V 的直接联系，将M、V层更加隔离开来，并释放了Activity的压力
- MVVM：为了更加分离M、V层，更加释放Activity的压力。使得V和M层之间的耦合程度进一步降低，分离更为彻底，同时更加减轻了Activity的压力。
宏观概览
- MVC:学习简单但是解耦不够彻底
- MVP:解耦更加彻底，学习起来也相对比较简单，但是代码相对比较繁琐
- MVVM:代码逻辑非常简洁，但是学习成本较大
