Android 项目开发整体架构设计与演进
前言
设计 App 的整体框架，首先要清楚我们做的是什么。一般我们与网络交互数据的方式有两种：主动请求 (HTTP) 和长连接推送。
结合网络交互数据的方式来说一下我们开发的 App 的类型和特点：
- 数据展示类型的 App：特点是页面多，需要频繁调用后端接口进行数据交互，以 HTTP 请求为主；推送模块、IM 类型 App 的 IM 核心功能以长连接为主，比较看重电量、流量消耗。
- 手机助手类 App：主要着眼于系统 API 的调用，达到辅助管理系统的目的，网络调用的方式以 HTTP 为主。
- 游戏：一般分为游戏引擎和业务逻辑，业务脚本化编写，网络以长连接为主，HTTP 为辅。
一般我们做的 App 都是类型 1，简要来说这类 App 的主要工作就是：
- 把服务端的数据拉下来给用户展示
- 把用户在客户端修改的数据上传给服务端处理
所以这类 App 的网络调用相当频繁，而且需要考虑到网络差、没网络等情况下 App 的运行。成熟的商业应用的网络调用一般是如下流程：
UI 发起请求 - 检查缓存 - 调用网络模块 - 解析返回 JSON / 统一处理异常 - JSON 对象映射为 Java 对象 - 缓存 - UI 获取数据并展示
这之中可以看到很明显职责划分，即：数据获取、数据管理、数据展示。确定了职责，就可以进入正题了。
1. 传统的 Android App 架构
Android 最原生也是最基础的架构，可以理解为 MVC，Controller 即是 Activity 和 Fragment，但是这两者掌握了 Android 系统中绝大多数的资源，并且在内部直接控制 View，因此传统的 Android App 一般是以 Activity 和 Fragment 为核心，将网络模块、数据库管理模块、文件管理模块、常用工具类等分离成若干工具类包，供 Activity 和 Fragment 使用。
这是比较基础的 Android 项目架构，市面上大部分 App 都是这种造型。
- 优点：开发简单，以页面为导向；如果构建水平可以，项目就已经基本实现模块化，基于 Activity、Fragment 这两个上帝般的存在，很多事情直接就妥了，不用绕。
- 缺点：维护难，因为是以页面为导向的，有些需要共用的业务逻辑就会很烦，Don't Repeat Yourself，你要不要 Repeat？不想 Repeat 就要写模块，慢慢的项目就会多出一堆乱七八糟的小模块。另一方面，测试很困难，因为所有的数据处理都在 Activity 和 Fragment，假如现在想先用假数据显示，就要直接改 Activity 和 Fragment 的数据控制逻辑。
2. 分层架构
如果仔细看自己的项目，可以发现绝大多数数据处理的代码是不需要使用 Activity 和 Fragment 持有的资源的（比如 Context），而很多时候我们需要多个页面共用一套数据和请求逻辑，很经典的例子是应用中的 User 对象，一般来说都是全局单例。
这些全局的数据源写多了，很容易就能想到将数据处理统一抽出来形成一层，向上层提供数据接口，而上层并不关心数据的来源（内存、缓存、网络），因为不用从 Activity 和 Fragment 拿资源而且主要工作是数据处理，所以这一层是 UI 无关的，大幅提升了复用性，我把这一层称为 DataManager 层。
Activity 和 Fragment 剥离了数据处理的责任后，持有 DataManager 的引用，负责获取数据并展示，向 DataManager 传递数据，绝不进行网络请求和缓存读写。
举一个例子，分页加载一般来说分页加载接口返回的数据是这样的：
{
"code": 0,
"message": "success",
"data":
......
