檢查追蹤記錄

CPU 分析器的追蹤記錄檢視畫面可讓您查看已記錄追蹤記錄的資訊。

如需方法追蹤記錄和函式追蹤記錄,您可查看「Threads」時間軸中的「Call Chart」,以及「Analysis」窗格中的「Flame Chart」、「Top Down」、「Bottom Up」,和「Events」分頁。針對呼叫堆疊框,您可以查看程式碼中執行的部分,以及叫用的原因。針對系統追蹤記錄,您可以直接在「Threads」時間軸查看「Trace Events」,以及「Analysis」 窗格的「Flame Chart」、「Top Down」、「Bottom Up」,以及「Events」分頁。

滑鼠和鍵盤快速鍵可讓您更輕鬆地瀏覽「Call Chart」或「Trace Events」

使用「Call Chart」檢查追蹤記錄

「Call Chart」可透過圖形呈現方法追蹤或函式追蹤,其中水平軸表示呼叫的時間範圍和時間,垂直軸表示的是被呼叫端。傳送至系統 API 的呼叫會以橘色顯示,向應用程式專屬方法的呼叫顯示為綠色,而對第三方 API (包括 Java 語言 API) 的呼叫會以藍色顯示。圖 4 顯示了呼叫圖範例,以及特定方法或函式的自身時間、子項時間和總時間概念。如要進一步瞭解這些概念,請參閱使用「Top Down」與「Bottom Up」檢查的追蹤

圖 1. 呼叫圖範例說明了方法 D 的自身時間、子項時間和總時間。

提示:如要跳出方法或函式的原始碼,請在該函式上按一下滑鼠右鍵,然後選取「Jump to Source」。可在任一「Analysis」窗格分頁中執行這項操作。

使用「Flame Chart」分頁檢查追蹤記錄

「Flame Chart」分頁會提供反轉的呼叫圖,以聚合相同的呼叫堆疊。也就是說,共享相同呼叫者順序的相同方法或函式會被收集起來,並在火焰圖中以一個長條表示(而非如同呼叫圖的多個短條)。如此一來,您就能更輕鬆地查看哪些方法或函式花費的時間最多。但這也表示水平軸並不代表時間軸;而是指出每個方法或函式執行的相對時間。

建議您查看圖 2 的呼叫圖,來瞭解這個概念。請注意,方法 D 向 B 發出多次呼叫 (B1、B2 和 B3),以及部分 D 對 B 發出的呼叫都會呼叫 C (C1 和 C3)。

圖 2. 具多個方法呼叫的呼叫圖,這些方法共享一個常見的呼叫端序列。

因為 B1、B2 和 B3 會共用相同的呼叫端序列 (A → D → B),如圖 3 所示。同樣地,C1 和 C3 也會累加在一起,因爲共用相同的呼叫端序列 (A → D → B → C);請留意到 C2 包含不同的呼叫端順序 (A → D → C),因此未包含在內。

圖 3. 聚合共用相同呼叫堆疊的相同方法。

使用聚合呼叫建立火焰圖,如圖 4 所示。請注意,對於火焰圖中的特定呼叫,會優先佔用最多 CPU 時間的呼叫端。

圖 4. 圖 5 中呼叫圖的火焰示意圖。

「Top Down」和「Bottom Up」檢查追蹤記錄

「Top Down」分頁會列出呼叫,該清單可展開方法或函式節點以顯示受呼叫端。圖 5 顯示圖 1 中呼叫圖的「Top Down」圖。圖表中的每個箭頭分別指向呼叫端和受呼叫端。

如圖 5 所示,在「Top Down」 分頁中展開方法 A 的節點,即可顯示其受呼叫端、方法 B 和 D。之後,延伸方法 D 的節點會公開其受呼叫端、方法 B 和 C 等。類似於「Flame Chart」分頁,「Top Down」樹狀結構會聚集共用相同呼叫堆疊的相同方法的追蹤記錄資訊。也就是說,「Flame Chart」分頁以圖形的方式呈現「Top Down」分頁。

「Top Down」分頁提供以下資訊,以說明每個呼叫所消耗的 CPU 作業時間 (時間也會以執行緒在所選範圍內的總時間百分比表示):

  • 「Self」方法或函式呼叫執行專屬程式碼的時間,而非受呼叫端的時間,如圖 1 中方法 D 所示。
  • 「Children」方法或函式呼叫執行受呼叫端的時間,而非其自身程式碼的時間,如圖 1 中方法 D 所示。
  • 「Total」:該方法「Self」和「Children」的時間總和。這代表應用程式執行呼叫的總時間,如圖 1 中方法 D 所示。

圖 5. 「Top Down」樹狀圖。

圖 6. 圖 5 中方法 C 的「Bottom Up」樹狀圖。

「Bottom Up」分頁會顯示呼叫,列出展開函式或方法節點後會顯示呼叫端。使用圖 5 中顯示的追蹤記錄範例,圖 6 提供了方法 C 的「Bottom Up」樹狀圖。在「Bottom Up」樹狀圖中開啟方法 C 的節點,會顯示各自不重複的呼叫端,亦即方法 B 和 D。請注意,雖然 B 呼叫了 C 兩次,但 B 在「Bottom Up」樹狀圖中展開方法 C 的節點時只會出現一次。之後,展開 B 節點即可顯示呼叫端 A 和方法 D。

「Bottom Up」分頁可用來依照耗費最多(或最少)CPU 作業時間將方法或函式排序。您可以查看每個節點,以判斷哪些呼叫端花費最多的 CPU 時間叫用這些方法或函式。相較於「Top Down」樹狀結構,「Bottom Up」樹狀結構每種方法或函式的時間資訊指的是每個樹狀結構頂端的方法 (頂端節點)。CPU 作業時間也代表記錄在錄音期間的總使用時間百分比。下表說明如何解讀熱門節點及其呼叫端 (子節點) 的時間資訊。

自身時間 子項時間 總時間
在「Bottom Up」樹狀圖頂端 (頂端節點) 的方法或函式 代表方法或函式執行程式碼 (而非受呼叫者) 的總時間長度。相較於「Top Down」樹狀圖,此時間資訊代表在記錄期間,對這個方法或函式發出的所有呼叫總數。 代表方法或函式執行呼叫端的總時間長度,而非其程式碼。相較於「Top Down」樹狀圖,這項時間資訊代表在這段錄製期間,對這個方法或函式的呼叫端的所有呼叫總和。 自身時間和子項時間的總和。
呼叫端 (子節點) 代表受呼叫者被呼叫端呼叫的總時間。以圖 6 的「Bottom Up」樹狀圖為例,方法 B 的自身時間將等於方法 C 被 B 呼叫時,每次執行的自身時間總和。 代表呼叫端叫用時受呼叫者的子項總時長。以圖 6 的「Bottom Up」為例,方法 B 的子項時間將等於方法 C 被 B 呼叫時,每次執行的子項時間總和。 自身時間和子項時間的總和。

注意:針對錄音檔,只要 Studio 的檔案大小達到該上限,Android Studio 就會停止收集新資料 (但並不會停止錄製)。執行追蹤記錄時,通常會更快完成這項作業,因為相較於取樣追蹤記錄,這種類型的追蹤記錄會在較短的時間內收集更多資料。如果您將檢查時間延伸至上限後產生的記錄時段,追蹤記錄窗格中的時間資料並不會改變 (因為沒有可用的新資料)。此外,如果您選取的記錄檔資料中沒有可用的資料,追蹤記錄窗格會顯示時間資訊的「NaN」

使用「Events」表格檢查追蹤記錄

「Events」表格會列出目前選取的執行緒的所有呼叫。您可以按一下欄標題來排序資料欄。選取表格中的某一列,即可前往時間軸的指定開始時間和結束時間。這可讓您在時間軸上精確找出事件。

圖 7. 在「Analysis」窗格中查看「Events」分頁。

檢查呼叫堆疊框

呼叫有助於瞭解程式碼的哪些部分已執行,以及叫用的原因。如果為 Java/Kotlin 程式收集呼叫堆疊的錄音範例,則呼叫堆疊通常包含 Java/Kotlin 程式碼,以及 JNI 原生程式碼、Java 虛擬機器的影格 (例如,android::AndroidRuntime::start) 和系統核心 ([kernel.kallsyms]+offset)。這是因為 Java/Kotlin 程式通常是透過 Java 虛擬機器執行。必須提供原生程式碼才能執行程式,程式也必須與系統和硬體通訊。分析器會呈現這些影格以確保準確;但根據您的調查,您可能會 (或可能不會) 認為這些額外呼叫框架實用。分析器可讓您收合不感興趣的影格,以便隱藏與調查無關的資訊。

在下方範例中,下列追蹤記錄有許多標示為 [kernel.kallsyms]+offset 的影格,但這些功能目前對開發作業沒有幫助。

呼叫追蹤範例

如要將這些頁框收合為單一項目,請從工具列中選取「Collapse frames」按鈕、選擇收合的路徑,然後選取「Apply」按鈕套用變更。在這個範例中,路徑為 [kernel.kallsyms]

Simpleperf 選單範例

此動作會在面板和右側面板中收合與所選路徑相對應的頁框,如下所示。

Simpleperf 收合頁框的範例

檢查系統追蹤記錄

檢查系統追蹤記錄時,您可以在「Threads」 時間軸中查看「Trace Events」,查看每個執行緒的詳細事件資料。將滑鼠遊標懸停在事件上,即可查看事件名稱和各狀態的使用時間。點擊一個事件,即可在「Analysis」窗格中查看更多資訊。

檢查系統追蹤記錄:CPU 核心

除了 CPU 排程資料之外,系統追蹤記錄也包含依核心區分的 CPU 頻率。這裡會顯示每個核心上的活動量,或許能讓您瞭解新型行動處理器中屬於「大」或「小」的核心

圖 8. 查看轉譯執行緒的 CPU 活動和追蹤記錄事件。

「CPU Cores」窗格 (如圖 8 所示) 會顯示每個核心排定的執行緒活動。將滑鼠游標懸停在執行緒活動上,即可查看這個核心在特定時間執行的執行緒。

如要進一步瞭解如何檢查系統追蹤的資訊,請參閱 systrace 說明文件的「調查 UI 效能問題」。

檢查系統追蹤:影格轉譯時間軸

您可以查看應用程式讓主執行緒和RenderThread 上轉譯每個影格需要的時間,調查造成 UI jank 和低影格速率的瓶頸。如要瞭解如何使用系統追蹤記錄來調查並降低 UI jank,請參閱 UI jank 偵測

檢查系統追蹤記錄:程序記憶體 (RSS)

針對部署至 Android 9 或以上版本裝置的應用程式,「Process Memory (RSS)」區段會顯示應用程式目前使用的實體記憶體量。

圖 9.查看分析器中的實體記憶體。

總計

這是程序目前使用的實體記憶體總量。在 Unix 系統上則稱為「居民集大小」,是匿名分配、檔案對應和共用記憶體分配的所有記憶體組合。

Windows 開發人員的「居民集大小」與「工作集大小」相似。

已分配

這個計數器會追蹤目前程序的一般記憶體分配作業實際使用了多少記憶體。這些是去識別化 (不由特定檔案支援) 與不公開 (未共用) 的配置。在大部分的應用程式中,這些項目由堆積分配量 (使用 mallocnew) 和堆疊記憶體組成。從實體記憶體替換時,這些配置會寫入系統替換檔案。

檔案對應

這個計數器會追蹤程序用於檔案對應的實體記憶體量,也就是記憶體記憶體管理員,從檔案對應到記憶體所在地區的記憶體。

分享

這個計數器會追蹤有多少實體記憶體在程序和系統中的其他程序之間共用記憶體。