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.
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:
We recommend you see the report for any optimization we do in this article to see how good each parameter is.
There are 2 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.
- 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.
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
- Specific all the dependency version
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
Go to Preferences -> Build, Execution, Deployment -> Build Tools -> Gradle
Other settings could help is increasing the heap size for
org.gradle.jvmargs = -Xmx5048m
jumboMode = true
preDexLibraries = false
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.