1.1. 背景
在我们平常的开发中构建工程是一个基础的环节，决定着开发效率的高低，然而随着业务代码不断累积，编译耗时也随之增长。虽然已经有许多增量编译加速方案，但不可避免的在很多场景，还是需要全量编译。而对于全量编译加速，我们遇到了一些困难：
- K歌的项目里，总代码量160w行，kotlin代码占比43%左右，编译耗时占比却高达70%，必须要压缩这个比例。
于是需要找到一种方法，既能继续享受kotlin带来的开发便利，也能缓解全量编译时间快速增长的问题。
1.2. 方案
如果能减少kotlin的编译数量，就能降低编译耗时，要么减少代码，要么提前编译代码，后者可行度高。
而Android里支持两种二进制归档文件：JAR、AAR
两种格式里源码都是以.class格式存在，不过jar不包含资源，对于在做组件化的项目不友好，library module在编译后会直接生成aar。
那么只要把所有library module都通过CI/CD工具，持续的自动生成aar，发布到同一个maven仓库，在编译时用这些aar参与编译就成功了。
1.3. 方案初步呈现
library modules提前编译成了aar，我们需要把依赖类型由implementation project更改为implementation aar。
如果library module代码改变了，都需要重复执行提前编译aar，修改依赖版本号，很浪费时间，这里能不能取缔这个重复操作环节让程序自动化?
一种更好的方式：编译时判断library module当前代码版本是否有可用的aar，有则使用aar参与编译。拆解流程：
计算当前代码版本所有文件的hash，包含如下：
- JavaSource
- JavaResource
- Assets
- Resources
- Aidl
- JniLibs
- AndroidManifest.xml
- Proguard
- Lint
判断maven仓库里是否有对应hash的aar，寻址 = repository/libraryName/version-md5
修改library module依赖类型为aar。
1.4. 遇到的问题
1. jar重复类冲突
可以看到B对C存在直接的依赖关系，这个关系会声明在B.arr的元数据文件.pom，又由于C的代码更改了导致无法匹配远程aar，所以最后C会同时以aar和project两种方式参与编译，如果C里包含了jar，就会冲突。
2. 工程重复类冲突
share_m和share是同一个代码仓库，开发便于验证更改了name，路由不一样代码一样，gradle认为是两个aar，报错重复。
3. 三方库版本冲突
最终编译后share代码版本依然为1.2.0，因为B.aar存在对share:1.2.0依赖。Gradle将考虑所有请求的版本，无论它们出现在依赖关系图中的何处。在这些版本中，它将选择最高的版本。
第一个问题：明显的需要把B(aar)—>C(aar)这个依赖项解除，这里常用有两个办法：
- 直接从pom里删除该项依赖元数据(K歌采用)。
- 修改B依赖C的依赖类型改为compileOnly，不过如果B使用了C的资源打包aar会报错。
第二个问题：K歌的做法是要求name保持一致，开发修改代码发布时只改变version。
第三个问题：因为这种模型也会存在正常开发中，对于版本冲突，有以下几项办法：
- 开发时用更高的版本去覆盖掉参与构建的所有版本。
- 修改B—>share:1.2.0依赖类型为compileOnly，来解除传递依赖。
- 如果一定要使用动态版本号+，且低于参与构建的版本，可以提取出白名单，从pom里删除该项依赖，统一由app主module依赖(K歌采用)。
- B在发布aar时，不保留pom里对三方的任何依赖元数据，编译时统一由app依赖。
想要解决传递依赖的问题还有常见的transitive，force，严格依赖等特性，K歌使用这些特性很少，考虑到要开发透明，保持原有代码，我们采用的都是直接修改pom文件依赖项来解除传递依赖。
从以上问题不难看出，唯一标识=自身内容+依赖关系图，所以在计算md5时，我们也需要把依赖关系算进去。什么时候可以获取依赖图?
Gradle的构建生命周期分为3步：
1、初始化
Gradle支持单项目和多项目构建。在初始化阶段，Gradle确定将要参与构建的项目，并为每个项目创建一个Project实例。
2、配置
在此阶段，将配置项目对象。执行作为构建一部分的所有项目的构建脚本。
3、执行
Gradle确定要在配置阶段创建和配置的任务子集。子集由传递给gradle命令的任务名称参数和当前目录确定。然后Gradle执行每个选定的任务。
明确在配置阶段是执行build.gradle，依赖图生成后，可以在项目评估回调里(afterEvaluate)解析完成我们的操作。
K歌的app module依赖了全局所有的library module，在编译时app最先收到评估回调，只要这时修改app的依赖关系图就能阻断其余library module的后续配置流程，而这时library module并未评估完成，拿不到依赖关系图就无法计算md5，只能手动解析library module的build.gradle文件里的依赖配置。K歌的配置一部分直接申明在dependencies里，一部分提取成了统一管理versionConfigs.gradle。
需要注意的是，每个项目评估完整结束后再修改依赖图是不安全的，Gradle会阻止。
1.5. 最终流程
- 构建项目，处于配置阶段时会执行每个project的build.gradle，里面会确定下来依赖关系，在评估项目之后(afterEvaluate)收到通知。
- 解析配置里对于本地project类型的依赖(DefaultProjectDependency)，计算project的md5，计算包含的内容为前面讲诉的aar内容，同时把project的依赖关系也要作为md5计算的范围。
- 计算出md5后按照maven库的寻址规则拼接到路径上访问远端maven仓库是否存在此aar。
- 存在aar，则将本地project的依赖类型改为远程aar依赖(DefaultExternalModuleDependency)。
