卡頓概述

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

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

識別卡頓

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

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

目視檢查法

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

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

務必確保您看到的內容與用戶將會看到的內容類似，要使用應用的發布版本（或至少是不可調試的版本）進行測試。因為版本和發布版本在性能上會存在較大的差異。

啟用 GPU 渲染模式分析功能。GPU 呈現模式分析功能會在屏幕上顯示一些條形，以相對于每幀16ms的基準，快速直觀地顯示呈現界面窗口幀所花的時間。每個條形都有帶顏色的區段，對應于呈現管道中的一個階段，這樣我們就可以看到哪個部分用時最長。例如，如果幀花費大量時間處理輸入，我們就應該查看負責處理用戶輸入的應用代碼。

某些組件（如 ）是卡頓的常見來源。如果我們使用了這一類組件，最好查看一下應用的這些部分。

有的卡頓只有在通過冷啟動的方式啟動時，才會出現。

我們可以嘗試在速度較慢的設備上運行您的應用，以放大卡頓問題。

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

方法

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

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

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

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

系統跟蹤信息會顯示每幀的繪制時間，并對每幀進行顏色編碼以突出顯示渲染速度緩慢的時間。與目視檢查相比，這種方法有助于您更準確地找出各個卡頓的幀。

系統跟蹤信息會檢測應用中的問題，并在各個幀和提醒面板中同時顯示提醒。

框架和庫的某些部分（如 ）包含跟蹤標記。因此，系統跟蹤信息時間軸會顯示在界面線程上執行這些方法的時間以及時長。

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

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

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

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

CPU 工具

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

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

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

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

示例圖：

CPU 的使用方法請參考前文《 CPU 性能分析工具介紹和使用詳解》。

線上性能監控方法

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

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

UI卡頓檢測（一）——基于機制的實現方案（線上方案） UI卡頓檢測（二）——基于原理的方案（線上方案）線上幀率的檢測。（通過.回調來實現幀率監控） 總結

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

PS：性能優化專欄：《性能》持續更新中……