SDK

最近在做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. 调用已注册的注解处理器 - 如果该过程生成了新的源文件，编译器将重复第1、2步 - 每次重复成为一轮 - 第一轮解析处理的是输入至编译器中的已有源文件 - 当注解处理器不再生成新的源文件，将进入最后一轮
3. 生成字节码

这里相对于 ARouter 的APT使用，我们没有通过 JavaPoet 生成新的Java文件。
同样类似ARouter的还有 ButterKnife 的使用。

相对于AutoRegister，它是通过Gradle Transform API基于字节码插桩，在Android中实现跨module自动注册功能。
Transform的执行流程图:

更多细节注意项和蓝色文档，后续整理补充……

参考文档：

• Repo 命令参考文档
• fat-aar-android
• AOP
• Lancet
• Java中SPI机制
• 注解处理器
• ARouter原理(apt、javapoet知识)
• AutoRegister:一种更高效的组件自动注册方案(android组件化开发)
• ButterKnife的使用与原理
• JavaPoet - 优雅地生成代码
• JVM进阶 -- 浅谈注解处理器
• Android 插件的 Transform API