Android设计架构：MVC/MVP/MVVM

---

为何需要使用架构

Android框架搭建1-架构选型

---

• Activity中包含大量控件说明和findViewById，或是ButterKnife的BindView，且Activity中代码冗长，包括控件数据绑定、业务逻辑处理、时间处理等；
• 网络请求：HttpUrlConnection/OkHttp及对应的回调处理、异常处理；
• 权限申请：分布于项目各个角落，修改权限请求方式时需逐个搜索修改，且可能存在遗漏的情况；
• 操作数据库的代码分布于主线程和子线程，且数据库有字段修改时，可能造成获取数据异常；
• 其他

架构设计的目的：使程序模块化，做到模块内部的高内聚和模块之间的低耦合。在开发的过程中，开发人员只需专注于提高程序开发的效率，并且更容易进行后续的测试及定位问题。
Android App的设计架构：MVC,MVP,MVVM与架构经验谈

MVC：Model View Controller

• View（视图层）：负责界面数据的展示，与用户进行交互，主要是XML布局文件，使用时方便引入，同时便于后期界面修改。逻辑中与界面对应的id不变化则不需要修改代码，增强代码的可维护性；
• Model（模型层）：负责处理数据的加载或存储，一般用来保存数据的状态，如数据存储，网络请求，同时通过某种事件机制通知View状态的改变来刷新View；
• Controller（控制层）：负责逻辑业务的处理，由View根据用户行为触发并响应来自View的用户交互，然后根据View的事件逻辑来修改对应的Model；

Android中存粹作为View的XML视图功能太弱，Activity基本上是View和Controller的合体，既要负责视图的显示又要加入控制逻辑，承担的功能过多，代码量大。

实例分析
Android 设计模式之MVC，从一个实例中来理解MVC
Android MVC 模式的介绍 与 实战

MVP：Model View Presenter

• View：负责View的绘制以及与用户的交互，对应于Activity和XML
• Model：负责提供数据，实体模型
• Presenter：负责完成View与Model之间的交互与业务逻辑
• *View interface：需要View实现的接口，View通过View interface与Presenter进行交互，降低耦合，方便进行单元测试

优点：（1）模型与视图完全分离，可以修改视图而不影响模型；（2）更高效的使用模型，原因在于所有交互都发生在Presenter内部；（3）可以将一个Presenter用于多个视图而无需改变Presenter的逻辑（视图的变化总是比模型变化频繁）；（4）将逻辑放在Presenter中，可以脱离用户接口来测试（单元测试）；

存在的问题

• 转移逻辑操作之后可能部分较为复杂的Activity内代码量仍不小，需要在分层的基础上再加入模板方法：在Activity内部分层
• Model中整体代码量大：做好模块划分，进行接口隔离，内部分层；
• 强化Presenter的作用：将所有逻辑操作放在Presenter中也易造成Presenter内的代码量过大；在Presenter负担过大时，考虑在UI和Presenter之间设置中介Mediator，将数据校验组装等轻量级逻辑操作放在Mediator中；在Presenter和Model之间使用代理Proxy，通过上述两者分担部分Presenter的逻辑操作，但整体框架的控制权还是在Presenter手中；

两张图看懂Android开发中MVC与MVP的区别

MVVM

如何构建Android MVVM 应用框架
Android MVVM架构分析
Android官方MVVM框架实现组件化之整体结构

• View：对应于Activity和XML，负责View的绘制和用户交互；
• Model：实体模型；
• ViewModel：负责完成View和Model之间的交互，负责业务逻辑；

特点：

1. 数据驱动：常规模式数据变化需要更新UI时，需要先获取UI的引用，然后再更新UI，获取用户的输入和操作也需要通过UI控件的引用，而在MVVM中，这些通过数据驱动来自动完成，数据变化会自动更新UI，UI的改变也自动反馈到数据层，数据成为主导因素。因此MVVM在业务逻辑处理中只关心数据，无需直接和UI打交道，业务处理过程简单方便；
2. 低耦合度：MVVM模式中，数据独立于UI。数据和业务逻辑处于一个独立的ViewModel中，ViewModel只需要关注数据和业务逻辑，不需要和UI或者控件打交道。UI想怎么处理数据都由UI自己决定，ViewModel不涉及任何和UI相关的事，也不持有UI控件的引用。即便是控件改变了（比如：TextView换成EditText），ViewModel也几乎不需要更改任何代码。它非常完美的解耦了View层和ViewModel，解决了上面我们所说的MVP的痛点。
3. 更新UI：在MVVM中，数据发生变化后，我们在工作线程直接修改（在数据是线程安全的情况下）ViewModel的数据即可，不用再考虑要切到主线程更新UI了，这些事情相关框架都帮我们做了。
4. 可复用性：一个ViewModel可以复用到多个View中。同样的一份数据，可以提供给不同的UI去做展示。对于版本迭代中频繁的UI改动，更新或新增一套View即可。如果想在UI上做A/B Testing，那MVVM是你不二选择。
5. 单元测试：ViewModel层做的事是数据处理和业务逻辑，View层中关注的是UI，两者完全没有依赖。不管是UI的单元测试还是业务逻辑的单元测试，都是低耦合的。在MVVM中数据是直接绑定到UI控件上的（部分数据是可以直接反映出UI上的内容），那么我们就可以直接通过修改绑定的数据源来间接做一些Android UI上的测试。

两种方案

• DataBinding库
• ACC

其他

选择恐惧症的福音！教你认清MVC，MVP和MVVM