1.前言
项目开发的过程中必然会接触到两个概念，那就是框架和设计模式。框架是什么，也许你不知道，但网络请求框架、图片加载框架和数据存储框架，这些一定不会陌生，甚至每个项目中都会引入。设计模式大家就很熟悉了，从学Java开始，会有意无意地去了解它。可架构和这两者是什么关系，为什么要提及它们？
在软件开发领域有三种级别的重用：内部重用，即在同一应用中能公共使用的抽象块；代码重用，即将通用模块组合成库或工具集，以便在多个应用和领域都能使用；框架重用，即为专用领域提供通用的或现成的基础架构，以获得最高级别的重用性。——《Android源码设计模式解析与实战》
看来，设计模式、框架、架构是级别不断升高的过程。架构的基本目的是保证项目的可读性和可维护性，框架则是对常用软件功能进行整合，设计模式归纳了各种情况下具体的解决方案。
2.核心思想
还记得当始学习安卓开发吗？对，就一界面，上面写着“Hello World”。那么，这是什么架构？写的第一个完整项目，就几个界面分别对应着Activity或者Fragment，所有的交互响应、业务逻辑、数据请求存储等都放在其中。这时，又是什么架构？
原来开发应用并不一定需要架构，只有当项目规模达到一定程度，才需要对整体结构做个规划，防止代码过于集中，导致结构混乱。设计架构的目的就是解耦，方法有两种：模块化和分层。前者按功能横向地将项目划分开（具体见下一篇），后者根据事件处理和更新频率，纵向地确定了层次。
3.共同点MV
以点击收藏按钮为例，分为事件传递、业务处理、数据存储和界面更新四个部分，涉及到了界面、业务、数据。界面的布局会随着应用版本升级不断变化，更新最为频繁；数据的结构会根据产品发展需要随之改变，更新较为频繁；业务的逻辑是项目的根本和特色，一般情况不会去变动。
按照解耦的要求，变化的部分必须独立出来，即最上面为View层，与用户进行交互，包括UI布局、效果显示和事件传递等；最底下为Model层，涉及本地和网络的数据，变化时发送通知，同时提供对外的操作接口，实现增删改查；中间是业务逻辑，扩展空间大，所以架构的改进集中在此。
4.C、P、VM
4.1.Controller
MVC的数据流是单向的，即Controller只负责对View传给的事件加以判断，按照业务逻辑进行处理，需要数据操作就调用Model的接口。而View界面的显示由Model内数据变化时发出的通知来更新。
在这个过程中，View是依赖于Model的，需要对数据进行分析处理，导致业务逻辑被塞入View中，增加View的复杂性。当界面修改时，不得不提取业务逻辑，麻烦不说，还会影响测试过的代码的正确性，不符合开闭原则。
4.2.Presenter
MVP就是将Model到View的数据流，变成Model到Presenter再到View。Presenter收到更新通知，从Model中获取数据，解析以后交由View显示。这样Model和View之间变化互不影响，同时将业务逻辑全部移到Presenter中，使各层职责单一，方便进行单元测试。
由于是通过接口解耦合的，这样会引入更多的类文件。若项目不够大，反而结构会显得复杂；项目大了，Presenter承担更多的业务，也就复杂了（但是考虑到Activity和Fragment不能被混淆，而Presenter可以，我就忍了）。
4.3.ViewModel
MVVM就是MVP的升级版，结构都是一样的。唯一区别引入双向绑定机制，当Model和View一方发生变化则会反应到另一方上，代替了Presenter来回传数据的工作，使它专注于业务逻辑的处理，以及Model和View状态改变。
最后，我们发现Controller、Presenter、ViewModel是一回事，就是在不同架构中为了区分而重命名。不得不称赞一下谷歌，它不仅提供了各种情况下MVP的搭建方式，还给出了双向绑定的支持库，让你自己选择。这里只是提取关键点以便于理解，详细内容参考hudan2714的文章。
5.总结
我们发现架构的变化是针对上一个的缺点，用新的技术加以弥补，其目的是层次的解耦，使每个层次符合面向对象的设计原则，提高项目的可维护性、可扩展性和可测试性。但是，任何框架没有好坏之分，需根据项目的发展阶段和团队的整体能力做出合适的选择，不能一味追求“高大上”，从而影响项目的开发进度，本末倒置。
