组件化框架简介
1 简介
1.1 什么是组件化?
App或模块拆分成多个⼦模块, 每个⼦模块可以独⽴编译和运⾏, 也可以任意组合成另⼀个新的App
组件化简单概括就是把⼀个功能完整的App
每个模块即不相互依赖但⼜可以相互交互, 遇到某些特殊情况甚⾄可以升级或者降级
1.2 为什么要组件化?
现在的项⽬随着需求的增加规模变得越来越⼤, 规模的增⼤带来了很多烦恼, 各种业务错中复杂的交织在⼀起, 每个业务模块之间, 代码没有约束, 带来了代码边界的模糊, 代码冲突时有发⽣, 更改⼀个⼩问题可能引起⼀些新的问题, 牵⼀发⽽动全⾝, 增加⼀个新需求, 瞻前顾后的熟悉了⼤量前辈们写的代码后才敢动⼿, 编译时间也不在断增加, 开发效率极度的下降, 在这种情况下组件化的出现就是为了解决以上的烦恼 1.3 分析现有的组件化⽅案
多⼯程+多 Module
多 P ⼯程(以页⾯为单元的代码隔
多 Module+多 P ⼯程(以页⾯为单元的代码隔
App更是以多⼯程
多 Module的结构(, 美团等超级App
很多⼤⼚的组件化⽅案是以多⼯程
多⼯程+多 Module
Git Submodule创建多个⼦仓库管理各个模块的代码, 并将各个模块的代码打包成AAR
Maven仓库
AAR上传⾄私有Maven
离⽅式)
离⽅式)的三级⼯程结构), 使⽤Git Submodule
使⽤远程版本号依赖的⽅式进⾏模块间代码的隔离
1.4 如何选择组件化⽅案?
按照康威定律, 系统架构的设计需要根据组织间的沟通结构, 因为现在⼤部分项⽬的规模和开发⼈员的数量以及结构还不⾜以需要某些⼤⼚发布的组件化⽅案⽀撑(⼤⼚的组织结构和项⽬规模都⾮常庞⼤, 他们的⽅案不⼀定完全适合所有公司的项⽬), 进⾏更严格更细粒度的代码间以及模块间的隔离, 盲⽬的使⽤某些组件化⽅案, 可能会带来开发效率降低, 开发成本远⼤于收益等情况, 性价⽐变低, 作为项⽬负责⼈, 应该根据项⽬⽬前的规模以及开发⼈员的组织结构去选择⽬前最适合的组件化⽅案, 做到以项⽬实际情况去制定技术⽅案, ⽽不是盲⽬跟随某些⼤⼚的技术⽅案让项⽬和开发⼈员花费⼤量时间去调整和适应
2 组件化⽅案描述射频调制器
多 Module的结构, 由于Demo
Demo较⼩仅仅为了展⽰基本规范, 所以也只是采⽤源码依赖并没有做到远
单⼯程+多 Module
Component_base ⽬前采⽤的是单⼯程
多分⽀的⽅式, 这样也是对于开发初期, 项⽬规模还较⼩, 开发⼈员也较少时, 开发效率较⾼的⽅
单仓库+多分⽀
程版本号依赖组件, 代码管理也只是采⽤单仓库
Maven仓库管理组件版本
多 Module, 并使⽤私有Maven
多⼯程+多 Module
案, 如果您的项⽬规模较⼤, 开发⼈员众多, 就可以采⽤上⾯提到的多⼯程
世界上没有⼀个⽅案可以完美到兼顾所有情况, 并且还满⾜所有⼈, 所有项⽬的需求, 所以项⽬负责⼈必须按照项⽬实际情况做出灵活的调整, 才能做出最适合⾃家项⽬的⽅案
翻板百叶2.1 架构图⼀览
Component_base 组件化架构图
2.2 架构图详解
⽬前架构⼀共分为三层, 从低到⾼依次是基础层, 业务层和宿主层, 由于⽬前项⽬较⼩⼈员较少所以三层都集中在⼀个⼯程中, 但您可以根据项⽬的规模和开发⼈员的数量拆分成多个⼯程协同开发 2.2.1 宿主层
App的⽣命周期(⽐
App, 这⼀层可以管理整个App
宿主层位于最上层, 主要作⽤是作为⼀个App
App壳, 将需要的模块组装成⼀个完整的App
音箱分频器制作
Application的初始化和各种组件以及三⽅库的初始化)
如Application
2.2.2 业务层
搜
业务层位于中层, ⾥⾯主要是根据业务需求和应⽤场景拆分过后的业务模块, 每个模块之间互不依赖, 但⼜可以相互交互, ⽐如⼀个商城App
App由搜⽀付等业务模块组成
购物车,⽀付
咖啡机使用流程
订单，购物车
索，订单
Tips: 每个业务模块都可以拥有⾃⼰独有的 SDK 依赖和⾃⼰独有的 UI 资源 (如果是其他业务模块都可以通⽤的 SDK 依赖 和 UI 资源 就可以将它们抽离)
2.2.2.1 业务模块的拆分
写业务之前先不要急着动⼿敲码, 应该先根据初期的产品需求到后期的运营规划结合起来清晰的梳理⼀下业务在未来可能会发⽣的发展, 确定业务之间的边界, 以及可能会发⽣的变化, 最后再确定下来真正需要拆分出来的业务模块再进⾏拆分
2.2.3 基础层
核⼼基础业务模块和公共服务模块
公共服务模块主要为业务层的每个
基础 SDK 模块，核⼼基础业务模块
公共服务模块、基础 SDK 模块
基础层位于最底层, ⾥⾯⼜包括核⼼基础业务模块
核⼼基础业务模块、公共服务模块
SDK以及第三⽅SDK
SDK, 为整个平台的基础设施建设提供动⼒基础 SDK 模块含有各种功能强⼤的团队⾃⾏封装的SDK
模块服务，基础 SDK 模块
2.2.
3.1 核⼼基础业务
业务层的每个业务模块提供⼀些与业务有关的基础服务, ⽐如在项⽬中以⽤户⾓⾊分为 2 个端⼝, ⽤户可以扮演多个⾓⾊, 但是在核⼼基础业务
热转印墨水配方核⼼基础业务为业务层
线上只能同时操作⼀个端⼝的业务, 这时每个端⼝都必须提供⼀个⾓⾊切换的功能, 以供⽤户随时在多个⾓⾊中切换,
核⼼基础业务被这 2 个端⼝所依赖(类似 拉勾, Boss 直聘等App
App可以在招聘这时在项⽬中就需要提供⼀个⽤于⽤户⾃由切换⾓⾊的管理类作为核⼼基础业务
者和应聘者之间切换)
核⼼基础业务的划分应该遵循是否为业务层⼤部分模块都需要的基础业务, 以及⼀些需要在各个业务模块之间交互的业务, 都可以划分为核⼼基础
核⼼基础核⼼基础业务
业务
2.2.
3.2 公共服务
业务层各个模块之间的交互(⾃定义⽅法和类的调⽤), 包含⾃定
Module, 主要的作⽤是⽤于业务层
公共服务
CommonService的Module
公共服务是⼀个名为CommonService
Service接⼝, 和可⽤于跨模块传递的⾃定义类
义Service
主要流程是:
提供服务的业务模块:
在公共服务(CommonService
Service接⼝, 再通
Service接⼝ (含有需要被调⽤的⾃定义⽅法), 然后在⾃⼰的模块中实现这个Service CommonService) 中声明Service
ARouter API暴露实现类一次性座套
过ARouter API
使⽤服务的业务模块:
Service接⼝中声明的⾃定义⽅法, 这样就可以达到模块之间Service接⼝(多态持有, 实际持有实现类), 即可调⽤Service
通过ARouter
ARouter的API
API拿到这个Service
的交互
跨模块传递的⾃定义类:
Service中的⾃定义⽅法和EventBus
EventBus中的事件实体类都可能需要⽤到⾃定义类), 就可以通公共服务中定义需要跨模块传递的⾃定义类后 (Service
在公共服务
URL中使⽤Json
Json参数传递⾃定义对象必须实
ARouter要求在URL
ARouter API, 在各个模块的页⾯之间跨模块传递这个⾃定义对象 (ARouter
过ARouter API
SerializationService接⼝)
现SerializationService
Tips: 建议在 CommonService 中给每个需要提供服务的业务模块都建⽴⼀个单独的包, 然后在这个包下放 Service 接⼝ 和 需要跨模块传递的⾃定义类, 这样更好管理
掌握公共服务层的⽤法最好要了解 ARouter 的 API
点击查阅 ARouter ⽂档
2.2.
3.3 基础 SDK
SDK, 提供给整个架构中的所有模块
Module, 其中包含了⼤量功能强⼤的SDK
基础 SDK
基础 SDK是⼀个名为CommonSDK
CommonSDK的Module
