最近のテクノロジー共有で、一部のネチズンから、中小企業はどのようなコンパイル最適化を検討できるのかと尋ねられました。この点については、まだまだ発展させていく必要があると思います。
コンパイルの最適化に関しては、必ずしもそれほど高いものではなく、一部の特殊な深海エリアを除けば、まだまだ微妙なところから開発できる部分があると個人的には考えています。今日は彼を水の中に引き込んでみます。
コンポーネント化
コンポーネント化とコンパイルの最適化にはどのような関係がありますか? コンポーネント化によってプロジェクト全体のコンパイル速度が遅くなるのではないかとさえ考える人もいます。
私の意見では、gradleこれは並列コンパイル モードであるため、プロジェクトがtaskGraph承認されると、依存関係のない多くのモジュールを並列コンパイルできると思います。この場合、並列コンパイルの機能を最大限に活用できます。
別の観点から見るとgradle build cache、より詳細な情報が得られますbuildcache。現在のモジュールが変更されていない場合、インクリメント中にも高速化される可能性があります。
DIやSPIを上手に使いこなす
以前は、DI(依赖注入)プロジェクトが大幅に複雑になると考えていたため、実際には非常に嫌悪感を抱いていました。結局のところ、 1つを習得するのは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。
花点钱接个GE
如果这个老板不太差这么点钱，我真的觉得GE(Gradle Enterprise)是个非常好的选择。可以很直观的看出一些工程的编译问题，而且对接的gradle同学也都很专业。
不要轻易魔改Gradle
非必要的情况下，个人是不太建议同学们改这个的。非常容易破坏整个编译缓存系统！这里不仅仅只针对Transform，还有对任意编译产物进行修改的，比如xml，资源等等。当然如果可以的话，尽可能的使用最新AGP提供的一些新的api去进行修改吧。这个可以多参考下2BAB大神的一些文章。
另外比如很多非必要的Transform转化建议本地编译的时候就直接关闭了，虽然可能会出现一些本地行为不一致的情况，但是可以大大的优化一些编译速度。字节码不是炫技的工具，谨记！
总结
最近基本没有做一些特别适合分享的内容，文章也就没有更新了。各位大佬们体谅啊，抱拳了。
在下封于修，前来讨教。既分生死，也决高下。