Speed up Android Studio build

3 min read

A few months ago, our colleagues complained that our project was slow to build: it normally took 5 minutes, especially in branch switching – which took about 10 minutes. After that, we realized – it doesn’t happen uniquely to our project, it’s a common issue. So here are a few things we did in our Android project to improve the situation.

Profiling

How long does it take to get your build done? Add the — profile param to get the exact number. In Android Studio, go to Preferences -> Build, Execution, Deployment -> Compiler and set:

Command-line Options: --profile

Let build. You could file a HTML file in [project_dir]/build/reports/profile/ generated with the detailed time spent for each build task as follows:

zen8labs android profiling

We recommend you see the report for any optimization we do in this article to see how good each parameter is.

Reasons

There are some common causes of the slow build:

Repositories and dependencies

What does Android Studio do when you click on “Sync Gradle” (if build.gradle file is changed)or create a project? Answer: Gradle collects all the dependencies. The good news is that Gradle uses cache, a folder that stores all dependencies to prevent them from going online. The bad news is, if Gradle cannot find any specific dependency, it will always go online to scan the repositories (usually mavenCenter or jcenter); so it will be prolonged if the network isn’t good enough.

There are 2 reasons why Gradle cache cannot be used:

  • Dependency version isn’t fixed.

You can use + signal to let Gradle check for the latest version of a dependency since it always gets Gradle online.

compile 'com.google.code.gson:gson:2.+'
  • Gradle version isn’t fixed.

Each Gradle organizes the cache itself and does not share the dependency cache. If your team has a few Gradle versions, it will take time to switch and download all the dependencies when you switch between Gradle versions.

Gradle isn’t optimised

Gradle provides several parameters that allow us to optimize but often they are not set in Android Studio.

Gradle is slow itself

Gradle is officially used and supported by the Android Team but it’s not the fastest build tool.

Solutions

The solutions to these issues are:

Setup the fixed Gradle and dependency versions

  • Use same Gradle version as your team settings. A good way is to use Gradle wrapper instead of local Gradle by creating the gradlew, checking the source code repository, and going to Preferences -> Build, Execution, Deployment -> Build Tools -> Gradle
How zen8labs use gradle in android
zen8labs android ii
  • Specific all the dependency version
compile 'com.google.code.gson:gson:2.4'

Use correct Gradle params

There are some Gradle params you could miss:

  • — offline: Force Gradle using cache
  • — configure-on-demand: Instead of all projects, let Gradle only build the relevant ones
  • — daemon: Let Gradle use in-process build and cut the initial and warm-up state
  • — parallel: Let Gradle build your projects in parallel, if possible
  • — max-workers: Going with — parallel param to let Gradle know how many threads it can use

So typically, the command line call would be:

$ ./gradlew :assembleDebug --offline --configure-on-demand --daemon --parallel --max-workers=8 --profile

Mapping to Android Studio config, they would be:

Go to Preferences -> Build, Execution, Deployment -> Compiler

How zen8labs makes complier's in android
zen8labs android iii

Go to Preferences -> Build, Execution, Deployment -> Build Tools -> Gradle

zen8labs use of gradle in the building tool.
zen8labs android iv

Other settings

Other settings could help is increasing the heap size for

  • JVM
org.gradle.jvmargs = -Xmx5048m
  • multiDex
dexOptions {
javaMaxHeapSize "4g"
jumboMode = true
preDexLibraries = false
incremental true
}

Use another build tool

It’s high time we built the project – Start by opening the HTML report file to see how much time we saved.

During the study, we found out that there are multiple tools that build faster  than Gradle, namely Buck which is used by Facebook. On our demo, it’s incredibly fast. But of course, it isn’t supported by Android Team and its community is also small. The idea of keeping Gradle and Buck building in parallel is nice – stability provided by Gradle, speed by Buck.

We will return with another post regarding this topic soon at this location.

Related posts

Normally when programming a mobile application, we often encounter apps crashing, which is when the current application cannot operate (force close). But there is another status that is less serious: Application Not Responding (ANR). Why is it less serious because your application can continue to be used normally after waiting? The question is how to minimize ANR errors? Let's find out below.
3 min read
The need to make mock A.P.I responses has become increasingly crucial for efficient testing and development workflows. While various tools offer powerful capabilities for intercepting and modifying HTTP traffic, they often come with an expensive price tag. This is where mitmproxy steps in as a cost-effective and feature-rich alternative.
5 min read
This tutorial is to provide you with a deep understanding of the core components of RxSwift, focusing mainly on the implementation behind the scenes of RxSwift. After reading this post, it is hoped that you will have a clear understanding of what observables are, what subscriptions are, and how observables work.
7 min read