Android应用开发规模的扩大，客户端业务逻辑也越来越复杂，已然不是简单的数据展示了。如同后端开发遇到瓶颈时采用的组件拆分思想，客户端也需要进行架构设计，拆分视图和数据，解除模块之间的耦合，提高模块内部的聚合度。
开始之前先上一张内部分享时用的PPT图：
以上是笔者在客户端开发过程中面临的问题，涉及到以下四个主题：
Android App的架构设计：从VM、MVC、MVP到MVVM
Android App的网络访问：支持REST、HTTPS及SPDY的Retrofit+Okhttp
Android App的响应式编程：RxJava/RxAndroid解决方案
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等；
安卓应用的架构设计:从VM, MVC, MVP到MVVM
