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

Zomato
Zomato
Sep 10, 2019 · 4 min read

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

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

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 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.

Zomato Technology

This space is for sharing what we’ve learnt, insights we’ve garnered and the inspiration behind our developments in Engineering, Design and Product

Zomato

Written by

Zomato

Better food for more people.

Zomato Technology

This space is for sharing what we’ve learnt, insights we’ve garnered and the inspiration behind our developments in Engineering, Design and Product

More From Medium

More on Zomato from Zomato Technology

More on Zomato from Zomato Technology

[India] Call for feedback — Restaurant Ratings v2

23

More on Engineering from Zomato Technology

More on Engineering from Zomato Technology

The Deep Tech Behind Estimating Food Preparation Time

44

More on Zomato from Zomato Technology

More on Zomato from Zomato Technology

All new Search and Discovery on Zomato

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade