導言
上一篇描述了通過Systrace分析繪制的問題，里面也有提到過，某一幀繪制過久，那么這可能是代碼等地方有問題，具體分析代碼問題，這時候就輪到TraceView發(fā)揮作用了
基礎
TraceView有兩種使用模式：
1.可以在DDMS里面手動開啟，然后再手動停止，然后生成的trace默認為這段時間內(nèi)的記錄，常用于在不確定具體卡頓代碼的情況下
2.可以在代碼中指定開始和結束
Debug.startMethodTracing("test");
...
Debug.stopMethodTracing();
常用于分析指定代碼或者具體操作
面板分析
看一下重點指標就可以了
Cpu Time：實際執(zhí)行的時間（不包括線程被掛起的等待時間）
Real Time：執(zhí)行的總時長（Cpu Time+等待的時間）
Calls+RecurCalls：函數(shù)執(zhí)行的總次數(shù)（包括遞歸執(zhí)行）
簡單的分析方法就是考慮一個函數(shù)的執(zhí)行次數(shù)和單次執(zhí)行時間，執(zhí)行次數(shù)過多的話要考慮是不是有過度調(diào)用或者遞歸的問題，執(zhí)行時間過長的話要考慮進行優(yōu)化操作
調(diào)用鏈分析
可以通過選擇具體的某個函數(shù)來看到該函數(shù)下面調(diào)用的其余函數(shù)的具體耗時，從而鏈式的向下分析
從圖中可以看出，當前函數(shù)內(nèi)部的三個函數(shù)基本上瓜分了執(zhí)行時間，那么后續(xù)就可以對這三個函數(shù)繼續(xù)進行調(diào)用鏈分析，分析的目的是在最后能夠對執(zhí)行時間進行優(yōu)化。
舉例說明
這里通過代碼中指定的方式來觀察一個網(wǎng)絡請求的開始到結束
我們這里就簡單觀察一下數(shù)據(jù)解析，因為返回數(shù)據(jù)都是為JSON串，統(tǒng)一都需要轉換為對象處理，這時候轉換的速度也就是我們關心的指標，這里對比一下Gson和FastJson的情況，對象統(tǒng)一不采用注解，僅僅是提供一致的字段名及對應的get/set方法
從結果上面很直觀的看出來FastJson的解析效率高一些，從追求性能的方向上面考慮可能使用FastJson會相對好一些。
同時也要注意到Json解析是一個相對耗時的操作，應當盡可能的放入到工作線程中處理而不是阻塞主線程，畢竟480ms已經(jīng)相當于30幀左右的時間了
總結
TraceView常用于分析方法的具體執(zhí)行時間，可以作為一種常用的調(diào)優(yōu)手段。
當然常規(guī)的使用模式應該是先通過Systrace來發(fā)現(xiàn)UI卡頓問題，然后再使用TraceView進行細化分析，這樣配合會更加的合適
文章系列：
基本的優(yōu)化總結（一）
基本的優(yōu)化總結（二）
基本的優(yōu)化總結（三）
基本的優(yōu)化總結（四）
基本的優(yōu)化總結（五）
基本的優(yōu)化總結（六）
