android優化卡頓

『壹』 Android 中的卡頓丟幀原因概述 - 應用篇

在探討Android設備的卡頓與丟幀問題時，我們首先需要區分問題的根源是系統層面還是應用層面。這篇文章專注於介紹由App自身引發的卡頓問題，幫助用戶在遇到設備卡頓現象時，能夠首先從應用角度進行排查。

卡頓與丟幀問題在Android設備上非常常見，這涉及到操作過程中幀率的波動。通常，設備每秒需要更新60幀以保證流暢體驗，若實際更新幀數少於60，用戶就會感知到卡頓。引起丟幀的原因多樣，包括硬體、軟體層面問題以及App自身的設計缺陷。

對於應用開發者而言，理解並解決這些問題對於提升用戶體驗至關重要。以下列舉了導致卡頓與丟幀的一些常見原因：

1. 主線程執行時間過長：主線程執行如輸入處理、動畫、測量布局、繪圖、點陣圖解碼等操作時，若耗時超過預期，會直接影響設備性能，導致卡頓。

2. Measure和Layout耗時過長：這些操作在視圖構建過程中占據重要地位，耗時或調度不及時，會直接導致卡頓。

3. 動畫回調耗時：動畫處理中的回調若處理時間過長，同樣會影響性能，導致卡頓現象。

4. 視圖初始化耗時：如在應用中初始化列表項，若耗時過長，會引發卡頓。

5. decodeBitmap耗時：點陣圖解碼操作過長，可能導致渲染線程性能下降，進而影響整體性能。

6. uploadBitmap耗時：頻繁上傳點陣圖至GPU，特別是對於大圖或動態變化的圖，會加重渲染線程負擔，導致卡頓。

7. BuildDrawingCache耗時：應用頻繁調用此操作，可能導致主線程執行時間過長，影響性能。

8. CPU渲染而非GPU渲染：不當的渲染策略可能導致UI線程負載加重，引起卡頓。

9.主線程Binder操作耗時：在Activity resume時，與AMS通信可能需要等待鎖操作，這在後台繁忙時會增加耗時，引起卡頓。

10.游戲SurfaceView內容繪制不均勻：游戲自身的繪制問題可能導致幀率波動，引起卡頓。

11. WebView性能不足：復雜頁面的渲染可能導致WebView性能下降，影響整體流暢度。

12.幀率與刷新率不匹配：屏幕幀率與系統幀率不匹配，可能導致畫面顯示不流暢。

13.應用性能跟不上高幀率屏幕和系統：在高幀率設備上，應用性能不足可能導致卡頓。

總結而言，Android系統的性能優化是一個持續發展的過程，不同版本解決的問題與引入的新問題並存。手機廠商在系統中加入大量自定義代碼，這在一定程度上影響了系統的整體性能。同時，Android的開放性意味著應用質量參差不齊，這直接影響用戶體驗。開發者需要重視應用的性能優化，以提供更好的用戶體驗。當發現應用存在性能問題時，系統開發者與開發者之間會進行溝通，共同尋找解決方案。理解並解決這些問題，對於提升Android應用的性能和用戶體驗至關重要。

『貳』 Android流暢度評估及卡頓優化

Google定義：界面呈現是指從應用生成幀並將其顯示在屏幕上的動作。要確保用戶能夠流暢地與應用互動，應用呈現每幀的時間不應超過16ms，以達到每秒60幀的呈現速度（為什麼是60fps？）。
如果應用存在界面呈現緩慢的問題，系統會不得不跳過一些幀，這會導致用戶感覺應用不流暢，我們將這種情況稱為卡頓。

來源於： Google Android的為什麼是60fps？

16ms意味著1000/60hz，相當於60fps。這是因為人眼與大腦之間的協作無法感知超過60fps的畫面更新。12fps大概類似手動快速翻動書籍的幀率， 這明顯是可以感知到不夠順滑的。24fps使得人眼感知的是連續線性的運動，這其實是歸功於運動模糊的效果。 24fps是電影膠圈通常使用的幀率，因為這個幀率已經足夠支撐大部分電影畫面需要表達的內容，同時能夠最大的減少費用支出。 但是低於30fps是 無法順暢表現絢麗的畫面內容的，此時就需要用到60fps來達到想要的效果，超過60fps就沒有必要了。如果我們的應用沒有在16ms內完成屏幕刷新的全部邏輯操作，就會發生卡頓。

首先要了解Android顯示1幀圖像，所經歷的完整過程。

如圖所示，屏幕顯示1幀圖像需要經歷5個步驟：

常見的丟幀情況： 渲染期間可能出現的情況，渲染大於16ms和小於16ms的情況：

上圖中應該繪制 4 幀數據 , 但是實際上只繪制了 3 幀 , 實際幀率少了一幀

判斷APP是否出現卡頓，我們從通用應用和游戲兩個緯度的代表公司標准來看，即Google的Android vitals性能指標和地球第一游戲大廠騰訊的PrefDog性能指標。

以Google Vitals的卡頓描述為准，即呈現速度緩慢和幀凍結兩個維度判斷：

PerfDog Jank計算方法：

幀率FPS高並不能反映流暢或不卡頓。比如：FPS為50幀，前200ms渲染一幀，後800ms渲染49幀，雖然幀率50，但依然覺得非常卡頓。同時幀率FPS低，並不代表卡頓，比如無卡頓時均勻FPS為15幀。所以平均幀率FPS與卡頓無任何直接關系)

當了解卡頓的標准以及渲染原理之後，可以得出結論，只有丟幀情況才能准確判斷是否卡頓。

mpsys 是一種在設備上運行並轉儲需要關注的系統服務狀態信息的 Android 工具。通過向 mpsys 傳遞 gfxinfo 命令，可以提供 logcat 格式的輸出，其中包含與錄制階段發生的動畫幀相關的性能信息。

藉助 Android 6.0（API 級別 23），該命令可將在整個進程生命周期中收集的幀數據的聚合分析輸出到 logcat。例如：

這些總體統計信息可以得到期間的FPS、Jank比例、各類渲染異常數量統計。

命令 adb shell mpsys gfxinfo <PACKAGE_NAME> framestats 可提供最近120個幀中，渲染各階段帶有納秒時間戳的幀時間信息。

關鍵參數說明：

通過gfxinfo輸出的幀信息，通過定時reset和列印幀信息，可以得到FPS(幀數/列印間隔時間)、丟幀比例（(janky_frames / total_frames_rendered)*100 %）、是否有幀凍結(幀耗時>700ms)。
根據第2部分的通用應用卡頓標准，可以通過丟幀比例和幀凍結數量，准確判斷當前場景是否卡頓。並且通過定時截圖，還可以根據截圖定位卡頓的具體場景。

如上圖所示，利用gfxinfo開發的檢查卡頓的小工具，圖中參數和卡頓說明如下：

根據上面對gfxinfo的幀信息解析，可以准確計算出每一幀的耗時。從而可以開發出滿足騰訊PerfDog中關於普通卡頓和嚴重卡頓的判斷。

依賴定時截圖，即可准確定位卡頓場景。如下圖所示（此處以PerfDog截圖示例）：

通過第3部分的卡頓評估方法，我們可以定位到卡頓場景，但是如何定位到具體卡頓原因呢。

首先了解卡頓問題定位工具，然後再了解常見的卡頓原因，即可通過復現卡頓場景的同時，用工具去定位具體卡頓問題。

重點就是，充分利用gfxinfo輸出的幀信息，對卡頓問題進行分類。

了解了高效定位卡頓的方法和卡頓問題定位工具，再熟悉一下常見的卡頓原因，可以更熟練的定位和優化卡頓。

SurfaceFlinger 負責 Surface 的合成，一旦 SurfaceFlinger 主線程調用超時，就會產生掉幀。
SurfaceFlinger 主線程耗時會也會導致 hwc service 和 crtc 不能及時完成，也會阻塞應用的 binder 調用，如 dequeueBuffer、queueBuffer 等。

後台進程活動太多，會導致系統非常繁忙，cpu io memory 等資源都會被佔用，這時候很容易出現卡頓問題，這也是系統這邊經常會碰到的問題。
mpsys cpuinfo 可以查看一段時間內 cpu 的使用情況：

當線程為 Runnable 狀態的時候，調度器如果遲遲不能對齊進行調度，那麼就會產生長時間的 Runnable 線程狀態，導致錯過 Vsync 而產生流暢性問題。

system_server 的 AMS 鎖和 WMS 鎖 , 在系統異常的情況下 , 會變得非常嚴重 , 如下圖所示 , 許多系統的關鍵任務都被阻塞 , 等待鎖的釋放 , 這時候如果有 App 發來的 Binder 請求帶鎖 , 那麼也會進入等待狀態 , 這時候 App 就會產生性能問題 ; 如果此時做 Window 動畫 , 那麼 system_server 的這些鎖也會導致窗口動畫卡頓。

Android P 修改了 Layer 的計算方法 , 把這部分放到了 SurfaceFlinger 主線程去執行, 如果後台 Layer 過多，就會導致 SurfaceFlinger 在執行 rebuildLayerStacks 的時候耗時 , 導致 SurfaceFlinger 主線程執行時間過長。

主線程執行 Input Animation Measure Layout Draw decodeBitmap 等操作超時都會導致卡頓 。

Activity resume 的時候, 與 AMS 通信要持有 AMS 鎖, 這時候如果碰到後台比較繁忙的時候, 等鎖操作就會比較耗時, 導致部分場景因為這個卡頓, 比如多任務手勢操作。

應用裡面涉及到 WebView 的時候, 如果頁面比較復雜, WebView 的性能就會比較差, 從而造成卡頓。

如果屏幕幀率和系統的 fps 不相符 , 那麼有可能會導致畫面不是那麼順暢. 比如使用 90 Hz 的屏幕搭配 60 fps 的動畫。

由上面的分析可知對象分配、垃圾回收(GC)、線程調度以及Binder調用 是Android系統中常見的卡頓原因，因此卡頓優化主要以下幾種方法，更多的要結合具體的應用來進行：

在計算機和通信領域，幀是一個包括「幀同步串列」的數字數據傳輸單元或數字數據包。
在視頻領域，電影、電視、數字視頻等可視為隨時間連續變換的許多張畫面，其中幀是指每一張畫面。