- 原文地址：Improving build speed in Android Studio
- 原文作者：Android Developers
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：qiuyuezhong
- 校對者：csming1995
由 Android Studio 產品經理 Leo Sei 釋出
改善構建速度
在 Android Studio 中，我們希望讓你成為最高效的開發者。通過與開發者的討論和調查，我們瞭解到緩慢的構建速度會降低生產力。
在這篇文章中，我們將分享一些新的分析方法，以便更好的指出是什麼真正影響了構建速度，並分享一些我們正在為此所作的工作，以及你能做些什麼來防止構建速度變慢。
- 感謝很多開發者選擇在 “preference > data sharing” 中與我們共享他們的使用統計資訊，使得這件事情變得可能。
不同的速度測量方式
我們做的第一件事情是使用開源專案（SignalAndroid, Tachiyomi, SantaTracker & skeleton of Uber）來建立內部 benchmark，用於測量各種修改（程式碼，資源，manifest 等）對於專案構建速度的影響。
例如，這是一個研究程式碼更改對構建速度影響的 benchmark，可以看出，隨著時間的推移，構建速度有很大的改善。
我們還研究了真實的資料，主要關注 Android Gradle 外掛升級前後構建除錯版本的速度。我們用它來體現新版本上構建速度的實際提升。
這表明了在新版本上，構建速度確實改善了很多，自 2.3 版本以來，構建時間提升了將近 50%。
最後，我們在忽略版本變化的情況下，研究了構建時間隨著時間的演變。我們用它來表示實際構建速度隨時間的變化。遺憾的是，結果表明了構建速度是隨著時間的推移而減慢的。
如果每個版本的構建速度確實越來越快，並且我們可以在資料中看到，那麼為什麼它們會隨著時間的推移而變得越來越慢呢？
我們在更深入的研究之後，意識到在我們的生態系統中發生的事情正在導致構建速度減慢，減慢的速度比我們提升的速度更快。
雖然我們知道隨著專案的迭代，程式碼的增加、資源的使用、語言特性的增加，使專案的構建速度越來越慢，但我們還發現，還有許多其他因素超出了我們的直接控制範圍：
- 2017 年末的 Spectre 和 Meltdown 補丁對新流程和 I/O 產生了一定影響，使清除構建的速度減慢了 50% 到 140% 之間。
- 第三方和客製化的 Gradle 外掛：96% 的 Android Studio 開發者使用一些額外的 Gradle 外掛（其中一些並沒有採用最新的最佳實踐）。
- 大多數使用的註釋處理器都是非增量化的，每次進行編輯時都會導致程式碼重新全量編譯。
- 使用 Java 8 語言特性會導致需要執行去語法糖操作，這將影響構建時間。然而，我們已經用 D8 降低了去語法糖操作的影響。
- 使用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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。