Android studio中android profile(性能分析器)的使用



Android Profiler分爲三大模塊: cpu、內存 、網絡。基本的使用在上一篇文章有講到。這裏詳細說一下。

一、 CPU分析器CPU Profiler

CPU分析器可幫助您實時檢查應用程序的CPU使用情況和線程活動,並記錄方法跟蹤,以便您可以優化和調試應用程序的代碼。

要打開CPU Profiler,請按照下列步驟操作:

  • 點擊 View > Tool Windows > Android Profiler (還可以點擊工具欄的image).
  • 從Android Profiler工具欄中選擇要配置的設備和應用程序進程(如果您已通過USB連接設備但未看到它,請確保已啓用USB調試)
  • 單擊CPU時間軸中的任意位置打開CPU Profiler。

1.1 爲什麼要優化CPU的使用

優化CPU使用率有許多優點,例如提供更快更流暢的用戶體驗,並保持設備電池壽命。它還可以幫助您的應用程序在各種較新舊的設備上運行良好,您可以使用CPU分析器在與應用程序交互時監視CPU使用情況和線程活動,但是,有關應用程序執行代碼的更詳細信息,應記錄並檢查方法跟蹤。

對於應用程序進程中的每個線程,您可以找到在一段時間內執行哪些方法以及每個方法在執行期間消耗的CPU資源。您還可以使用方法跟蹤來識別調用者和被調用者,調用者是一種調用另一種方法的方法,被調用方是另一種方法調用的方法。您可以使用此信息來確定哪些方法太頻繁地調用特定資源繁重的任務,就可以嘗試優化應用程序的代碼以避免不必要的工作。

如果要收集詳細的系統級數據,幫助您檢查本地系統進程並解決由丟幀引起的UI jank,則應使用Systrace。或者,如果要導出使用Debug捕獲的.trace文件,則應使用Traceview

1.2 CPU Profiler概述

當您打開CPU分析器時,它會立即開始顯示應用程序的CPU使用情況和線程活動。你會看到類似於下圖的內容
image

如上圖所示,CPU Profiler的默認視圖包括以下內容:

  • ①Event timeline: 顯示您的應用程序在其生命週期中轉換不同狀態的活動,並指示用戶與設備的交互,包括屏幕旋轉事件。要了解有關事件時間軸的更多信息,包括如何啓用它,請閱讀我上一篇文章說到的啓用高級分析
  • ②CPU timeline: 顯示您的應用程序的實時CPU使用率(佔總可用CPU的百分比)以及應用程序使用的線程總數,時間軸還顯示其他進程的CPU使用情況(如系統進程或其他應用程序),所以您可以將其與應用程序的使用情況進行比較。您可以通過沿着時間軸的水平軸移動鼠標來檢查歷史CPU使用率數據。
  • ③Thread activity timeline: 列出屬於您的應用程序進程的每個線程,並使用不同的顏色在時間軸上指示其活動。記錄方法跟蹤後,可以從此時間軸中選擇一個線程,在跟蹤窗格中檢查其數據。
    • 綠色: 線程處於活動狀態或準備好使用CPU。也就是說,它處於”運行”或”可運行”狀態。
    • 黃色: 線程處於活動狀態,但是在完成其工作之前,它正在等待I / O操作(如文件或網絡I / O)。
    • 灰色: 線程正在睡眠,不會消耗任何CPU時間,當線程需要訪問尚未可用的資源時,有時會發生這種情況。要麼線程進入自願性睡眠,要麼內核使線程休眠,直到所需的資源可用。
  • ④Tracing type:允許您選擇以下選項之一來確定分析器如何記錄方法跟蹤。
    • Sampled: 在應用程序執行期間,您可以頻繁地捕獲應用程序的調用堆棧。profiler將捕獲的數據集進行比較,以獲取關於應用程序代碼執行的時間和資源使用信息。基於sampled跟蹤的一個固有問題是,如果您的應用程序在捕獲調用堆棧並在下一次捕獲之前退出該方法,那麼該方法調用不會被分析器記錄。如果您對具有這樣短生命週期的跟蹤方法感興趣,您應該使用工具跟蹤。
    • Instrumented: 在您的應用程序運行時記錄每個方法調用的開始和結束時的時間戳。收集時間戳並與生成方法跟蹤數據進行比較,包括時間信息和CPU使用。請注意,對每種方法進行檢測的開銷會影響運行時性能,並可能影響性能分析,因此對於具有相對較短的生命週期的方法來說,這更加值得注意。此外,如果您的應用程序在短時間內執行大量的方法,profiler可能很快超過它的文件大小限制,進而不能記錄任何進一步的跟蹤數據。
  • ⑤Record button:開始和停止記錄方法跟蹤。要了解更多信息,請繼續看下去

    提示:profiler還報告了Android Studio和Android平臺在你的應用程序過程中添加的線程的CPU使用情況,如JDWP、Profile Saver、Studio:VMStats、Studio:Perfa和Studio:Heartbeat(儘管,在線程活動時間線中顯示的確切名稱可能會有所不同)。這意味着您的應用程序在CPU時間軸上的CPU使用率也會報告這些線程使用的CPU時間。您可以在線程活動時間表中看到這些線程,並監視它們的活動。(但是,由於profiler線程執行native代碼,因此無法爲它們記錄方法跟蹤數據。)Android Studio會報告這些數據,這樣你就可以很容易地識別出線程活動和CPU使用實際上是由你的應用程序代碼引起的。

1.3 記錄和檢查方法跟蹤

要開始記錄方法跟蹤,從下拉菜單中選擇SampledInstrumented類型,然後單擊Record開始進行記錄,完成後點擊Stop recording停止記錄。profiler自動選擇記錄的時間幀,並在方法跟蹤窗格中顯示它的跟蹤信息,如下圖所示。如果要檢查不同線程的方法跟蹤,只需從線程活動時間軸中選擇它。
image

  • ① Selected time frame: 在跟蹤窗格中檢查的記錄時間框架的部分。當您第一次記錄一個方法跟蹤時,CPU分析器將自動選擇您在CPU時間線中記錄的整個長度。如果要檢查僅記錄的時間幀的一部分的方法跟蹤數據,您可以單擊並拖動高亮顯示區域的邊緣來修改它的長度。
  • ②Timestamp: 表示記錄方法跟蹤的開始和結束時間(相對於profiler開始從設備收集CPU使用信息時)。你可以點擊時間戳來自動選擇整個記錄作爲你選定的時間框架——如果你有多個你想要轉換的記錄,這是非常有用的。
  • ③Trace pane:顯示您所選擇的時間框架和線程的方法跟蹤數據。僅當您記錄至少一個方法跟蹤後,此窗格纔會顯示。在此窗格中,您可以選擇如何查看每個堆棧跟蹤(使用跟蹤選項卡)以及如何測量執行時間(使用時間參考下拉菜單)。
  • ④: 選擇顯示爲Top Down tree, Bottom Up tree, Call Chart, or Flame Chart這些類型的圖。您可以在下面的部分中瞭解有關每個跟蹤窗格選項卡的更多信息。
  • 從下拉菜單中選擇以下選項之一,以確定如何測量每個方法調用的時序信息:
    • Wall clock time: 表示實際經過時間。
    • Thread time:計時信息表示實際的消耗時間減去不消耗CPU資源的那段時間的任何部分。對於任何給定的方法,它的線程時間總是小於或等於它的時鐘時間。使用線程時間讓您更好地瞭解給定方法所消耗的線程實際CPU使用量

1.3.1 使用Call Chart選項卡檢查跟蹤

Call Chart選項卡提供一個方法跟蹤的圖形表示,其中一個方法調用(或調用者)的週期和時間在水平軸上表示,而它的callees則顯示在垂直軸上。對系統api的方法調用以橙色顯示,調用您的應用程序自己的方法以綠色顯示,方法調用第三方api(包括java語言api)以藍色顯示。下面的圖顯示了一個示例調用圖,並說明了給定方法的自時間、子時間和總時間的概念。關於如何使用自上而下和自下而上檢查痕跡的部分,請繼續看下去

圖3

提示: 如果想要跳轉到方法的源代碼,請右鍵單擊該方法,然後選擇Jump to Source。這可以從任何窗格選項卡工作。

1.3.2 使用火焰圖表(Flame Chart)選項卡檢查痕跡

火焰圖選項卡提供了一個反向調用圖表,聚合了相同的調用堆棧。也就是說,收集相同的調用序列的相同方法被收集並表示爲火焰圖中的一個較長的欄(而不是將它們顯示爲多個更短的條,如調用圖所示)。這樣就更容易看出哪些方法消耗的時間最多。然而,這也意味着橫軸不再表示時間軸,相反,它表示每個方法執行的相對時間。

爲了幫助說明這個概念,考慮下面圖4中的調用圖表。注意,方法D對B(B1、B2和B3)進行多次調用,其中一些調用B對C(C1和C3)進行調用。

image

因爲B1、B2和B3共享相同的序列調用者(A→D→B)聚合,如下所示。同樣,C1和C3聚合,因爲它們共享相同的序列調用者(A→D→B→C)注意不包括C2,因爲它有不同的調用者序列(A→D→C)。

image

聚合方法調用用於創建flame 圖,如下圖所示。注意,對於任何給定的方法調用,在flame圖中,消耗最多CPU時間的callees首先出現。
image

1.3.3 使用自上而下和自下而上檢查

Top Down選項卡顯示方法調用的列表,擴展方法節點顯示其callees。下圖顯示了上面的圖3中調用圖的頂部向下圖。圖中的每個箭頭都是從調用者到callee。

下圖所示,在頂部的down選項卡中擴展方法A的節點將顯示它的callees、方法B和D。在此之後,擴展方法D的節點將暴露它的callees、方法B和C,等等。與火焰圖選項卡類似,頂部向下的樹聚合跟蹤信息,用於共享相同調用堆棧的相同方法。也就是說,火焰圖標籤提供了頂部下標籤的圖形表示。

Top Down選項卡提供以下信息,以幫助描述在每個方法調用上花費的CPU時間(在選定的時間段內,時間也代表線程總時間的百分比):

  • Self:方法調用用於執行自己的代碼而不是它的callees的時間量,如上面的圖3所示。
  • Children:方法調用花費的時間用於執行其被調用者,而不是其自己的代碼,如圖3中的方法D所示。
  • Total:方法的Self和Children的時間的總和。這表示應用程序執行方法調用的總時間量,如圖3所示的方法D。
    image

Bottom Up選項卡顯示一個方法調用列表,擴展方法的節點顯示其調用者。使用上圖所示的例子中,下圖提供了一個自下而上方法C .在自下而上的樹中打開方法C的節點,顯示每個獨特的調用者,方法B和d .注意,雖然B兩次調用C,B當擴大節點只出現一次自下而上方法C的樹。再此之後,展開節點B顯示其調用者方法A和D.

image

Bottom Up選項卡對於那些消耗最多(或最少)CPU時間的方法的排序方法很有用。您可以檢查每個節點,以確定哪些調用者在調用這些方法上花費最多的CPU時間。與上面的樹相比,底部樹中每個方法的定時信息都是在每棵樹的頂部(頂部節點)的方法。在記錄期間,CPU時間也被表示爲線程總時間的百分比。下表有助於解釋如何解釋頂級節點及其調用方方法(子節點)的定時信息。

名稱 Self Children Total
自下而上樹頂部的方法(頂層節點) 表示用於執行其自己的代碼而不是其callees的方法的總時間。與上面的樹相比,這個時間信息表示在記錄期間對該方法的所有調用的總和。 表示用於執行callees而不是自己的代碼的總時間。與上面的樹相比,這個時間信息表示在記錄期間對該方法的callees調用的所有調用的總和。 Self時間和Children的時間總和
Caller 方法 (子節點) 表示調用者調用callee的總時間。使用上圖中的底向上樹作爲例子,方法B的自我時間將等於每個方法C調用時的Self時間的總和。 表示調用者調用的callee的總子時間。在上圖中使用底部向上的樹爲例,方法B的孩子時間將等於每個方法C調用時執行方法C的總和。 Self時間和Children的時間總和

對於給定的記錄,當profiler達到文件大小限制時,Android Studio停止收集新數據(但是這並沒有停止記錄)。這種情況在執行檢測跟蹤時通常會發生得更快,因爲這種類型的跟蹤會在較短的時間內收集更多的數據,而不是取樣跟蹤。如果將檢查時間幀擴展到在到達限制後發生的記錄期間,那麼跟蹤窗格中的計時數據不會發生變化(因爲沒有可用的新數據)。此外,當您只選擇沒有可用數據的記錄的部分時,跟蹤窗格將顯示NaN用於計時信息。

二、 內存分析器memory profiler

內存分析器是Android Profiler中的一個組件,它可以幫助您識別內存泄漏和內存溢出,從而導致存根、凍結甚至應用程序崩潰。它顯示了應用程序內存使用的實時圖,讓您捕獲堆轉儲、強制垃圾收集和跟蹤內存分配。

要打開內存分析器和cpu檢查器一樣,就在隔壁。

2.1 爲什麼使用內存分析器

Android提供了一個託管內存環境——當它確定你的應用不再使用某些對象時,垃圾收集器會將未使用的內存釋放回堆。在所有Android版本的某個點上,系統必須短暫地暫停代碼。大多數時候,停頓是不可察覺的。但是,如果你的應用程序分配內存的速度快於系統收集的速度,你的應用程序可能會被延遲,而收集器釋放了足夠的內存來滿足你的分配。延遲可能會導致應用程序跳過幀並導致明顯的慢速。

即使你的應用程序沒有表現出緩慢,如果它泄露了內存,它仍然可以保留那個內存,即使它在後臺。通過強制不必要的垃圾收集事件,這種行爲可以降低系統內存性能的其他部分。最終,系統不得不殺死你的應用程序來回收內存。然後當用戶返回到你的應用程序時,它必須重新啓動。

爲了幫助防止這些問題,您應該使用內存分析器來執行以下操作:

  • 在可能導致性能問題的時間軸中尋找不良的內存分配模式
  • Dump Java堆,以便在任何時間查看哪些對象正在使用內存。長時間的堆轉儲可以幫助識別內存泄漏。
  • 在正常和極端的用戶交互過程中記錄內存分配,以精確地確定您的代碼在短時間內分配的對象或分配被泄漏的對象。

有關可以減少應用程序內存使用的編程實踐的信息,請參閱管理應用程序的內存

2.2 內存分析器概述

image

如上圖所示,內存分析器的默認視圖包括以下內容:

  • ① 強制執行垃圾收集事件的按鈕。
  • ② 捕獲堆轉儲的按鈕。
  • ③ 記錄內存分配的按鈕。
  • ④ 放大時間線的按鈕。
  • ⑤ 跳轉到實時內存數據的按鈕。
  • ⑥ 事件時間線顯示活動狀態、用戶輸入事件和屏幕旋轉事件。
  • ⑦ 內存使用時間表,其中包括以下內容:
    • 每個內存類別使用多少內存的堆棧圖,如左邊的y軸和頂部的顏色鍵所示。
    • 虛線表示已分配對象的數量,如右側y軸所示。
    • 每個垃圾收集事件的圖標。

但是,默認情況下並不是所有的分析數據都可見。如果您看到一條消息,說“高級分析不可用於所選進程”,則需要啓用高級分析以查看以下內容:

  • 活動時間表
  • 分配對象的數量
  • 垃圾收集事件

提示: 與之前的Android監控工具相比,新的內存分析器記錄了你的內存使用情況,所以看起來你的內存使用量會更高。內存分析器監視一些額外的類別,這些類別增加了總數,但如果您只關心Java堆內存,那麼“Java”的數字應該與上一個Android監視器的值類似。新的號碼記錄了從Zygote分派到應用程序的Java堆中的所有物理內存頁面,這準確表示您的應用程序實際使用多少物理內存。

2.3 記錄內存分配

查看堆轉儲時,查看分配了多少內存的快照很有用,它不會顯示如何分配內存。爲此,您需要記錄內存分配。完成記錄會話後,您可以看到以下記錄的持續時間:

  • 分配了哪些對象以及它們使用了多少空間。
  • 在堆棧跟蹤中分配每個對象的位置,其中包括線程。

image

要查看應用程序的內存分配,請單擊內存分析器工具欄中的Record memory allocations。當它記錄時,與你的應用程序進行交互,以引起內存溢出或內存泄漏。完成後,單擊Stop recording

分配的對象列表出現在時間軸下面,按類名稱分組,按堆計數排序,如上圖所示。

分配跟蹤器最多記錄65535個分配。如果您的記錄超出此限制,則只有最近65535個分配將保存在該記錄中。

要檢查分配記錄,請按照下列步驟操作:

  • 瀏覽列表以查找具有非常大的堆計數且可能泄漏的對象,要幫助查找已知類,請單擊類名列標題按字母順序排序。然後單擊一個類名,Instance View 窗格就會顯示在右側,顯示該類的每個實例,如下圖所示。
  • Instance View窗格中,單擊一個實例。Call Stack選項卡顯示在下面,顯示了哪個實例被分配在哪個線程中。
  • Call Stack選項卡中,單擊任意行可以在編輯器中跳轉到該代碼。

image

默認情況下,列表是按類名排列的。在列表的頂部,您可以使用右下拉菜單在列表之間切換:

  • Arrange by class: 根據類名分配。
  • Arrange by package:根據包名分配。
  • Arrange by callstack: 根據調用堆棧排序

2.4 捕獲堆轉儲

堆轉儲顯示在捕獲堆轉儲時應用程序正在使用內存的對象。特別是在擴展用戶會話之後,堆轉儲可以通過顯示仍然在內存中的對象來幫助識別內存泄漏。捕獲堆轉儲後,可以查看以下內容:

  • 您的應用程序分配了哪些類型的對象,以及每個對象的數量。
  • 每個對象使用多少內存
  • 每個對象的引用被保留在你的代碼中。
  • 調用堆棧,用於分配對象的位置(只有在記錄分配時捕獲堆轉儲)。

圖4

要捕獲堆轉儲,單擊Memory-Profiler工具欄中的dump Java堆image。在轉儲堆時,Java內存的數量可能會暫時增加。這是正常的,因爲堆轉儲發生在與應用程序相同的進程中,需要一些內存來收集數據。

堆轉儲出現在內存時間軸下方,顯示堆中的所有類類型,如上圖所示。

要檢查你的堆,請按照下列步驟操作:

  • 瀏覽列表以查找具有異常大堆計數的對象,因爲它可能會被泄露。爲了幫助查找已知類,請單擊類名列標題以按字母順序排序。然後單擊類名。實例視圖窗格出現在右邊,顯示該類的每個實例,如下圖所示。
  • Instance View窗格中,單擊一個實例。 References選項卡顯示在下面,顯示對該對象的所有引用。或者單擊實例名稱旁邊的箭頭以查看其所有字段,然後單擊字段名稱以查看其所有引用。如果要查看某個字段的實例詳細信息,請右鍵單擊該字段,然後選擇Go to Instance
  • References選項卡中,如果識別可能是內存泄漏的引用,請右鍵單擊它,然後選擇Go to Instance.。這將從堆轉儲中選擇相應的實例,顯示您自己的實例數據。

默認情況下,堆轉儲不會顯示每個已分配對象的堆棧跟蹤。要獲取堆棧跟蹤,您必須在單擊轉儲Java堆之前開始記錄內存分配。如果您這樣做,您可以在實例視圖中選擇一個實例,並在References選項卡旁邊看到Call Stack選項卡,如下圖所示。但是,在開始記錄分配之前,可能已經分配了一些對象,因此這些對象無法使用調用堆棧。包含一個調用堆棧的實例在圖標上有一個stack標記image

image

在classes列表中,您可以看到以下信息:

  • Heap Count: 堆中的實例數。
  • Shallow Size: 此堆中所有實例的總大小(以字節爲單位)。
  • Retained Size: 這個類的所有實例(以字節爲單位)保留的內存總大小。

在類列表的頂部,可以使用左下拉列表在以下堆轉儲之間切換:

  • Default heap: 當系統沒有指定堆時。
  • App heap: 應用程序分配內存的主堆。
  • Image heap: 系統引導映像,包含在引導期間預加載的類。這裏的分配保證永遠不會移動或離開。
  • Zygote heap: Android系統中分發應用程序進程的寫時複製堆

默認情況下,列表按保留大小列排序。您可以單擊任何列標題來更改列表的排序方式。

在Instance View中,每個實例包括以下內容:

  • Depth:從任何GC根到所選實例的跳數最短。
  • Shallow Size:此實例的大小。
  • Retained Size:此實例支配的內存大小(根據支配者樹)。

三、 網絡分析器(Network Profiler)

網絡分析器在時間軸上顯示實時網絡活動,顯示發送和接收的數據,以及當前連接的數量。這讓您可以檢查應用程序如何和何時傳輸數據,並適當地優化底層代碼。

打開面板的步驟和上面的幾乎一致。

3.1 爲什麼要使用網絡分析器

當應用程序向網絡發出請求時,設備必須使用耗電的移動或WiFi無線電來發送和接收數據包。接收器不僅使用電力傳輸數據,而且還使用額外的電源打開和保持喚醒。

使用網絡分析器,您可以查找頻繁的、短的網絡活動高峯,這意味着您的應用程序要求網絡經常打開,或者長時間保持喚醒,以處理許多短的請求。這一模式表明,您可以通過批處理網絡請求來優化應用程序,以改善電池性能,從而減少網絡必須打開或接收數據的次數。這也使得網絡可以切換到低功率模式,以節省電池的時間間隔。

有關優化應用程序網絡活動的技術的更多信息,請參閱 Reducing Network Battery Drain

3.2 網絡分析器概述

在窗口的頂部,您可以看到事件時間線和①無線電電源狀態(high/low)和wi-fi。在時間軸上,您可以單擊和拖動來選擇②時間軸的一部分來檢查流量。下面的③窗口顯示在時間軸的選定部分中發送和接收的文件,包括文件名、大小、類型、狀態和時間。您可以通過單擊任何列標題來對列表進行排序。您還可以看到時間線所選部分的詳細分解,顯示每個文件被髮送或接收的時間。

單擊連接的名稱,查看所選文件發送或接收的詳細信息。單擊④選項卡查看響應數據、頭信息或調用堆棧。

image

提示:您必須啓用高級概要分析來選擇時間軸的一部分來檢查,查看發送和接收的文件的列表,或者查看所選文件發送或接收的詳細信息。爲了啓用高級分析,請查看上一篇文章

3.3 網絡連接疑難解答

如果網絡分析器檢測到流量值,但無法識別任何支持的網絡請求。您將收到以下錯誤消息:”Network Profiling Data Unavailable: There is no information for the network traffic you’ve selected.”

目前,網絡分析器只支持HttpURLConnection和OkHttp庫。如果您的應用程序使用另一個網絡連接庫,那麼您可能無法在網絡分析器中查看您的網絡活動。如果您已經收到了這個錯誤消息,但是您的應用程序確實使用HttpURLConnection或OkHttp,請報告錯誤,以便我們可以調查這個問題。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章