瞭解 Systrace

systrace 是分析 Android 裝置效能的主要工具。 但實際是其他工具的包裝函式。這是主機端包裝函式 atrace 是裝置端可執行檔，可控制使用者空間 追蹤記錄及設定 ftrace，以及 Linux 的主要追蹤機制 核心。systrace 使用追蹤記錄來啟用追蹤功能，然後讀取 ftrace 緩衝區，並 將所有內容包裝在一個獨立的 HTML 檢視器中。(儘管較新的核心提供支援 Linux Enhanced Berkeley Packet Filter (eBPF)，請參閱下列說明文件 與 Pixel/Pixel 使用的 3.18 核心 (無 eFPF) 有關 XL)。

Systrace 是由 Google Android 和 Google Chrome 團隊所有， 將開放原始碼做為 Catapult 專案。於 除了 Systrace，Catapult 還提供其他實用公用程式例如： Ftrace 的功能比 systrace 或 atrace 直接啟用，而且 包含一些對效能偵錯非常重要的進階功能 如要解決關聯問題，可用 Apriori 這類關聯規則學習技術和演算法(這些功能需要 Root 存取權，且通常是新的核心)。

執行 Systrace

在 Pixel/Pixel XL 上偵錯時基誤差時，請先從以下項目著手： 指令：

./systrace.py sched freq idle am wm gfx view sync binder_driver irq workq input -b 96000

結合 GPU 和螢幕所需的額外追蹤點時 這樣就能透過管道活動追蹤使用者輸入內容 。將緩衝區空間設為較大，以免遺失 事件 (因為如果沒有大型緩衝區，有些 CPU 在 執行記錄

瀏覽 Systrace 時，請留意每個事件

由於 Systrace 是建立在 CPU 上的 ftrace 和 ftrace 之上， 某個 CPU 上的內容必須寫入 ftrace 緩衝區，以便記錄硬體變更。 這表示，如果您想知道螢幕圍欄為何變更狀態， 可查看 CPU 執行階段在轉換點正在執行的操作 (在 CPU 上執行的操作觸發而記錄中變更)。這個 概念是使用 Systrace 分析效能的基礎。

範例：工作框

這個範例說明一般 UI 管道的 Systrace。共襄盛舉 建議使用下載追蹤記錄的 ZIP 檔案。 (也包括本節提及的其他追蹤記錄)、將檔案解壓縮， 然後在瀏覽器中開啟 systrace_tutorial.html 檔案。保持警告 這個 Systrace 是大型檔案除非每天使用 systrace 可能會因此更龐大的追蹤記錄 在單一追蹤記錄中呈現的資料

針對一致的週期性工作負載，例如 TouchLatency、UI 管道 包含下列項目：

1. SurfaceFlinger 中的 EventThread 會喚醒應用程式 UI 執行緒，表明現在是時候了 轉譯新影格
2. 應用程式使用 CPU 和 以及 GPU 資源這是 UI 花費的大量容量。
3. 應用程式使用繫結器將轉譯的影格傳送至 SurfaceFlinger，然後 SurfaceFlinger 會進入休眠模式。
4. SurfaceFlinger 中的第二個 EventThread 喚醒 SurfaceFlinger 以觸發 組合及顯示輸出內容如果 SurfaceFlinger 判定沒有任何工作 完成時，就會回到休眠狀態。
5. SurfaceFlinger 使用 Hardware Composer (HWC)/硬體處理組合 Composer 2 (HWC2) 或 GL。HWC/HWC2 組成 速度更快，耗電量更低，但因晶片系統而異，有限度地會受到限制 (SoC)。這項程序通常需要 4 到 6 毫秒，但可能會與步驟 2 重疊，因為 Android 裝置 應用程式一律會進行三重緩衝。(雖然應用程式一律會緩衝處理，但 可能是 1 個待審影格，導致 SurfaceFlinger 待處理 與雙緩衝區相同)。
6. SurfaceFlinger 會派出最終輸出並顯示供應商驅動程式 回到休眠狀態，等待 EventThread 喚醒。

讓我們從 15409 毫秒起的影格開始逐步說明：

，瞭解如何調查及移除這項存取權。

圖 1 是一般的影格，周圍環繞著一般影格，所以 開始瞭解 UI 管道運作方式UI 執行緒列 在不同時間對 TouchLatency 提供不同的顏色長條表示 執行緒的不同狀態：

• 灰色。睡覺。
• 藍色。可執行 (可以執行，但排程器未執行) 挑選和執行了)。
• 綠色。運作中 (排程器認為 執行中)。
• 紅色。不可中斷的睡眠 (一般在鎖頭上進入休眠模式) 核心部分)。可能代表 I/O 負載。非常適合偵錯 效能問題
• 橘色。因 I/O 負載而中斷不中斷的睡眠。

如要查看不可中斷睡眠的原因 (請前往 sched_blocked_reason 追蹤記錄點)，選取不可中斷的紅色 或睡眠片段

執行 EventThread 時，TouchLatency 的 UI 執行緒會變為 可以執行。如要查看喚醒的是什麼，請按一下藍色部分。

，瞭解如何調查及移除這項存取權。

圖 2 顯示 Touch Latency UI 執行緒被 tid 6843 喚醒， 對應至 EventThread。UI 執行緒會喚醒、轉譯影格，並將訊息排入佇列 讓 SurfaceFlinger 使用

，瞭解如何調查及移除這項存取權。

如果追蹤記錄已啟用 binder_driver 標記，您可以選取 以繫結方式交易來查看 交易。

，瞭解如何調查及移除這項存取權。

圖 4 顯示，在 SurfaceFlinger 中，15,423.65 毫秒的 Binder:6832_1 會變成 因 tid 9579 而執行，也就是 TouchLatency 的 RenderThread。你也可以 請查看繫結器交易兩側的 QueueBuffer。

在 SurfaceFlinger 端的 QueueBuffer 中，待處理數量 的影格速率介於 1 至 2 之間

，瞭解如何調查及移除這項存取權。

圖 5 顯示三段緩衝處理，其中有兩個已完成的影格和 應用程式即將開始轉譯第三次這是因為 因此應用程式會保留兩個待處理影格，而非單一影格 進一步捨棄影格

不久之後，SurfaceFlinger 的主執行緒遭到第二個 EventThread 喚醒， 它可以在顯示屏上輸出較舊的待處理影格：

，瞭解如何調查及移除這項存取權。

SurfaceFlinger 會先鎖住較舊的待處理緩衝區，導致 待處理的緩衝區數量，從 2 減少到 1。

，瞭解如何調查及移除這項存取權。

綁架緩衝區後，SurfaceFlinger 會設定組合並提交 影格的最終畫面(其中有些部分會在 mdss 追蹤記錄點，因此可能不包含在您的 SoC 中)。

，瞭解如何調查及移除這項存取權。

接著，mdss_fb0 會在 CPU 0 上喚醒。mdss_fb0是 顯示管道的核心執行緒，用來將轉譯的影格輸出至螢幕。 可以在追蹤記錄中看到 mdss_fb0 做為獨立的資料列 (向下捲動至 資料檢視)。

mdss_fb0 醒來，短暫執行，進入不可中斷的睡眠。 然後再喚醒。

範例：非工作影格

這個範例中的 Systrace 是用於偵錯 Pixel/Pixel XL 的時基誤差。目的地： 請按照範例的指示下載 ZIP 檔案 追蹤記錄檔案，包括這份記錄中提及的其他追蹤 區段)，解壓縮檔案並開啟systrace_tutorial.html 。

開啟 Systrace 後，您會看到如下的內容：

，瞭解如何調查及移除這項存取權。

尋找卡頓時，請檢查 SurfaceFlinger 下方的「FrameMissed」列。 FrameMissed 是 HWC2 提供的改善生活品質。查看期間 如果是其他裝置的 Systrace，就可能不會顯示「FrameMissed」資料列 並未使用 HWC2無論是 畫面，FrameMissed 會與 SurfaceFlinger 缺少其中一個 應用程式極其正常的執行階段，以及未變更的待處理緩衝區數量 (com.prefabulated.touchlatency) 執行 vsync。

，瞭解如何調查及移除這項存取權。

圖 11 顯示 15598.29&nbps; 毫秒的影格錯過。SurfaceFlinger 在以下時間短暫醒來 非同步間隔，並在不進行任何工作的情況下回到休眠狀態 SurfaceFlinger 認為嘗試將影格傳送至螢幕並不值得 可以選取「重新建立」，再次生成新的提示原因是什麼？

如要瞭解這個影格的管道中斷情形，請先查看 上述工作影格範例，瞭解正常 UI 管道在 systrace 中的顯示方式。 準備就緒後，請返回遺漏的影格並反向處理。請注意 SurfaceFlinger 喚醒後會立即進入休眠模式。查看 針對 TouchLatency 提供的兩個影格，有兩個影格 (這個線索 才能釐清問題。

，瞭解如何調查及移除這項存取權。

由於 SurfaceFlinger 中含有影格，這不是應用程式問題。此外， SurfaceFlinger 在正確時間喚醒，所以它不是 SurfaceFlinger 問題。如果 SurfaceFlinger 和應用程式的外觀都正常，那麼可能是 像是驅動程式問題

因為 mdss 和 sync 追蹤點已啟用 我們可以取得圍欄的相關資訊 (顯示器驅動程式與 SurfaceFlinger)，可控制影格提交至顯示的時機。 這些圍欄會列在「mdss_fb0_retire」下方 表示影格已開啟。這些圍欄 屬於 sync 追蹤記錄類別的一部分。哪個圍欄對應到 SurfaceFlinger 中的特定事件取決於您的 SOC 和驅動程式堆疊，所以 請與 SOC 供應商合作，瞭解貴機構組織中 追蹤記錄

圖 13 顯示影格顯示時間為 33 毫秒，而非正常的 16.7 毫秒。 通過該切片的一半，該影格應該替換成新的影格 卻沒有查看上一幅畫面並尋找任何內容。

，瞭解如何調查及移除這項存取權。

圖 14 顯示影格的 14.482 毫秒。拆分的兩個影格區段為 33.6 毫秒 相當於兩個影格的顯示內容 (以 60 Hz 算繪為 16.7 毫秒) 相差甚遠)。但是 14.482 毫秒才不會接近 16.7 毫秒 暗示螢幕的管路有問題。

請確實調查柵欄終點的位置，以找出控制的控制項目。

，瞭解如何調查及移除這項存取權。

工作佇列包含 __vsync_retire_work_handler， 啟動狀態從核心來源查看可以看出 Google 文件應用程式。這好像 執行螢幕管道的路徑，必須讓顯示管道盡快執行。是 執行 70 小時以上 (不必長時間排程延遲)，但屬於工作佇列 可能無法準確排定時程

請查看先前的影格，判斷是否有貢獻有時抖動 可能會隨著時間的推移而增加，最終導致錯過期限

，瞭解如何調查及移除這項存取權。

觀眾啟用了 kworker 的可執行線條，因此看不到 如已選取為白色，但統計資料則傳達訊息：排程器有 2.3 毫秒 部分多媒體管道關鍵路徑的錯誤。 繼續操作前，請先移動這個部分的 顯示工作佇列中重要的管道路徑 (以 SCHED_OTHER CFS 執行緒) 至專屬的SCHED_FIFO kthread這個函式需要時間保證工作佇列無法 (且不會 提供額外服務

這是卡頓的原因嗎？很難說出結論。外部 易於診斷的情況，例如因核心鎖定爭用而造成顯示重要畫面 追蹤記錄通常無法說明問題。 這個時基誤差是影格遺失的原因嗎？當然可以。 圍欄時間應為 16.7 毫秒，但影格中所有影格都不十分接近 直到出現掉格的影格考慮到顯示管道與多媒體管道的緊密結合 原先圍欄的時抖動可能會 相框。

在本例中，轉換解決方案 從工作佇列到專屬互連網路的 __vsync_retire_work_handler kthread大幅改善了模型的時基誤差 並減少資源浪費 彈力球後續追蹤記錄會顯示懸停位置非常接近的圍欄時間 到 16.7 毫秒。