I. Official recommendations

The official recommendations here are mostly general ones, as listed below:

1. Use the latest Android Gradle plugin

   General operation.

2. Avoid activating old Multidex

   This is a routine operation that Android Studio after 2.3 automatically avoids.

3. Disable Multiple APK builds

   Domestic generally do not open.

4. Minimize packaged resource files

   Not much, maybe 1, 2s.

5. Disable the general PNG compression operation.

6. Use the Apply Change

   Added in 3.5, detailed below.

7. Avoid passive changes

   Do not easily change the contents of the list file, routine operation.

8. Do not use dynamic version identifiers

   A point that is easy to overlook.

9. Gradle memory allocation tuning

   General operation.

10. Enable Gradle build cache

    More on that.

Second, build the cache

Build cache is the build cache.

This can be enabled by adding the –build-cache parameter to the command line or org.gradle.caching=true to the project root directory gradle.properties.

But when it was enabled, I didn’t see much effect.

The build scan shows that the cache misses, so the speed does not change.

If the state of the code is a-B-A, the build-cache does not work in the a-B phase, but in the B-A phase, it does work, saving about 20 seconds.

Third, the parallel

Parallel is also a property of Gradle that can be built in parallel.

This is enabled by default in Android Studio:

--parallel

gradlew assembleDebug --parallel
Copy the code

Without — PARALLEL, project build times hover between 23s-1m40s.

With — PARALLEL, the build time of the project has been stable at around 23s.

(By build, I mean build over and over again without changing the code at all)

Dynamic version

There are no obvious dynamic releases introduced in a typical project, but there are two situations that are easy to overlook:

• The referenced A library is A fixed version, but the A library references the dynamic version of the B library.
• The Gradle plugin, which references the C library, adds a dynamic version of the D library itself at runtime.

I’ve had this problem.

Fifth, build scan

Build Scan is a tool provided by Gradle to analyze builds.

It is simple to use by adding –scan to the command line, as in

gradlew assembleDebug --scan --parallel
Copy the code

When I see the project generated report, found that every building has a task execution: tinkerProcessDebugResourceId.

So I skipped the task with the following Settings.

afterEvaluate {
    tinkerProcessDebugResourceId.onlyIf { project.hasProperty('withTinker')}}Copy the code

After the skip, something magical happened and the packing speed was significantly improved:

Sixth, the Apply Change

Android Studio 3.5 removed Instant Run and added Apply Change, which works on Android 8.0 and above.

Next to Android Studio’s original Run button are the two Apply Change buttons: Apply Code Changes and Apply Changes and Restart Activity.

6.1 Apply Code Changes

Function:

After modification directly applied to the existing interface, completely traceless replacement, the experience is very good.

Limitations:

It can only be used when modifying code, not modifying resources.

Here are some tests to modify code:

• Delete a few lines of code, yes
• Add log, ok
• You can change the content of your setText()
• Add Toast, no
  

  

• SetOnClickListener, no
  

  

• Delete a method, no
  

  

6.2 Apply Changes and Restart Activity

Function:

After modification, instead of restarting the application, restart the Activity. The Activity is killed after restart, after onSaveInstanceState, onDestroy, onCreate, onRestoreInstanceState… This eliminates the need for redundant page paths, such as the need to change an inside page, so that you can skip the annoying step of opening the screen and advertising.

Limitations:

It only has more support for resource Changes than Apply Code Changes, and it does not support Code Changes that Are not supported by Apply Code Changes.