Android卡頓的檢測及優化方法彙總（線下+線上）

時間 2021-08-15 標籤 Android性能 android 性能卡頓監控工具

卡頓概述

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

如果我們的應用存在卡頓，應該如何進行診斷和解決呢？

想要在應用中找出導致卡頓的代碼可能並非易事。接下來我們將介紹常用的一些方法和工具。

有效識別卡頓，有如下幾種方法：

打開你的應用並手動查看應用的不同部分，看看是否有卡頓的界面。該方法有助於你找出導致卡頓的用例和場景。

使用目視檢查時，要注意以下幾點：

務必確保您看到的內容與用戶將會看到的內容類似，要使用應用的發佈版本（或至少是不可調試的版本）進行測試。因爲Debug版本和發佈版本在性能上會存在較大的差異。
啓用 GPU 渲染模式分析功能。GPU 呈現模式分析功能會在屏幕上顯示一些條形，以相對於每幀16ms的基準，快速直觀地顯示呈現界面窗口幀所花的時間。每個條形都有帶顏色的區段，對應於呈現管道中的一個階段，這樣我們就可以看到哪個部分用時最長。例如，如果幀花費大量時間處理輸入，我們就應該查看負責處理用戶輸入的應用代碼。
某些組件（如 RecyclerView）是卡頓的常見來源。如果我們使用了這一類組件，最好查看一下應用的這些部分。
有的卡頓只有在通過冷啓動的方式啓動時，纔會出現。
我們可以嘗試在速度較慢的設備上運行您的應用，以放大卡頓問題。

通過目視檢查法，我們發現了導致卡頓的用例和場景，通過本地代碼分析，我們可能已經找到了卡頓原因。但是，如果卡頓原因並沒有準確定位，就需要我們收集更多的信息來進一步深入分析了。

Systrace 工具用於顯示整個設備在做些什麼，不過也可用於識別應用中的卡頓。Systrace 的系統開銷非常小，因此我們可以在插樁測試期間體驗實際卡頓情況。

在設備上執行卡頓的用例的場景時，我們可以使用 Systrace 記錄跟蹤信息。系統跟蹤信息會按進程和線程進行細分，我們可以在 Systrace 中查看應用的進程，該進程應如圖所示：

圖：systrace信息（系統跟蹤信息）

系統跟蹤信息包含以下用於識別卡頓的信息：

查看系統跟蹤信息輸出後，可能我們會懷疑應用中的某些方法是導致卡頓的因素。

例如，如果時間軸顯示某個幀的呈現速度較慢是因爲 RecyclerView 花費很長時間導致的，這時，我們可以在相關代碼中添加跟蹤標記（性能分析工具Systrace的使用詳解），然後重新運行 systrace 以獲取更多信息。在新的系統跟蹤信息中，時間軸會顯示應用中的方法的調用時間和執行時長。

注意：記錄系統跟蹤信息時，每個跟蹤標記（執行的開始和結束對）會增加大約 10μs 的開銷。爲了避免出現假正例卡頓，對於在一幀中會被調用數十次或用時少於 200us 的方法，請勿爲其添加跟蹤標記。

注：關於Systrace的詳細使用方法，請參考前文《性能分析工具Systrace的使用詳解》。

如果Systrace信息未顯示關於界面線程工作爲何用時較長的詳細信息，我們可能需要使用 Android CPU Profiler 來記錄採樣或插樁測試的方法跟蹤信息。

Android Studio CPU 性能剖析器可實時檢查應用的 CPU 使用率和線程活動。你還可以檢查方法跟蹤記錄、函數跟蹤記錄和系統跟蹤記錄中的詳細信息。

使用CPU profiler可以查看主線程中，每個方法的耗時情況，以及每個方法的調用棧，可以很方便的分析卡頓產生的原因，以及定位到具體的代碼方法。

通常情況下，方法跟蹤信息不適合用於識別卡頓，因爲它們會因開銷過大而導致出現假正例卡頓，且無法查看線程何時運行以及何時處於阻塞狀態。不過，方法跟蹤信息可以幫助我們找出應用中用時最多的方法。找出這些方法後，我們就可以添加跟蹤標記並重新運行 systrace 以查看這些方法是否會導致卡頓。

示例圖：

以上的方法都屬於線下性能檢測場景，使用它們可以發現一些特定的場景或者卡頓明顯的場景。但是針對線上用戶，用戶的使用場景和機型千差萬別，這時我們必須要具備線上的性能採集方案，監控線上用戶的使用狀況。

線上卡頓監控方案，可以參考之前寫的幾個方案：

本文介紹了卡頓是什麼，以及如何使用適合的工具發現卡頓、如何在線上和線下環境實現卡頓的監控。