如何使用AndroidProfiler中的cpumemorynetwork分析器

這篇文章給大家介紹如何使用AndroidProfiler中的cpumemorynetwork分析器，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

一、 CPU分析器CPU Profiler

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

要打開CPU Profiler，請按照下列步驟操作：

• 點擊 View > Tool Windows > Android Profiler (還可以點擊工具欄的).

• 從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使用情況和線程活動。你會看到類似于下圖的內容

①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 記錄和檢查方法跟蹤

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

① 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)以藍色顯示。下面的圖顯示了一個示例調用圖，并說明了給定方法的自時間、子時間和總時間的概念。關于如何使用自上而下和自下而上檢查痕跡的部分，請繼續看下去

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

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

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

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

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

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

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。

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

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

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

二、 內存分析器memory profiler

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

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

2.1 為什么使用內存分析器

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

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

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

在可能導致性能問題的時間軸中尋找不良的內存分配模式

Dump Java堆，以便在任何時間查看哪些對象正在使用內存。長時間的堆轉儲可以幫助識別內存泄漏。

在正常和極端的用戶交互過程中記錄內存分配，以精確地確定您的代碼在短時間內分配的對象或分配被泄漏的對象。

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

2.2 內存分析器概述

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

① 強制執行垃圾收集事件的按鈕。
② 捕獲堆轉儲的按鈕。
③ 記錄內存分配的按鈕。
④ 放大時間線的按鈕。
⑤ 跳轉到實時內存數據的按鈕。
⑥ 事件時間線顯示活動狀態、用戶輸入事件和屏幕旋轉事件。
⑦ 內存使用時間表，其中包括以下內容：

每個內存類別使用多少內存的堆棧圖，如左邊的y軸和頂部的顏色鍵所示。

虛線表示已分配對象的數量，如右側y軸所示。

每個垃圾收集事件的圖標。

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

• 活動時間表

• 分配對象的數量

• 垃圾收集事件

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

2.3 記錄內存分配

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

分配了哪些對象以及它們使用了多少空間。

在堆棧跟蹤中分配每個對象的位置，其中包括線程。

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

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

分配跟蹤器最多記錄65535個分配。如果您的記錄超出此限制，則只有最近65535個分配將保存在該記錄中。
要檢查分配記錄，請按照下列步驟操作：

瀏覽列表以查找具有非常大的堆計數且可能泄漏的對象，要幫助查找已知類，請單擊類名列標題按字母順序排序。然后單擊一個類名，Instance View 窗格就會顯示在右側，顯示該類的每個實例，如下圖所示。

在Instance View窗格中，單擊一個實例。Call Stack選項卡顯示在下面，顯示了哪個實例被分配在哪個線程中。

在Call Stack選項卡中，單擊任意行可以在編輯器中跳轉到該代碼。

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

• Arrange by class： 根據類名分配。

• Arrange by package：根據包名分配。

• Arrange by callstack: 根據調用堆棧排序

2.4 捕獲堆轉儲

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

您的應用程序分配了哪些類型的對象，以及每個對象的數量。

每個對象使用多少內存

每個對象的引用被保留在你的代碼中。

調用堆棧，用于分配對象的位置（只有在記錄分配時捕獲堆轉儲）。

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

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

要檢查你的堆，請按照下列步驟操作：

瀏覽列表以查找具有異常大堆計數的對象，因為它可能會被泄露。為了幫助查找已知類，請單擊類名列標題以按字母順序排序。然后單擊類名。實例視圖窗格出現在右邊，顯示該類的每個實例，如下圖所示。

在Instance View窗格中，單擊一個實例。 References選項卡顯示在下面，顯示對該對象的所有引用。或者單擊實例名稱旁邊的箭頭以查看其所有字段，然后單擊字段名稱以查看其所有引用。如果要查看某個字段的實例詳細信息，請右鍵單擊該字段，然后選擇Go to Instance。

在References選項卡中，如果識別可能是內存泄漏的引用，請右鍵單擊它，然后選擇Go to Instance.。這將從堆轉儲中選擇相應的實例，顯示您自己的實例數據。

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

在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。在時間軸上，您可以單擊和拖動來選擇②時間軸的一部分來檢查流量。下面的③窗口顯示在時間軸的選定部分中發送和接收的文件，包括文件名、大小、類型、狀態和時間。您可以通過單擊任何列標題來對列表進行排序。您還可以看到時間線所選部分的詳細分解，顯示每個文件被發送或接收的時間。

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

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

3.3 網絡連接疑難解答

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

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

總結

以上所述是小編給大家介紹的AndroidStudio3.0最新 Android Profiler分析器(cpu memory network 分析器)的相關知識，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對億速云網站的支持！

關于如何使用AndroidProfiler中的cpumemorynetwork分析器就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。