Ten tips to speed up Android app building

The build speed of the application will directly affect the development efficiency. This article will take you through the transformation of an Android application: "Google Santa Tracker" to provide you with ten tips to help you improve the Gradle build speed of the application. After we applied all the tips, the build speed of the demo application was more than three times faster.

Secondly, before we start the speed improvement tuning, let's understand the description of the three performance indicators:

• Full build, that is, recompiling the debug version of the entire project;

• Incremental code build means we modify the Java/Kotlin code of the project;

• Incremental resource construction refers to our modification of resource files, such as adding or reducing image and string resources.

Each update of the Android Gradle plugin will fix a large number of bugs and improve performance and other new features, so it is very necessary to keep the latest version of the Android Gradle plugin.

Starting from version 3.0, we will distribute the new Android Gradle plugin through the google() Maven repository, so you need to add google() to your repositories to get the latest plugin updates (now Android Studio will add the google() Maven repository reference by default when creating a new project).

This is the result after updating the Android Gradle plugin version from 2.x to 3.0.0-alpha1 (the demonstration here is based on version 3.0.0-alpha1. As the plugin version is updated, the performance improvement will be more obvious). We can see that the time for a full build of the application is directly reduced by 25%, the incremental build of code changes is reduced by nearly 40%, and the incremental build of resource changes is also reduced by 16%.

• Enable multidex
  https://developer.android.google.cn/studio/build/multidex.html

If you are building via the Run/Debug button in Android Studio, you don't need to worry about this issue. The new version of Android Studio will automatically detect connected devices and emulators, and provide native multidex support if the system API level is greater than 21, while ignoring the minimum API level (minSdkVersion) setting in the project.

The performance improvement results are very significant (the gray line is the initial result). We reduced the full build time by another 5.5 seconds, and the incremental build time for code changes was reduced by more than 50%. The incremental build time for resource changes is the same as before.

Disabling multi-APK builds cannot be set only in splits, because the settings here are visible to all build variants in the project . The correct way to disable multi-APK builds is to create a property to make a judgment. Here we set a property called "devBuild" and pass this value to gradle during the build process. At this time, gradle will set splits.abi.enable and splits.density.enable to false, and it will not generate multiple APKs.

In Android Studio, you can add the command line parameter: -PdevBuild in the Build, Execution and Deployment category of Preferences. Android Studio will pass this value to gradle every time you build to avoid generating multiple APKs.

As shown in the figure above, this is the effect after I disabled multiple APKs, and all indicators continue to decrease.

• Multiple APK

  https://developer.android.google.cn/google/play/publishing/multiple-apks.html

• Build variants

  https://developer.android.google.cn/studio/build/build-variants.html

Here we see a significant improvement, with full build time reduced by another 6 seconds and incremental build time reduced by more than 20%.

If we want to avoid using PNG compression, we can do it as mentioned in Tip 3 by adding aaptOptions.cruncherEnabled = false to the devBuild properties. Passing this value to gradle during the build process will prevent it from executing the PNG compression command.

It can be seen that the full build time has been reduced by another 9 seconds. This is also because there are more than 3,500 PNG images in the Google Santa Tracker app, which takes a lot of time to compress and calculate, so the efficiency improvement in this area is obvious, while other incremental builds just maintain the previous situation.  

Starting with Android Studio 3.5 (currently in the Beta build channel), developers can use the Apply Changes feature to improve build performance, which allows code and resource changes to take effect directly without restarting the app, and sometimes even without restarting the current Activity. Unlike the implementation of Instant Run, Apply Changes takes full advantage of the features of the Android 8.0 and above operating systems for runtime detection, thereby dynamically redefining classes. Therefore, if you want to use Apply Changes, you need to run your project on a real device or emulator running Android 8.0 (API level 26) or above.

In this example, we deliberately add some messy code to the build script to show the damage it causes. We also give an actual example of using Crashlytics. This plugin will add a unique ID as a build identifier to each build by default, which will cause unnecessary time loss. You can avoid this by adding ext.alwaysUpdateBuildId = false to the build script. Of course, you can also choose to completely turn off Crashlytics during the development phase.

Gradle provides a very convenient dependency library version management function, which allows developers to use a plus sign "+" to indicate that they want to use the latest version of the dependency library. However, there are several risks in using dynamic versions. From a performance perspective, Gradle will check for updates to the dependency library every 24 hours. If you have many dependent libraries and all use the setting of dynamically obtaining the latest version, it will have a certain impact on the performance of the build.

Even if you don't particularly care about these performance losses, it is still risky - version updates of dependent libraries will make your build full of uncertainty. Maybe two weeks later you are building a completely different project because updates to dependent library code are invisible to developers.

• About Gradle build cache
  https://docs.gradle.org/current/userguide/build_cache.html
  

Summarize

• Code repository
  https://github.com/jmslau/santa-tracker-android
• Official Documentation
  https://developer.android.google.cn/studio/build/optimize-your-build