1、ddms與traceview的區別
ddms是乙個集除錯、瀏覽、控制等操作為一體的工具箱，而traceview只是乙個效能調優工具，可通過它檢視程式中方法的執行效率等指標。
2、traceview的使用
traceview的開啟有兩種方式
①最簡單的方式就是直接開啟ddms，選擇乙個程序，然後按上面的「start method profiling」按鈕，等紅色小點變成黑色以後就表示traceview已經開始工作了。然後進行手機操作，操作最好不要超過5s，因為最好是進行小範圍的效能測試
。然後再按一下剛才按的按鈕，等一會就會出現上面這幅圖，然後就可以開始分析了。
②第2種方式就是使用android.os.debug.startmethodtracing();和android.os.debug.stopmethodtracing();方法，將android.os.debug.stopmethodtracing();放在結束除錯的地方。當執行了這段**的時候，就會有乙個trace檔案在/sdcard目錄中生成，也可以呼叫startmethodtracing(string tracename)設定trace檔案的檔名，最後你可以使用adb pull /sdcard/test.trace /tmp命令將trace檔案複製到你的電腦中，然後用ddms工具開啟就會出現第一幅圖了。
上述兩種方式都可以進行測試的開始，第一種方式適用於更大範圍的除錯，第二種更加的精確，可以在區域性方法測試。
3、traceview中的指標
每個方法前面都有乙個數字，可能是全部方法按照incl cpu time 時間的排序序號（後面會講到）
點乙個方法後可以看到有兩部分，乙個是parents，另乙個是children。
incl cpu time表示方法top執行的總時間，假如說方法top的執行時間為10ms，方法a執行了1ms，方法b執行了2ms，方法c執行了3ms，方法d執行了4ms（這裡是為了舉個栗子，實際情況中方法a、b、c、d的執行總時間肯定比方法top的執行總時間要小一點）。
public void top()incl cpu time
top10%
a10%
b20%
c30%
d40%
從上面圖中可以看到：
toplevel的 incl cpu time 是1110.943，而io.bxbxbai.android.examples.activity.expandablelayoutmainactivity$******adapter.getitemview方法的incl cpu time為12.859，說明後者的incl cpu time % 約為1.2%
這個指標表示
這個方法以及這個方法的子方法（比如top方法中的a、b、c、d方法）一共執行的時間
2. excl cpu time
理解了incl cpu time以後就可以很好理解excl cpu time了，還是上面top方法的栗子：
方法top 的 incl cpu time 減去 方法a、b、c、d的incl cpu time 的時間就是方法top的excl cpu time 了
3. incl real time
這個感覺和incl cpu time 差不多，第7條會講到。
4. excl real time
同上5. calls + recur calls / total
這個指標非常重要！
它表示這個方法執行的次數，這個指標中有兩個值，乙個call表示這個方法呼叫的次數，recur call表示遞迴呼叫次數，看下圖：
我選中了乙個方法，可以看到這個方法的calls + recur calls值是14 + 0，表示這個方法呼叫了14次，但是沒有遞迴呼叫
從children這一塊來看，很多方法呼叫都是13的倍數，說明父方法中有乙個判斷，但是這不是重點，有些child方法呼叫calls為26，這說明了這些方法被呼叫了兩遍，是不是可能存在重複呼叫的情況？這些都是可能可以優化效能的地方。
6. cpu time / call
重點來了！！！！！！！！！！
這個指標應該說是最重要的，從上圖可以看到，133這個方法的呼叫次數為20次，而它的incl cpu time為12.859ms，那麼133方法每一次執行的時間是0.643ms（133這個方法是******adapter的getitemview方法）
對於乙個adapter的getview方法來說0.643ms是非常快的（因為這個adapter中只有乙個textview，我為了測試用的）
如果getview方法執行時間很長，那麼必然導致列表滑動的時候產生卡頓現象，可以在getview方法的children方法列表中找到耗時最長的方法，分析出現問題的原因：
7. real time / call
real time 和 cpu time 我現在還不太明白它們的區別，我的理解應該是:
為什麼它們會有區別呢？可能是因為cpu的上下文切換、阻塞、gc等原因方法的實際執行時間要比cpu time 要稍微長一點。
traceview是乙個非常強大的效能分析工具，因為android 官網對這個工具的使用介紹文件很少，而且一些中文部落格中寫的也都是抄來抄去，沒有講到底怎麼使用。
最近我在做這方面的效能分析，就慢慢琢磨了這麼工具的使用，發現非常強大，寫下來總結一下。
android的效能分析工具還有很多，比如：
dump ui hierarchy for ui atomator，分析ui層級
systrace
其他原文出處：
bxbxbai 的部落格（@白瓦力）
使用TraceView工具定位耗時操作
eclipse中生成trace檔案的方法 android studio生成trace檔案的方法 生成的trace檔案將顯示在captures視窗 直接把trace檔案拖到安裝了adt外掛程式的eclipse就能開啟。timeline展示各個執行緒占用cpu的情況。橫軸為從開始到結束trace的cpu...
CWinThread的使用詳解
分類 c c 1.afxbeginthread 與 cwinthread createthread的區別 2.常見的啟動執行緒函式有三個 createthread beginthread 以及 beginthreadex afxbeginthread 1和2是sdk函式，3是mfc函式 至於啟動的是...
rails grape 的使用詳解
1 gem準備 gem grape 0.8.0 gem grape jbuilder 0.2.0 gem jbuilder 2.0 class api grape api version v1 using path format json formatter json,grape formatter...