Android Gradle Builds won’t be faster, here is why
One of the biggest pain point for Android Developers is the build time. This is a real concern, so why despite the successive versions of Gradle and Android Gradle Plugin, building an Android app takes so long?
Android Studio, your winter heater
It has been a running joke for a few years now, Android Studio, or more precisely Gradle, is using the CPU intensively, resulting in most computers to overheat and requiring their fan system to go at full speed (especially MacBook Pro Intel edition).
This is a reality, a thing that Android Developers experience everyday, with computers becoming incredibly hot, and this gets even worse during summer days. Obviously, such situation is very far from the ideal work environment. To add to that, build time seems to become slower and slower, day after day, version after version.
Gradle, a Java tool
When looking a little closer, we can notice that when a Gradle task is started, Java is started too.
We can see that the CPU is used at more than 700% by Java. Thanks to multi-core / multi-thread, Gradle and Java can use all the resources available in order to speed up the build (at least they try).
Gradle build are also using an important amount of memory, up to 1500MB for this build (which is a single activity of 1 screen with Jetpack Compose, with a couple of buttons).
Java is known for using a lot of RAM and a fair bit of CPU too. This is because it is running a Virtual Machine, which is heavy to launch, but gets better once it is warm. A second build with ./gradlew clean assembleDebug will run much faster (even with clean), essentially because almost everything is already loaded into memory. This is where Java can perform well, also thank tp Gradle Deamon.
Improvements in the last few years
Despite Gradle build feeling slow, the teams worked a lot on improving the performance, and they explored a few areas:
Parallel compilation
With the rise of multi-core CPUs, multiple processes can be run at once, virtually multiplicating the speed by the number of cores. But that was enabled years ago, so at the time you may have noticed an improvement, but that’s not something you can really count on anymore. Unless you get a lot more CPU-core than you have today.
Gradle Daemon
To make sure Java and Gradle are warm, the Gradle team introduced Gradle Daemon, so that the software is always ready to run your compilation without having to initialise again. That definitely improved a bit the performance at the time, but that was some time ago…
Caching
That is probably one of the thing that has worked the best and is still relevant today. Modules can be cached, which means that if you architecture your app in a way where you have multiple modules (for example layers, UI, Data, Network…), Gradle will skip the module-build if nothing has changed in that module. This can really speed up your build time.
But why is it getting slower?
What if I’m telling you it is not, and it is actually faster? The Gradle and Java Teams work and improve things a little bit every iteration, but nothing significant enough.
While they are doing that, two things happen:
Your code base increase
With mobile teams ranging from 2–50 developers, it is easy to see how a lot more code can be written between 2 version of Android Studio/Gradle.
Your hardware is ageing
You computer itself is getting older, accumulating a bit more dust, and running other software that takes more RAM and CPU. All of this, reduces a bit what compute power Android Studio, Gradle and Java can use themselves.
Is there any hope?
I’m afraid that the answer is no. Surely the Gradle Team is working on some feature to try to improve the build time, such a configuration cache. But it won’t improve tremendously the build time.
The only area that I didn’t hear anything about is using the GPU for Gradle builds and as-far-as I know, GPU are not design for this kind of compilation.
Software wise, there isn’t much that can be done. Sure, it will improve a little, but nothing significant, unlike most Android Developer expect, such as reducing by 50% the build time.
What can I do?
Since the software won’t improve much, and your hardware will continue ageing, the only valid solution I see today is to buy a new computer, something that has many-many cores so that you can take advantage of the parallel execution and something with a decent amount of RAM, because by design Java needs a lot of this.
Many people will argue that MacBook Pro M1 Pro/MAX are ideal computers and I support that idea, they have up to 10-cores and up to 64GB or RAM, but they are very expensive in this configuration. In the PC world it is possible to find 8-cores at a decent price, Linux is also a good OS for Android Development 😉.
Last but not least, you can modularise your app, to take advantage of the caching mechanism. This may require a significant effort from your team, but will pay off in the long run.
One last tip
Identifying Gradle bottle neck, can help you define a modularisation strategy.
./gradlew assembleDebug --profile
One more thought
When Google introduced Kotlin, a few years back, I was already complaining about slow builds and overheating laptop. And I had hope that one day they would ditch Java and use Kotlin only to compile natively without Gradle, Java or JVM at all. JetBrains has since provided Kotlin Native, which compile Kotlin code thanks to LLVM into byte code, without any JVM.
But in order to ditch Java completely, some of the Android foundation would need to be in Kotlin or anything but Java and most of all, not rely on JVM. This would require some deep OS changes to run Kotlin natively directly to the silicon. I’m glad to see that Google is commited to Kotlin and that any new Jetpack library is now Kotlin only and at some point, with a few bridge and binding, we might be able to compile our Apps without relying on Java or JVM.
Conclusion
That’s it for me, as always if you enjoyed reading, please clap 👏, tap that button many-many times to show your appreciation, that is always warmly appreciated 🙂.
