Android Gradle 提速實戰

一、官方建議

官方建議在這裏，大部分都是常規操作，下面簡單列舉下：

1. 使用最新的 Android Gradle 插件
   常規操作。
2. 避免激活舊的 Multidex
   常規操作，2.3 之後的 Android Studio 會自動規避。
3. 禁用 Multiple APK 構建
   國內一般都沒有開啓。
4. 最小化打包資源文件
   收效甚微，也許有個 1、2s 吧。
5. 禁用 PNG 壓縮
   常規操作。
6. 使用 Apply Change
   3.5 中新增，下面細說。
7. 避免被動的改動
   不輕易改變清單文件的內容，常規操作。
8. 不使用動態版本標識
   容易忽略的點，下面細說。
9. Gradle 內存分配調優
   常規操作。
10. 開啓 Gradle 構建緩存
    下面細說。

二、build cache

build cache 就是構建緩存。

可以通過在命令行里加入 --build-cache 參數或者在工程根目錄的 gradle.properties 里加入 org.gradle.caching=true 來啓用該功能。

但啓用後，我並沒有看到什麼效果。

通過 build scan（下面會說）查看，發現 cache 都 miss 了，沒有命中，所以速度沒有改變。

這纔想到 cache 的含義，先存再用。我都沒存下來，當然不會有複用，也就沒有加速了。

假設代碼的狀態變化是 A-B-A，A-B 階段的 build-cache 沒有作用，但 B-A 時，就有用了，親測能省 20s 左右的時間。

三、parallel

parallel 也是 Gradle 的一個屬性，可以進行並行構建。

Android Studio 中默認是打開的：

命令行中，可以添加 --parallel 來打開：

gradlew assembleDebug --parallel

不帶 --parallel 時，項目的構建時間在 23s-1m40s 之間徘徊。

帶了 --parallel 時，項目的構建時間一直穩定在 23s 左右。

（這裏的構建指的是完全不改代碼，重複構建）

四、動態版本

一般項目中都不會有明顯的動態版本引入，但有兩種情況比較容易忽略：

• 引用的 A 庫是固定版本，但 A 庫又引用了動態版本的 B 庫。
• 引用的 C 庫的 Gradle 插件，在執行時自己添加了動態版本的 D 庫。

我就曾經遇到過這樣的問題。

五、build scan

build scan 是 Gradle 提供的一個分析構建的工具。

它的使用很簡單，命令行中添加 --scan 即可，如

gradlew assembleDebug --scan --parallel

當我查看項目生成的報告，發現每次構建有一個 task 都會執行：tinkerProcessDebugResourceId。

這個 task 執行一次約 20s，看名字，是項目內集成的 tinker 插件所需要的 task。這在熱修復中有用，但在日常的其他功能開發、測試工作中，並不需要這些功能。

於是我通過以下設置，跳過這個 task。

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

跳過之後，神奇的事情發生了，打包速度得到了明顯提升：

	跳過前	跳過後
跳過後完全不修改，再次打包	23s	2s
修改代碼（新增一個空行），再次打包	1m35s	1m10s
修改 xml（新增一個空行），再次打包	26s	4s

六、Apply Change

Android Studio 3.5 中取消了 Instant Run，新增了 Apply Change，可以在 Android 8.0 及以上的機型執行。

Android Studio 原本的 Run 按鈕旁邊就是 Apply Change 的兩個按鈕，依次是：Apply Code Changes 和 Apply Changes and Restart Activity。

它們都不會影響編譯時間，但減少了安裝、進入目標頁面的時間。

6.1 Apply Code Changes

功能：

修改之後後直接應用到現有界面上，完全無痕替換，體驗感非常好。

限制：

它只能在修改代碼時使用，修改資源不能使用。

下面是修改代碼的一些測試：

• 刪除幾行代碼，可以
• 添加 log，可以
• 改變 setText() 的內容，可以
• 添加 Toast，不行
  
• setOnClickListener，不行
  
• 刪除一個方法，不行
  

6.2 Apply Changes and Restart Activity

功能：

修改之後，不用重啓應用，而是重啓 Activity。
即 Activity 被殺死後重新啓動，經過 onSaveInstanceState、onDestroy、onCreate、onRestoreInstanceState…這樣可以免去冗餘的頁面路徑，比如需要改一個內頁，就可以直接跳過開屏廣告等煩人的步驟。

限制：

它只比 Apply Code Changes 多了支持資源修改的功能，Apply Code Changes 不支持的代碼修改它也不支持。