一、卡頓原因
屏幕1秒60幀，平均每幀16.6毫秒，如果代碼實現不佳，或者過於複雜，導致一幀繪製時間大於16.6毫秒，則無法完成繪製，造成丟幀，連續出現掉幀，在現象上表現爲卡頓。
二、App啓動時間
1、方法1
adb shell am start -W com.zhoupushuju.zhouyi/com.rnmobx.MainActivity
結果
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.zhoupushuju.zhouyi/com.rnmobx.MainActivity }
Status: ok
LaunchState: COLD
Activity: com.zhoupushuju.zhouyi/com.rnmobx.MainActivity
TotalTime: 931
WaitTime: 934
Complete
- LaunchState：啓動方式，此爲冷啓動
- Activity：啓動頁面
- TotalTime：啓動Activity的總耗時
- WaitTime：啓動Activity的總耗時+少量的系統耗時
2、方法2
adb logcat -b all | grep am_activity_launch_time
結果
[0,78748358,com.zhoupushuju.zhouyi/com.rnmobx.MainActivity,931]
三、AndroidStudio Profile使用
1、在 Android 12 及更高版本上檢測卡頓情況
對於搭載 Android 12（API 級別 31）或更高版本的設備，CPU 性能分析器中 Display 窗格下的 Janky Frameworks 軌道中會顯示捕獲的軌跡。
如需檢測卡頓情況，請按以下步驟操作：
-
在 Android Studio 中，依次選擇 View > Tool Windows > Profiler，或點擊工具欄中的 Profile 圖標
![]()
如果 Select Deployment Target 對話框顯示提示，請選擇要將您的應用部署到哪個設備以進行性能分析。如果您已通過 USB 連接設備但系統未列出該設備，請確保您已啓用 USB 調試。
點擊 CPU 時間軸上的任意位置以打開 CPU 性能分析器。
從 CPU 性能分析器的配置菜單中選擇 System Trace，然後點擊 Record。完成與應用的交互後，點擊 Stop。
-
您應該會在 Display 下方看到 Janky frames 軌道。默認情況下，性能分析器只會將卡頓幀顯示爲有待調查的候選對象。在每個卡頓幀中，紅色部分突出顯示了相應幀超出其渲染截止時間的時長。
![]()
-
發現卡頓幀後，點擊該幀；可根據需要按 M 鍵調整縮放程度以聚焦到所選幀。相關事件會在以下線程中突出顯示：主線程、RenderThread 和 GPU completion。
![]()
-
通過選中或取消選中 All Frames 和 Lifecycle 複選框，您可以根據需要查看所有幀或呈現時間的細分數據。
![]()
2、在Android 11上檢測卡頓情況
對於搭載 Android 11（API 級別 30）的設備，CPU 性能分析器的 Frame Lifecycle 部分會顯示捕獲的軌跡。
Frame Lifecycle 部分包含層名稱和四個軌跡。每個軌跡分別代表幀呈現流水線中的一個階段。Frame Lifecycle 元素如下：
- Frame Lifecycle (層名稱)：該部分的標題包含用括號括起來的層名稱。層是單個組合單元。
-
Application：此軌跡顯示從緩衝區被應用移出隊列到重新回到隊列的時間。這通常對應於
RenderThread中的軌跡事件。 - Wait for GPU：此軌跡顯示 GPU 擁有相應緩衝區的時長。該時長指的是，從相應緩衝區的內容被髮送至 GPU，到 GPU 利用相應緩衝區的內容完成其工作，期間所經歷的時間。這並不表示 GPU 在此期間僅使用相應緩衝區的內容工作。如需詳細瞭解給定時間內 GPU 執行的工作，您可能需要使用 Android GPU 檢查器。
- Composition：此軌跡顯示，從 SurfaceFlinger 佔有相應緩衝區併發送相應緩衝區的內容以進行合成，到相應緩衝區的內容被髮送到顯示屏，期間所經歷的時間。
- Frames on display：此軌跡顯示相應幀在屏幕上的時長。
Frame Lifecycle 部分說明了幀緩衝區在呈現流水線的不同階段之間的切換方式。幀按幀號進行顏色編碼，以便更輕鬆地跟蹤特定幀。
Android Studio 還會在 All Frames 標籤頁中以表格格式顯示軌跡中的所有幀。
Frame #、Application、Wait for GPU 和 Composition 列表示的數據與上方 Frame Lifecycle 部分的軌跡表示的數據一樣。Frame Duration 列表示從 Application 開始到 Frames on Display 開始所經歷的時間。這本質上是端到端呈現幀的時長。
您可以按任意列對“Frames”表進行排序，以便快速找到最短或最長的幀。該表還支持分頁控件，您可以藉助這些控件瀏覽數以百計的幀。
如需在 Android 11 上檢測和調查卡頓情況，請按以下步驟操作：
-
按 Application 列對 All Frames 表進行降序排序，使耗時最長的幀首先顯示。
![]()
-
找到運行時間最長的幀，然後選擇表中的一行。這將在左側的時間軸視圖中放大所選的幀。
![]()
-
在 Frame Lifecycle 和 Threads 部分查找相關線程。
![]()
3、在Android 10及更低版本上檢測卡頓情況
對於搭載 Android 10（API 級別 29）及更低版本的設備，相關的操作系統圖形管道信息會顯示在 CPU 性能分析器系統軌跡中的單個部分，稱爲 Display。
-
Frames：此部分顯示應用中的界面線程和
RenderThread軌跡事件。時長超過 16 毫秒的事件會以紅色表示，以突出顯示潛在的卡頓幀，因爲它們超出了以 60 幀/秒 (fps) 的速度進行呈現的截止時間。 - SurfaceFlinger：此部分顯示 SurfaceFlinger 處理幀緩衝區的時間。SurfaceFlinger 是負責將緩衝區內容發送到顯示屏的系統進程。
- VSYNC：此部分顯示 VSYNC，這是一個表示與顯示流水線保持同步的信號。該軌跡會顯示 VSYNC-app 信號，這個信號會在應用啓動時間過晚時顯示。通常情況下，發生這種情況是因爲界面線程處於忙碌狀態。在動畫播放期間，它會導致屏幕上出現可見的閃爍，並且在動畫或滾動完成之前，會持續帶來額外的輸入延遲。對於刷新率較高的顯示屏，尤其要注意查看該軌跡，因爲與刷新率爲 60 次/秒或刷新率可變的顯示屏相比，這種顯示屏更容易出現此類問題。
-
BufferQueue：此部分顯示有多少幀緩衝區在排隊等待 SurfaceFlinger 使用。對於部署到搭載 Android 9（API 級別 28）或更高版本的設備的應用，此軌跡顯示應用 surface BufferQueue 的緩衝區計數（
0、1或2）。BufferQueue 可幫助您瞭解圖像緩衝區在 Android 圖形組件之間切換時的狀態。例如，值2表示應用當前處於三重緩衝狀態，這會導致額外的輸入延遲。
Display 部分會提供有助於檢測潛在卡頓的實用信號，例如何時界面線程或 RenderThread 的用時超過 16 毫秒。若要調查導致卡頓的確切細節，您可以查看 Threads 部分，其中會顯示與界面呈現有關的線程。
在上圖中，Threads 部分顯示了界面線程 (java.com.google.samples.apps.iosched)、RenderThread 和 GPU completion 線程。這些線程與界面呈現有關，可能是導致卡頓的原因。
如需在 Android 10 或更低版本上檢測卡頓情況，請執行以下操作：
-
查看 Display 中的 Frames 軌跡。紅色幀是要調查的候選對象。
![]()
-
發現可能存在卡頓的幀後，請按
W，或在按住 <kbd style="box-sizing: inherit;">Control</kbd> 鍵（在 macOS 設備上，則按住 <kbd style="box-sizing: inherit;">Command</kbd> 鍵）的同時滾動鼠標滾輪，以便進行放大。繼續放大，直到您看到界面線程和RenderThread中的軌跡事件。
![]()
在上圖中，
Choreographer#doFrame顯示了界面線程何時調用Choreographer來協調動畫、視圖佈局、圖像繪製和相關進程。DrawFrames顯示了RenderThread何時形成並向 GPU 發出實際繪製命令。 如果您發現某個軌跡事件特別長，可以進一步放大，以便找出可能導致呈現速度緩慢的原因。上圖顯示了界面線程中的
inflate，這意味着應用正在花時間膨脹佈局。當您放大其中一個inflate事件時，可以確切瞭解每個界面組件花費的時間，如下所示。
