[譯] 改善 Android Studio 的構建速度

• 原文地址：Improving build speed in Android Studio
• 原文做者：Android Developers
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：qiuyuezhong
• 校對者：csming1995

改善 Android Studio 的構建速度

由 Android Studio 產品經理 Leo Sei 發佈

改善構建速度

在 Android Studio 中，咱們但願讓你成爲最高效的開發者。經過與開發者的討論和調查，咱們瞭解到緩慢的構建速度會下降生產力。

在這篇文章中，咱們將分享一些新的分析方法，以便更好的指出是什麼真正影響了構建速度，並分享一些咱們正在爲此所做的工做，以及你能作些什麼來防止構建速度變慢。

• 感謝不少開發者選擇在 「preference > data sharing」 中與咱們共享他們的使用統計信息，使得這件事情變得可能。

不一樣的速度測量方式

咱們作的第一件事情是使用開源項目（SignalAndroid, Tachiyomi, SantaTracker & skeleton of Uber）來建立內部 benchmark，用於測量各類修改（代碼，資源，manifest 等）對於項目構建速度的影響。

例如，這是一個研究代碼更改對構建速度影響的 benchmark，能夠看出，隨着時間的推移，構建速度有很大的改善。

咱們還研究了真實的數據，主要關注 Android Gradle 插件升級先後構建調試版本的速度。咱們用它來體現新版本上構建速度的實際提高。

這代表了在新版本上，構建速度確實改善了不少，自 2.3 版本以來，構建時間提高了將近 50%。

最後，咱們在忽略版本變化的狀況下，研究了構建時間隨着時間的演變。咱們用它來表示實際構建速度隨時間的變化。遺憾的是，結果代表了構建速度是隨着時間的推移而減慢的。

若是每一個版本的構建速度確實愈來愈快，而且咱們能夠在數據中看到，那麼爲何它們會隨着時間的推移而變得愈來愈慢呢？

咱們在更深刻的研究以後，意識到在咱們的生態系統中發生的事情正在致使構建速度減慢，減慢的速度比咱們提高的速度更快。

雖然咱們知道隨着項目的迭代，代碼的增長、資源的使用、語言特性的增長，使項目的構建速度愈來愈慢，但咱們還發現，還有許多其餘因素超出了咱們的直接控制範圍：

1. 2017 年底的 Spectre 和 Meltdown 補丁對新流程和 I/O 產生了必定影響，使清除構建的速度減慢了 50% 到 140% 之間。
2. 第三方和客製化的 Gradle 插件：96% 的 Android Studio 開發者使用一些額外的 Gradle 插件（其中一些並無採用最新的最佳實踐）。
3. 大多數使用的註釋處理器都是非增量化的，每次進行編輯時都會致使代碼從新全量編譯。
4. 使用 Java 8 語言特性會致使須要執行去語法糖操做，這將影響構建時間。然而，咱們已經用 D8 下降了去語法糖操做的影響。
5. 使用Kotlin，尤爲是 Kotlin（KAPT）中的註釋處理，也會影響構建性能。咱們將繼續與 JetBrains 合做，以將影響降至最低。

• 和真實的項目不一樣，那些項目的構建時間不會隨着時間的推移而增加。Benchmark 模擬更改，而後撤銷更改，僅測量咱們的插件隨時間推移而受到的影響。

• 3.3 版本專一於將來改善的基礎工做（例如，名稱空間資源、增量註釋處理器支持、Gradle workers），所以提高了 0%。

咱們在作什麼？

肯定內部流程並持續提高性能。

咱們也認可，許多問題來自於谷歌擁有的和推廣的功能，咱們改變了內部流程，以便在發佈過程的早期更好地得到構建反饋。

咱們還致力於讓註釋處理器增量化。截至目前，Glide、Dagger 和 Auto Service 都是增量化的，而且咱們還在研究其餘的。

在最近的版本中，咱們還加入了 R light class generation、lazy task 和 worker API，並繼續與 Gradle Inc. 和 JetBrains 合做，以持續改善整體構建性能。

屬性工具

最近的一項調查顯示，約 60% 的開發者不去分析構建的影響或不知道如何分析。所以，咱們但願改善 Android Studio 中的工具，在社區中提升對構建時間影響的意識和透明度。

咱們正在探索如何在 Android Studio 中更好地提供插件和任務對構建時間影響的相關信息。

你如今能作些什麼？

雖然配置時間可能因變量、模塊和其餘因素的數量而有所不一樣，但咱們但願將與 Android Gradle 插件相關聯的配置時間做爲參考點，並和實際場景共享數據。

若是發現構建時間慢不少，多是有客製化的構建邏輯（或者三方的 Gradle 插件）影響到構建時間。

使用的工具

Gradle 提供了一組免費的工具來幫助分析構建中正在發生的事情。

咱們建議你使用 Gradle scan，它提供了關於構建的大部分信息。若是你不但願構建信息上傳到 Gradle 服務器上，可使用 Gradle profiler，相對於 Gradle scan，它提供的信息要少一些，可是能夠保證全部內容都在本地。

注意：對於那些你可能想使用傳統 JVM profiler 的項目，Gradle scan 對研究它們的配置延遲沒有幫助。

優化構建配置和任務

在研究構建速度時，這裏有幾個須要注意的最佳實踐，能夠隨時查看咱們的最新最佳實踐。

配置

• 僅使用配置來建立任務（使用 lazy API），避免在其中執行任何 I/O 或任何其餘工做。（配置不適合查詢 git、讀取文件、搜索鏈接的設備、進行計算等）。
• 在配置中建立全部的任務。配置不會知道實際生成了什麼內容。

優化任務

• 保證每一個任務都聲明瞭輸入/輸出（即使是非文件性的），而且是增量化的和可緩存的。
• 將複雜的步驟拆分爲多個任務，以幫助實現增量化和可緩存性。 （有些任務能夠是最新的，而另外一些任務能夠執行或並行執行）。
• 確保任務不會寫入或刪除其餘任務的輸出。
• 在插件或 buildSrc 中用 Java/Kotlin 編寫任務，而不是在 build.gradle 中用 Groovy 直接編寫。

做爲開發者，咱們關心你的生產力。隨着咱們持續努力加快構建速度，但願這裏的提示和指導方針可以幫助你縮短構建時間，以便讓你可以更加專一於開發精彩的應用程序。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。