手機明明沒做什麼卻發燙掉幀：Android 的 HWC 退化，問題常常不在硬體

2026 年 9 月 24 日，掘金上一篇名為「Android HWC 退化與防治方法」的技術文章開始在開發者圈流傳。文章談的並不是新聞事件，而是一個存在已久的系統問題：不少 Android 手機的卡頓與耗電，真正的原因是畫面合成工作從專用硬體「退化」到了 GPU 身上。這個議題每隔一段時間就會被重新翻出來討論，因為它踩中了一個常見的誤區：使用者把流暢度問題歸因於「手機效能不夠」，但很多時候是軟體使用方式把硬體的省電通道繞掉了。

先弄懂：螢幕上的畫面是「疊」出來的

你在手機上看起來「一整張」的畫面，其實是由好幾個圖層疊出來的：App 的視窗、最上面的對話框、頂部狀態列、底部導覽列，各自是獨立的 Surface。負責把這些 Surface 合成為最終畫面送進螢幕的，是系統程序裡的 SurfaceFlinger。

可以把這件事想成辦桌。每個 Surface 是一道菜，SurfaceFlinger 是總鋪師，負責把菜擺盤上桌。而上菜有兩種方式：一種是請一位全能大廚（GPU）把所有菜先炒成一大盤再端出去，什麼都能做，但代價高；另一種是料理包直送（HWC），由專門的硬體通道直接把各道菜分層擺上桌，不用開火，快而且省。

HWC 的全名是 Hardware Composer，它靠螢幕驅動的 Overlay 通道直接分層掃描輸出，不經過 GPU 運算。原文點出它的兩個核心價值：釋放 GPU 算力給 App 層的遊戲渲染、UI 動效與自訂 Shader，以及降低功耗，因為 GPU 是高功耗組件，而高通 MDP／SDE 這類顯示控制器針對圖層疊加做過極度優化，能耗比遠優於 GPU。看影片、長時間待機的場景特別明顯。

退化是怎麼發生的

所謂 HWC 退化，就是合成工作從專用硬體回落到 GPU Client 合成。注意這個「Client」並非指在 App 裡合成，它仍然由 SurfaceFlinger 調度 GPU 執行，只是把原本不開火的省電路徑，換成了要開火的大廚路徑。

SurfaceFlinger 會優先讀取晶片方案的配置。若配置為 HWC 優先，圖層會先提交給 HWC；一旦 HWC 處理不了，才退回 GPU 兜底。而 HWC 雖快又省，能力其實相當有限。原文列出幾種典型的觸發情況：

• Surface 帶有複雜的矩陣變換，例如特殊旋轉
• 使用 HWC 不支援的像素格式，例如 RGBA1010102 或其他特殊格式
• 圖層疊加結構過於複雜、數量過多，超過單一螢幕 Overlay 通道的負載

在旗艦機上，HWC 通道多、能力強，這些邊界不容易踩到；但在 Overlay 通道少、支援格式有限的中低階裝置上，同樣的 App 很容易整批退化為 GPU 合成。症狀就是原文描述的明顯卡頓與掉幀，而使用者往往把它當成「這手機就是慢」。

一般人與開發者各自能做什麼

對多數使用者來說，這個機制解釋了一個日常經驗：同一款 App，旗艦機順、中低階機燙，差距未必來自處理器分數，而可能來自畫面結構踩中了 HWC 的地雷，逼 GPU 全程待命。這也是為什麼「規格表上看不到的，往往才是重點」，帳面 GPU 效能再強，只要合成路徑走錯，電池與流暢度照樣付出代價。

對 Android 開發者而言，原文提供的判斷方向很具體：懷疑畫面卡頓時，先確認合成路徑是否已退化為 GPU Client，再檢查自己的 Surface 是否帶有不必要的旋轉變換、非支援清單內的像素格式，或疊層數量是否爆表。很多被當成「系統效能問題」的個案，追下去其實是使用不當或架構設計問題。

原文另有一段值得留意的宏觀觀察：目前 Android 的創新集中在 AI 應用，而 On-Device AI 受限於模型算力、記憶體與介面不統一，尚未成氣候；但隨著人形機器人與手機硬體演進，端側運算會是趨勢。這個判斷與 HWC 治理其實是同一件事的兩面：當 GPU 未來要騰出手跑端側模型，把簡單的圖層疊加還給專用硬體，就不只是省電問題，而是算力排程問題。

想追蹤 Google 近年在 Android 底層架構上如何調整資源分配的讀者，可以參考我們先前分析的Google 收回 AOSP 公共走道的策略轉向，兩者都指向同一個趨勢：平臺廠正在更精細地控制硬體資源誰能用、怎麼用。

下次手機發燙掉幀，先別急著怪處理器。有相當的機率，是某個 App 的畫面結構把省電的直送通道堵住了，讓 GPU 這位大廚從早忙到晚。