TIP
本文主要是介绍 组件化框架方案 。
组件化框架简介
# 1 简介
# 1.1 什么是组件化?
组件化简单概括就是把一个功能完整的App或模块拆分成多个子模块, 每个子模块可以独立编译和运行, 也可以任意组合成另一个新的App或模块, 每个模块即不相互依赖但又可以相互交互, 遇到某些特殊情况甚至可以升级或者降级
# 1.2 为什么要组件化?
现在的项目随着需求的增加规模变得越来越大, 规模的增大带来了很多烦恼, 各种业务错中复杂的交织在一起, 每个业务模块之间, 代码没有约束, 带来了代码边界的模糊, 代码冲突时有发生, 更改一个小问题可能引起一些新的问题, 牵一发而动全身, 增加一个新需求, 瞻前顾后的熟悉了大量前辈们写的代码后才敢动手, 编译时间也不在断增加, 开发效率极度的下降, 在这种情况下组件化的出现就是为了解决以上的烦恼
# 1.3 分析现有的组件化方案
很多大厂的组件化方案是以多工程+多 Module的结构(微信, 美团等超级App更是以多工程+多 Module+多 P 工程(以页面为单元的代码隔离方式)的三级工程结构), 使用Git Submodule创建多个子仓库管理各个模块的代码, 并将各个模块的代码打包成AAR上传至私有Maven仓库使用远程版本号依赖的方式进行模块间代码的隔离
# 1.4 如何选择组件化方案?
按照康威定律, 系统架构的设计需要根据组织间的沟通结构, 因为现在大部分项目的规模和开发人员的数量以及结构还不足以需要某些大厂发布的组件化方案支撑(大厂的组织结构和项目规模都非常庞大, 他们的方案不一定完全适合所有公司的项目), 进行更严格更细粒度的代码间以及模块间的隔离, 盲目的使用某些组件化方案, 可能会带来开发效率降低, 开发成本远大于收益等情况, 性价比变低, 作为项目负责人, 应该根据项目目前的规模以及开发人员的组织结构去选择目前最适合的组件化方案, 做到以项目实际情况去制定技术方案, 而不是盲目跟随某些大厂的技术方案让项目和开发人员花费大量时间去调整和适应
# 2 组件化方案描述
Component_base 目前采用的是单工程+多 Module的结构, 由于Demo较小仅仅为了展示基本规范, 所以也只是采用源码依赖并没有做到远程版本号依赖组件, 代码管理也只是采用单仓库+多分支的方式, 这样也是对于开发初期, 项目规模还较小, 开发人员也较少时, 开发效率较高的方案, 如果您的项目规模较大, 开发人员众多, 就可以采用上面提到的多工程+多 Module, 并使用私有Maven仓库管理组件版本
世界上没有一个方案可以完美到兼顾所有情况, 并且还满足所有人, 所有项目的需求, 所以项目负责人必须按照项目实际情况做出灵活的调整, 才能做出最适合自家项目的方案
# 2.1 架构图一览
Component_base 组件化架构图
# 2.2 架构图详解
目前架构一共分为三层, 从低到高依次是基础层, 业务层和宿主层, 由于目前项目较小人员较少所以三层都集中在一个工程中, 但您可以根据项目的规模和开发人员的数量拆分成多个工程协同开发
# 2.2.1 宿主层
宿主层位于最上层, 主要作用是作为一个App壳, 将需要的模块组装成一个完整的App, 这一层可以管理整个App的生命周期(比如Application的初始化和各种组件以及三方库的初始化)
# 2.2.2 业务层
业务层位于中层, 里面主要是根据业务需求和应用场景拆分过后的业务模块, 每个模块之间互不依赖, 但又可以相互交互, 比如一个商城App由搜索,订单,购物车,支付等业务模块组成
Tips: 每个业务模块都可以拥有自己独有的 SDK 依赖和自己独有的 UI 资源 (如果是其他业务模块都可以通用的 SDK 依赖 和 UI 资源 就可以将它们抽离)
# 2.2.2.1 业务模块的拆分
写业务之前先不要急着动手敲码, 应该先根据初期的产品需求到后期的运营规划结合起来清晰的梳理一下业务在未来可能会发生的发展, 确定业务之间的边界, 以及可能会发生的变化, 最后再确定下来真正需要拆分出来的业务模块再进行拆分
# 2.2.3 基础层
基础层位于最底层, 里面又包括核心基础业务模块、公共服务模块、基础 SDK 模块,核心基础业务模块和公共服务模块主要为业务层的每个模块服务,基础 SDK 模块含有各种功能强大的团队自行封装的SDK以及第三方SDK, 为整个平台的基础设施建设提供动力
# 2.2.3.1 核心基础业务
核心基础业务为业务层的每个业务模块提供一些与业务有关的基础服务, 比如在项目中以用户角色分为 2 个端口, 用户可以扮演多个角色, 但是在线上只能同时操作一个端口的业务, 这时每个端口都必须提供一个角色切换的功能, 以供用户随时在多个角色中切换,
这时在项目中就需要提供一个用于用户自由切换角色的管理类作为核心基础业务被这 2 个端口所依赖(类似 拉勾, Boss 直聘等App可以在招聘者和应聘者之间切换)
核心基础业务的划分应该遵循是否为业务层大部分模块都需要的基础业务, 以及一些需要在各个业务模块之间交互的业务, 都可以划分为核心基础业务
# 2.2.3.2 公共服务
公共服务是一个名为CommonService的Module, 主要的作用是用于业务层各个模块之间的交互(自定义方法和类的调用), 包含自定义Service接口, 和可用于跨模块传递的自定义类
主要流程是:
提供服务的业务模块:
在公共服务(CommonService) 中声明Service接口 (含有需要被调用的自定义方法), 然后在自己的模块中实现这个Service接口, 再通过ARouter API暴露实现类
使用服务的业务模块:
通过ARouter的API拿到这个Service接口(多态持有, 实际持有实现类), 即可调用Service接口中声明的自定义方法, 这样就可以达到模块之间的交互
跨模块传递的自定义类:
在公共服务中定义需要跨模块传递的自定义类后 (Service中的自定义方法和EventBus中的事件实体类都可能需要用到自定义类), 就可以通过ARouter API, 在各个模块的页面之间跨模块传递这个自定义对象 (ARouter要求在URL中使用Json参数传递自定义对象必须实现SerializationService接口)
Tips: 建议在 CommonService 中给每个需要提供服务的业务模块都建立一个单独的包, 然后在这个包下放 Service 接口 和 需要跨模块传递的自定义类, 这样更好管理
掌握公共服务层的用法最好要了解 ARouter 的 API
点击查阅 ARouter 文档 (opens new window)
简单使用：https://www.jianshu.com/p/fb20ab18c4cb?from=timeline&isappinstalled=0
# 2.2.3.3 基础 SDK
基础 SDK是一个名为CommonSDK的Module, 其中包含了大量功能强大的SDK, 提供给整个架构中的所有模块
参考文章 ：http://mp.weixin.qq.com/s/hey2ZcsgucLVEGYJ2qfVWA
文章来自:https://www.jianshu.com/p/f671dd76868f
# 参考文章
- https://www.jianshu.com/p/40e745038471
← 框架架构组件关系整理 热门微服务框架概览 →
