7年Android惨遭小公司裁员，拿完n+1补偿后进鹅厂…
Android 项目一般使用 gradle 作为构建打包工具，而其执行速度慢也一直为人所诟病，对于今日头条 Android 项目这种千万行级别的大型工程来说，全量编译一次的时间可能高达六七分钟，在某些需要快速验证功能的场景，改动一行代码的增量编译甚至也需要等两三分钟，这般龟速严重影响了开发体验与效率，因此针对 gradle 编译构建耗时进行优化显得尤为重要。
在今日头条 Android 项目上，编译构建速度的优化和恶化一直在交替执行，18 年时由于模块化拆分等影响，clean build 一次的耗时达到了顶峰 7 分 30s 左右，相关同学通过模块 aar 化，maven 代理加速，以及增量 java 编译等优化手段，将 clean build 耗时优化到 4 分钟，增量编译优化到 20~30s 。但是后面随着 kotlin 的大规模使用，自定义 transform 以及 apt 库泛滥，又将增量编译速度拖慢到 2 分 30s ，且有进一步恶化的趋势。为了优化现有不合理的编译耗时，防止进一步的恶化，最近的 5，6 双月又针对编译耗时做了一些列专项优化(kapt,transform,dexBuilder,build-cache 等) 并添加了相关的防恶化管控方案。 从 4.27 截止到 6.29 ，整体的优化效果如下:
由于 18 年左右客户端基础技术相关同学已经对今日头条 Android 工程做了许多 gradle 相关的优化，且这些优化是近期优化的基础，因此先挑选几个具有代表性的方案进行介绍，作为下文的背景同步。
gradle 工程往往会在 repositories 中添加一些列的 maven 仓库地址，作为组件依赖获取的查找路径，早期在今日头条的项目中配置了十几个 maven 的地址，但是依赖获取是按照 maven 仓库配置的顺序依次查找的，如果某个组件存在于最后一个仓库中，那前面的十几个仓库得依次发起网络请求查找，并在网络请求返回失败后才查找下一个，如果项目中大多组件都在较后仓库的位置，累加起来的查找时间就会很长。
今日头条项目进行了多次组件化和模块化的重构，分拆出了 200 多个子模块，这些子模块如果全都 include 进项目，那么在 clean build 的时候，所有子模块的代码需要重新编译，而对于大多数开发人员来说，基本上只关心自己负责的少数几个模块，根本不需要改动其他模块的代码，这些其他 project 的配置和编译时间就成为了不必要的代价。
对于以上子模块过多的解决方案是：将所有模块发布成 aar ，在项目中全部默认通过 maven 依赖这些编译好的组件，而在需要修改某个模块时，通过配置项将该模块的依赖形式改为源码依赖，做到在编译时只编译改动的模块。但是这样做会导致模块渐渐的又全部变为源码依赖的形式，除非规定每次修改完对应模块后，开发人员自己手动将模块发布成 aar ，并改回依赖形式。这种严重依赖开发人员自觉，并且在模块数量多依赖关系复杂的时候会显得异常繁琐，因此为了开发阶段的便利，设计了一整套更完整细致的方案:
通过上述改造，将源码模块切换成 aar 依赖后，clean build 耗时从 7，8 分钟降低至 4，5 分钟，收益接近 50%，效果显著。
在非 clean build 的情况下，更改 java/kotlin 代码虽然会做增量编译，但是为了绝对的正确性，gradle 会根据一些列依赖关系计算，选择需要重新编译的代码，这个计算粒度比较粗，稍微改动一个类的代码，就可能导致大量代码重新执行 apt, 编译等流程。
由于 gradle 作为通用框架，其设计的基本原则是绝对的正确，因此很容易导致增量编译失效，在实际开发中，为了快速编译展示结果，可以在编译正确性和编译速度上做一个折中的方案：
以上方案（下文全部简称为 fastbuild) 虽然在涉及常量修改，方法签名变更方面 存在一定的问题（常量内联等），但是能换来增量编译从 2 分多降低至 20~30s，极大的提升编译效率，且有问题的场景并不常见，因此整体上该方案是利大于弊的。
通过上文介绍的几个优化方案和其他优化方式，在 18 年时，今日头条 Android 项目的整体编译速度（clean build 4~5min, fast 增量编译 20~30s）在同量级的大型工程中来说是比较快的 ，然而后期随着业务发展的需求，编译脚本添加了很多新的逻辑：
这些逻辑的引入，使得增量编译耗时恶化到 2 分 30s，即使采用 fastbuild，改动一行代码编译也需要 1 分 30s 之多，开发体验非常差。而下文将着重描述最近一段时间对上述问题的优化过程。
今日头条工程经过多次模块化，组件化重构后， app 模块(NewsArticle)的大部分代码都已经迁移到子模块（上文已经介绍过子模块可以采用 aar 化用于编译速度优化，app 模块只剩下一个壳而已。
但是从 build profile 数据（执行 gradle 命令时添加 --profile 参数会在编译完成后输出相关 task 耗时的统计文件） 中发现到一个异常 case：明明只有 2 个类的 app 模块 kapt(annotationProcessor 注解处理) 相关耗时近 1 分钟。
通过进一步观察，虽然 app 模块拆分后只有 2 个简单类的代码，但是却用了 6 种 kapt 库， 且实际生效的只是其中 ServiceImpl 一个注解 （内部 ServiceManager 框架，用于指示生产 Proxy 类，对模块之间代码调用进行解耦）。如此一顿操作猛如虎，每次编译却只生成固定的两个 Proxy 类，与 53s 的高耗时相比，投入产出比极低。
把固定生成的 Proxy 类从 generate 目录移动到 src 目录，然后禁止 app 模块中 kapt 相关 task ，并添加相关管控方案（如下图: 检测到不合理情况后立刻抛出异常），防止其他人添加新增的 kapt 库。
通过上文介绍在 app 模块发现的异常的 kapt case， 进而发现在工程中为了方便，定义了一个 library.gradle ，该文件的作用是定义项目中通用的 Android dsl 配置和共有的基础依赖，因此项目中所有子模块均 apply 了这个文件，但是这个文件陆陆续续的被不同的业务添加新的 kapt 注解处理库，在全源码编译时，所有子模块都得执行 library 模块中定义的全部 6 个 kapt ，即使该模块没有任何注解相关的处理也不例外。
而上述情况的问题在于：相比纯 java 模块的注解处理，kotlin 代码需要先通过 kaptGenerateStub 将 kt 文件转换成为 java ，让 apt 处理程序能够统一的面向 java 做注解扫描和处理。但是上面讲到其实有很多模块是根本不会有任何实际 kapt 处理过程的，却白白的做了一次 kt 转 java 的操作，源码引入的模块越多，这种无意义的耗时累加起来也非常可观。
为了能够弄清楚到底有哪些子模块真正用到了 kapt ，哪些没用到可以禁用掉 kapt 相关 task ，对项目中所有子模块进行了一遍扫描：
使用上述方案，通过全源码打包最终扫描出来大概是 70+模块不会进行任何 kapt 的实际输出，且将这些不会进行输出的 kapt，kaptGenerateStub 的 task 耗时累加起来较高 217s （由于 task 并发执行所以实际总时长可能要少一些).
获取到不实际生成 kapt 内容的模块后，开始对这些模块进行细粒度的拆分，让它们从 apply library.gradle 改为没有 kapt 相关的 library-api.gradle ，该文件除了禁用 kapt 外，与 library 逻辑一致。
但是这样做算是在背后偷偷做了些更改，很可能后续新来的同学不知道有这种优化手段，可能新增了注解后却没有任何输出且找不到原因，而优化效果最好是尽量少给业务同学带来困扰。为了避免这种情况，便对这些 library-api 模块依赖的注解做隔离优化，即：把这些模块依赖的注解库全部 自动 exclude 掉，在尝试使用注解时会因获取不到引用（如下图所示），第一时间发现到依赖被移除的问题。
另一方面在编译出现错误时，对应 gradle 插件会自动解析找不到的符号，如果发现该符号是被隔离优化的注解，会提示将 library-api 替换成 library，尽可能降低优化方案对业务的负面影响。
transform 作为 Android gradle plugin 提供给开发者的 API，用于在 apk 构建过程中，对 class 字节码，resources 等文件内容进行插桩修改，例如官方的 dex, proguard 等功能均由此 api 实现。
对于今日头条这种大型工程来说，有很多诸如性能插桩、自动埋点插桩等相关需求，因此基于此 api 开发了大量 transform，用于实现特定功能，但是这些 transform 基本上都是不支持增量编译的，即使只改动了一行代码，这 些 transform 都会遍历所有 class 文件，解析字节码中的方法字段信息，关键是这类 transform 数量有十几个，将这些遍历耗时乘以 10 累加之后，增量编译耗时自然居高不下。
根据分析，其中性能插桩等相关 transform 做的一些面向线上的插桩方案是完全可以只在 release 打包时打开的，因此可以直接在 debug 编译时禁用这些功能，用于提升开发期间的编译速度。而剩下的 9 个 transform 特征比较相似，可能在一些插桩细节上有所不同，它们大致的处理逻辑为：
由于这 9 个自定义 transform 的功能如此类似，便决定将这些 transform 合并成一个，这样同一个文件的读写操作只执行一次，并且可以做定制化的增量编译优化。虽然公司内有类似的 transform 合并优化方案 byteX ( 已在 github 开源），但是由于今日头条项目在 debug 阶段未开启该功能，且 ByteX 做了一些诸如 ClassGrapth 的构建，对类文件做两次遍历等操作，对于实现类信息收集和信息注入 这个功能来说，byteX 显得比较重 ，于是仍然针对类信息收集注入功能这个细分场景开发了一个收敛框架。
该框架完成了内部 9 种类信息收集注入相关框架的收敛，编译耗时的绝对值加速了 25s 左右，且由于提供了统一的增量缓存功能，使得改动一行代码的耗时可以从 2 分 30s 降低到 35~40s ，实现了增量编译速度大的飞跃。最关键的是将所有自定义 transform 统一管控后，后续可以做统一定制化的需求，进一步优化编译速度。
在 Android debug 编译 过程中，最主要的耗时在 transform 上，而上文 介绍 今日头条项目自定义 transform 已经被高度优化过，剩下的 dexBuilder(将 class 转换成 dex ) ，dexMerge 等 task 耗时就成为了性能瓶颈，dexBuilder 全量编译耗时 60s 左右，增量编译耗时 22s 左右。
根据 DexArchiveBuilderTransform 关键方法 launchProcessing 里面关键一行 isDirectoryBased，如果是目录类型的输入，会根据具体变动 class 文件做增量的 dex 编译 ，但是如果是 jar 输入类型，那只要 jar 里任何一个类变动，则整个 jar 所有类都需要重执行 dex，但是由于 gradle 的依赖特性，基本上只有 app 模块是目录类的输入，其他 library 都是 jar 输入类型，对于比较大的业务模块 ，如果该模块有几千个类，那每改动一次类，就会有几千类连带重新 执行 dex 编译。
在优化前为了得到真正的重新执行 dex 编译的数值，做到最佳优化，设计了一套 hook dex 编译流程的方法(该方法理论上可以 hook Android gradle plugin 任意类：大致就是 hook classLoader ，提前用 asm 修改 D8DexArchiveBuilder 中的 convert 方法
通过对 D8DexArchiveBuilder 的 hook ，统计到优化前改动一行代码会连带着 24968 个类重新执行 dex 编译，增量效果非常差。
既然 jar 输入相比于 目录输入来说增量编译效果非常差，那么可以想到 hook TransformInvocation 中的 input 方法，动态将 project 的 jar 类型输入（JarInput）映射为一个 目录输入（DirectoryInput），那么子模块修改对应代码时，只重新编译目录中被修改的 class 为 dex（而不是原来的整个 jar 内所有 class 重新执行 dex 编译），整体 dex 重新编译的数量将大幅度减少。实现具体方案如下：
而 jar 转 目录的映射细节为:
在第一次增量修改完成后，重新执行 dex 编译的类数量降低至 2152 个，但是其中仍然有很多迷惑的不该执行 dex 编译的类，预期是修改多少类，就重新执行 多少次 dex，因此继续对其中原因进行进一步的探索
由于 java8 的字节码有些指令在 Android 虚拟机中并不能得到支持，会在编译流程中，将这些指令进行脱糖，转换成已有的指令，而 d8 中 desugar 的流程合并到了 dexBuilder 中，为了避免某些类 desugar 后，依赖它的类的行为正确，需要把依赖它的所有类重新执行一遍 dex 编译。
而 d8 会根据 DesugaringGraph 查找 desguar 有变动的类及其依赖的 jar 包，如图下面获得到的 addtionalPaths 是 desguar 类可能直接间接相关的 jar 包，即使这些 jar 包没有任何文件内容变更，其中所有类也得重新全部执行一次 dex 编译。
该类用来辅助获取依赖或间接依赖到变更文件的所有文件，而它的生成逻辑为: 全量或增量编译类的时候记录类型之间的依赖和被依赖关系，依赖关系的判断条件有
DesugaringGraph 不仅记录了类依赖的类，和依赖它的类，同时也记录了一个文件路径包含了哪些类
在增量编译时检查到变动的文件时，会检查这个文件路径包含的所有类， 然后递归查找所有直接/间接依赖它的类，并且找到这些依赖它的类后，会把这个类所在的 jar 包作为额外的处理类型（即使 jar 本身没有任何变动，里面所有的类仍然需要重新 dex 编译)
顺着这个解析关系，找到了一个不正常的 jar 包 bdjson_api ，这个 jar 只有 3 个文件 (IBDJson,BDJsonCollector, BDJsonConstants) 。但是 BDJsonCollector 是一个 stub 类，每次执行 transform 会收集到其他类的信息然后往该类的方法中注入，因此该文件每次编译时都会变动。 这个类本身并没有多少直接依赖它的类，主要是 它所在的 jar 包还有个 IBDJson 接口。
按照之前的 DesugaringGraph 依赖关系，所有 IBDJson 接口的实现类被判断为依赖它，然后这些实现类如果出现在某个 dynamic 方法中，又会被层层查找，查找完了之后，还得计算所有依赖类所在的 jar 包，jar 包中其他没有依赖它的类也会被重新 dex 编译， 在这个 case 的依赖查找中，连带重新执行 dex 编译的类数量并不多，大概为 4 个 jar 包共 2000 多个类重新执行了无意义的 dex 流程，但是如果是其他 sdk jar 包，则可能就会给 dexBuilder 增量带来毁灭性的打击。 上述问题的解决方法：
修复后修改一行代码重新执行 dex 的数量为 10 ，其中 9 个是每次 transform 会修改的 stub 类，1 个是实际修改类。做到了真正的 改多少类，执行多次 dex 编译。
assemebleDebug 的增量编译中从原来（上文 transform 优化后）的 35s~40s 是降低至均值 17s，在 fast build 中效果最明显(屏蔽了 apt)，第二次增量编译能突破到 9s 实现秒级编译。
而经过上面所有的优化后，耗时数据里耗时最严重的 dexBuilder 和 dex-merge 基本都降低在 1s 左右，自定义 transform 也是 1s 左右，其他 task 基本都是零点几秒。在不使用 hotfix 方案的情况下（由于今日头条项目使用了过多的自定义 transform 和插件方案，所以不好使用 instantrun 等 hostfix 方案），相关 task 的耗时基本达到了优化的极限。
Build-cache 是 gralde 提供的一个编译缓存方案，目的是在构建过程中当两个 task 的输入相同时，可以复用缓存内容，直接跳过 task 的执行拿到缓存好的执行结果。由于缓存结果既可以放在本地磁盘，也可以从远程获取，因此容易想到利用 ci 提前 构建缓存包，在其他 ci 机器和开发时利用缓存包获得加速效果。
那么如何判断 task 可以直接获取 之前 task 的缓存内容作为输出呢？定义为可缓存的 task ，会定义一些缓存相关的属性，task 执行时通过文件指纹，缓存属性等一大堆属性计算出缓存 key ，用于查找是否命中缓存，计算维度有:
但是原生的 build-cahce 在缓存命中率上惨不忍睹，公司内抖音团队基于 gradle4.x 的源码做过一些提高命中率的修改，不过今日头条用的 gradle 版本是 5.1 ，受抖音团队的启发，也对 gradle5.1 源码做了些定制化的修改，用于 dump 缓存 key 的计算流程，快速发现缓存问题。相比于抖音发现的一些影响缓存命中的问题，额外发现了一些诸如 mbox , kapt 元素遍历顺序不固定的问题，这里只挑一个典型的 apt 顺序不一致的问题进行介绍：
经过修改 gradle5.1 源码后对编译流程的信息采集，发现有的 task 缓存无法命中是因为 kapt 时，很多生成代码块逻辑是一样的，但是顺序不一样(如下图 demo ：下面两个生成方法的逻辑一致，但是判断顺序不一致，这应该是在 processor 中通过 RoundEnviroment 获取到 注解元素 elemnts 顺序不一致导致的 ）
其内部的原因可能是文件遍历目录时获取子文件的顺序不一致，导致了子文件对应注解元素的顺序也不一致， 总之这个操作影响了生成文件内代码的顺序，也影响了该文件的 hash 计算结果，导致 build-cache 在计算 javac task 的 key 时会错乱导致缓存无法命中。
但是注意到 AbstractProcessor 的核心方法 process 的两个参数都是接口，因此想到可以代理原来的 RoundEnvironment 接口，将其 getElementXx 的方法经过固定排序后返回，使得 apt 注解元素的顺序能够固定下来。
由于篇幅影响，其他影响缓存命中相关的 case 略(主要是一些涉及到文件绝对路径， classPath 相关的问题）
在今日头条这种大型工程中，有很多业务部门参与开发，仅 Android 工程 开发人员就有几百人且人员变动频繁，因此内部任何一项优化工作必然是得搭配上一些管控措施的，否则一边优化一边恶化，空浪费人力。
为此制定了一些管控方案，首先是 debug 阶段的 新增 transform 管控，设置为白名单形式，如果在开发阶段新增了 transform 直接终止编译流程，通过说明文档告知管控的规则，当然，管控的目的是尽可能减少一些不必要的不合理的编译问题，并不是与业务团队作对，如果某一个操作拖慢了整体的编译耗时，但是在 app 性能/稳定性方面有更大收益，且无法在编译期做更多的优化，仍然是允许添加的，只不过是得提前把这个问题暴露出来而已，能更快的找出更多的解决思路，比如引导使用 byteX 等 transform 收敛方案。
另一方面的是合码流程方面的阻塞 ： 今日头条 为了保障 app 的性能稳定性，在合码流程上设置了许多自动化的卡点： 如 包大小检测，插件依赖变更检查， so 变更检查，启动性能检测等，检测到对应问题（如包大小增加异常）会阻塞合码流程。为了管控编译速度 ，使其不至于恶化的太快，也加上了对应的 基于 task 级别的管控，当某一个 task 耗时异常波动，或者新增全新类型的 task 时，能够自动的发现问题，通过机器人将相关人员拉到 mr 讨论群中， 尽量在 合码完成前能发现问题。
为了持续稳定的保持较快的编译速度，可能需要做到以下几点：
背景介绍
Android 项目一般使用 gradle 作为构建打包工具，而其执行速度慢也一直为人所诟病，对于今日头条 Android 项目这种千万行级别的大型工程来说，全量编译一次的时间可能高达六七分钟，在某些需要快速验证功能的场景，改动一行代码的增量编译甚至也需要等两三分钟，这般龟速严重影响了开发体验与效率，因此针对 gradle 编译构建耗时进行优化显得尤为重要。
在今日头条 Android 项目上，编译构建速度的优化和恶化一直在交替执行，18 年时由于模块化拆分等影响，clean build 一次的耗时达到了顶峰 7 分 30s 左右，相关同学通过模块 aar 化，maven 代理加速，以及增量 java 编译等优化手段，将 clean build 耗时优化到 4 分钟，增量编译优化到 20~30s 。但是后面随着 kotlin 的大规模使用，自定义 transform 以及 apt 库泛滥，又将增量编译速度拖慢到 2 分 30s ，且有进一步恶化的趋势。为了优化现有不合理的编译耗时，防止进一步的恶化，最近的 5，6 双月又针对编译耗时做了一些列专项优化(kapt,transform,dexBuilder,build-cache 等) 并添加了相关的防恶化管控方案。 从 4.27 截止到 6.29 ，整体的优化效果如下:
由于 18 年左右客户端基础技术相关同学已经对今日头条 Android 工程做了许多 gradle 相关的优化，且这些优化是近期优化的基础，因此先挑选几个具有代表性的方案进行介绍，作为下文的背景同步。
gradle 工程往往会在 repositories 中添加一些列的 maven 仓库地址，作为组件依赖获取的查找路径，早期在今日头条的项目中配置了十几个 maven 的地址，但是依赖获取是按照 maven 仓库配置的顺序依次查找的，如果某个组件存在于最后一个仓库中，那前面的十几个仓库得依次发起网络请求查找，并在网络请求返回失败后才查找下一个，如果项目中大多组件都在较后仓库的位置，累加起来的查找时间就会很长。
今日头条项目进行了多次组件化和模块化的重构，分拆出了 200 多个子模块，这些子模块如果全都 include 进项目，那么在 clean build 的时候，所有子模块的代码需要重新编译，而对于大多数开发人员来说，基本上只关心自己负责的少数几个模块，根本不需要改动其他模块的代码，这些其他 project 的配置和编译时间就成为了不必要的代价。
对于以上子模块过多的解决方案是：将所有模块发布成 aar ，在项目中全部默认通过 maven 依赖这些编译好的组件，而在需要修改某个模块时，通过配置项将该模块的依赖形式改为源码依赖，做到在编译时只编译改动的模块。但是这样做会导致模块渐渐的又全部变为源码依赖的形式，除非规定每次修改完对应模块后，开发人员自己手动将模块发布成 aar ，并改回依赖形式。这种严重依赖开发人员自觉，并且在模块数量多依赖关系复杂的时候会显得异常繁琐，因此为了开发阶段的便利，设计了一整套更完整细致的方案:
通过上述改造，将源码模块切换成 aar 依赖后，clean build 耗时从 7，8 分钟降低至 4，5 分钟，收益接近 50%，效果显著。
在非 clean build 的情况下，更改 java/kotlin 代码虽然会做增量编译，但是为了绝对的正确性，gradle 会根据一些列依赖关系计算，选择需要重新编译的代码，这个计算粒度比较粗，稍微改动一个类的代码，就可能导致大量代码重新执行 apt, 编译等流程。
由于 gradle 作为通用框架，其设计的基本原则是绝对的正确，因此很容易导致增量编译失效，在实际开发中，为了快速编译展示结果，可以在编译正确性和编译速度上做一个折中的方案：
以上方案（下文全部简称为 fastbuild) 虽然在涉及常量修改，方法签名变更方面 存在一定的问题（常量内联等），但是能换来增量编译从 2 分多降低至 20~30s，极大的提升编译效率，且有问题的场景并不常见，因此整体上该方案是利大于弊的。
通过上文介绍的几个优化方案和其他优化方式，在 18 年时，今日头条 Android 项目的整体编译速度（clean build 4~5min, fast 增量编译 20~30s）在同量级的大型工程中来说是比较快的 ，然而后期随着业务发展的需求，编译脚本添加了很多新的逻辑：
这些逻辑的引入，使得增量编译耗时恶化到 2 分 30s，即使采用 fastbuild，改动一行代码编译也需要 1 分 30s 之多，开发体验非常差。而下文将着重描述最近一段时间对上述问题的优化过程。
今日头条工程经过多次模块化，组件化重构后， app 模块(NewsArticle)的大部分代码都已经迁移到子模块（上文已经介绍过子模块可以采用 aar 化用于编译速度优化，app 模块只剩下一个壳而已。
但是从 build profile 数据（执行 gradle 命令时添加 --profile 参数会在编译完成后输出相关 task 耗时的统计文件） 中发现到一个异常 case：明明只有 2 个类的 app 模块 kapt(annotationProcessor 注解处理) 相关耗时近 1 分钟。
通过进一步观察，虽然 app 模块拆分后只有 2 个简单类的代码，但是却用了 6 种 kapt 库， 且实际生效的只是其中 ServiceImpl 一个注解 （内部 ServiceManager 框架，用于指示生产 Proxy 类，对模块之间代码调用进行解耦）。如此一顿操作猛如虎，每次编译却只生成固定的两个 Proxy 类，与 53s 的高耗时相比，投入产出比极低。
把固定生成的 Proxy 类从 generate 目录移动到 src 目录，然后禁止 app 模块中 kapt 相关 task ，并添加相关管控方案（如下图: 检测到不合理情况后立刻抛出异常），防止其他人添加新增的 kapt 库。
通过上文介绍在 app 模块发现的异常的 kapt case， 进而发现在工程中为了方便，定义了一个 library.gradle ，该文件的作用是定义项目中通用的 Android dsl 配置和共有的基础依赖，因此项目中所有子模块均 apply 了这个文件，但是这个文件陆陆续续的被不同的业务添加新的 kapt 注解处理库，在全源码编译时，所有子模块都得执行 library 模块中定义的全部 6 个 kapt ，即使该模块没有任何注解相关的处理也不例外。
而上述情况的问题在于：相比纯 java 模块的注解处理，kotlin 代码需要先通过 kaptGenerateStub 将 kt 文件转换成为 java ，让 apt 处理程序能够统一的面向 java 做注解扫描和处理。但是上面讲到其实有很多模块是根本不会有任何实际 kapt 处理过程的，却白白的做了一次 kt 转 java 的操作，源码引入的模块越多，这种无意义的耗时累加起来也非常可观。
为了能够弄清楚到底有哪些子模块真正用到了 kapt ，哪些没用到可以禁用掉 kapt 相关 task ，对项目中所有子模块进行了一遍扫描：
使用上述方案，通过全源码打包最终扫描出来大概是 70+模块不会进行任何 kapt 的实际输出，且将这些不会进行输出的 kapt，kaptGenerateStub 的 task 耗时累加起来较高 217s （由于 task 并发执行所以实际总时长可能要少一些).
获取到不实际生成 kapt 内容的模块后，开始对这些模块进行细粒度的拆分，让它们从 apply library.gradle 改为没有 kapt 相关的 library-api.gradle ，该文件除了禁用 kapt 外，与 library 逻辑一致。
但是这样做算是在背后偷偷做了些更改，很可能后续新来的同学不知道有这种优化手段，可能新增了注解后却没有任何输出且找不到原因，而优化效果最好是尽量少给业务同学带来困扰。为了避免这种情况，便对这些 library-api 模块依赖的注解做隔离优化，即：把这些模块依赖的注解库全部 自动 exclude 掉，在尝试使用注解时会因获取不到引用（如下图所示），第一时间发现到依赖被移除的问题。
另一方面在编译出现错误时，对应 gradle 插件会自动解析找不到的符号，如果发现该符号是被隔离优化的注解，会提示将 library-api 替换成 library，尽可能降低优化方案对业务的负面影响。
transform 作为 Android gradle plugin 提供给开发者的 API，用于在 apk 构建过程中，对 class 字节码，resources 等文件内容进行插桩修改，例如官方的 dex, proguard 等功能均由此 api 实现。
对于今日头条这种大型工程来说，有很多诸如性能插桩、自动埋点插桩等相关需求，因此基于此 api 开发了大量 transform，用于实现特定功能，但是这些 transform 基本上都是不支持增量编译的，即使只改动了一行代码，这 些 transform 都会遍历所有 class 文件，解析字节码中的方法字段信息，关键是这类 transform 数量有十几个，将这些遍历耗时乘以 10 累加之后，增量编译耗时自然居高不下。
根据分析，其中性能插桩等相关 transform 做的一些面向线上的插桩方案是完全可以只在 release 打包时打开的，因此可以直接在 debug 编译时禁用这些功能，用于提升开发期间的编译速度。而剩下的 9 个 transform 特征比较相似，可能在一些插桩细节上有所不同，它们大致的处理逻辑为：
由于这 9 个自定义 transform 的功能如此类似，便决定将这些 transform 合并成一个，这样同一个文件的读写操作只执行一次，并且可以做定制化的增量编译优化。虽然公司内有类似的 transform 合并优化方案 byteX ( 已在 github 开源），但是由于今日头条项目在 debug 阶段未开启该功能，且 ByteX 做了一些诸如 ClassGrapth 的构建，对类文件做两次遍历等操作，对于实现类信息收集和信息注入 这个功能来说，byteX 显得比较重 ，于是仍然针对类信息收集注入功能这个细分场景开发了一个收敛框架。
该框架完成了内部 9 种类信息收集注入相关框架的收敛，编译耗时的绝对值加速了 25s 左右，且由于提供了统一的增量缓存功能，使得改动一行代码的耗时可以从 2 分 30s 降低到 35~40s ，实现了增量编译速度大的飞跃。最关键的是将所有自定义 transform 统一管控后，后续可以做统一定制化的需求，进一步优化编译速度。
在 Android debug 编译 过程中，最主要的耗时在 transform 上，而上文 介绍 今日头条项目自定义 transform 已经被高度优化过，剩下的 dexBuilder(将 class 转换成 dex ) ，dexMerge 等 task 耗时就成为了性能瓶颈，dexBuilder 全量编译耗时 60s 左右，增量编译耗时 22s 左右。
根据 DexArchiveBuilderTransform 关键方法 launchProcessing 里面关键一行 isDirectoryBased，如果是目录类型的输入，会根据具体变动 class 文件做增量的 dex 编译 ，但是如果是 jar 输入类型，那只要 jar 里任何一个类变动，则整个 jar 所有类都需要重执行 dex，但是由于 gradle 的依赖特性，基本上只有 app 模块是目录类的输入，其他 library 都是 jar 输入类型，对于比较大的业务模块 ，如果该模块有几千个类，那每改动一次类，就会有几千类连带重新 执行 dex 编译。
在优化前为了得到真正的重新执行 dex 编译的数值，做到最佳优化，设计了一套 hook dex 编译流程的方法(该方法理论上可以 hook Android gradle plugin 任意类：大致就是 hook classLoader ，提前用 asm 修改 D8DexArchiveBuilder 中的 convert 方法
通过对 D8DexArchiveBuilder 的 hook ，统计到优化前改动一行代码会连带着 24968 个类重新执行 dex 编译，增量效果非常差。
既然 jar 输入相比于 目录输入来说增量编译效果非常差，那么可以想到 hook TransformInvocation 中的 input 方法，动态将 project 的 jar 类型输入（JarInput）映射为一个 目录输入（DirectoryInput），那么子模块修改对应代码时，只重新编译目录中被修改的 class 为 dex（而不是原来的整个 jar 内所有 class 重新执行 dex 编译），整体 dex 重新编译的数量将大幅度减少。实现具体方案如下：
而 jar 转 目录的映射细节为:
在第一次增量修改完成后，重新执行 dex 编译的类数量降低至 2152 个，但是其中仍然有很多迷惑的不该执行 dex 编译的类，预期是修改多少类，就重新执行 多少次 dex，因此继续对其中原因进行进一步的探索
由于 java8 的字节码有些指令在 Android 虚拟机中并不能得到支持，会在编译流程中，将这些指令进行脱糖，转换成已有的指令，而 d8 中 desugar 的流程合并到了 dexBuilder 中，为了避免某些类 desugar 后，依赖它的类的行为正确，需要把依赖它的所有类重新执行一遍 dex 编译。
而 d8 会根据 DesugaringGraph 查找 desguar 有变动的类及其依赖的 jar 包，如图下面获得到的 addtionalPaths 是 desguar 类可能直接间接相关的 jar 包，即使这些 jar 包没有任何文件内容变更，其中所有类也得重新全部执行一次 dex 编译。
该类用来辅助获取依赖或间接依赖到变更文件的所有文件，而它的生成逻辑为: 全量或增量编译类的时候记录类型之间的依赖和被依赖关系，依赖关系的判断条件有
DesugaringGraph 不仅记录了类依赖的类，和依赖它的类，同时也记录了一个文件路径包含了哪些类
在增量编译时检查到变动的文件时，会检查这个文件路径包含的所有类， 然后递归查找所有直接/间接依赖它的类，并且找到这些依赖它的类后，会把这个类所在的 jar 包作为额外的处理类型（即使 jar 本身没有任何变动，里面所有的类仍然需要重新 dex 编译)
顺着这个解析关系，找到了一个不正常的 jar 包 bdjson_api ，这个 jar 只有 3 个文件 (IBDJson,BDJsonCollector, BDJsonConstants) 。但是 BDJsonCollector 是一个 stub 类，每次执行 transform 会收集到其他类的信息然后往该类的方法中注入，因此该文件每次编译时都会变动。 这个类本身并没有多少直接依赖它的类，主要是 它所在的 jar 包还有个 IBDJson 接口。
按照之前的 DesugaringGraph 依赖关系，所有 IBDJson 接口的实现类被判断为依赖它，然后这些实现类如果出现在某个 dynamic 方法中，又会被层层查找，查找完了之后，还得计算所有依赖类所在的 jar 包，jar 包中其他没有依赖它的类也会被重新 dex 编译， 在这个 case 的依赖查找中，连带重新执行 dex 编译的类数量并不多，大概为 4 个 jar 包共 2000 多个类重新执行了无意义的 dex 流程，但是如果是其他 sdk jar 包，则可能就会给 dexBuilder 增量带来毁灭性的打击。 上述问题的解决方法：
修复后修改一行代码重新执行 dex 的数量为 10 ，其中 9 个是每次 transform 会修改的 stub 类，1 个是实际修改类。做到了真正的 改多少类，执行多次 dex 编译。
assemebleDebug 的增量编译中从原来（上文 transform 优化后）的 35s~40s 是降低至均值 17s，在 fast build 中效果最明显(屏蔽了 apt)，第二次增量编译能突破到 9s 实现秒级编译。
而经过上面所有的优化后，耗时数据里耗时最严重的 dexBuilder 和 dex-merge 基本都降低在 1s 左右，自定义 transform 也是 1s 左右，其他 task 基本都是零点几秒。在不使用 hotfix 方案的情况下（由于今日头条项目使用了过多的自定义 transform 和插件方案，所以不好使用 instantrun 等 hostfix 方案），相关 task 的耗时基本达到了优化的极限。
Build-cache 是 gralde 提供的一个编译缓存方案，目的是在构建过程中当两个 task 的输入相同时，可以复用缓存内容，直接跳过 task 的执行拿到缓存好的执行结果。由于缓存结果既可以放在本地磁盘，也可以从远程获取，因此容易想到利用 ci 提前 构建缓存包，在其他 ci 机器和开发时利用缓存包获得加速效果。
那么如何判断 task 可以直接获取 之前 task 的缓存内容作为输出呢？定义为可缓存的 task ，会定义一些缓存相关的属性，task 执行时通过文件指纹，缓存属性等一大堆属性计算出缓存 key ，用于查找是否命中缓存，计算维度有:
但是原生的 build-cahce 在缓存命中率上惨不忍睹，公司内抖音团队基于 gradle4.x 的源码做过一些提高命中率的修改，不过今日头条用的 gradle 版本是 5.1 ，受抖音团队的启发，也对 gradle5.1 源码做了些定制化的修改，用于 dump 缓存 key 的计算流程，快速发现缓存问题。相比于抖音发现的一些影响缓存命中的问题，额外发现了一些诸如 mbox , kapt 元素遍历顺序不固定的问题，这里只挑一个典型的 apt 顺序不一致的问题进行介绍：
经过修改 gradle5.1 源码后对编译流程的信息采集，发现有的 task 缓存无法命中是因为 kapt 时，很多生成代码块逻辑是一样的，但是顺序不一样(如下图 demo ：下面两个生成方法的逻辑一致，但是判断顺序不一致，这应该是在 processor 中通过 RoundEnviroment 获取到 注解元素 elemnts 顺序不一致导致的 ）
其内部的原因可能是文件遍历目录时获取子文件的顺序不一致，导致了子文件对应注解元素的顺序也不一致， 总之这个操作影响了生成文件内代码的顺序，也影响了该文件的 hash 计算结果，导致 build-cache 在计算 javac task 的 key 时会错乱导致缓存无法命中。
但是注意到 AbstractProcessor 的核心方法 process 的两个参数都是接口，因此想到可以代理原来的 RoundEnvironment 接口，将其 getElementXx 的方法经过固定排序后返回，使得 apt 注解元素的顺序能够固定下来。
由于篇幅影响，其他影响缓存命中相关的 case 略(主要是一些涉及到文件绝对路径， classPath 相关的问题）
在今日头条这种大型工程中，有很多业务部门参与开发，仅 Android 工程 开发人员就有几百人且人员变动频繁，因此内部任何一项优化工作必然是得搭配上一些管控措施的，否则一边优化一边恶化，空浪费人力。
为此制定了一些管控方案，首先是 debug 阶段的 新增 transform 管控，设置为白名单形式，如果在开发阶段新增了 transform 直接终止编译流程，通过说明文档告知管控的规则，当然，管控的目的是尽可能减少一些不必要的不合理的编译问题，并不是与业务团队作对，如果某一个操作拖慢了整体的编译耗时，但是在 app 性能/稳定性方面有更大收益，且无法在编译期做更多的优化，仍然是允许添加的，只不过是得提前把这个问题暴露出来而已，能更快的找出更多的解决思路，比如引导使用 byteX 等 transform 收敛方案。
另一方面的是合码流程方面的阻塞 ： 今日头条 为了保障 app 的性能稳定性，在合码流程上设置了许多自动化的卡点： 如 包大小检测，插件依赖变更检查， so 变更检查，启动性能检测等，检测到对应问题（如包大小增加异常）会阻塞合码流程。为了管控编译速度 ，使其不至于恶化的太快，也加上了对应的 基于 task 级别的管控，当某一个 task 耗时异常波动，或者新增全新类型的 task 时，能够自动的发现问题，通过机器人将相关人员拉到 mr 讨论群中， 尽量在 合码完成前能发现问题。
为了持续稳定的保持较快的编译速度，可能需要做到以下几点：
字节跳动-GIP-Android 平台架构团队以服务今日头条产品为主，同时协助公司其他产品，在产品性能、稳定性等用户体验，研发流程，编译优化，架构方向上不断优化和深入探索，以满足产品快速迭代的同时，保持较高的用户体验。我们长期招聘 Android 平台架构方向的同学，在北京，深圳均有相关岗位，想深入交流或者需要部门内推、投递简历的可以联系邮箱 wangshupeng@bytedance.com （标题注明 : 字节跳动-GIP 平台 android 部门直推）
欢迎关注字节跳动技术团队
又一开源项目爆火于GitHub，Android插件化强化实战
5月份的时候，我被裁了…
工作7年，裁员新闻经常会听到，我也跟同事调侃说被裁拿n+1更爽，直到自己遇上这种事，宛如晴天霹雳一样。人事大变动，整条业务线被砍，收拾东西，签协议，回到家睡了一天一夜，还是昏沉沉的…
几年前就想着跳槽进大厂，一直想找个时间梳理一下自己的技术体系，准备面试什么的，谁知道拖着拖着到现在了还没准备……正好趁着这个时间，把之前收集的一些资料整理了一下，又根据自己的理解，查阅过资料之后把许多面试题整理了答案。
在我认为，对于Android面试以及进阶最佳的学习方法莫过于刷题+博客+书籍+总结！
苦肝两个月没怎么出门，今日终于拿到了腾讯的offer！给大家分享一下我总结的一些面试题，如有错误，恳请批评指正！
以上是整理总结的Android中高级面试遇到的真题解析，希望对大家有帮助；同时很多人经常也会遇到很多关于简历制作，职业困惑、HR经典面试问题回答等有关面试的问题。同样我也搜集整理了全套简历制作、金三银四社招困惑、HR面试等问题解析，有疑问，可以提供专业的解答。
如何做好面试突击，规划学习方向？面试题集可以帮助你查漏补缺，有方向有针对性的学习，为之后进大厂做准备。但是如果你仅仅是看一遍，而不去学习和深究。那么这份面试题对你的帮助会很有限。最终还是要靠资深技术水平说话。
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。建议先制定学习计划，根据学习计划把知识点关联起来，形成一个系统化的知识体系。
学习方向很容易规划，但是如果只通过碎片化的学习，对自己的提升是很慢的。
我这几年收录整理的Android学习PDF+架构视频+面试文档+源码笔记，高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料可以分享给大家
这些都是我现在闲暇还会反复翻阅的精品资料。 相信可以有效的帮助大家掌握知识、理解原理。
你也可以拿去查漏补缺，提升自身的竞争力。
如果你有需要的话，可以私信我【提升】获取
互联网行业是一个知识迭代非常快的行业，如果你不养成学习的习惯，其他人不会停下来等你，这样的话你就等于一直在退步！
可以加入我们的学习氛围强的技术群跟我们一起学习吧~
RTOS操作系统中HOOK函数的用途
Android插件化是之前几年里的一个很火的技术概念。从2012年开始就有人在研究这门技术。从粗糙的AndroidDynamicLoader框架，到第一代的DroidPlugin等，继而发展到第二代的VirtualApk，Replugin等，再到现如今的VirtualApp，Atlas。插件化在国内逐渐的发展和完善，却也在近几年出现了RN等替代品以后慢慢会走向弱势。
尽管插件化技术的研究热潮已经过去，但是这门技术本身还是有着大量的技术实践，对于我们了解Android机制很有帮助。所以从这篇文章开始我会写一系列的文章，加上自己对插件化的实践，最后会去从源码角度分析几个优秀的插件化库，形成一套完整的插件化的理论体系。
下面是插件化的技术框架，也是我这个系列文章的行文思路，
网上分析Binder机制的文章已经很多了，在这篇文章里，我不会去讲解Binder的使用，而是会去讲解清楚Binder的设计思路，设计原理和对于插件化的使用。
为什么需要Binder
首先我们知道，Android是基于Linux内核开发的。对于Linux来说，操作系统为一个二进制可执行文件创建了一个载有该文件自己的栈，堆、数据映射以及共享库的内存片段，还为其分配特殊的内部管理结构。这就是一个进程。操作系统必须提供公平的使用机制，使得每个进程能正常的开始，执行和终结。
这样呢，就引入了一个问题。一个进程能不能去操作别的进程的数据呢？我们可以想一下，这是绝对不能出现的，尤其是系统级的进程，如果被别的进程影响了可能会造成整个系统的崩塌。所以我们很自然的想到，我们应该把进程隔离起来，linux也是这样做的，它的虚拟内存机制为每个进程分配连续的内存空间，进程只能操作自己的虚拟内存空间。同时，还必须满足进程之间保持通信的能力，毕竟团结力量大，单凭单个进程的独立运作是不能撑起操作系统的功能需求的。
为了解决这个问题，Linux引进了用户空间User Space和内核空间Kernel Space的区别。用户空间要想访问内核空间，唯一方式就是系统调用。内核空间通过接口把应用程序请求传给内核处理后返回给应用程序。同时，用户空间进程如果想升级为内核空间进程，需要进行安全检查。
以上就是linux系统的跨进程通信机制。而我们马上要说的Binder，就是跨进程的一种方式
Binder是一种进程间通信(IPC)方式，Android常见的进程中通信方式有文件共享，Bundle，AIDL，Messenger，ContentProvider，Socket。其中AIDL，Messenger，ContentProvider都是基于Binder。Linux系统通过Binder驱动来管理Binder机制。
首先Binder机制有四个参与者，Server，Client两个进程，ServiceManager，Binder驱动(内核空间)。其中ServiceManager和Binder驱动都是系统实现的，而Server和Client是需要开发者自己实现的。四者之中只有Binder驱动是运行在内核空间的。
这里的ServiceManager作为Manager，承担着Binder通信的建立，Binder的注册和传递的能力。Service负责创建Binder，并为他起一个字符形式的名字，然后把Binder和名字通过通过Binder驱动，借助于ServiceManager自带的Binder向ServiceManager注册。注意这里，因为Service和ServiceManager也是跨进程通信需要Binder，ServerManager是自带Binder的，所以相对ServiceManager来说Service也就相当于Client了。
Service注册了这个Binder以后，Client就能通过名字获得Binder的引用了。这里的跨进程通信双方就变成了Client和ServiceManager，然后ServiceManager从Binder表取出Binder的引用返给Client，这样的话如果有多个Client的话，多次返回引用就行了，但是事实上引用的都是放在ServiceManager中的Service。
当Client经过Binder驱动跟Service通信的时候，往往需要获取到Service的某个对象object。这时候为了安全考虑，Binder会把object的代理对象proxyobject返回，这个对象拥有一模一样的方法，但是没有具体能力，只负责接收参数传给真正的object使用。
所以完整的Binder通信过程是
OK，跨进程通信就讲清楚了。接下来我们讲讲插件化中的Binder。
首先，我们先回顾一下Activity的启动过程，Instrumentation调用了ActivityManagerNative，这个AMN是我们的本地对象，然后AMN调用getDefault拿到了ActivityManagerProxy，这个人AMP就是AMS在本地的代理。相当于binder模型中的Client，而这个AMP继承的是IActivityManager，拥有四大组件的所有需要AMS参与的方法。本地通过调用这个AMP方法来间接地调用AMS。这样，我们就调用到了AMS启动了Activity。
那么，AMS如何与Client进行通信呢？现在我们通过Launcher启动了Activity，肯定要告诉Launcher “没你什么事了，你洗洗睡吧”。大家可以看到，这里双方的角色就发生了改变，AMS需要去发消息，承担Client的角色，而Launcher这时候作为Service提供服务。而这次通信同样也是使用的Binder机制。AMS这边保存了一个ApplicationThreadProxy对象，这个对象就是Launcher的ApplicationThread的代理。AMS通过ATP给App发消息，App通过ApplicationThread处理。
以上，就是Binder机制在Android中的运用，我们后面会通过hook这个过程实现插件化。
看了这么多，可能还是很多朋友不懂Binder。我也是这样，很长一段时间都不知道Binder到底指的是啥。后来我看到了这样一种定义：
双亲委托模型
Java中默认有三种ClassLoader。分别是:
ClassLoader默认使用双亲委托模型来搜索类。每个ClassLoader都有一个父类的引用。当ClassLoader需要加载某个类时，先判断是否加载过，如果加载过就返回Class对象。否则交给他的父类去加载，继续判断是否加载过。这样 层层判断，就到了最顶层的BootStrap ClassLoader来试图加载。如果连最顶层的Bootstrap ClassLoader都没加载过，那就加载。如果加载失败，就转交给子ClassLoader，层层加载，直到最底层。如果还不能加载的话那就只能抛出异常了。
通过这种双亲委托模型，好处是：
Android中的ClassLoader
android从5.0开始使用art虚拟机，这种虚拟机在程序运行时也需要ClassLoader将类加载到内存中，但是与java不同的是，java虚拟机通过读取class字节码来加载，但是art则是通过dex字节码来加载。这是一种优化，可以合并多个class文件为一个classes.dex文件。
android一共有三种类加载器:
看PathClassLoader和DexClassLoader源码，都是继承自BaseDexClassLoader。
我们可以看到PathClassLoader的两个参数都为null，表明只能接受固定的dex文件，而这个文件是只能在安装后出现的。而DexClassLoader中optimizedDirectory，和librarySearchPath都是可以自己定义的，说明我们可以传入一个jar或者apk包，保证解压缩后是一个dex文件就可以操作了。因此，我们通常使用DexClassLoader来进行插件化和热修复。
可以看到，BaseDexClassLoader有一个相当重要的过程就是初始化DexPathList。初始化DexPathList的过程主要是收集dexElements和nativeLibraryPathElements。一个Classloader可以包含多个dex文件，每个dex文件被封装到一个Element对象。这element对象在初始化和热修复逻辑中是相当重要的。当查找某个类时，会遍历dexElements，如果找到就返回，否则继续遍历。所以当多个dex中有相同的类，只会加载前面的dex中的类。下面是这段逻辑的具体实现
我们先是讲解了Java中类加载的双亲委托机制，然后介绍了Android中的几种ClassLoader，从源码角度介绍了两种ClassLoader加载机制的不同。以后的插件化实践中，我们会经常用到DexClassLoader。
这里是一份BAT大厂面试资料专题包：
欢迎从事移动开发3到5年的朋友关注我，我正整理高级的系统提升资料，希望帮更多人突破目前的技术瓶颈进入大厂发展。而想进大厂，要先自身达到大厂的技术水平要求。行百里者半九十，我希望你能坚持到最后。
更多Android开发架构资料和面试资料，关注+私信我【开发】获取
