Android组件化—2、组件化架构

转自jessyan大佬的github：

https://github.com/JessYanCoding/ArmsComponent

关于组件化的架构我们做了从上至下的划分，分别为：

宿主层、业务层、基础层。

1、宿主层

宿主层位于最上层, 主要作用是作为一个App壳, 将需要的模块组装成一个完整的App, 这一层可以管理整个App的生命周期(比如Application的初始化和各种组件以及三方库的初始化)

2、业务层

业务层位于中层, 里面主要是根据业务需求和应用场景拆分过后的业务模块, 每个模块之间互不依赖, 但又可以相互交互, 比如一个商城App由搜索,订单,购物车,支付等业务模块组成。

当然，每个业务模块都可以拥有自己独有的sdk依赖或UI资源，如有通用的 可以抽离到CommonSDK或CommonRes中由基础层管理。

2.1 业务模块的拆分

业务拆分之前需根据初期的产品需求到后期的运营规划结合起来清晰的梳理一下业务在未来可能会发生的发展, 考虑业务划分的维度，确定业务之间的边界, 以及可能会发生的变化, 最后再确定下来真正需要拆分出来的业务模块再进行拆分。

3 基础层

基础层位于最底层,里面又包括核心基础业务模块、公共服务模块、基础 SDK 模块,核心基础业务模块和公共服务模块主要为业务层的每个模块服务,基础 SDK。

模块含有各种功能强大的团队自行封装的SDK以及第三方SDK（列如网络请求、图片加载）。相当于整个机器的发动机，为整个平台的基础设施建设提供源源不断的动力。

3.1 核心基础业务

核心基础业务为业务层的每个业务模块提供一些与业务有关的基础服务,整个项目都依赖于这一块业务逻辑，

比如在项目中以用户角色分为 2 个端口, 用户可以扮演多个角色, 但是在线上只能同时操作一个端口的业务,

这时每个端口都必须提供一个角色切换的功能, 以供用户随时在多个角色中切换,

这时在项目中就需要提供一个用于用户自由切换角色的管理类作为核心基础业务被这 2 个端口所依赖(类似 拉勾, Boss

直聘等App可以在招聘者和应聘者之间切换、全日制的家长端、学生端、教师端的账号角色切换、或者学员切换)

核心基础业务的划分应该遵循是否为业务层大部分模块都需要的基础业务, 以及一些需要在各个业务模块之间交互的业务, 都可以划分为核心基础业务

3.2 公共服务

公共服务是一个名为CommonService的Module, 主要的作用是用于业务层各个模块之间的交互(自定义方法和类的调用), 包含自定义Service接口, 和可用于跨模块传递的自定义类

主要流程是:

提供服务的业务模块:

在公共服务(CommonService) 中声明Service接口 (含有需要被调用的自定义方法), 然后在自己的模块中实现这个Service接口, 再通过ARouter API暴露实现类

使用服务的业务模块:

通过ARouter的API拿到这个Service接口(多态持有, 实际持有实现类), 即可调用Service接口中声明的自定义方法, 这样就可以达到模块之间的交互

跨模块传递的自定义类:

在公共服务中定义需要跨模块传递的自定义类后

(Service中的自定义方法和EventBus中的事件实体类都可能需要用到自定义类), 就可以通过ARouter API,

在各个模块的页面之间跨模块传递这个自定义对象

(ARouter要求在URL中使用Json参数传递自定义对象必须实现SerializationService接口)

最好在 CommonService 中给每个需要提供服务的业务模块都建立一个单独的包, 然后在这个包下放 Service 接口 和 需要跨模块传递的自定义类, 这样更好管理。

下一篇：组件化如何具体实现