Android應用最佳化（6）工具篇，android應用工具篇

Android應用最佳化（6）工具篇，android應用工具篇

本篇介紹幾個Android上用於進行效能分析的工具，都是SDK內建的，每個都夠強大夠大家細細分析使用。

先來說說TraceView

這個工具SDK文檔中說的比較隨意，就大概說了一下有什麼。但是真正要使用它來分析問題還需要詳細的瞭解一下怎麼用並且快速的定位到問題所在。

下面將分四部分來講：

首先是基本操作：

1、擷取trace資訊，這個有兩種辦法，一是在DDMS介面選擇需要檢查的進程，然後再點擊Start Method Profiling，會出來一個模式選擇框，大家就選擇預設的Sample based profiling就好了，Trace base那個由於追蹤了每個方法會導致介面卡頓會影響測試效果。結束點擊同一個按鈕Stop即可。

2、這個在SDK的文檔上說的比較多，在需要測試的代碼中添加下面兩個方法，把trace寫入到sdcard上的檔案中，然後可以拷貝到電腦上用命名行來啟動Traceview查看這個檔案，得到和第一種方式一樣的視圖。

    // start tracing to "/sdcard/calc.trace"    Debug.startMethodTracing("calc");    // ...    // stop tracing    Debug.stopMethodTracing();

註：trace檔案還可以藉助 dmtracedump產生另外一種堆棧調用的樹形視圖，這個後面講。

然後是視圖結構：

前面兩個操作得到的視圖入所示，分為三個地區，1地區中顯示的是各個線程、2地區是時間軸，這裡顯示的是各個方法執行的時間上的關係、3地區是方法詳情，展示的是各個方法的調用情況以及一些參數資訊。選擇時間地區內會執行放大操作將所選擇地區放到顯示，雙擊右上方或者時間軸可以換成原來大小，但是這個基本不會使用因為即使放大了也很難看清楚每個方法，一般都是直接看地區3。

地區3用來分析每個方法的CPU和實際耗時，那麼就必須對這些指數逐一認識。

Name：這個很明顯就是各個方法名，展開後包括Parents和Children，Parents是調用者，Children是此方法中調用的其他方法以及自身，表明的就是方法堆棧調用資訊。

Incl Cpu Time%和Incl Cpu Time：這兩個都是說的這個方法體整體佔用CPU的時間和比例，這個比例的分母是誰呢？來看下面這個

這個0（toplevel）就是代表的這個監測過程的整個trace，所有的百分比都是根據它計算出來的，後面就只需要解釋不帶%的數值就行了。

繼續來看，展開之後可以看到Parents和Children各個方法的時間和佔比，對於Parents來說就是當前方法在這個父方法中所佔的時間和比例，Children各個子項就是子方法在本方法總的執行時間中所佔數值和比例。

Excl Cpu Time%和Excl Cpu Time：除外的CPU時間，這個怎麼說呢，這個還是猜測，有些情況下這個數值如地區3的圖中兩個紅色的地區，數值是一樣的，也就是說這個時間是方法本身除調用子方法所花費的時間，但是有時候這個數值時沒有關係的，self為零Excl Cpu Time也是有值的，我猜測應該是進程調度，方法調用等其他系統處理所耗費的CPU時間。如果這個值過大比例很高，那麼耗時問題主要就在本方法體內了，子方法耗時相對較少。

對應的上面的參數都有一組叫Real的參數，這個所指的是實際的已耗用時間非CPU時間（包括CPU時間，切換時間和等待時間，但是Looper.loop, NativeStart.main, Method.invoke等幾個方法的時間比較詭異，本人還沒弄明白為什麼！），與地區1時間軸上的時間區間和長度是一致的。

Calls+RecurCalls/Total：這是表示該方法調用的次數和遞迴調用的次數。

Cpu Time/Call：該方法調用一次佔用的Cpu時間。

Real Time/Call：該方法執行一次實際所花時間。

快速定位問題：

通過上述對各個參數的解釋，相信大家心裡都有一個直觀的意識，那就是只需要關注Real Time的有關參數並且Real Time/Call值較高或者Calls+RecurCalls/Total較高的都是需要重點關注的對象，因為單個方法執行耗時大部分情況需要最佳化的，而多次調用需要看看流程中是否可以減少調用次數。

一般來說Android上一個功能的實現出現了效能問題，可以將出現問題的操作功能這樣分析一下，直接將Incl Real Time按大小排列一下，挑幾個大頭來仔細看看（最開始的幾個比如Looper.loop, NativeStart.main, Method.invoke的可以忽略，這幾個耗時也是後面的操作造成的，也不要漫無目的的找要針對自己分析的問題來，本文舉例是啟動速度的有很多系統方法的幹擾，查滑動卡就簡單多了。）看看調用次數較多的是否與設計邏輯不一致或者可以減少，看看執行時間較長的方法是不是有執行資料庫操作啊、儲存讀寫啊、建立Bitmap啊，或者解析很複雜的布局等等。

堆棧樹形視圖結構：

這是需要用到SDK中的dmtracedump工具，怎奈我自己試了很多次都無法讀取產生的trace檔案，沒辦法在這說經驗了，給大家推薦一個文章吧：http://blog.csdn.net/yiyaaixuexi/article/details/6716884

本人實際使用和寫這篇部落格有參考此篇http://www.oschina.net/news/56500/traceview-android

然後是systrace

這個是分析系統繪製效能的工具，比如動畫為什麼掉幀啦不流暢等問題。systrace它把應用和整個系統的運行情況放在同一個時間軸上分析更加直觀。

首先說一下基本操作，在DDMS介面左邊的Devices視窗中選擇Capture system wide trace using Android systrace這個，會彈出一個Android System Trace的選擇框，裡面需要配置此次收集的參數：trace檔案儲存體的路徑，時間長度以及緩衝的大小，最後是最重要的就是我們需要關注tags，一般來說需要根據我們分析的情境設想一下可能的原因來選擇（比如我們分析動畫掉幀的情況就可以選上Graphics、ResourceLoading、Dalvik VM和Synchronization標籤），設定之後ok就進行收集狀態，這時做我們需要分析的操作得到一個trace.html檔案，在Chrome瀏覽器中輸入chrome://tracing/，load產生的tram.html檔案即可。

先來看一個列表滑動正常的測試代碼得到的systrace圖：

可以簡要的看一下這個圖中包含了一些什麼內容，這張圖中，看看VSYNC和surfaceflinger的繪製間隔都保持在16.6ms以內並且很好的對應了起來，這樣的繪製時能滿足60幀的。但是如果如所示就很不樂觀了，下面我故意在Adapter的getView方法中放置了建立Bitmap的操作使得listview滑動起來卡頓，得到了如下的systrace圖：

看上面這個簡單的例子，很容易看出來由於decodeBitmap和GC，使得繪製間隔已經不是原來的16.7ms了，目前是34.33ms，也就是說現在這個只有30幀左右了，理所當然的看上去就會有卡頓的效果了，改也很好改，將decodeBitmap過程放到子線程中並且做緩衝處理減少GC。

接下來提一下Allocation Tracker

這個東西顧名思義啊，就是跟蹤記憶體配置的，在DDMS中選擇一個進程然後在Allocation Tracker視窗頁面中點擊Start Tracking，就進入了跟蹤狀態，執行一個操作之後，點擊get Allocatios就會在下面列出當前記憶體配置的情況如所示：

這裡展示了當前分配記憶體配置的序號、大小、類型、線程號、內容對象所在的類和方法。比如我在主線程中建立了一張bitmap，就會看到這樣的記錄：

這樣就很容易跟蹤當前操作地區是否有不必要的記憶體情況，這個工具列出的是應用運行時整個系統分配記憶體的情況包括framework部分的執行，特別適合分析當前應用程式運行記憶體峰值很高的情況，可以看到都是哪些對象佔用了較多記憶體能不能最佳化；當然不能分析記憶體泄露啊，那個得靠Heap和MAT分析了。

其實另外還有一個NB的工具OpenGL Trace，這個東西一般用來分析OpenGL的繪製本人還沒用過就不說了。

PS：寫的差不多的時候，無意間網上看了一篇大神的文檔：http://blog.csdn.net/innost/article/details/9008691，這個汗顏啊，說一樣的東西，那文筆和思路巨清晰，確實對初次使用的人有很大協助。我還得加油啊。