基于MVP的 Android App架构设计与案例分析

目 录

第一章 绪论 1
1.1 研究背景 1
1.2 Android 架构的现状和发展 1
1.2.1 Android 架构的初期状态 1
1.2.2Android 4.0 之后，Fragment 的引入 1
1.2.3MVP & MVVM 2
1.2.4 事件驱动编程 2
1.2.5 RxJava 带来的革命 2
第二章 架构需求分析 3
2.1 需求目标 3
2.1.1 目标产品 3
2.1.2 目标用户(开发者) 3
2.2 开发需求 3
2.2.1 开发期的功能需求 3
2.2.2 开发期的质量需求 4
2.3 用户级需求 4
2.3.1 用户级功能需求 4
2.3.2 运行期质量需求 5
2.4 需求总结 5
第三章 架构整体设计 6
3.1 架构逻辑设计 6
3.1.1 架构图 6
3.1.2 架构结构划分 6
3.1.3 架构特点 7
3.1.4 架构核心 Common 7
3.2 项目开发期间架构设计 9
3.2.1 工程结构 9
3.2.2 使用本架构构建 App 9
3.2.3 编译期间依赖关系 11
3.2.4 模块隔离开发 11
3.3 运行期间架构 12
3.3.1 运行期间的模块加载升级 12
3.3.2 运行期组件依赖 12
3.3.3 页面导航和业务服务导航 12
第四章 分层架构 13
4.1 分层概述 13
4.2 MVC 分层架构 13
4.2.1 MVC 简介 13
3.2.2 Model 模型层 14
4.2.3Controller 控制器 15
4.2.4View 层 15
4.2.5 MVC 所存在的问题 15
4.3 MVVM 分层架构 17
4.3.1 MVVM 简介 17
4.3.2 MVVM 各层 17
4.3.3 DataBinding 原理简介 18
4.3.4 MVVM 缺点 19
4.4 MVP 分层架构 19
4.4.1 MVP 简介 19
4.4.2 Model 层设计 20
4.4.3 View 层设计 20
4.4.3 Presenter 层设计 21
4.4.4 MVP 的统筹 协议层设计 21
4.4.5 MVP 的优缺点 22
4.4.6 MVP 与 MVC 的不同。 22
第五章 组件化 24
5.1 组件化介绍 24
5.2 本架构中组件的实现 24
5.3Component 的依赖 25
5.4Component 的生命周期 25
5.5MVP Component 26
5.6API Component 27
5.7AppComponent 28
5.7.1 AppComponent 含义 28
5.7.2 各个基础组件 29
5.8组件管理器 ComponentManager 31
第六章 DI 依赖注入 33
6.1 依赖注入定义 33
6.2 依赖注入意义 33
6.3 Android 中的依赖注入 Dagger2 34
6.3.1 简介 34
6.3.2 Dagger2 中的重要概念 34
6.4 本架构中的依赖注入 35
6.4.1 MVP 三层依赖组装 35
6.4.2 App 全局组件依赖 36
6.4.3 业务组件依赖拼装 37
第七章 AOP 面向切面编程 40
7.1 AOP 的定义 40
7.2 在 Android 上使用 Aspectj 实现 AOP 40
7.3 动态织入实现原理 41
7.4 AOP 在本架构中的使用 42
7.4.1 动态权限检测 42
7.4.2 登陆检测 43
7.4.3 性能检测 & Log 43
7.4.4 异步与主线程 44
第八章 Bundle 模块化容器化 46
8.1 定义 46
8.2 意义 46
8.3 Atlas & Small 46
8.3.1 简介 46
8.3.2 原理 47
8.4 本架构中的模块化 48
第九章 Router 页面路由 50
9.1 背景 50
9.2 Intent 导航遇到的问题 50
9.3 意义 50
9.4 页面路由的使用 51
9.5 页面路由的原理及实现 52
9.5.1 页面发现 52
9.5.2 页面分发 53
第十章 事件驱动 54
10.1 事件驱动定义 54
10.2 事件驱动意义 54
10.3 事件驱动框架原理 54
10.4 事件框架的实现 EventPoster 56
10.4.1 EventPoster 优势简述 56
10.4.2 模块 Handler 以及分发 57
10.4.3 性能优化 57
10.4.4 防止 Leak 58
第十一章 框架原理及实践 59
11.1 自己动手实现 JSON ORM 框架 59
11.2 图像异步加载框架原理及实现 63
11.2.1 Cache 63
11.2.2 线程池 64
11.2.3 图片压缩 64
11.2.4 其他优化 64
11.3 Http 请求框架 Retrofit 65
11.3.1 原理 65
11.3.2 源码分析 65
第十二章 案例实践 68
12.1 案例简述-数读 68
12.2 需求简述-数读 68
12.3 重构之前的程序结构-数读 68
12.4 重构后的程序结构-数读 69
12.4.1 架构裁剪-数读 69
12.4.2 UML 类图-数读 70
12.4.3 主要功能需求-数读 70
12.4.4 重构带来的改变 73
结 论 75
致 谢 76
参 考 文 献 77

2.1 需求目标
2.1.1 目标产品

第二章 架构需求分析

本架构的目标产品是标准的 C/S 软件系统中的 Android 客户端产品，经过调查市 面上百分之八十以上的 App 都属于此类型。
所以本架构需要分离出这类 App 共同的特征，并且为这些共同特征提供解决方案。 此外在部分非本类型的 App，通过架构裁剪和简单调整，本架构依然可以适用于这
些 App。比如文件管理器类型的 App，可能并不需要联网通讯，则可以酌情裁剪掉网 络请求组件。
2.1.2 目标用户(开发者)
本架构的目标开发者是中小型或者创业类型的团队。这部分用户在互联网创业热潮 的今天占了开发者很大一部分比重。
这类团队人员往往较少，并且团队成员的经验多有不足。这些团队在接手项目的时 候往往不知道怎么架构一个项目，转而去借鉴互联网上的一些开源项目，而这些开源项 目有可能已经老旧过时。这样的话项目建设初期就没有打下一个良好的基础。
2.2 开发需求
2.2.1 开发期的功能需求

1. 开发者希望架构能够提供其开发所需要的各种公共组件，这样的话开发者可以 将精力放在业务本身的开发上。
2. 开发者希望架构能使他们开发的业务流程更加清晰，这就需要我们对主体业务 进行架构分层。而在大多数 C/S 架构的 Android App 中，主要的业务流程无非就是用 户操作 -> 请求服务器 -> 处理返回数据 -> 显示给用户。这个是一类非常统一类似的 业务场景，我们需要做的就是怎么让这个流程更加清晰规范。
3. 开发者不希望写大量的重复代码，在客户端开发中，开发者往往身陷于各种重 复的状态检测，和业务调用前的准备工作:例如检查网络，检查权限，检查用户登陆状态， 检查点击事件防止双击等等一系列的类似工作。所以开发者希望架构能帮助其解决这样 问题。在本架构中我们使用 AOP 为开发者解决了这一难题。
4. 开发者往往要求平滑更加平滑的业务添加，在现今开发中，产品和设计为了提

高产品的竞争力往往高频率的提出各种新的需求，一个不成熟的架构往往会拖慢这一进 度。小至一个界面的需求添加，大到一个完整的大型业务模块。这就要求我们对架构进 行科学的业务切割，架构需要把握细粒度定义业务划分边界并管理他们之间的依赖和生 命周期，这就要用到组件化了。在开发期间的团队协作中，代码的管理和团队人员的任 务的管理也让人头疼，本架构引入模块让各个团队各司其职，工程开发期间互相不受影 响。