En un intercambio de tecnología reciente, algunos internautas me preguntaron qué optimizaciones de compilación pueden considerar hacer las pequeñas empresas. Creo que todavía es necesario ampliar este tema.
En términos de optimización de la compilación, personalmente creo que no es necesariamente algo particularmente alto. Excepto por algunas áreas especiales de aguas profundas, todavía hay algunas cosas que se pueden desarrollar a partir de las sutilezas. Hoy intentaremos tirar de él al agua.
Componentización
¿Cuál es la relación entre la creación de componentes y la optimización de la compilación?Algunas personas incluso piensan que puede ralentizar la velocidad de compilación de todo el proyecto.
En mi opinión, gradlees un modo de compilación en paralelo, por lo que cuando se taskGraphconfirme nuestro proyecto, se pueden compilar en paralelo muchos módulos sin dependencias. En este caso, podemos usar completamente la capacidad de compilación paralela.
Y desde otra perspectiva gradle build cache, podemos tener una más detallada buildcache. También puede ser más rápido durante un incremento si el módulo actual no cambia.
Usa DI o SPI hábilmente
En el pasado, en realidad estaba bastante disgustado DI(依赖注入), pensé que aumentaría en gran medida la complejidad del proyecto. DI(依赖注入)Después de todo, es bastante problemático dominar uno .
Pero recientemente me di cuenta de repente. GE(Gradle Enterprise)Cuando lo leí antes, descubrí que hay dependencias entre algunos módulos comerciales, lo que lleva a que el orden de compilación de estos módulos deba estar en un estado relativamente posterior, pero debido a que dependerá com.android.applicationde todos los módulos comerciales. módulos, en este momento se activará la teoría del cubo, y la compilación de este módulo es el tablero corto más corto de todo el cubo. También hace que la compilación paralela de todo el proyecto no esté disponible durante un tiempo.
Entonces podemos resolver este problema en forma de DI(依赖注入)o . SPI(服务发现)El módulo no depende directamente de la realización del negocio, sino que se basa en una interfaz abstracta del negocio para la programación, que puede optimizar las dependencias entre los módulos de proyectos existentes.
Aunque la razón es simple, la eliminación de la abstracción real también pondrá a prueba la capacidad de código del desarrollo correspondiente.
Preste atención al plan de optimización de 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。
花点钱接个GE
如果这个老板不太差这么点钱，我真的觉得GE(Gradle Enterprise)是个非常好的选择。可以很直观的看出一些工程的编译问题，而且对接的gradle同学也都很专业。
不要轻易魔改Gradle
非必要的情况下，个人是不太建议同学们改这个的。非常容易破坏整个编译缓存系统！这里不仅仅只针对Transform，还有对任意编译产物进行修改的，比如xml，资源等等。当然如果可以的话，尽可能的使用最新AGP提供的一些新的api去进行修改吧。这个可以多参考下2BAB大神的一些文章。
另外比如很多非必要的Transform转化建议本地编译的时候就直接关闭了，虽然可能会出现一些本地行为不一致的情况，但是可以大大的优化一些编译速度。字节码不是炫技的工具，谨记！
总结
最近基本没有做一些特别适合分享的内容，文章也就没有更新了。各位大佬们体谅啊，抱拳了。
在下封于修，前来讨教。既分生死，也决高下。