如何打造高質量的應用？
應用至少會經過開發、編譯 CI(自動編譯,提交到gitlab之後,合併之前)、測試、灰度和發佈這幾個階段。
開發階段。耗時分析工具 Traceview 來說，它背後的實現原理是什麼？能不能做一個完全沒有性能損耗的 Traceview？或者怎麼樣將它移植到線上使用？
Traceview:-
編譯 CI 階段。如何防止代碼不斷地惡化？怎樣進一步優化性能？d8 與 ReDex 有什麼神奇的黑科技？如何利用好 Coverity、Infer 這些靜態分析工具？這部分可能需要一些編譯原理的知識，
你可以把編譯簡單理解爲，將高級語言轉化爲機器或者虛擬機所能識別的低級語言的過程。對於 Android 來說，這個過程就是把 Java 或者 Kotlin 轉變爲 Android 虛擬機能夠運行的Dalvik 字節碼的過程。
編譯實在太重要了，每個公司的情況又各不相同，必須強行造一套自己的“輪子”。已經開源的項目有 Facebook 的Buck以及 Google 的Bazel。
Gradle、Buck、Bazel 都是以更快的編譯速度、更強大的代碼優化爲目標
![]()
編譯時間和安裝時間兩個緯度來看Android的編譯速度。
編譯時間。把 Java 或者 Kotlin 代碼編譯爲“.class“文件，然後通過 dx 編譯爲 Dex
文件。對於增量編譯，我們希望編譯儘可能少的代碼和資源，最理想情況是隻編譯變化的部分。但是由於代碼之間的依賴，大部分情況這並不可行。這個時候我們只能退而求其次，希望編譯更少的模塊。Android
Plugin 3.0及以後的版本使用 Implementation 代替 Compile，正是爲了優化依賴關係；
安裝時間。我們要先經過簽名校驗，校驗成功後會有一大堆的文件拷貝工作，例如 APK 文件、Library 文件、Dex
文件等。之後我們還需要編譯 Odex 文件，這個過程特別是在 Android 5.0 和 6.0
會非常耗時。對於增量編譯，最好的優化是直接應用新的代碼，無需重新安裝新的 APK。
對於增量編譯，我先來講講 Gradle 的官方方案Instant Run。在 Android Plugin 2.3 之前，它使用的 Multidex 實現。在 Android Plugin 2.3 之後，它使用 Android 5.0 新增的 Split APK 機制。資源和 Manifest 都放在 Base APK 中， 在 Base APK 中代碼只有 Instant Run 框架，應用的本身的代碼都在 Split APK 中。Google 的人也發現了 Instant Run 的種種問題，在 Android Studio 3.5 之後，對於 Android 8.0 以後的設備將會使用新的方案“Apply Changes”代替 Instant Run
對於編譯速度的優化，我還有幾個建議：
1.更換編譯機器。對於實力雄厚的公司，直接更換 Mac 或者其他更給力的設備作爲編譯機，這種方式是最簡單的；
2.Build Cache。可以將大部分不常改變的項目拆離出去，並使用遠端 Cache模式保留編譯後的緩存；
3.升級 Gradle 和 SDK Build Tools。我們應該及時去升級最新的編譯工具鏈，享受 Google 的最新優化成果；
4.使用 Buck。無論是 Buck 的 exopackage，還是代碼的增量編譯，Buck
都更加高效。但我前面也說過，一個大型項目如果要切換到 Buck，其實顧慮還是比較多的。在 2014 年初微信就接入了
Buck，但是因爲跟其他項目協作的問題，導致在 2015 年切換回 Gradle 方案。
相比之下，可能目前最熱的 Flutter 中Hot Reload秒級編譯功能會更有吸引力。
當然最近幾個 Android Studio 版本，Google 也做了大量的其他優化，例如使用AAPT2替代了 AAPT 來編譯 Android 資源。AAPT2 實現了資源的增量編譯，它將資源的編譯拆分成 Compile 和 Link 兩個步驟。前者資源文件以二進制形式編譯 Flat 格式，後者合併所有的文件再打包。
ProGuard、d8、R8 和 ReDex 這四種我們可能會用到的代碼優化工具
ProGuard:在微信 Release 包 12 分鐘的編譯過程裏，單獨 ProGuard 就需要花費 8 分鐘。儘管 ProGuard 真的很慢，但是基本每個項目都會使用到它。ProGuard 主要有混淆、裁剪、優化這三大功能.其中優化包括內聯、修飾符、合併類和方法等 30 多種
D8:Android Studio 3.0 推出了d8，並在 3.1 正式成爲默認工具。它的作用是將“.class”文件編譯爲 Dex 文件，取代之前的 dx 工具,d8 除了更快的編譯速度之外，還有一個優化是減少生成的 Dex 大小。根據 Google 的測試結果，大約會有 3%～5% 的優化
R8:R8 在 Android Studio 3.1 中引入，它的志向更加高遠，它的目標是取代 ProGuard 和 d8。我們可以直接使用 R8 把“.class”文件變成 Dex。
ReDex 是 Facebook 開源的工具，通過對字節碼進行優化，以減小 Android Apk 大小，同時提高 App 啓動速度。
GitHub：ReDex github，官網主頁：fbredex.com
- 測試階段。我們希望可以做到測試“左移”，儘可能早地發現問題。但是很多時候我們不是不想測試，而是發現測不出什麼問題。那麼怎樣提升實驗室發現問題的能力呢？如何儘可能地模擬用戶的操作路徑？做好測試並不容易，自動化測試結合 AI 或許可以幫助我們解決一些痛點。
-
灰度和發佈階段。
![]()
