最近在做SDK的升级，因为是在老版本上拉分支进行了很多定制的改动，而且同时在维护多条业务线不同的定制需求，现在多条业务线需要跨多个版本升级，拉分支的这种方式凸显了他的不友好。
前期为了让SDK里各自的部分方便开发和使用，内部进行了细粒度的拆分，将项目拆分成多个仓库，使用 repo 组织完整的项目。
然后整体项目使用 fat-aar 打包成一个完整aar的解决方案。
注意：包含多个module，module中存在lib库的时候，防止aar打包丢失lib库，可以每个module都添加fat-aar配置，并添加embed
各条业务线的需求在必须定制修改使用SDK的时候，采用了轻量级Android AOP框架 Lancet 进行定制开发。
在SDK的基础上，除了定制的改动，还有各自业务线的独立需求增加，最终混淆处理后，也打fat-aar完整包提供业务SDK。
注意：因为fat-aar是通过复制各module编译后的资源合并的，所以混淆规则需写到主module中
整个过程，因SDK细粒度的拆分在前，定制内容梳理在后，而且是跨越多个版本，升级变的很麻烦，需要一条条对比，确认哪些是可以合入SDK的，哪些是需要业务线自己通过lancet修改的，哪些是业务新增的独立部分。
SPI机制
在SDK里一些数据处理的组件使用的是Java中的SPI机制。
整体机制图如下：
Java SPI 实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制。
该机制需要指定在 /META-INF/文件夹 目录，包含所有接口命名的文件，内容是要应用的实现类。然后通过使用 ServiceLoader 来加载配置文件中指定的实现。
注解处理器
这个过程我们使用了注解处理器，不再手动去维护配置。
编译过程:
- 将源文件解析为抽象语法树
- 调用已注册的注解处理器 - 如果该过程生成了新的源文件，编译器将重复第1、2步 - 每次重复成为一轮 - 第一轮解析处理的是输入至编译器中的已有源文件 - 当注解处理器不再生成新的源文件，将进入最后一轮
- 生成字节码
这里相对于 ARouter 的APT使用，我们没有通过 JavaPoet 生成新的Java文件。
同样类似ARouter的还有 ButterKnife 的使用。
相对于AutoRegister，它是通过Gradle Transform API基于字节码插桩，在Android中实现跨module自动注册功能。
Transform的执行流程图:
更多细节注意项和蓝色文档，后续整理补充……
参考文档：
网友评论