應用的構建速度會直接影響開發效率，本文將帶您通過改造一個 Android 應用: “Google 追蹤圣誕老人 (Google Santa Tracker)” 來為大家提供十個小技巧，幫助提升應用的 Gradle 構建速度，當我們應用了所有的小技巧之后，該演示應用的構建速度快了三倍以上。

 

首先來了解一下 “Google 追蹤圣誕老人” 應用的工程背景: 這個應用有約 60M 大小，它包含 9 個模塊，有 500 多個 Java 文件，1,700 多個 XML 文件、3,500 多張 PNG 圖片資源，用到了 Mutil-dex，沒有注解處理器。

其次，在我們開啟速度提升調優之前，來了解本次三個性能指標的說明:

• 全量構建，也就是重新開始編譯整個工程的 debug 版；

• 代碼增量構建，指的是我們修改了工程的 Java / Kotlin 代碼；

• 資源增量構建，指的是我們對資源文件的修改，增加減少了圖片和字符串資源等。

 

每個小技巧實施以后，我們會對比如上三個場景的構建時間以作為我們的量化標準。請注意，由于工程規模大小不一、開發環境各異，開發者們在實際的操作中的結果可能會與本文的結果有所不同。

 

小技巧 1: 使用最新版本的 Android Gradle 插件

 

 

 

每次 Android Gradle 插件的更新都會修復大量的 bug 及提升性能等新特性，因此保持最新的 Android Gradle 插件版本有非常大的必要。

從 3.0 版本開始，我們將通過 google() 的 Maven 倉庫分發新的 Android Gradle 插件，所以需要在 repositories 處加入 google() 以獲得最新的插件更新 (現在的 Android Studio 新建工程的時候會默認加入 google() 的 Maven 倉庫指向)。

這是將 Android Gradle 插件版本從 2.x 更新到 3.0.0-alpha1 之后得到的結果 (這里的演示是基于 3.0.0-alpha1 版本，隨著插件版本的更新，性能的提升會更加明顯)，我們可以看出，全量構建一次應用的時間直接減少了 25%，代碼改動的增量構建減少了將近 40%，資源改動的增量構建也減少了 16%。  

 

小技巧 2: 避免激活舊版的 Multidex

 

這個小技巧大家應該比較熟悉——避免激活舊版的 multidex。當您的應用配置方法數超過 64K 的時候，您需要啟用 multidex。當您啟用了 multidex，且工程的最低 API 級別在 21 之前時，舊版的 multidex 就會被激活，這將嚴重拖慢您的構建速度，原因是 21 之前的 API 級別并沒有原生的支持 multidex。

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

如果您是通過 Android Studio 的運行/調試按鈕來執行構建，那么無需考慮這個問題，新版本的 Android Studio 會自動檢測連接的設備和模擬器，如果系統的 API 級別大于 21 則進行原生的 multidex 支持，同時會忽略工程里對最低 API 級別 (minSdkVersion) 的設置。

 

習慣通過命令行窗口構建工程的開發者們則需要試著避免這個問題: 配置一個新的 productFlavor，設定工程的最低 API 級別為 21 或者以上，在命令行里調用 assembleDevelopmentDebug 即可避免這個問題。

這一次的性能改進結果效果也非常明顯 (灰色的線條是最初的結果)，在全量構建的時候我們又降低了 5.5 秒的時間，而在代碼改動的增量構建里時間減少了 50% 以上，資源改動的增量構建與之前的時間相同。  

 

小技巧 3: 禁用 Multiple APK 構建

在應用需要發布和上架的時候，我們往往會使用 “Multiple APK” 構建，它可以根據 ABI 和像素密度創建不同版本的應用，使包體積降低等。但這個在開發階段似乎顯得有些多余，所以我們需要禁用多 APK 構建特性以提高構建速度。

 

禁用多 APK 構建不能僅僅在 splits 里設置，因為這里的設置對工程里所有的構建變體都是可見的。正確的禁用多 APK 構建的方法是創建一個屬性來做判斷，這里我們設置了一個名為 “devBuild” 的屬性，在構建的過程中把這個值傳給 gradle，此時 gradle 會將 splits.abi.enable 和 splits.density.enable 設置為 false，它就不會生成多個 APK 了。

在 Android Studio 里，您可以通過偏好設置，構建、執行和部署分類里，選擇編譯器選項來為命令行加入參數: -PdevBuild，這樣每次在構建的時候 Android Studio 會把這個值傳遞給 gradle 以避免生成多個 APK。 

如上圖所示，這是我在禁用了多 APK 之后的效果，各項指標都在繼續降低。 

• Multiple APK

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

• 構建變體

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

 

小技巧 4: 最小化使用資源文件

 

 

當您的應用包含大量本地化資源或者為不同像素密度加入了特別的資源時，您可能需要應用這個小技巧來提高構建速度——最小化開發階段打包進應用的資源數量。

 

構建系統默認會將聲明過或者使用過的資源全部打包進 APK，但在開發階段我們可能只用到了其中一套而已，針對這種情況，我們需要使用 resConfigs() 來指定構建開發版本時所需要用到的資源，如語言版本和屏幕像素密度。

 

這里我們看到了較大程度上的改觀，全量構建的時間又降低了 6 秒，增量構建的時間也分別降低了 20% 以上。 

 

小技巧 5: 禁用 PNG 壓縮

 

 

 

與小技巧 4 一樣，這個特性本身在打包發布階段是相當有幫助的—— PNG 壓縮，但在開發階段禁用這個功能可以提高構建效率。默認情況下，AAPT 會壓縮工程的 PNG 資源以減小 APK 體積，根據圖片的數量和大小，這個過程所消耗的時間有長有短。

 

如果要避免使用 PNG 壓縮，我們可以在小技巧 3 里提到的，在 devBuild 屬性里加入 aaptOptions.cruncherEnabled = false 來實現，在構建的過程中把這個值傳給 gradle，它就可以避免執行 PNG 壓縮命令了。 

 

 

另外一個避免壓縮 PNG 的方法是使用把 PNG 轉換成 WebP 格式的圖片，對比 PNG 格式，WebP 可以減少最多 25% 的大小，同時 2.3 以上版本的 Android Studio 直接支持 PNG 到 WebP 格式的轉換。

 

需要注意的是，API 級別 15 及更高可以支持不透明的 WebP 格式圖片，如果是透明格式的 WebP，需要 API 級別 18 以及更高。

這可以看到全量構建又減少了 9 秒的時間，這也是因為 Google 追蹤圣誕老人應用里有 3,500 多張 PNG 圖片，這要花費大量的時間進行壓縮計算，所以這方面的效率提升顯得很明顯，而其他增量構建只是維持了之前的情況。 

特別提出一下關于 APK 體積的問題——對比了啟用和禁用 PNG 壓縮之后的 APK 體積之后，我們發現前后的體積并沒有太大改變，這說明該工程里使用的 PNG 圖片在導入之前已經經過了充分優化，PNG 壓縮在這里實屬多此一舉。

 

小技巧 6: 使用 Apply Changes

 

 

 

從 Android Studio 3.5 版開始 (3.5 版目前在 Beta 構建渠道發布)，開發者們可以使用 Apply Changes 功能來提高構建性能，它可以讓代碼和資源的改動直接生效而無需重啟應用，有時候甚至無需重啟當前的 Activity。與 Instant Run 的實現方式不一樣，Apply Changes 充分利用了 Android 8.0 以上版本操作系統的特性進行運行時檢測，從而動態的對類進行重新定義。因此，如果您希望使用 Apply Changes，則需要讓您的工程運行在 Android 8.0 (API級別26) 以上的真機或者模擬器上。

 

小技巧 7: 避免被動的改動

 

 

我們通過一個很小的例子來說明這個小技巧: 我們把工程的版本號設定為基于當前時間的數字 (實際上大家應該不會這么操作)，這樣的結果是每次構建的時候版本號都是新的，工程的清單文件會因此發生改變，最后帶來的結果就是拖慢了本次的構建速度。

如圖所示，我們發現增量構建的時間甚至增加了一倍，因此盡量不要在構建腳本里加入太多無意義的內容。

解決這個問題并不難，我們可以通過在構建腳本里判斷是否有 devBuild 標記，如果有的話，我們就把版本號設置為一個固定值就可以了。

 

這個例子里，我們故意在構建腳本中加入里一些搗亂的代碼以展現其帶來的損失。同時也舉一個在使用 Crashlytics 時的實際例子，這個插件默認會為每次構建中都加入唯一 ID 作為構建標識，這會帶來不必要的時間損失，您可以通過在構建腳本里加入 ext.alwaysUpdateBuildId = false 來避免這個，當然也可以選擇在開發階段完全關閉 Crashlytics。

 

小技巧 8: 不使用動態版本標識

 

 

 

 

Gradle 提供了一個非常方便的依賴庫版本號管理功能，方便開發者們通過使用一個加號 “+” 標識希望使用這個依賴庫的最新版本。但是使用動態版本有幾個風險，從性能角度來說，Gradle 會每隔 24 小時去檢查一次依賴庫的更新，如果您的依賴庫很多，而且都使用了動態獲取最新版本的這個設定，那會對構建時候的性能產生一定的影響。

即使您不是特別在意這些性能損耗，但是它仍然是有風險的——依賴庫的版本更新會讓您的構建充滿不確定性，可能兩周之后您就在構建一個完全不一樣的工程了，因為依賴庫代碼的更新對開發者們是不可見的。 

 

小技巧 9: Gradle 內存分配調優

 

 

 

默認的構建環境里，我們會給 Gradle 分配 1.5G 的內存，但這個并非適用于所有的項目，您需要通過對這個數字對調優來得到適合您工程的最佳 Gradle 內存分配。

與此同時，從 Android Gradle 插件 2.1 版本之后，dex 已經默認在進程里了，所以如果您之前設定過 javaMaxHeapSize 值，可以選擇刪掉它了。

 

 

 

小技巧 10: 開啟 Gradle 構建緩存

 

 

 

Gradle 新推出的緩存機制效果非常出色，我們建議大家嘗試開啟，最新的 Gradle 支持了 Kotlin 項目使用構建緩存，構建速度可以提高很多。Gradle 的構建緩存默認是不開啟的，您可以通過在命令行里加入 --build-cache 參數或者在工程根目錄的 gradle.properties 里加入 org.gradle.caching=true 為所有人啟用構建緩存。您可以在這個文檔里了解更多關于 Gradle 構建緩存的內容。

• 關于 Gradle 構建緩存
  https://docs.gradle.org/current/userguide/build_cache.html
  

 總結 

 

在實踐了所有的速度提升小技巧之后，得到的整體的改善結果，全量構建的速度比之前快了三倍以上，而代碼改動的增量構建則快了 12 倍以上，我們在 GitHub 上創建了一個代碼倉庫，大家可以下載并實踐一下我們今天所提到的構建速度提升的技巧。更多關于如何提高應用構建速度的內容，請關注我們的官方文檔。

• 代碼倉庫
  https://github.com/jmslau/santa-tracker-android
• 官方文檔
  https://developer.android.google.cn/studio/build/optimize-your-build