浅谈Android MVC、MVP、MVVM架构

为什么做架构设计

谈架构之前，我们应该理解，为什么需要做架构设计？

这个问题，单看网上各种架构优缺点分析、什么解耦、方便测试之类的，是很难有深入的理解的，必须要结合实际的项目经验去思考。相信很多小公司的同学会和我有一样的疑问，没有这些所谓的架构，照样代码能写的很嗨，尤其是在项目迭代初期和写一些简单页面时，直接编程反而更加直观更加快速。架构似乎并没有那么牛逼，能够显著提高我们的开发效率。

其实，架构设计是软件复杂性的产物，它帮助我们把复杂的东西划分成更小的结构，更加便于理解和维护，说白了就是我们接触的项目不够复杂，有架构和无架构之间的差距并不是很大而已。试想一下，在淘宝那样复杂的页面中修改一些代码会是什么情况？无架构的情况下，可能会需要在几千行的Activity代码中去改逻辑，而在MVVM架构中可能只需要在ViewModel和XML文件中修改几个字段而已。

当然，大家可能会反驳，几千行的Activity代码是因为封装没做好等等，确实是这样，自己去做代码拆分、封装也是可以的，这其实就是最初级的架构设计。而架构是什么？架构其实就是这种方法的总结而已，为解决这些复杂性提供了可靠的模板方案。其实架构设计也不是很高深的东西，本质上还是离不开那些软件设计原则，更多的是这些原则的归纳总结，解决具体场景问题的最佳方案而已。学习一个架构，更多是要理解里面的设计思想，能够结合实际项目最好。下面就结合个人的一些项目经验来分享一下个人对Android MVC、MVP、MVVM架构的一些理解吧。

MVC架构

MVC架构也是Android开发最初的模式：XML作为View层、SQLite/文件/网络等作为Model层，Activity作为Controller负责连接View层和Model层。实际开发过程中，Activity作为Controller职责过重，所有的逻辑处理代码、页面展示代码都会集中在这里面，最终导致了几千行代码的Activity类。想想维护这样一个庞大的类会是多么困难，而且这个类不仅涉及页面展示，还涉及逻辑处理&数据获取。我也有过这样的经历，做一个功能，代码看了半天，上线还得小心翼翼生怕影响到其他功能，这也是MVC架构的最大痛点吧。

当然，这种情况下可以进行代码的拆分封装，拆成多个Helper or Util，实现代码的复用，但终归View的逻辑绑定在Activity中，而且Activity承担着Controller的职责，复杂性不可避免，修改的影响面也不好控制。

MVP架构

MVP架构相比于MVC主要有两个进步：
1、单一职责：引入Presenter解放了Activity Controller的职责，把后续代码修改的关注点分离，影响面拆分开来了，也就是说Activity只要保证View对数据的展示正确即可，然后重点关注Presenter中的逻辑代码和数据获取即可
2、解耦：Presenter和View之间通过接口的形式进行依赖，没有强耦合，Presenter也可以不依赖UI进行单元测试（这其实也是国内的一大问题，对测试不够看重，导致这个优点不是很明显了）
MVP核心点是定义出Presenter和View的接口，这个主要是根据用户的交互定义出Presenter的交互接口，并根据页面变化定义出View的接口，然后去实现两者的交互即可，详细见官方demo

说完MVP的优点，也来吐槽一下MVP的缺点吧：MVP最致命的缺点就是Presenter和View的接口定义不具备很强的复用性，导致开发成本的提升。我们项目之前有推过MVP架构，包括BasePresenter和BaseActivity的一些封装都有做，结果还是发现每张页面的开发有点过于繁琐，需要定义出一堆的Presenter和View的接口，这些接口的定义粒度和复用性真的很难把控，尤其是在项目初期，大家甚至懒得定义这些东西了，导致后面不了了之。这其实也警醒了我，架构设计不能是空谈，需要结合实际项目进行落地的，最终目的还是为了提高开发效率。

MVVM

MVVM其实和MVP是类似的结构，只不过把Presenter替换成了ViewModel，但这一点就是非常大的进步！ViewModel和Presenter都是连接View和Model层，但是思想完全不一样，上面有说过Presenter是面向用户交互来定义接口的，而ViewModel是面向数据流的，或者说面向View控件的，这种有什么好处呢？大家想想看，View的控件种类是有限的，它与Model的绑定方式也就是有限的，这样的话就可以把这些绑定关系的处理做成自动化模板的方式了，这就是DataBinding Library做的事情，把View和Model的绑定关系自动化工程化，无需开发者操心，而开发者只需要重点关注数据变化逻辑即可，关注点更少了，是不是开发效率就更高了！

其实，仔细看这些架构、框架的演进过程，终极目标还是为了更高效快捷的开发，而主要手段就是通过标准化模板化的方法，把一些东西做成自动化，节省人力成本，同时也减少了人为误差的风险。这是我觉得学到的最重要的思想吧，也是我们在工作过程中应该思考的，是否有这种工程化自动化的方式去偷懒~