【白水日记】加快gradle编译速度
gradle编译项目虽然方便，但随着项目体积的增长，编译速度越来越慢，浪费了大量时间，短则也要1分钟，长则4 5 分钟，缩短gradle构建时间虽然重要，却往往不被人们重视，因此本篇总结了压缩gradle构建时间的建议
尽量使用最新的插件，官方升级gradle插件，不光是为了修复上一个版本的问题，每次迭代升级都会考虑加入一些缓存策略，提高编译速度，虽然会带来一些改造成本，不过为了提高编译速度，可以考虑提高gradle plugin和Android gradle的版本，AndroidStudio工具版本，SDK版本
在同一个模块中，尽量不要混合java代码和kotlin代码，尽量隔离两种语言的代码
如果没有必要，不要为Android library modules生成 buildConfig文件
AGP4.0+开始支持细化配置构建功能，例如禁掉view binding或者data binding，可在gradle.properities中配置aidl，compose，databinding，prefab，renderscript，shaders等功能，禁用掉不会使用的功能，也会提升效率
删除掉不会被使用的代码，资源，依赖，图片迁移到webp，本质还是优化工程体积，极端一些的，甚至可以禁用png
android {buildTypes {release {Disables PNG crunching for the release build type.crunchPngs false}}}
禁用jetifier，此插件主要工作支持AndroidX迁移转换，但前提是程序里的代码已经都完成了AndroidX迁移，不需要兼容
使用Android Gradle 构建缓存插件：https://github.com/gradle/android-cache-fix-gradle-plugin
使用gradle插件分析构建问题耗时
禁用掉一些不必要的gradle插件，根据环境区分动态使用插件
开发环境使用-all.zip包，可以完整调试gradle脚本代码，生产环境，为了加快速度可以替换成-bin.zip包
使用gradle daemon，当然了在3.0以后的版本，默认开启，原理就是将重要的相关数据放到内存中，用空间换时间，避免在中gradle.properties出现org.gradle.daemon=false
保证各个软件jdk版本的一致性，jdk版本不同，会导致产生新的gradle守护进程，有可能会导致内存消耗翻倍
如果gradle配置了多个依赖仓库，默认情况下，gradle会搜索所有的仓库，这也是个耗时行为，通过api指定某个仓库，也是一个解决方案
repositories {mavenCentral()exclusiveContent {forRepository {maven {url = uri("https://repo.example.com/maven2")}}filter {includeGroup("com.example")}}}
解耦并进行模块化，同样会节省大量编译时间，如果有条件，甚至可解耦出纯java的模块，这样做后，也会避免gradle构建浪费
R8是一个耗时的工作，可以考虑在debug环境中禁用。其主要耗时包括代码收缩，资源压缩，混淆，优化检查，减小dex文件。minifyEnabled & shrinkResources选项同样会花费时间构建，debug环境也可考虑关闭
优化网络环境：gradle构建有时候瓶颈是在下载远端依赖
不要滥用传递依赖，适当用implementation替换api，减少依赖传递，同样可以减少gradle工作量
减少R文件的大小android.nonTransitiveRClass=true，如果有必要，不要传递R文件
强制并行执行gradle任务org.gradle.parallel=true，简单说也是用内存换时间
不要全量执行variants，一个项目往往有多个变体，默认会执行所有的变体，编译时可以区分，如果没必要，可以跳过
总结：优化项目编译速度，是一件重要却不紧急的事情，项目推进中，大部分人都只关心收益、成果。光鲜亮丽的一面固然重要，却也需要其他枯燥甚至脏活的支撑。如果大家都只关注紧急且重要的事情，永远都在向前跑，导致技术债越背越多，早晚有进行不下去的一天。一个健康合理的架构，是需要有资源投入到优化当中进行。想起小时候看纪录片的故事：一个探险队在原始部落探险，请了当地的一位土著当向导。结果向导走一段路，就要停下来歇息一会。探险家疑惑不解，请教土著向导为何如此？土著向导答道：每走一段路，就要停下来等等灵魂。