🔧 阿川の電商水電行
============================================
最近 Google 官方宣布，將 **AutoFDO（Automatic Feedback-Directed Optimization）應用到 Android kernel**，也就是在核心編譯優化中使用，從而在不同場景下提升約 4%–21% 的系統效能。
一般來說，過去的編譯器（例如 LLVM）通常靠靜態程式碼分析，或依據啟發式規則進行優化，例如猜測哪個分支較常被執行；而 AutoFDO 不同，它會在實驗環境中，針對裝置在真實執行熱門 App（Top 100）時的 CPU 執行流資料（分支歷史），蒐集 Profile，然後讓編譯器根據這些真實的「執行影像」重新編譯核心。它能精準識別程式碼中的「熱點（Hot paths）」，進而做更智慧的函式內聯（Inlining）與程式碼佈局（Code Layout）優化。
換句話說：過去編譯器只能靠靜態推測哪些函式該內聯、哪些分支較熱；現在先用取樣型 profiling 收集真實執行路徑，再把這些「熱點路徑」回饋給編譯器，讓下一次建置時做出更聰明的函式內聯與程式碼布局決策。
AutoFDO 在這裡主要影響的是編譯器的啟發式決策，例如內聯、程式碼布局等，因此不會改變原始碼語意；對於沒有被 profile 覆蓋到的冷函式，會退回到標準優化流程。這一點很關鍵，因為核心優化最怕遇到 edge case 回歸，所以 Google 的做法是：先穩定獲益，再逐步擴大覆蓋面。
因此，AutoFDO 的工作就是優化核心，而在 Android 系統中，核心程式碼約佔用系統總 CPU 時間的 40%，所以即便核心效能提升幅度不算非常大，也會在冷啟動、系統回應與電池續航等場景產生連鎖的正面影響。在 Pixel 裝置（核心版本 6.1、6.6、6.12）上的測試結果如下：
- 冷啟動速度：提升約 4%
- 開機時間：減少約 2%
- 使用者感知：介面更順暢、應用切換更快、續航更久
目前這項調整已在 android16-6.12 與 android15-6.6 分支部署，並計畫擴展到更新的 android17-6.18，將以 GKI（通用核心映像） 的形式普惠至所有廠商。
因為這只是不改變程式邏輯、僅變更編譯決策，因此不會引入邏輯性 Bug。
同時 Google 也提到，未來想繼續擴展到 GKI modules 與 vendor modules，也指出 Kleaf 與 simpleperf 已具備支援基礎，代表未來 profile-guided kernel optimization 會擴及更多 Android 底層元件。
有人或許會問，如果我的 App 不是 Top 100 的那種呢？Google 明確表示，這項優化是透過 Top 100 apps + AI 抓取 + Pixel 實機取樣 + ARM ETE/TRBE branch history 來生成 profile，那對特定 App 有用嗎？
實際上 AutoFDO 不是在優化 App 二進位檔，而是在優化核心二進位檔；核心的熱點並非某個 App 專屬，例如 scheduler、binder、系統呼叫、分頁錯誤（page fault）等路徑幾乎所有 App 都會經過，所以這裡的 Top 100 主要是找出 Android 使用者最常走的系統路徑。這也是為什麼 Google 強調：
profile 與內部 fleet 工作負載具有 85% 的相似度，因此這項優化不是針對單一 App 的行為，而是統計分布上的改善。
因此在多數情況下，這項調整會帶來正向效果；當然，如果廠商修改了核心或驅動、或你的 App 對核心有深度 Hook，或你的自研引擎高度依賴核心行為，就有可能出現反效果。
另外，這種以採樣回饋為基礎的優化方式，未來也可能被 KMP 的 Kotlin/Native 等部分借鏡，針對特定裝置生成更佳的程式碼。
總的來說，這項優化相當有意義，可以讓 Android 15–16 的裝置普遍受益，且未來還會進一步擴大優化範圍。最重要的是這次升級是安全的，官方表示不會帶來 Bug。
那，你覺得呢？
連結
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
