Android系統性能調優工具介紹

時間 2019-11-07

原文原文鏈接

經做者受權，發表Tieto某青年牛的一篇《程序員》大做。 html

Android系統性能調優工具介紹

在軟件開發過程當中，想必不少讀者都遇到過系統性能問題。而解決系統性能問題的幾個主要步驟是： java

測評：對系統進行大量有針對性的測試，以獲得合適的測試數據。
分析系統瓶頸：分析測試數據，找到其中的hotspot（熱點，即bottleneck）。
性能優化：對hotspot相關的代碼進行優化。

由上述步驟可知，性能優化的目標對象是hotspot。若是找到的hotspot並不是真正的熱點，則性能優化的結果必然是事倍功半甚至竹籃打水一場空。因此，做爲Android性能調優相關知識的第一部分，本篇首先將向讀者介紹Android平臺中三個重要的性能測試工具，它們能很好得幫助開發者找到hotspot。 python

一Traceview介紹

1.1 Traceview簡介

Traceview是Android平臺特有的數據採集和分析工具，它主要用於分析Android中應用程序的hotspot。Traceview自己只是一個數據分析工具，而數據的採集則須要使用Android SDK中的Debug類或者利用DDMS工具。兩者的用法以下： linux

開發者在一些關鍵代碼段開始前調用Android SDK中Debug類的startMethodTracing函數，並在關鍵代碼段結束前調用stopMethodTracing函數。這兩個函數運行過程當中將採集運行時間內該應用全部線程（注意，只能是Java線程）的函數執行狀況，並將採集數據保存到/mnt/sdcard/下的一個文件中。開發者而後須要利用SDK中的Traceview工具來分析這些數據。
藉助Android SDK中的DDMS工具。DDMS可採集系統中某個正在運行的進程的函數調用信息。對開發者而言，此方法適用於沒有目標應用源代碼的狀況。DDMS工具中Traceview的使用如圖1-1所示。

圖1-1 DDMS中Traceview使用示意圖 android

點擊圖1-1中所示按鈕便可以採集目標進程的數據。當中止採集時，DDMS會自動觸發Traceview工具來瀏覽採集數據。程序員

下面，咱們經過一個示例程序向讀者介紹Debug類以及Traceview的使用。瀏覽器

1.2 Traceview示例分析

示例程序運行時的界面如圖1-2所示：性能優化

圖1-2 示例界面圖架構

圖1-2中： composer

SystraceDemoStringAAA等字樣是TraceviewDemo程序啓動時ListView最初顯示的字符串。
當用戶點擊ListView中的某一項時，Traceview將計算對應項當前顯示的字符串的MD5值40次，而後用計算獲得的MD5字符串替換該項以前顯示的內容。其效果如圖1-2中的「MD5值「箭頭所示。

該示例的關鍵代碼如圖1-3所示：

圖1-3示例代碼

由圖1-3可知：

左圖中，Debug類的startMethodTracing和stopMethodTracing分別在MainAcvtivity的構造方法和onDestroy函數中調用。
onCreate函數中咱們設置了第一個hotspot，即getStringToShow函數。它將解析一個XML文件，並將解析後的字符串保存到mListItem中以做爲ListView的顯示內容。
右圖中，當用戶點擊ListView中的某個Item時，程序在onListItem中將計算MD5值40次，而後用計算結果作爲被點擊項的新字符串顯示。generateMD5中的函數是本示例的第二個hotspot。

如今，咱們用Traceview工具將測試結果文件TraceviewDemo.trace打開。

Traceview界面比較複雜，其UI劃分爲上下兩個面板，即Timeline Panel(時間線面板)和Profile Panel(分析面板)。圖1-4所示爲Timeline Panel界面：

圖1-4 Traceview Timeline Panel示意圖

圖1-4中的Timeline Panel又可細分爲左右兩個Pane：

左邊Pane顯示的是測試數據中所採集的線程信息。由圖1-4可知，本次測試數據採集了main線程，兩個Binder線程和其它系統輔助線程（例如GC線程等）的信息。
右邊Pane所示爲時間線，時間線上是每一個線程測試時間段內所涉及的函數調用信息。這些信息包括函數名、函數執行時間等。由圖1-4可知，main線程對應行的的內容很是豐富，而其餘線程在這段時間內幹得工做則要少得多。
另外，開發者能夠在時間線Pane中移動時間線縱軸。縱軸上邊將顯示當前時間點中某線程正在執行的函數信息。

如今來看Traceview的Profile Panel界面，如圖1-5所示：

圖1-5 TraceviewProfile Panel界面

Profile Panel是Traceview的核心界面，其內涵很是豐富。它主要展現了某個線程（先在Timeline Panel中選擇線程）中各個函數調用的狀況，包括CPU使用時間、調用次數等信息。而這些信息正是查找hotspot的關鍵依據。因此，對開發者而言，必定要了解Profile Panel中各列的含義。筆者總結了其中幾個重要列的做用，如表1-1所示：

表1-1 Profile Panel各列做用說明

列名	描述
Name	該線程運行過程當中所調用的函數名
Incl Cpu Time	某函數佔用的CPU時間，包含內部調用其它函數的CPU時間
Excl Cpu Time	某函數佔用的CPU時間，但不含內部調用其它函數所佔用的CPU時間
Incl Real Time	某函數運行的真實時間（以毫秒爲單位），內含調用其它函數所佔用的真實時間
Excl Real Time	某函數運行的真實時間（以毫秒爲單位），不含調用其它函數所佔用的真實時間
Call+Recur Calls/Total	某函數被調用次數以及遞歸調用佔總調用次數的百分比
Cpu Time/Call	某函數調用CPU時間與調用次數的比。至關於該函數平均執行時間
Real Time/Call	同CPU Time/Call相似，只不過統計單位換成了真實時間

另外，每個Time列還對應有一個用時間百分比來統計的列（如Incl Cpu Time列對應還有一個列名爲Incl Cpu Time %的列，表示以時間百分比來統計的Incl Cpu Time）。

瞭解完Traceview的UI後，如今介紹如何利用Traceview來查找hotspot。

通常而言，hotspot包括兩種類型的函數：

一類是調用次數很少，但每次調用卻須要花費很長時間的函數。在示例代碼中，它就是hotspot 1。
一類是那些自身佔用時間不長，但調用卻很是頻繁的函數。在示例代碼中，它就是hotspot 2。

首先，咱們來查找hotspot 1。

在Profile Panel中，選擇按Cpu Time/Call進行降序排序（從上之下排列，每項的耗費時間由高到低），獲得如圖1-6所示的結果：

圖1-6 按CPU Time/Call降序排列數據

圖1-6中：

MainActivity.onCreate是應用程序中的函數，它耗時爲4618.684。而後，點擊MainActivity.onCreate項，獲得箭頭所示的小圖。
小圖中，Parents一行顯示的是MainActivity.onCreate的調用者，本例中它是performCreate函數。這部分代碼屬於Framework部分。Children行顯示的是MainActivity.onCreate調用的子函數。
在MainActivity.onCreate調用的子函數中，咱們發現getStringsToShow在Incl Cpu Time %一列中佔據了63.3%，它是onCreate子函數耗費時間最長的，並且Calls+Recur Calls/Total列顯示其調用次數爲1，即它僅僅被調用一次了。這個函數是應用程序實現的，因此極有多是一個潛在的Hotspot。
另外，因爲筆者已經知道getStringsToShow是示例應用本身實現的函數，故在圖1-6的大圖中，可直接根據MainActivity.getStringsToShow花費了2921.913CPU時間這個信息來肯定Hotspot就是它。

相對來講，類型1的hotspot比較好找，步驟是先按降序對時間項進行排列（能夠是時間百分比、真實時間或CPU時間），而後查找耗費時間最多的函數。通常而言，先應對應用程序本身實現的函數進行排查，Framework的函數也有多是hotspot，但主因通常仍是在應用自己（例如設置複雜的界面，致使對應XML解析很是慢）。

如今，咱們來看如何查找類型2的hotspot。

點擊Call/Recur Calls/Total列頭，使之按降序排列。關注點放在那些調用頻繁而且佔用資源較多的函數。圖1-7爲降序排列的結果圖。

圖1-7類型2 Hotspot查找過程示意之一

圖1-7所示的運行最頻繁的幾個函數中，咱們發現了幾個懷疑點，由圖中的1和2箭頭標示。

結合代碼，箭頭1所指的函數在代碼中實際並不存在。這是由於代碼中直接訪問了內部類的私有成員，致使java編譯器在編譯時自動生成了這個函數。這個函數的調用次數很是多。因此，爲了提升效率，咱們能夠修改內部類成員的訪問類型定義爲public。不過，該函數的Incl Cpu Time並不高，只有3.2%。
一樣，箭頭2所指部分的函數調用次數也不少，達到了5888屢次。不過它們佔用的時間百分比只有0.9%。

第一次查找的潛在點被排除後，繼續瀏覽數據，獲得如圖1-8所示的結果。

圖1-8 類型2 Hotspot查找過程示意之二

在圖1-8中：

紅框處有兩個重載的MyMD5.getHashString函數調用，它們各運行了368次，並且佔用的CPU時間百分比達到了31.8%和53.2%。很顯然，這2處調用就有優化的餘地，這就是咱們所懷疑的hotspot2。

找到hotspot以後，開發者就須要結合代碼來進行對應的優化了。關於Java代碼優化，讀者可參考以下資料：http://developer.android.com/training/articles/perf-tips.html

整體而言，Hotspot的查找是一個細緻的工做，須要開發者對目標程序的代碼，以及Traceview工具都比較熟悉才行。

1.3 Traceview小結

Traceview工具是Android平臺應用程序性能分析的利器。不過筆者以爲它的UI仍是有些複雜。而且使用時感受流暢度不夠好。

Google官方關於Traceview的介紹可參考如下連接，不過其內容以及較久未更新了。http://developer.android.com/tools/debugging/debugging-tracing.html。

二Systrace介紹

2.1 Systrace簡介

Systrace是Android4.1中新增的性能數據採樣和分析工具。它可幫助開發者收集Android關鍵子系統（如surfaceflinger、WindowManagerService等Framework部分關鍵模塊、服務）的運行信息，從而幫助開發者更直觀的分析系統瓶頸，改進性能。

Systrace的功能包括跟蹤系統的I/O操做、內核工做隊列、CPU負載以及Android各個子系統的運行情況等。在Android平臺中，它主要由3部分組成：

內核部分：Systrace利用了Linux Kernel中的ftrace功能。因此，若是要使用Systrace的話，必須開啓kernel中和ftrace相關的模塊。
數據採集部分：Android定義了一個Trace類。應用程序可利用該類把統計信息輸出給ftrace。同時，Android還有一個atrace程序，它能夠從ftrace中讀取統計信息而後交給數據分析工具來處理。
數據分析工具：Android提供一個systrace.py（python腳本文件，位於Android SDK目錄/tools/systrace中，其內部將調用atrace程序）用來配置數據採集的方式（如採集數據的標籤、輸出文件名等）和收集ftrace統計數據並生成一個結果網頁文件供用戶查看。

從本質上說，Systrace是對Linux Kernel中ftrace的封裝。應用進程須要利用Android提供的Trace類來使用Systrace。Android 4.1爲系統中的幾個關鍵進程和模塊都添加了Systrace功能。以顯示系統中重要模塊Hwcomposer爲例，其代碼中使用Systrace的方法如圖2-1所示：

圖2-1 Hwcomposer模塊Systrace使用示例

圖2-1中，應用程序只要經過三個宏就可以使用Systrace了：

定義ATRACE_TAG：Hwcomposer使用了ATRACE_TAG_GRAPHICS，表示它和Graphics相關。
ATRACE_INIT：用於統計某個變量使用的狀況。下文將見到代碼中」VSYNC」的統計結果。
ATRACE_CALL：用於統計函數的調用狀況。

因爲篇幅關係，關於Trace使用更多的信息請讀者閱讀frameworks/native/include/utils/Trace.h或者android.os.Trace類。下面，咱們經過一個示例來展現Systrace的使用。

2.2 Systrace實例

首先，在PC機上運行以下命令以啓動Systrace，如圖2-2所示：

圖2-2 Systrace操做步驟

執行上述命令後，將獲得一個名爲trace.html的文件（trace.html是默認文件名，讀者也可在命令行中指定其餘文件名）。經過瀏覽器打開此文件，結果如圖2-3所示：

圖 2-3 trace.html內容示意

圖2-3中所示的trace.html頁面內容和Traceview的Timeline Panel很是相似。圖中包含的內容以下：

因爲在systrace.py中指定了-f -l和-i參數，Systrace將生成CPU頻率、負載和狀態相關的信息。它們爲圖2-1中第一個紅框所示。因爲筆者所測手機CPU爲雙核，故圖中有CPU 0和CPU 1之分。爲行文方便，筆者用CPU N來指代CPU的某個核。
「CPU N「所示行對應於整個測試時間內，某個核上運行的進程信息。
「CPU N C-State「所示行爲整個測試時間內，某個CPU狀態的變化。C-State取值見表2-1。
「CPU N Clock Frequency」所示行展現了某個CPU運行的頻率。經過點擊這一行的色塊能夠查看某個時間點上CPU N的運行頻率。
「cpufreq」：該行所示內容和CPU交互式頻率調節器（Interactive Governor）的工做有關。交互式CPU調節器驅動添加了對CPU頻率調節事件的跟蹤。感興趣的讀者不妨閱讀kernel中的include/trace/events/cpufreq_interactive.h文件以瞭解更多的信息。

圖2-1中，CPU信息如下的行就是經過Trace.h提供的宏而添加的統計信息，其中：

VSYNC：這一行的統計信息來自於圖2-1中ATRACE_INIT宏的使用。在Hwcomposer代碼中，ATRACE_INIT宏被用於統計VSYNC[1]的Tick-Tack狀況（即0,1,0,1交錯輸出）。VSYNC行顯示了每次Tick Tack的時間大概都在16ms左右。
因爲Framework代碼也在顯示部分添加了ATRACE_INIT的使用，因此圖中com.example.systracedemo/com.example.systracedemo.MainActivity所示爲應用程序佔用顯示Buffer的Tick-Tack狀況。若是使用時間超過16ms，將致使界面顯示遲滯等現象。
SurfaceFlinger使用了ATRACE_CALL宏，故圖中SurfaceFlinger行展現了其函數調用的CPU耗時狀況（如箭頭1所指，SurfaceFlinger中的onMessageReceived函數的運行信息）。
在圖2-1最下部的方框中，詳細顯示了當前鼠標在時間線中選擇的部分（即SurfaceFlinger中的onMessageReceived）的詳細信息。

表2-1所示爲CPU狀態取值信息：

表2-1 CPU狀態

C-state	描述
C-0	RUN MODE，運行模式。
C-1	STANDBY，就位模式，隨時準備投入運行
C-2	DORMANT，休眠狀態，被喚醒投入運行時有必定的延遲
C-3	SHUTDOWN，關閉狀態，須要有較長的延遲才能進入運行狀態，減小耗電

2.3 Systrace小結

整體來講，Systrace比Traceview用途更普遍，它支持對CPU、Native進程甚至Kernel線程進行性能數據採樣，可幫助開發者對整個系統的性能狀況進行一個詳盡的分析。不過其用法比Traceview要複雜，並且還須要對Kernel作一些配置調整。

Android官方對Systrace也有一些介紹，請讀者閱讀：

http://developer.android.com/tools/debugging/systrace.html

三Oprofile的使用

3.1 Oprofile簡介

Oprofile是另外一個功能更強大的性能數據採集和分析工具，其工做原理以下：

它利用性能計數器(Performance Counter)或者定時器(針對kernel不支持性能計數器的狀況)，經過連續的採樣得到統計數據，從而對內核和用戶空間進程進行性能分析。
以性能計數器爲例，在系統運行過程當中，當某個事件發生時，對應的性能計數器就會自加。當達到計數器的設定值時會產生一箇中斷。Oprofile驅動利用這個中斷來進行採樣統計。經過獲取中斷髮生時PC指針的值以及內核中保存運行的任務的信息等，並把它們轉化成對測評有用的數據。
Oprofile包括內核驅動和用戶空間工具兩個部分，其中：
內核驅動實現了一個oprofilefs虛擬文件系統。它掛載到/dev/oprofile，用來向用戶空間報告數據和接收來自用戶空間的設置。它是用戶空間進程與內核通訊的橋樑。驅動中還包括了與架構相關和通用的驅動，經過它們訪問性能計數器寄存器、收集數據後報告給用戶空間。守護進程用戶從內核接收數據並保存在磁盤上以備分析使用。
在用戶空間提供了兩個工具：oprofiled（做爲守護進程在後臺經過和/dev/oprofile交互以獲取驅動收集的數據）、opcontrol（用戶操做的控制工具，它經過讀寫oprofilefs來控制採樣相關的設置）。

Android默認提供了對Oprofile的支持，其組成包括：

代碼：位於exetrnal/oprofile中。不過，只有編譯類型爲非user的系統纔會使用它。
四個主要工具，即opcontrol，oprofiled、opreport和opimport。開發者只要使用opcontrol和opreport便可。
讀者應該熟練掌握opcontrol和oprofiled工具的做用，咱們此處也總結了它們的用法：
opcontrol：它用來控制採樣過程，好比採樣的開始和結束、採樣的事件類型和頻率等。其內部經過讀寫oprofilefs來實現。opcontrol的經常使用選項如表3-1所示:

表3-1 opcontrol經常使用選項

opcontrol選項	功能
--list-events	列出當前CPU所支持的事件
--setup	對測評進行設置，好比關閉舊的守護進程、掛載oprofilefs
--vmlinux=	設置將要分析的Android內核鏡像文件
--callgraph	設置跟蹤函數調用的層數
--kernel-range=start,end	內核二進制文件起始和結束的虛擬地址
--start/--stop	開始/中止採樣
--event=name:count:unitmask:kernel:user	設置對某事件進行採樣。 Name：事件的名字 Count：採樣時事件發生的次數Unitmask：事件的掩碼（CPU支持的事件以及掩碼見oprofile的文檔） Kernel：是否採樣內核事件 User：是否採樣用戶事件

opreport：opreport是使用採樣數據生成報告的工具，可根據用戶要求生成不一樣的報告。通常用法是「opreport [options] [image]」，其中image指定報告須要顯示的程序的名字（指程序名字、共享庫名字和內核）。image參數可選。不指定它時，opreport將打印全部進程的報告結果。經常使用options如表3-2所示：

表3-2 opreport經常使用選項

opreprt選項	功能
-l	顯示函數調用的符號名字
-g	以調試的形式打印函數符號，包括函數所在文件及行數等。
-c	顯示函數調用堆棧
-o	報告輸出到指定文件

另外，Android提供了一個特別的工具opimport_pull。它可把採樣數據從手機中pull到PC上，並對數據進行一些簡單處理以供opreport使用。因此，在Android平臺上，開發者只要使用opimport_pull了就能夠了。

如今，咱們來看Oprofile的使用實例。

3.2 Oprofile實例

Oprofile的使用大致能夠分紅如下三步：

內核加載oprofile驅動（若是該驅動靜態編譯到內核中，則可略過此步驟）。
配置採樣事件、而後進行採樣。
獲取報告、進行分析，針對分析結果進行改進。

下面分別來看這三個步驟：

3.2.1 Oprofile內核配置

以下所示爲內核配置的示例，如圖3-1所示：

圖3-1 Oprofile內核配置示意

運行Oprofile須要root權限，因此目標設備中最好運行的是userdebug或者engineer版本的Android OS。

3.2.2 Oprofile用戶空間配置

Oprofile用戶空間配置的示例如圖3-2所示。假設當前目錄爲Android源碼根目錄，而且已經初始化Android編譯環境（執行完畢build/envsetup.sh和lunch）。

圖3-2 Oprofile用戶空間配置示意

用戶空間的配置主要經過執行opcontrol命令來完成。而opcontrol內部是經過往oprofilefs傳遞對應的控制參數來完成的。例如圖3-2中「opcontrol --callgraph=16」命令也可經過「echo 16> /dev/oprofile/backtrace_depth」來實現。