In a recent technology sharing, some netizens asked me what compilation optimizations small companies can consider doing? I think it is still necessary to expand on this subject.
In terms of compilation optimization, I personally think that it is not necessarily a particularly tall thing. Except for some special deep-water areas, there are still some things that can be developed from the subtleties. Today we will try to pull him into the water.
Componentization
What is the relationship between componentization and compilation optimization? Some people even think that it may slow down the compilation speed of the entire project.
In my opinion, gradleit is a parallel compilation mode, so when our project is taskGraphconfirmed, many modules without dependencies can be compiled in parallel. In this case, we can fully use the ability of parallel compilation.
And from another perspective gradle build cache, we can have a more detailed buildcache. It can also be faster during an increment if the current module is unchanged.
Use DI or SPI skillfully
In the past, I was actually quite disgusted DI(依赖注入). I thought it would greatly increase the complexity of the project. DI(依赖注入)After all, it is quite troublesome to master one .
But recently I suddenly figured it out. GE(Gradle Enterprise)When I read it before, I found that there are dependencies between some business modules, which leads to the compilation order of these modules must be in a relatively later state, but because it com.android.applicationwill depend on all business modules, at this time The bucket theory will be triggered, and the compilation of this module is the shortest short board of the entire bucket. It also makes parallel compilation of the entire project unavailable for a while.
Then we can solve this problem in the form of DI(依赖注入)or . SPI(服务发现)The module does not directly depend on the realization of the business but relies on an abstract interface of the business for programming, which can optimize the dependencies between existing project modules.
Although the reason is simple, the actual de-abstraction will also test the code ability of the corresponding development.
Pay attention to AGP optimization plan
这部分我觉得是很容易被开发遗忘的，比如我们最近在做的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。
花点钱接个GE
如果这个老板不太差这么点钱，我真的觉得GE(Gradle Enterprise)是个非常好的选择。可以很直观的看出一些工程的编译问题，而且对接的gradle同学也都很专业。
不要轻易魔改Gradle
非必要的情况下，个人是不太建议同学们改这个的。非常容易破坏整个编译缓存系统！这里不仅仅只针对Transform，还有对任意编译产物进行修改的，比如xml，资源等等。当然如果可以的话，尽可能的使用最新AGP提供的一些新的api去进行修改吧。这个可以多参考下2BAB大神的一些文章。
另外比如很多非必要的Transform转化建议本地编译的时候就直接关闭了，虽然可能会出现一些本地行为不一致的情况，但是可以大大的优化一些编译速度。字节码不是炫技的工具，谨记！
总结
最近基本没有做一些特别适合分享的内容，文章也就没有更新了。各位大佬们体谅啊，抱拳了。
在下封于修，前来讨教。既分生死，也决高下。