Press Kit
I'm logo
Arnav Gupta | April 24, 2019
How we cut the build time for our Android app by 95%

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.

More for you to read

Engineering

Tania Kohli | August 8, 2019
Huddle Diaries – Product Design

Huddle by Zomato is an event that is focused on building a stronger tech community in the Delhi region.

Engineering

Vamica Butola | July 9, 2019
Women in Tech – Chapter 2

Follow the personal journeys of some of the most incredible Women in Tech at Zomato.

Engineering

Mehak Satija | June 11, 2019
Women in Tech – Chapter 1

Follow the personal journeys of some of the most incredible Women in Tech at Zomato.

Engineering

Tania Kohli | June 6, 2019
Engineers can now ‘demo’ work with Zomato

Trial Week is a concept where engineers register to work for a week and eventually secure a place in Zomato’s engineering team.