Android打包加速新知（2023-3）

背景

代码特性：大概50w行代码，30左右个module，源码依赖flutter。
设备：性能一般（i5+16g）的mac。
架构：虽然有多模块，但是大部分代码都集中在一个核心模块，且该模块被几个独立业务模块依赖，有独立且干净的app模块。

参考

Android官方
Gradle官方

实操总结

对于一般性能的设备，官方的建议很多是反作用的。如下：

• 最新版的AGP 7 + Gradle 7 + jdk 11性能实际上是比 4 + 6 + 11 差的，主要是内存消耗明显增加，scan里的GC时间明显高
• JavaCompile.options.fork = true是负向的，主要体现在GC时间上，应该是fork后整体内存更吃紧了，预计IPC也有消耗
• JavaCompile.options.incremental = true是负向的（大模块改一行代码），原因未知
• configurationOnDemand没啥用
• configurationCache和flutter冲突，用不了

几个容易被忽略的特征：

• daemon的复用对性能影响极大，应该是有大量内存对象有复用提速效果
• GC时间对于其他task的执行时间影响极大，会有放大效应，主要是打断和内存换出
• 号称依赖会影响打包时间，梳理可以用这个插件
  • configuration时间最好情况下降20%，但极不稳定
  • 影响configuration时间的主要还是task个数，需要和并行度做trade off
  • ROI低，不值得做
• Non-transitive R，见文章。本地测试效果不明显。

少量修改最无用的耗时主要是几个方面：

• configuration，每次都有，且flutter源码依赖无法开cache -> flutter产物依赖+cache
• dex archive builder，每次都有，cache按模块，如果有瓶颈模块会很慢 -> 蹲一个wade plugin，原理不复杂，结果应该很管用
• merge dex，每次都有，基本没办法cache
• packge，每次都有，没办法cache -> 和merge dex都是靠业务独立工程更靠谱