One of the most common problems encountered in Android development is that projects take too long to compile, wasting a lot of development time. This article has put together a few ideas to optimize the speed of AndroidStudio builds to help you.

Update your computer’s configuration

Upgrade your CPU to top (I7 XXK), 32GB of ram, and 360GB of solid state.

Ha ha, just kidding. If you are local rich, I believe you will not mind, and will agree with me.

Second, update your tools to the latest version

  1. Update higher stable versions of AndroidStudio and Gradle plug-ins. Google is to update the version, it must be optimized a lot of things, in the selection at the same time better look at the version, choose the official stable version of the tool.
  2. When developing applications, deploy them to devices running Android 7.0 (API level 24) or higher whenever possible. Newer versions of the Android platform implement better mechanisms for pushing updates to your application, such as the Android Runtime (ART) and native support for multiple DEX files.

    Note: After you complete your first build, you may notice that subsequent builds (clean and Incremental) perform faster (even without using any of the optimizations described on this page). This is because Gradle daemons have a “warm-up period” of performance improvement, similar to other JVM processes.

Use new dependencies and configurations

The new configuration Deprecated configuration behavior
implementation compile When your module configures a implementation dependency, let Gradle know that the module does not need to disclose the dependency to other modules at compile time. That is, dependencies are only available to other modules at run time. Using this dependency configuration instead of API or COMPILE can lead to a significant build time improvement because it reduces the number of projects that need to be recompiled to build the system. For example, if a implementation dependency changes its API, Gradle only recompiles the dependency and the modules that directly depend on it. Most applications and test modules should use this configuration.
api compile When a module contains API dependencies, let Gradle know that the module wants to export the dependencies transitively to other modules so that they can be used at run time and compile time. This configuration behaves like compile (now deprecated), and you should normally only use it in library modules. This is because if an API dependency changes the external API, Gradle recompiles all modules that have access to the dependency at compile time. So, having a lot of API dependencies increases build time. Use the implementation dependency unless you want to expose a dependent API to a separate test module.

That is to say after AndroidStudio3.0, if you can use implementation, you can use implementation, and implementation can improve the compilation speed

4. Enable D8 compilation

Compared to the previous DX compilation engine, Google’s next-generation D8 dex compilation engine not only improves compilation efficiency (in terms of reduced compilation time), but also reduces the size of the generated.dex files. The D8 DEX compilation engine is already available in Android Studio 3.0 and will be the default engine in Android Studio 3.1. You can use the D8 dex compilation engine by setting android.enableD8 to true in the gradle.properties file.

android.enableD8 = trueCopy the code

5. Convert the image to WebP

WebP is an image file format that provides lossy compression (such as JPEG) as well as transparency (such as PNG), but can provide better compression than JPEG or PNG. Reducing the size of image files without having to perform build-time compression can speed up your build, especially if your application uses a lot of image resources. However, you may notice a small increase in device CPU usage when decompressing the WebP image. With Android Studio, you can easily convert images to WebP.

Disable PNG

If you can’t (or don’t want to) convert your PNG images to WebP, you can still speed up your build by disabling automatic image compression every time you build your application. PNG for the Debug build type is disabled by default if you are using Android plugin 3.0.0 or later. To disable this optimization for other build types, add the following to your build.gradle file:

Android {buildTypes {release {// disables PNG for publish buildTypes. crunchPngsfalse}} // If you are using an older version of the plugin, please use the following content // aaptOptions {// cruncherEnabledfalse/ /}}Copy the code

Use statically dependent versions

In the build. Gradle dependencies, declared in a file should be avoided in the final with a plus sign the version number, for example ‘com. Android. View the build: gradle: 2. +’. Using dynamic version numbers can lead to unexpected version updates, difficulty in resolving version differences and Gradle checking for slower versions due to updates. You should use static/hard-coded version numbers.

8. Enable offline mode

If your network connection is slow, your build time may suffer when Gradle tries to use network resources to resolve dependencies. You can tell Gradle to avoid using network resources by only using artifacts cached locally.

To use Gradle offline when building with Android Studio, follow these steps:

  1. Click File > Settings
  2. In the left pane, click Build, Execution, Deployment > Gradle.
  3. Select the Offline Work check box.
  4. Click Apply or OK.

Configure the daemons

  1. Click File > Settings.
  2. In the left pane, click Build, Execution, Deployment > Compiler.
  3. Select the Configure on Demand check box.
  4. Click Apply or OK.

10. Enable Instant Run

Instant Run dramatically reduces the time required to update applications by pushing certain code and resource changes without building a new APK, and in some cases without even restarting the current activity.

Customize your VM options

The most common option to improve Studio performance is to adjust the maximum heap size, but you can also use the studio.vmoptions file to override other default Settings, such as the initial heap size, cache size, and Java garbage collection switch.

To create a new studio. Vmoptions file or open an existing file, use the following steps:

  1. Click Help > Edit Custom VM Options, and if you have never edited Android Studio’s VM Options before, the IDE will prompt you to create a new studio.vmOptions file. Click to create the file.

  2. Open the studio. Vmoptions file and edit the file to add your own custom VM options. For a complete list of customizable JVM options, see Oracle’s Java HotSpot VM Options page. The following is my own configuration for reference only.

     -Xms2048m
 -Xmx2048m
 -XX:MaxPermSize=2048m
 -XX:ReservedCodeCacheSize=1024mCopy the code

Create a build Variant for development

When developing an application, much of the configuration you need to prepare to develop the application is not required. Enabling unnecessary build processes slows incremental and clean builds, so configure the build variant so that only the build configuration remains when developing your application. The following example creates a “dev” style and a “prod” style (for your distribution configuration) :

android { ... defaultConfig {... } buildTypes {... } productFlavors {// When building a Variant that uses this style, the following configuration overrides the configuration in the defaultConfig block. Dev {// To avoid using traditional multidex when building from the command line, set minSdkVersion to 21 or higher. // When using Android Studio 2.3 or later, traditional Multidex is automatically avoided when building devices deployed to run API level 21 or higher //, regardless of whether you are set to minSdkVersion. minSdkVersion 21 versionNameSuffix"-dev"
          applicationIdSuffix '.dev'} prod {// If you have configured the defaultConfig block for the release version of your application, you can leave this block empty, and Gradle uses the configuration in the defaultConfig block. You will still need to create the flavor or all variants will use the "dev" flavor configuration. }}}Copy the code

If your build configuration already uses Product Flavors to create different versions of the application, try combining “Dev” and “Prod” flavors with those flavors. For example, if you already have “Demo” and “prod” styles configured, you can use the following sample configuration to create combinations of flavors, such as “devDemo” and “prodFull” :

android { ... defaultConfig {... } buildTypes {... } // Specify the flavor dimensions to use. // Lists the priority of each dimensions in descending order // When Gradle merges variant sources and configurations. You must assign each Product Flavors you configure to one of the Flavor dimensions. flavorDimensions"stage"."mode"

  productFlavors {
dev {
      dimension "stage"
      minSdkVersion 21
      versionNameSuffix "-dev"
      applicationIdSuffix '.dev'. } prod { dimension"stage". } demo { dimension"mode". } full { dimension"mode". }}}Copy the code

Avoid compiling and packaging untested resources (such as screen density resources). You can do that by specifying just one screen density resource and masking your “Dev” Flavors, as shown in the following example:

android { ... productFlavors { dev { ... // The following configuration limits the "dev" style to use xxhdPI screen density resources. resConfigs"xxhdpi"}... }}Copy the code

Xiii. Crashlytics Report Settings

If you don’t need to run Crashlytics reports, speed up your debug version by disabling the plugin, as shown below:

android {
  ...
  buildTypes {
    debug {
      ext.enableCrashlytics = false}}Copy the code

You also need to disable the Crashlytics suite at run time for debug builds by changing the way you initialize Fabric support in your application, as follows:

// Initialize a build that does not use the debug build type. Crashlytics crashlyticsKit = new Crashlytics.Builder() .core(new CrashlyticsCore.Builder().disabled(BuildConfig.DEBUG).build()) .build(); Fabric.with(this, crashlyticsKit);Copy the code

If you want to use Crashlytics in a debug build, you can still speed up incremental builds by preventing Crashlytics from updating application resources with its own unique build ID during each build. To prevent Crashlytics from constantly updating its build ID, add the following to your build.gradle file:

android {
  ...
  buildTypes {
    debug {
      ext.alwaysUpdateBuildId = false}}Copy the code