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
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
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
Talk is Cheap, Show Me Some Code 😅
Sure thing. Here is the sample project demonstrating the approach. It can be easily integrated into other Android projects too.
- Dev modules need to be specified in local.properties
- Approach can be toggled ON/OFF using a single flag in local.properties
And here’s the code in action, demonstrating:
- Seamless Feature Toggle
- Generation of local AARs repository
- Specifying & Switching between Dev Modules
- Command line compatibility
What was the Impact of This Exercise?
We got what we were looking for. Build and module times improved, and Android Studio was now significantly faster.
Developers could now stay in the flow — meaning we received a productivity boost. 🙌
Oh, Here’s a Little Bonus Trick 😉
Hope this approach helps you as much as it helped us, especially if you are working on a multi-module app. Keep calm and happy coding!