余物宝Android组件化架构设计

MVP MVVM框架引入

1. MVC框架
   现在项目还是采用的是mvc框架，在mvc框架下Activity和Fragment承担了v c职责，会有如下的一些缺点：

• Activity和Fragment越来越多的同时承担了Controller和View的职责，导致他们变得及其臃肿且难以维护；
• 由于Controller和View的揉合，导致单元测试起来很困难；
• 回调嵌套太多，面对复杂业务时的代码逻辑不清晰，难以理解且不利于后期维护；
• 各层次模块之间职责不清晰等等

2. MVP框架
   google为了解决MVC的这些缺点，优化MVC框架，推出了MVP框架，MVP隔离了MVC中M与V的直接联系，靠Presenter来中转，因此，Activity及Fragment从MVC中的Controller中解放出来了，这会Activity主要做显示View的作用和用户交互。通过对比MVC与MVP，可以证实MVP模式的一些优点：

• 在MVP中，Activity的代码不臃肿；
• 在MVP中，Model的改动不会影响Activity(View)，两者也互不干涉，而在MVC中会；
• 在MVP中，可以实现方便地对Presenter的测试；
• 在MVP中，Presenter可以用于多个视图，但是在MVC中的Activity就不行

3. MVVM框架
   MVVM可以算是MVP的升级版，其中的VM是ViewModel的缩写，ViewModel可以理解成是View的数据模型和Presenter的合体，ViewModel和View之间的交互通过Data Binding完成，而Data Binding可以实现双向的交互，这就使得视图和控制层之间的耦合程度进一步降低，关注点分离更为彻底，同时减轻了Activity的压力。

P`_B%Y%66C20LBZ8({G{YWR.png

引用MVP框架后整个项目的结构如下：

_QKF_33%U%RXQRH775P{}D6.png

另外这套MVP，MVVM架构还为我们带来了一个额外的好处：我们有了足够明确的开发规范和标准。细致到了每一个类应该放到哪个包下，哪个类具体应该负责什么职责等等。这对于我们的Code Review、接手他人的功能模块等都提供了极大的便利。

响应式编程，链式编程方式引入

1. 响应式编程
   请先阅读响应式宣言
   响应式编程的特点如下：

• 响应性是指一个系统应该总是能够及时响应用户请求，并且保持很低的延迟。
• 弹性是指一个系统即使在部分组件开始出现故障的情况下也应该能够作出响应，将停机时间将至最低。
• 可伸缩性是指一个系统在负载增加时应该能够根据需求增加资源以确保响应性，但同时也应该能在负载降低时减少资源，保持高效的资源利用率。
• 消息驱动是指在一个系统的不同部分之间传递消息

2. 链式编程

• 链式编程思想
  是将多个操作（多行代码）通过点号(.)链接在一起成为一句代码,使代码可读性好。a(1).b(2).c(3)
• 链式编程特点
  方法的返回值是block,block必须有返回值（本身对象），block参数（需要操作的值）
• 链式编程优点
  逻辑清晰，结构明显

对于现阶段开发主要以引入第3方框架来实现，比如著名的Rxjava框架

依赖注入框架Dagger2引入

1. 什么是依赖注入

依赖注入就是非自己主动初始化依赖，而通过外部来传入依赖的方式，简单来说就是不使用 new 来创建依赖对象。使用 Dagger2 创建依赖对象，我们就不用手动初始化了。个人认为 Dagger2 和 MVP 架构是比较不错的搭配，Activity 依赖的 Presenter 可以使用该DI框架直接生成，实现解耦，简单的使用方式如下

public class MainActivity extends BaseActivity {
@Inject MainActivityPresenter presenter;
...
}

2.为什么使用依赖注入

首先我们需要知道，人们在很长的一段时间里都是利用控制反转原则规定：应用程序的流程取决于在程序运行时对象图的建立。通过抽象定义的对象交互可以实现这样的动态流程。而使用依赖注入技术或者服务定位器便可以完成运行时绑定。

使用依赖注入可以带来以下好处：

依赖的注入和配置独立于组件之外。
因为对象是在一个独立、不耦合的地方初始化，所以当注入抽象方法的时候，我们只需要修改对象的实现方法，而不用大改代码库。
依赖可以注入到一个组件中：我们可以注入这些依赖的模拟实现，这样使得测试更加简单。

AOP思路和框架引入

1. 编程思想
   面向切面编程，是一种设计理念，并非Spring特有。AOP通过横向分离关注点，把一些公共的辅助性组件代码从核心组件代码中剥离，降低组件之后的耦合性，提高组件代码的复用性
2. AOP在android中的应用
   AOP把软件系统分为两个部分：核心关注点和横切关注点。业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处都基本相似。AOP的作用在于分离系统中的各种关注点，将核心关注点和横切关注点分离开来。在Android App中，哪些是我们需要的横切关注点？个人认为主要包括以下几个方面：Http, SharedPreferences, Json, Xml, File, Device, System, Log, 格式转换等。Android App的需求差别很大，不同的需求横切关注点必然是不一样的。一般的App工程中应该有一个Util Package来存放相关的切面操作，在项目多了之后可以将其中使用较多的Util封装为一个Jar包供工程调用。
   在使用MVP和AOP对App进行纵向和横向的切割之后，能够使得App整体的结构更清晰合理，避免局部的代码臃肿，方便开发、测试以及后续的维护。

项目前期不做要求，以学习为主

项目组件化模块化

组件化开发就是将一个app分成多个模块，每个模块都是一个组件（Module），开发的过程中我们可以让这些组件相互依赖或者单独调试部分组件等，但是最终发布的时候是将这些组件合并统一成一个apk，这就是组件化开发。

组件化优点

• 业务模块间解耦
• 单个业务模块单独编译打包，加快编译速度
• 多团队间并行开发、测试
• 降低研发成本

整个项目分为三层，从下往上分别是：

• Basic Component Layer: 基础组件层，顾名思义就是一些基础组件，包含了各种开源库以及和业务无关的各种自研工具库；
• Business Component Layer: 业务组件层，这一层的所有组件都是业务相关的
• Business Module Layer: 业务module层，在Android Studio中每块业务对应一个单独的module，每个单独的Business Module都必须准遵守前面提到的MVP MVVM架构。

同时针对模块化我们也需要定义一些自己的游戏规则:

• 对于Business Module Layer，各业务模块之间的通讯跳转采用路由框架ARouter(阿里出品)来实现
• 对于Business Component Layer，单一业务组件只能对应某一项具体的业务，对于有个性化需求的对外部提供接口让调用方定制;
• 合理控制各组件和各业务模块的拆分粒度，太小的公有模块不足以构成单独组件或者模块的，我们先放到类似于CommonBusiness的组件中，在后期不断的重构迭代中视情况进行进一步的拆分
• 上层的公有的业务或者功能模块可以逐步下放到下层，合理把握好度就好；
• 各Layer间严禁反向依赖，横向依赖关系由各业务Leader和技术小组商讨决定。
• 上层依赖下层，下层以api接口的方式将数据暴露给上层，下层严禁依赖上层
• 基础组件层除共有第3方库外，相互之间不依赖

余物宝项目组件化拆分后结构如下

I@ZDJ3P7$MSC)9Q4%IUSVR3.png