相信大家都有過呢種崩潰體驗：用電話睇緊網頁上的長篇文章，手指一直向下掃，畫面突然窒一窒或者跳格，確實破壞手機上網嘅體驗。
雖然 Android 系統早前已經刷新紀錄，成為最快嘅行動網頁瀏覽平台，但要造就完美嘅用戶體驗，單靠快係唔夠嘅。早喺 2023 年，Google 團隊就想徹底消滅捲動卡頓嘅根源。經過多年嘅努力，由 2023 年至 2026 年間，Android 版 Chrome 嘅捲動卡頓頻率，已經成功大幅減少 48%！。Chrome 團隊最近就在 Chromium Blog 分享這些改進背後的技術進程。
穩定性行先
點解畫面會窒？簡單嚟講，當手機未能準時運算出新一格 (Frame) 嘅捲動位置並顯示出嚟，卡頓就會發生。
Chrome 內部有一條極度嚴格嘅死線：佢必須喺螢幕下一次刷新之前，將每一格畫面準備好交貨。如果處理過程有任何延遲、過咗呢條死線，螢幕就唯有硬食，繼續顯示上一格嘅舊畫面，直到下一個刷新週期 (以 60Hz 螢幕為例，大概係 16.7 毫秒) 。
人類嘅肉眼非常敏感，呢啲跌 Frame落喺我哋眼中，就會變成你感覺到嘅窒機跳格。要避免呢種情況，Chrome 由接收你手指滑動嘅指令，到將畫面顯示出嚟嘅時間必須極度穩定 —— 每一次捲動更新嘅處理時間都要一模一樣。
Chrome 比一般 App 更難？
要顯示捲動動畫需要啲咩基本元素：
- 觸控指令 (Input events) ：話畀個 App 知你隻手指喺螢幕邊個位，等佢計算出新嘅捲動位置。
- VSync 訊號 (垂直同步) ：就好似手機嘅節拍器，由作業系統每個刷新週期發出一次，精準話畀個 App 知夠鐘準備下一格畫面喇。
普通嘅 Android App 會喺同一個 Thread 入面，同時接收觸控指令同 VSync 訊號，然後直接整出新畫面，乾脆俐落。
但 Chrome 嘅架構複雜得多！佢採用咗 Multi-process 模型，將瀏覽器、渲染同圖像處理分開獨立運作。呢個做法雖然大幅提升咗穩定性、安全性同整體效能，但同時令底層運算變得極度轉折：
- 當你隻手指掂到螢幕，硬體產生嘅觸控指令唔會只係去一個 Thread 或者一個 Process。佢首先會入去 Browser Process 做點擊測試 (Hit testing) ，然後再 Pass 畀 Renderer Process 去計出新嘅捲動偏移量。
- 另一邊廂，VSync 訊號就行緊另一條路。佢會先到達 GPU Process 裡面嘅 Viz 合成器，再傳送畀 Renderer Process。Renderer Process 收到之後，先會將佢同啲觸控指令相認並畫出新一格。
- 畫好嘅新一格畫面，又要交返畀 GPU Process 去生成像素放入 GPU Buffer (緩衝區) ，最後先由 OS 顯示上個 Mon 度。
Chrome 會直接從硬體接收觸控訊號。即係話，你手指嘅動作會以唔規則嘅頻率瘋狂傳入 Chrome，甚至喺一個刷新週期入面彈出好多次，令到成個對齊過程難上加難。
團隊透過全面為 Chrome 嘅觸控至渲染管線進行數據監測：
- 分析追蹤日誌，搵出導致捲動卡頓嘅底層罪魁禍首，再度橋策劃專案去解決。
- 實裝呢啲改進專案，並透過 A/B 測試喺真實環境中運行。
- 嚴格對比效能指標，一旦證實測試能成功減少卡頓，就向 100% 嘅用戶全面推送。
- 重複以上步驟，逐一解決所有效能樽頸。
