以下文章轉(zhuǎn)載自http://blog.jobbole.com/78995/

TraceView界面

現(xiàn)來看一下整個(gè)界面的圖，整個(gè)界面包括上下兩部分，上面是你測(cè)試的進(jìn)程中每個(gè)線程的執(zhí)行情況，每個(gè)線程占一行；下面是每個(gè)方法執(zhí)行的各個(gè)指標(biāo)的值

上面一部分是你測(cè)試進(jìn)程的中每個(gè)線程運(yùn)行的時(shí)間線，下圖中可以可以看到，主要只有一個(gè)main線程在執(zhí)行，因?yàn)槲一瑒?dòng)了一下列表，main線程（UI線程）正在進(jìn)行繪制View呢~

然后我點(diǎn)擊了序號(hào)為133的一個(gè)方法io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView，就會(huì)出現(xiàn)兩部分?jǐn)?shù)據(jù)：

• Parents
• Children

Parents表示調(diào)用133這個(gè)方法的父方法，可以看到序號(hào)為130。Children表示方法133調(diào)用的其他方法，可以看到有好幾個(gè)方法。

如何使用TraceView

因?yàn)檫@次我主要是分析列表滑動(dòng)卡頓問題，我就講講我是怎么使用這個(gè)工具的，并且我是怎么分析的。

使用TraceView主要有兩種方式：

最簡單的方式就是直接打開DDMS，選擇一個(gè)進(jìn)程，然后按上面的“Start Method Profiling”按鈕，等紅色小點(diǎn)變成黑色以后就表示TraceView已經(jīng)開始工作了。然后我就可以滑動(dòng)一下列表（現(xiàn)在手機(jī)上的操作肯定會(huì)很卡，因?yàn)锳ndroid系統(tǒng)在檢測(cè)Dalvik虛擬機(jī)中每個(gè)Java方法的調(diào)用，這是我猜測(cè)的）。操作最好不要超過5s，因?yàn)樽詈檬沁M(jìn)行小范圍的性能測(cè)試。然后再按一下剛才按的按鈕，等一會(huì)就會(huì)出現(xiàn)上面這幅圖，然后就可以開始分析了。

第2種方式就是使用android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing();方法，當(dāng)運(yùn)行了這段代碼的時(shí)候，就會(huì)有一個(gè)trace文件在/sdcard目錄中生成，也可以調(diào)用startMethodTracing(String traceName)?設(shè)置trace文件的文件名，最后你可以使用adb pull /sdcard/test.trace /tmp?命令將trace文件復(fù)制到你的電腦中，然后用DDMS工具打開就會(huì)出現(xiàn)第一幅圖了

第一種方式相對(duì)來說是一種簡單，但是測(cè)試的范圍很寬泛，第二中方式相對(duì)來說精確一點(diǎn)，不過我個(gè)人喜歡使用第一種，因?yàn)楹唵?#xff0c;而且它是檢測(cè)你的某一個(gè)操作。因?yàn)榈诙懈m合檢測(cè)某一個(gè)方法的性能，其實(shí)也沒有那種好，看使用的場(chǎng)景和喜好了。。。

看懂TraceView中的指標(biāo)

其實(shí)我今年7月份就已經(jīng)開始使用TraceView工具了，但是當(dāng)時(shí)不懂其中每個(gè)指標(biāo)的含義，就沒注意到它強(qiáng)大的地方。看不懂界面下方表格中的指標(biāo)，這些數(shù)據(jù)其實(shí)一點(diǎn)意義都沒有。

網(wǎng)上包括Android官網(wǎng)也沒有對(duì)TraceView工具的使用有詳細(xì)的說明文檔，這點(diǎn)確實(shí)比較蛋疼。

縱軸

TraceView界面下方表格中縱軸就是每個(gè)方法，包括了JDK的，Android SDK的，也有native方法的，當(dāng)然最重要的就是app中你自己寫的方法，有些Android系統(tǒng)的方法執(zhí)行時(shí)間很長，那么有很大的可能就是你app中調(diào)用這些方法過多導(dǎo)致的。

每個(gè)方法前面都有一個(gè)數(shù)字，可能是全部方法按照Incl CPU Time 時(shí)間的排序序號(hào)（后面會(huì)講到）

點(diǎn)一個(gè)方法后可以看到有兩部分，一個(gè)是Parents，另一個(gè)是Children。

• Parent表示調(diào)用這個(gè)方法的方法，可以叫做父方法
• Children表示這個(gè)方法中調(diào)用的其他方法，可以叫做子方法

橫軸

橫軸上是很多指標(biāo)，這些指標(biāo)表示什么意思真的困擾了我很長一段時(shí)間。。。

能夠很衡量一個(gè)方法性能的指標(biāo)應(yīng)該只有時(shí)間了吧？ 一個(gè)方法肯定就是執(zhí)行時(shí)間越短約好咯~~

1. Incl Cpu Time

define?inclusive?： 全包括的

上圖中可以看到0（toplevel）?的Incl Cpu Time 占了100%的時(shí)間，這個(gè)不是說100%的時(shí)間都是它在執(zhí)行，請(qǐng)看下面代碼：

1 2 3 4 5 6

public void top() { ????a(); ????b(); ????c(); ????d(); }

Incl Cpu Time表示方法top執(zhí)行的總時(shí)間，假如說方法top的執(zhí)行時(shí)間為10ms，方法a執(zhí)行了1ms，方法b執(zhí)行了2ms，方法c執(zhí)行了3ms，方法d執(zhí)行了4ms（這里是為了舉個(gè)栗子，實(shí)際情況中方法a、b、c、d的執(zhí)行總時(shí)間肯定比方法top的執(zhí)行總時(shí)間要小一點(diǎn)）。

而且調(diào)用方法top的方法的執(zhí)行時(shí)間是100ms，那么：

? ? Incl Cpu Time

top	?	10%
?	a	10%
?	b	20%
?	c	30%
?	d	40%

從上面圖中可以看到：
toplevel的 Incl Cpu Time 是1110.943，而io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView方法的Incl Cpu Time為12.859，說明后者的Incl Cpu Time % 約為1.2%

這個(gè)指標(biāo)表示?這個(gè)方法以及這個(gè)方法的子方法（比如top方法中的a、b、c、d方法）一共執(zhí)行的時(shí)間

2. Excl Cpu Time

理解了Incl Cpu Time以后就可以很好理解Excl Cpu Time了，還是上面top方法的栗子：

方法top 的 Incl Cpu Time 減去 方法a、b、c、d的Incl Cpu Time 的時(shí)間就是方法top的Excl Cpu Time 了

3. Incl Real Time

這個(gè)感覺和Incl Cpu Time 差不多，第7條會(huì)講到。

4. Excl Real Time

同上

5. Calls + Recur Calls / Total

這個(gè)指標(biāo)非常重要！

它表示這個(gè)方法執(zhí)行的次數(shù)，這個(gè)指標(biāo)中有兩個(gè)值，一個(gè)Call表示這個(gè)方法調(diào)用的次數(shù)，Recur Call表示遞歸調(diào)用次數(shù)，看下圖：

我選中了一個(gè)方法，可以看到這個(gè)方法的Calls + Recur Calls?值是14 + 0，表示這個(gè)方法調(diào)用了14次，但是沒有遞歸調(diào)用

從Children這一塊來看，很多方法調(diào)用都是13的倍數(shù)，說明父方法中有一個(gè)判斷，但是這不是重點(diǎn)，有些Child方法調(diào)用Calls為26，這說明了這些方法被調(diào)用了兩遍，是不是可能存在重復(fù)調(diào)用的情況？這些都是可能可以優(yōu)化性能的地方。

6. Cpu Time / Call

重點(diǎn)來了！！！！！！！！！！

這個(gè)指標(biāo)應(yīng)該說是最重要的，從上圖可以看到，133這個(gè)方法的調(diào)用次數(shù)為20次，而它的Incl Cpu Time為12.859ms，那么133方法每一次執(zhí)行的時(shí)間是0.643ms（133這個(gè)方法是SimpleAdapter的getItemView方法）

對(duì)于一個(gè)adapter的getView方法來說0.643ms是非常快的（因?yàn)檫@個(gè)adapter中只有一個(gè)TextView，我為了測(cè)試用的）

如果getView方法執(zhí)行時(shí)間很長，那么必然導(dǎo)致列表滑動(dòng)的時(shí)候產(chǎn)生卡頓現(xiàn)象，可以在getView方法的Children方法列表中找到耗時(shí)最長的方法，分析出現(xiàn)問題的原因：

• 是因?yàn)橛羞^多的計(jì)算？
• 還是因?yàn)橛凶x取SD卡的操作？
• 還是因?yàn)閍dapter中View太復(fù)雜了？
• 還是因?yàn)樾枰泻芏嗯袛?#xff0c;設(shè)置View的顯示還是隱藏
• 還是因?yàn)槠渌颉?/li>

7. Real Time / Call

Real Time 和 Cpu Time 我現(xiàn)在還不太明白它們的區(qū)別，我的理解應(yīng)該是:

• Cpu Time 應(yīng)該是某個(gè)方法占用CPU的時(shí)間
• Real Time 應(yīng)該是這個(gè)方法的實(shí)際運(yùn)行時(shí)間

為什么它們會(huì)有區(qū)別呢？可能是因?yàn)镃PU的上下文切換、阻塞、GC等原因方法的實(shí)際執(zhí)行時(shí)間要比Cpu Time 要稍微長一點(diǎn)。

總結(jié)

TraceView是一個(gè)非常強(qiáng)大的性能分析工具，因?yàn)锳ndroid 官網(wǎng)對(duì)這個(gè)工具的使用介紹文檔很少，而且一些中文博客中寫的也都是抄來抄去，沒有講到底怎么使用。

最近我在做這方面的性能分析，就慢慢琢磨了這么工具的使用，發(fā)現(xiàn)非常強(qiáng)大，寫下來總結(jié)一下。

Android的性能分析工具還有很多，比如：

• Eclipse Memory Analyzer Tool 來分析Android app的內(nèi)存使用
• Dump UI Hierarchy for UI Atomator，分析UI層級(jí)
• systrace
• 其他

下圖這一條工具欄中有很多性能分析工具~~~

總結(jié)

以上是生活随笔為你收集整理的Android Trace View使用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。