最近在一次技能分享中，有网友问我小公司能够考虑做哪些编译优化？我觉得这个课题也仍是挺有必要打开下讲讲的。

编译优化方面其实我个人觉得并不一定是特别高大上的东西，除了一些特别深水区的当地，仍是有些东西仍是能从细微处进行打开的。今天咱们就测验下拉他下水。

组件化

组件化和编译优化有啥关系? 有些人甚至觉得可能会拖慢整个工程编译速度吧。

在我的认知中gradle是一个并行编译的模式，所以当咱们的工程的taskGraph确认之后，许多没有依靠关系的模块是能够并行编译的。这样的状况下咱们就能够充沛的运用并行编译的才能。

并且从别的一个角度gradle build cache出发，咱们能够具有更细致的buildcache。假如当时模块没有改变，那么在增量过程中也能够变得更快。

巧用DI或许SPI

以前我其实挺反感DI(依靠注入)的，我以为会大大的增加工程的复杂度。究竟掌握一门DI(依靠注入)仍是挺麻烦的。

可是最近我突然想通了，我之前看GE(Gradle Enterprise)的时分，发现有些事务模块之间有依靠关系，导致了这些模块的编译次序必须在相对靠后的一个状态，可是由于com.android.application会依靠所有事务模块，这个时分就会触发水桶理论，该模块的编译就是整个水桶最短的短板。也让整个工程的并行编译有一段时刻不可用。

那么这种问题咱们能够通过DI(依靠注入)或许SPI(服务发现)的方式进行处理。模块并不直接依靠事务的完成而是依靠于事务的一个抽象接口进行编程，这样能够优化既有工程模块间的依靠关系。

道理尽管简略，可是真的去抽象也会考验对应开发的代码才能。

关注AGP优化方案

这部分我觉得是很简单被开发遗忘的，比方咱们最近在做的buildConfig，AIDL编译时默许封闭，还有去年到本年一直在进行的非传递R文件的改造。官方的Configuration Cache，还有后续的全局AGP通用属性，还有默许封闭Jetfied等等，这些跟随AGP迭代的属性。

结果上看封闭非必要模块的buildConfig AIDL能够让全量编译时刻缩短大约2min，当然主要是咱们模块多。而非传递R能够让咱们的工程的R文件改变的增量缓存更好管理。

Kotlin技能栈更新

kt现已发布很长时刻了，最近最让我等待的是kt2.0带来的K2的release版别。能大大的提升kotlin compiler编译速度。

别的还有kt之前发布的ksp，是一个十分牛逼的kapt的替代方案。并且官方也在逐步对ksp进行支持。比方room这个结构就现已适配好了ksp。我自己也写过好几个ksp插件。我个人以为仍是十分酷的。

最后还有一些抛弃东西的下架，比方KAE(kotlin-android-extensions)这种现已被明确说是后续不继续进行支持的结构。咱们最近测验的方案是通过Android Lint把所有声明KAE的进行报错处理。剩余的就是事务自行决定是改成findViewById仍是viewBinding。

KAEDetector

花点钱接个GE

假如这个老板不太差这么点钱，我真的觉得GE(Gradle Enterprise)是个十分好的挑选。能够很直观的看出一些工程的编译问题，并且对接的gradle同学也都很专业。

不要容易魔改Gradle

非必要的状况下，个人是不太建议同学们改这个的。十分简单损坏整个编译缓存体系！这儿不仅仅只针对Transform，还有对任意编译产品进行修正的，比方xml，资源等等。当然假如能够的话，尽可能的运用最新AGP供给的一些新的api去进行修正吧。这个能够多参阅下2BAB大神的一些文章。

别的比方许多非必要的Transform转化建议本地编译的时分就直接封闭了，尽管可能会出现一些本地行为不一致的状况，可是能够大大的优化一些编译速度。字节码不是炫技的东西，谨记！

总结

最近基本没有做一些特别适合分享的内容，文章也就没有更新了。各位大佬们体谅啊，抱拳了。

在下封于修，前来讨教。既分存亡，也决高下。