Tech

How We Improved Performance and Build Times in Android Studio

A guide to optimise Android Studio performance in multi-module apps, and maximise developer productivity.

Gojek

Oct 28, 2019 • 4 min read

By Akhil Gupta

Gojek’s consumer Android app follows a mono repo approach. It consists of 120+ modules, which vary in size from small/medium core modules to large product modules.

Obviously, our developers work with Android Studio, which is not always the easiest thing to do. Here are a few reasons why:

- Android Studio keeps on indexing, especially when opening a project

- Long waiting time for layout editor preview

- Long waiting time for auto-completion popup in layout and code editors

- Slows down other apps in the system (especially while building & indexing)

As a side effect of these problems, developers had to deal with long build times, increased turnaround times when testing even small fixes, and a fear of the Gradle Sync button, after pulling new changes. This general slowdown also leads to developers getting distracted by other tasks and thus losing context on the task at hand.

The result? A sharp decline in dev productivity, and a growing unwillingness to refactor and improve code — leading to tech debt.

We couldn’t have that.

In this post, we’ll explain a few tips and tricks to improve the performance of Android Studio, and by extension, reduce developer frustration.

The Road to a Solution

To begin with, we analysed a few commits done by devs on a normal development day. These were our key observations:

70% of devs worked on a single module at a time

25% worked on two modules at a time

Rest worked on max 4~5 modules in a single commit

The Hypothesis

If we can reduce the number of modules a dev is working on, we can tackle this problem and increase developer productivity (and happiness quotient). 😀

So we got to work.

Approach 1: Load/Unload Feature in Android Studio

https://www.jetbrains.com/help/idea/unloading-modules.html

When we discovered this feature in Android Studio, there was a collective sigh of relief. This approach improved the Android Studio responsiveness.

But we weren’t in the clear. While this solution had potential, it proved to be a mirage in the desert.

Why, you ask?

- Gradle sync fails on pulling new changes / or after code changes

- Dependencies didn’t get resolved properly as few desired modules are unloaded

- No improvement in build time

What was still missing?

We wanted the ability to specify dev modules and load only those, as well as the ability to quickly switch between these modules. There was also the larger issue of requiring better build times for the app and individual modules, faster dependency resolution, and proper Gradle sync.

Note: Dev Modules == modules where Developers want to make changes/ are actively working on.

In a nutshell, we needed Android Studio to be faster.

So our search continued.

Approach 2: Local AARs with the flexibility to specify dev modules

We brainstormed some more, and came up with a new solution to meet our requirements. The answer lay in AAR.

AAR: Application Archive (Android Library)

Here’s what we did:

Publish all modules as AARs in a local maven repository
Define a way to specify Dev modules and load only those in Android Studio
Find a way to utilise build time spent in CI pipeline and download AARs from the same