How we cut the build time for our Android app by 95%

By Arnav Gupta

This post was originally published on Zomato Blog on April 24, 2019.

How much time does it take you to rebuild your Android app every time you make changes?

How much time do you think the Zomato app used to take to build for our engineering team? Here are some reference points for you to be able to take an intelligent guess –

• 29 submodules
• 6400 java files, 1300 kotlin files and over 17000 xml files
• ~1.2M lines of Java

Well, here is the typical build time it used to take –

2 minutes and 18 seconds. Let’s estimate the huge amount of productivity loss that it used to lead to. A 10 member Android engineering team — running/building the app 20 times a day post even a minor change in code, results in 10*20*2.18 = 436min = ~7 hours per day of lost productivity; every day simply waiting for builds. That’s huge, and wasn’t cool until we decided to do something about it.

Slow build times make developers avoid testing on the fly, which resulted in a less stable app for our end users.

Keeping build times low is important for an engineering team’s fulfilment at work; it also indirectly leads to better, more stable products, leading to higher user satisfaction.

So how did we cut down the build time by 95%?

Understanding the problem — Gradle build profile and scans

The first step is to run gradle assembleDebug --profile to get a breakdown of how much time specific parts of your build take. If you want detailed results of why each step took place, and a thread-wise report of all executed tasks, use gradle assembleDebug --scan.

A thread wise Gradle scan of our build. Notice how we are unable to leverage the 12 threads, and most of the build time is spent building the main app module on a single thread

BUD optimisation

1. Bottlenecks

If a project has a lot of modules, it is important to make sure the dependency graph is created well. It is also important to decide where to use implementation and api when creating module-to-module dependencies.

• If we have the following setup:
  app -> api(modA) -> api(modB) -> api(modC) then, any changes to modC will lead to recompilation of modB, modA and finally, app
• In contrast, if we have this setup:
  app -> implementation(modA) -> implementation(modB) -> implementation(modC) then changes to modC, will only read to modB recompilation

2. Unnecessary Work

The removal of unnecessary steps from the build is essential when making debug builds.

• Do not run firebase-perf or newrelic plugins on debug builds. These transform your classes for performance tracking and increase Java/Kotlin compile time
• If your development team is mostly using similar test devices and testing only English languages, you can set resConfig to only en, xxhdpi, which will reduce resource packaging for other dpis and languages

Removing these steps from our debug build dropped 40s from our build. Isn’t that amazing?

3. Duplicated Work

We noticed that even without a single line of change, the tasks kotlinCompile and javaCompile were still running for the entire duration it usually takes in a clean build.

That made us suspect that the compiled jars are not saved for incremental builds.

In the Gradle build scan, you can click on each task and get to know the reason why that task had been run

The culprit? We had fields in BuildConfig.java that were changing in every build. For example, saving the build timestamp.

Changes in BuildConfig invalidates all the incremental build jars from the last iteration, and also stops Android Instant Run from working.

The Result

Our builds are now heavily parallelised, leveraging Gradle parallel processing, since our dependency graph is properly setup now.

Our new gradle build scan

Making changes to deep-down library modules, that are used across the entire app in multiple modules still takes time. However, now we don’t have to wait for 2 minutes to view changes to reflect for as simple a thing as a padding of a button.

When there are only a few changes to our consumer app codebase (without any changes to inner modules), it takes only 7 seconds to build.

Not having ever-changing variables in BuildConfig.java, in our debug builds, means that Instant Run now works and greatly improves iteration time of UI changes.

Part of our build time optimisation effort also got us up to date with the Android Gradle Build plugin version 3.3 (we were on 3.0 till now). We can now release our app as app bundles and reduce download sizes by 20% for our users.

If you are an Android engineer who loves challenges and is keen on working with Zomato, do check this out.