Android App的架构设计：从VM、MVC、MVP到MVVM

随着Android应用开发规模的扩大，客户端业务逻辑也愈来愈复杂，已然不是简单的数据展现了。如同后端开发遇到瓶颈时采用的组件拆分思想，客户端也须要进行架构设计，拆分视图和数据，解除模块之间的耦合，提升模块内部的聚合度。

开始以前先上一张内部分享时用的PPT图：

以上是笔者在客户端开发过程当中面临的问题，涉及到如下四个主题：

1. Android App的架构设计：从VM、MVC、MVP到MVVM
2. Android App的网络访问：支持REST、HTTPS及SPDY的Retrofit+Okhttp
3. Android App的响应式编程：RxJava/RxAndroid解决方案
4. Android App的依赖注入：Dagger2和ButterKnife使用

本文将从架构设计入手，分享笔者在Android开发中采用MVC、MVP及MVVM的一些想法。

1、Android原生开发中的MVC

Android原生开发采用XML文件实现页面布局，经过Java在Activity中开发业务逻辑，这种开发模式实际上已经采用了MVC的思想，分离视图和控制器。MVC模式（Model–view–controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。

MVC模式最先由Trygve Reenskaug在1978年提出，是施乐帕罗奥多研究中心（Xerox
PARC）在20世纪80年代为程序语言Smalltalk发明的一种软件架构。MVC模式的目的是实现一种动态的程序设计，使后续对程序的修改和扩展简化，而且使程序某一部分的重复利用成为可能。除此以外，此模式经过对复杂度的简化，使程序结构更加直观。软件系统经过对自身基本部分分离的同时也赋予了各个基本部分应有的功能。专业人员能够经过自身的专长分组：

• 控制器（Controller）- 负责转发请求，对请求进行处理。
• 视图（View） - 界面设计人员进行图形界面设计。
• 模型（Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(能够实现具体的功能)。

——以上内容来自《维基百科》

在Android编程中，View对应xml布局文件，Model对应实体模型（网络、数据库、I/O），Controller对应Activity业务逻辑，数据处理和UI处理。以下图所示。

但在实际开发过程当中，纯粹做为View的各个XML文件功能较弱，Activity基本上都是View和Controller的合体，既要负责视图的显示又要加入控制逻辑，承担的功能不少，致使代码量很大。全部更贴切的目前常规的开发说应该是View-Model模式，大部分都是经过Activity的协调，链接处理逻辑的。

2、从MVC过渡到MVP

在业务逻辑稍微复杂一点的页面，Activity的代码超过一千是很容易的，若是做者又恰好读过《如何写出没法维护的代码》，那么恭喜后来接手该代码的童鞋，接下来的几个月会很酸爽的。。。

既然Activity存在代码量过大的问题，那天然会想到进行拆分。上节说到Android原生开发采用了MVC的思想，但Activity并非一个标准的MVC模式中的Controller，它的首要职责是加载应用的布局和初始化用户界面，并接受并处理来自用户的操做请求，进而做出响应。随着界面及其逻辑的复杂度不断提高，Activity类的职责不断增长，以至变得庞大臃肿。

MVP是从MVC过渡而来，MVP框架由三部分组成：View负责显示，Presenter负责逻辑处理，Model提供数据。Android开发从MVC过渡到MVP，最主要的变化就是将Activity中负责业务逻辑的代码移到Presenter中，Activity只充当MVP中的View，负责界面初始化以及创建界面控件与Presenter的关联。

这样拆分以后，Presenter承担了大量的逻辑操做，避免了Activity的臃肿。整个架构以下图所示。

• View(Activity)负责响应用户操做，经过Presenter暴露的方法请求数据；
• Presenter在获取数据后，经过View(Activity)暴露的方法实现界面控制（showLoading/showUsers）；
• Presenter的数据是经过Model来获取的，Model包含网络、数据库以及I/O等；
• Model经过回调的方式将数据传到Presenter中。

采用MVP明显的优势是避免了传统开发模式中View和Model耦合的状况，提升了代码可扩展性、组件复用能力、团队协做的效率以及单元测试的便利性。但也有一些缺点，好比：

• Model到Presenter的数据传递过程须要经过回调；
• View(Activity)须要持有Presenter的引用，同时，Presenter也须要持有View(Activity)的引用，增长了控制的复杂度；
• MVC中Activity的代码很臃肿，转移到MVP的Presenter中，一样形成了Presenter在业务逻辑复杂时的代码臃肿。

3、从Presenter到ViewModel

MVVM是Model-View-ViewModel的简称，从实际效果来看，ViewModel是View的数据模型和Presenter的结合，具体结构以下图所示：

• View（视图层）采用XML文件进行界面的描述；
• Model（模型层）经过网络和本地数据库获取视图层所需数据；
• ViewModel（视图-模型层）负责View和Model之间的通讯，以此分离视图和数据。

View和Model之间经过Android Data Binding技术，实现视图和数据的双向绑定；ViewModel持有Model的引用，经过Model的方法请求数据；获取数据后，经过Callback（回调）的方式回到ViewModel中，因为ViewModel与View的双向绑定，使得界面得以实时更新。同时，界面输入的数据变化时，因为双向绑定技术，ViewModel中的数据得以实时更新，提升了数据采集的效率。

采用ViewModel解决MVP中View(Activity)和Presenter相互持有对方应用的问题，界面由数据进行驱动，响应界面操做无需由View(Activity)传递，数据的变化也无需Presenter调用View(Activity)实现，使得数据传递的过程更加简洁，高效。

在Android中实现MVVM架构的核心支撑技术是Google去年I/O大会开源的Data binding技术，这项技术的思想并不新颖，最初由微软提出，在前端开发中已经有成熟的应用。下面对其进行简要的介绍。

4、Android中的Data Binding

学习Data Binding主要推荐两个内容：

1. 官方的Data Binding教程
2. 精通 Android Data Binding

这两篇文章中已经将Data Binding的基本内容描述的很详细了。这里仅列两个在实践中遇到的坑，抛砖引玉。

• ObservableField的get方法可能没法返回界面实时更新的内容

public ObservableField<String> username = new ObservableField<>();

上述username表示用户名，在界面上可能会与EditText绑定。经过username的set方法能够设置EditText显示，但若是输入变动后，经过get方法却不必定能及时返回界面的数据。

• Data Binding依然有不少支持的很差的组件（listview，recyclerView等），不可能经过给全部组件绑定ViewModel从而实现Activity没有业务逻辑操做。另外，ViewModel获取数据以后，也不可能把全部数据直接绑定到界面，有些也须要经过回调传到Activity中。

从MVC、MVP到MVVM，其实是模型和视图的分离过程。MVC中模型和视图没有彻底分离，形成Activity代码臃肿，MVP中经过Presenter来进行中转，模型和视图完全分离，但因为V和P互相引用，代码不够优雅。ViewModel经过Data Binding实现了视图和数据的绑定，解决了这种MVP的缺陷，但目前也存在Data Binding还不成熟的问题。

其实，MVC、MVP及MVVM没有绝对好坏，在软件编程过程当中，也不必非此即彼，最重要的是让软件高内聚、低耦合、可维护、可扩展，至于架构，根据实际状况选择吧。