Android软件设计框架——MVC、MVP、MVVM
对于许多初级的Android开发工程师，刚开始只是注重界面设计和逻辑跳转，对于一个小型APP来讲这也许用不了一个月就能搞定，仅仅为了实现任务需求而做，没有考虑过软件的编写成本和拓展难易程度，但是遇到大项目时，再这样一个个依赖包整合一行行代码敲下去，那三四个月能敲完代码就不错了，还得另加逻辑，恐怕一整套下来半年一年的时间就过去了。所以我们主张在做项目之前先进行项目的架构设计，这样不仅能节省后期码代码的时间增加开发效率，而且由于各个类要做的事情条理清晰，还不会在逻辑上弄的晕头转向，对以后业务上的拓展很有帮助。
作者：刘跃明
Android高级开发工程师，6年以上开发经验，对应用设计框架有着深刻的认识，负责京东商城结算模块的开发，设计并完成了结算配送模块的MVVM框架开发。
码农对APP的架构，好比于工人对楼房的奠基。先把架构底层整顺了整明白了，不仅可以使得后期的开发阶段事半功倍，而且可以保证整个APP在上线运行后一路稳定不会出现bug。
如果没有一个好的软件架构，随着代码量的逐渐增加和业务逻辑越来越复杂，后续再进行一个业务需求的开发你就发现编码成本越来越大，维护成本也越来越大，代码业务量变大以后程序员会面临几个问题：
● 代码耦合度高，不利于团队协作和阅读
● 开发维护成本大，加大开发成本
● 拓展比较难
● 不利于软件测试
可以看到如果你现在负责的是一个业务逻辑复杂项目，如果架构设计不好，那么你今后的开发将会越来越难，成本越来越大，因此我们有必要进行软件架构的设计。
那么现在的问题是应该怎么设计软件才是最合适的呢？
目前Android App的主流设计架构有三个：MVC、MVP、MVVM，我们先来看一张图：
通过这张图我们可以看出，其实不管是MVC、MVP还是MVVM，其实他们都是想让软件的架构层级清楚，实现纵向解耦，这样每一层都可以专注于自己层级的逻辑，既然MVC和MVP都是这个目的，为什么会随着业务越来越大而出现问题了呢，下面我们来仔细分析一下这三个架构的优缺点。
MVC框架
View：XML布局文件。
Model：实体模型（数据的获取、存储、数据状态变化）。
Controller：对应于Activity，处理数据、业务和UI。
介绍：
Android中纯粹作为View的XML视图功能太弱，我们大量处理View的逻辑只能写在Activity中，这样Activity就充当了View和Controller两个角色。所以，更贴切的说法是，这个MVC结构最终其实只是一个Model-View（Activity:View&Controller）的结构。
缺点：
层级之间耦合度太高，直接给以后的开发埋下了一个大大的雷。
总结：
MVC框架开发成本低，但是层级耦合度高，所以适合业务量较少的场景。
MVP框架
View: 对应于Activity和XML，负责View的绘制以及与用户的交互。
Model: 依然是实体模型。
Presenter: 负责完成View与Model间的交互和业务逻辑。
介绍：
前面我们说，Activity充当了View和Controller两个角色，MVP就能很好地解决这个问题，其核心理念是通过一个抽象的View接口（不是真正的View层）将Presenter与真正的View层进行解耦。Persenter持有该View接口，对该接口进行操作，而不是直接操作View层。这样就可以把视图操作和业务逻辑解耦，从而让Activity成为真正的View层。
缺点：
● P层和V层之间的交互式通过接口交互的，接口粒度不好控制，粒度太大解耦效果不好，粒度太小太过碎片化
● V层与P层还是有一定的耦合度。一旦V层某个UI元素更改，那么对应的接口就必须得改
● 复杂的业务同时也可能会导致P层太大，代码臃肿的问题依然不能解决
总结：
实现此框架需要一定的工作量，适合业务量中等的场景。
MVVM框架
View: 对应于Activity和XML，负责View的绘制以及与用户交互。
Model: 实体模型。
ViewModel: 负责完成View与Model间的交互，负责业务逻辑。
介绍：
MVVM通过数据绑定监听，实现了以数据为中心，这样我们就可以专注于业务数据的处理，而不用更多的管理View层的逻辑，View层和VIewModel层是完全剥离的，同时Model层和ViewModel层之间会有一个转换，把网络数据结构Bean转换成与View一一对应的Model，ViewModel和View不直接持有Model层的数据Bean，Model层的改动也不会影响View层和ViewModel层，实现Model和View的完全剥离。
优点：
● 数据驱动，只需关心数据即可，不用操作UI，在业务处理过程中简单很多
● 低耦合度，V层和逻辑数据层完全剥离，View的变化不影响数据逻辑层，数据逻辑层也不影响View层
● 可直接在工作线程中操作数据，不用担心更新UI是否在主线程
● 团队协作
● 可复用性，一个ViewModel可以对应多个View，尤其适合UI A/B Test场景
● 单元测试，不管是业务测试还是UI测试都是低耦合度的
总结：
实现有一定工作量，适合复杂的业务场景。
下面以我实际开发中的项目为例子，来给大家讲讲实现MVVM之后的好处。
项目介绍：
这是一个配送方式切换的页面，按上面的分解横向模块可以分为：Button模块、Description模块、Protocol模块、ShipInfo模块，点击Button可以切换配送方式，每个配送方式会对应不同的Description、Protocol、ShipInfo，而且每个不同的配送方式会有不同样式、业务逻辑和数量的配送信息（也就是ShipInfo）。
MVVM框架实现：
从这个框架图中可以看到，项目已经实现了模块之间的横向和纵向解耦，每个模块之间的View、ViewModel和Model都是分层的，不同模块ViewModel之间通过发送消息交互，实现很弱的耦合，这样的框架很明显会有以下好处：
● 低耦合度，不仅模块内的纵向是解耦的，而且模块间也是横向解耦的，层级特别清楚
● 团队协作，以后的需求即可以按View、ViewModel和Model进行分配，也可以按模块进行分配，也可以两者交叉分配，每个人独立完成自己的需求
● 易拓展，如果需求增加一个模块，那后续单独开发这个模块即可，不影响其他模块（前提是模块之间没有交互，如果有交互只需发送消息交互即可，不影响之前和现在的模块）
● 开发维护成本低，哪个模块的哪层有需求或者bug，只需相应解决该模块或者该层即可，不牵扯其他部分
● 易测试，因为业务和View是解耦的，进行单元测试或者UI测试都不会相互影响
不管任何一个软件架构目的都是为了提高生产力，只要找到你合适的软件架构，生产力就会大大提高，为你的公司节约大量的人力和时间成本。
长按识别图中二维码立即关注