随着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的一些想法。

一、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的协调，连接处理逻辑的。

二、从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在业务逻辑复杂时的代码臃肿。

三、从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技术，这项技术的思想并不新颖，最初由微软提出，在前端开发中已经有成熟的应用。下面对其进行简要的介绍。

四、Android中的Data Binding

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

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

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

  • ObservableField的get方法可能无法返回界面实时更新的内容
1
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没有绝对好坏，在软件编程过程中，也没必要非此即彼，最重要的是让软件高内聚、低耦合、可维护、可扩展，至于架构，根据实际情况选择吧。