各位戰士，歡迎來到第十一天的戰場。至今為止，我們的所有戰術——無論是為 Application 瘦身，還是延遲載入 Activity——都屬於「執行期優化」。我們在 App 運行時，透過聰明的程式碼組織來改善性能。但今天，我們要探討一個更根本、更強大的策略：在 App 被使用者第一次打開前，就讓它準備好高速運行。

這聽起來像魔法，但它背後的原理是 Android 程式碼編譯的演進。而實現這個魔法的鑰匙，就是 Baseline Profiles。

編譯的戰爭：JIT vs. AOT

要理解 Baseline Profiles 的威力，我們必須先了解 Android 系統是如何執行我們寫的 Kotlin/Java 程式碼的。

1. 即時編譯 (Just-In-Time, JIT)：當你第一次運行某段程式碼時，Android 執行環境 (ART) 會先解釋執行，同時在背景將其編譯成機器碼。這意味著第一次執行總是比較慢，因為包含了編譯的成本。後續執行才會變快。

2. 預先編譯 (Ahead-Of-Time, AOT)：系統在 App 安裝時，或在設備閒置充電時，提前將部分或全部程式碼編譯成機器碼。這樣，當你第一次運行時，它已經是最高效的狀態了。

Android 採用的是一種混合模式。問題在於，我們無法保證系統何時會為我們最關鍵的程式碼路徑（例如應用啟動）進行 AOT 編譯。使用者的第一次冷啟動體驗，很可能就犧牲在了 JIT 編譯的耗時上。

我們的作戰藍圖：Baseline Profiles

Baseline Profiles 就是我們提供給 Android 系統的一份「作戰藍圖」。它是一個純文字檔案 (baseline-prof.txt)，裡面列出了一系列類別 (Classes) 和方法 (Methods)，這些都是我們認為在關鍵使用者旅程 (Critical User Journey) 中會被頻繁使用到的程式碼。

最典型的關鍵使用者旅程就是應用啟動。

它的運作模式如下：

1. 我們在開發過程中，透過自動化測試產生一份描述了啟動流程的 Baseline Profile。
2. 我們將這份 baseline-prof.txt 檔案打包進我們的 App Bundle (AAB) 或 APK 中。
3. 當使用者從 Google Play 商店安裝我們的 App 時，系統會讀取這份 Profile。
4. 系統會在安裝期間，就對 Profile 中列出的所有方法進行 AOT 預先編譯。

結果就是： 當使用者第一次點擊你的 App 圖示時，所有啟動所需的關鍵程式碼都已經是最佳化的原生機器碼了。JIT 編譯的延遲被徹底繞過，使用者將體驗到一個極速的冷啟動。

威力有多大？

這不是一個微小的改進，而是一個巨大的飛躍。根據 Google 官方的數據，使用 Baseline Profiles 可以：

• 將應用程式的啟動速度提升高達 40%。
• 改善畫面滾動的流暢度，減少掉幀 (Jank)。
• 縮短頁面跳轉的等待時間。

它不僅對啟動有效，任何你定義在 Profile 中的關鍵旅程（例如：從主頁進入商品詳情頁、打開相機等）都能享受到 AOT 編譯帶來的性能提升。

可以把它想像成餐廳備料。沒有 Baseline Profile，廚師（ART）在接到第一份訂單（App 啟動）時，才開始手忙腳亂地洗菜、切菜（JIT 編譯），出餐自然很慢。而有了 Baseline Profile，我們就等於給了廚師一份「熱門菜色清單」，讓他在餐廳開門前就把所有需要的食材都準備好（AOT 編譯）。當第一位客人點餐時，他就能立刻下鍋，快速出餐。

今日總結

今天，我們進行了一次戰略層級的學習，從根本上理解了如何加速我們的應用。

• 我們了解了 Android 的 JIT 和 AOT 編譯機制。
• 我們認識到 Baseline Profiles 是一份我們提供給系統的「預先編譯指南」。
• 我們知道了它能在安裝期就完成關鍵程式碼的優化，從而大幅提升執行期的性能。

理論的學習已經完成，我們知道了這件武器的強大之處。明天，我們將親自動手，學習如何為我們的專案實際產生並應用一份 Baseline Profile，將今天的理論轉化為實實在在的性能提升！

準備好迎接實作的挑戰，我們明天見！