开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 10 天，点击查看活动详情

Android Gradle构建不能更快了? 原因在这

对于Android开发者来说，最大的痛点之一就是构建时间. 这是一个真正的问题, 那么为什么尽管有了Gradle和Android Gradle插件的连续版本, 构建一个Android应用仍然需要这么长时间?

Android Studio, 是你的冬日加热器

这几年来一直是个笑话, Android Studio, 或者更准确的说是Gradle, 正在密集地使用CPU, 导致大多数电脑过热, 需要他们的风扇系统全速运转(特别是MacBook Pro Intel版).

这是一个现实, 一个Android开发者每天都会经历的事情, 电脑变得非常热, 而且在夏天的时候情况会更糟糕. 显然, 这种情况离理想的工作环境很远. 此外, 构建时间似乎变得越来越慢, 一天又一天, 一个版本又一个版本.

Gradle, 是一个Java工具

当仔细观察时(如在MacOS上的Activity Monitor), 我们可以注意到, 当Gradle任务启动时, Java也会被启动.

在./gradlew assembleDebug运行时的java进程

我们可以看到, Java的CPU使用率超过了700%. 多亏了多核/多线程, Gradle和Java可以使用所有可用的资源, 以加快构建速度(至少他们在努力).

Gradle的构建也使用了大量的内存, 这个构建的内存高达1500MB(这是一个使用Jetpack Compose的单一屏幕活动, 有几个按钮)

Java以使用大量的内存和相当多的CPU而闻名. 这是因为它在运行一个虚拟机, 启动时很重, 但一旦热起来就会变好. 用./gradlew clean assembleDebug进行第二次构建, 运行速度会快得多(即使有clean), 主要是因为几乎所有东西都已经加载到内存中了. 这就是Java可以表现良好的地方, 也要感谢Gradle Deamon.

过去几年中的改善

尽管Gradle构建感觉很慢, 但各团队在提高性能方面做了很多工作, 他们探索了一些领域:

并行编译

随着多核CPU的兴起, 多个进程可以同时运行, 实际上是将速度乘以核数. 但那是几年前启用的, 所以当时你可能已经注意到了改进, 但这已经不是你真正可以指望的了. 除非你得到比今天多得多的CPU-核心.

Gradle守护进程

为了确保Java和Gradle是温暖的, Gradle团队引入了Gradle Daemon, 这样软件就可以随时准备好运行你的编译, 而不需要再次初始化. 这无疑改善了当时的性能, 但那是一段时间以前的事了...

缓存

这可能是效果最好的事情之一, 而且至今仍然适用. 模块可以被缓存, 这意味着如果你在架构你的应用程序时有多个模块(例如图层, UI, 数据, 网络...), 如果该模块没有变化, Gradle将跳过模块的构建. 这真的可以加快你的构建时间.

未完, 待续...