一、traceview的使用方式有2種方式

這2種方式可以根據(jù)場景，去選擇哪一種方式。最終效果是一樣的

• 通過手動埋點(diǎn)
• Profile

1.1、通過手動埋點(diǎn)。

步驟1: 比如我們知道在點(diǎn)擊一個按鈕的時候，會有卡頓，那么就可以用

//可以用以下代碼測試你的代碼。 //開始埋點(diǎn)，“app”是最后生成的性能分析文件 Debug.startMethodTracing("App");//埋點(diǎn)結(jié)束，期間start 到 stop 之間的代碼，就是你要測試的代碼范圍 Debug.stopMethodTracing();

步驟2: 運(yùn)行完測試代碼后，我們點(diǎn)開studio右下角的Device Explorer，在下圖的“第一步”，打開之后我們要找到我們生成的trace文件，路徑在sdcard/Android/data/項(xiàng)目包名/files,如圖：

步驟3： 直接左鍵雙擊可以打開我們的文件如圖：

部分1：是時間選擇范圍，整段就是我們剛剛用代碼埋點(diǎn)指定的。上面的時間標(biāo)志是時間戳。

部分2：表示當(dāng)前埋點(diǎn)的代碼有5個線程。可以點(diǎn)擊任何一個線程查看
部分3：這里有4個按鈕

• Call Chart
• Flame Chart
• Top Down
• Bottom Up

接下來我們具體看看這四個按鈕

1.1.1、Top Down

點(diǎn)開我們的Top Down，如下：

紅色框1： 表示main里的一些情況。

• Total：表示main函數(shù)所有執(zhí)行需要的時間
• Self: 表示main函數(shù)里，除了調(diào)用別的函數(shù)方法外，自己方法內(nèi)代碼的執(zhí)行時間
• Children: 表示mian函數(shù)里，調(diào)用別的函數(shù)所執(zhí)行的時間
  ?

紅色框2： 里面有2個選項(xiàng)，可以切換成Wall Clock Time或者Thread Time

• Wall Clock Time：指這個線程真正的執(zhí)行時間，比如消耗了100ms就是消耗了100ms
• Thread Time：CPU的執(zhí)行時間，比Wall Clock Time少。

為什么這兩個時間會不一樣？舉個不恰當(dāng)?shù)谋扔?#xff0c;比如運(yùn)行一個方法，因?yàn)殒i的原因，線程等待。這個時候等待時間也算在了Wall Clock Time里。 但是Thread Time是CPU的執(zhí)行時間，線程閑置的時候并沒有消耗CPU，當(dāng)然這個等待時間也就不算在Thread Time里了。

紅色框3： 表示方法的依次調(diào)用。及每個子方法調(diào)用所消耗的時間。這里也可以看成是Call Chart表的“代碼化”。

1.1.2、Call Chart

點(diǎn)開Call Chart如下：

?

這里注意要注意幾點(diǎn)：

• 這里的圖標(biāo)表示，比如2個方法A和B。方法A調(diào)用方法B，那么方法A就在方法B的上方。
• 橙色：表示系統(tǒng)API方法調(diào)用
• 綠色：表示自身方法調(diào)用
• 藍(lán)色：表示第三方調(diào)用

1.1.3、Flame Chart

點(diǎn)開Flame Chart后，如下:

這里的意思是會把相似或相同的方法統(tǒng)計(jì)在一起，比如A方法調(diào)用B方法調(diào)用C方法：A->B->C,那么他會將所有按此順序的方法收集在一起，或者將A->B->D也會收集在上，橫軸表示的是相對時間。

1.1.4、Bottom Up

點(diǎn)開Bottom Up如下

這里點(diǎn)開initX5web() -> 顯示了main();也就是說誰調(diào)用了我。main()方法里調(diào)用initX5web();

1.2、通過Andorid studio 的Profile

點(diǎn)擊Profile運(yùn)行項(xiàng)目

運(yùn)行后如下圖：

鼠標(biāo)移動到CPU那里后，左鍵雙擊CPU后，如圖:

可以看到，這里和我們上面用代碼埋點(diǎn)界面幾乎相同了，這里有個按鈕，Record,點(diǎn)擊后，文案會變成stop;我們就可以在APP里操作，來到我們覺得卡頓或者有問題的功能里。點(diǎn)擊stop就形成了我們trace一樣的文件里。里面的操作都是一樣的

二、我們來舉個小例子，來解決一項(xiàng)卡頓

---

拿以前做的一個項(xiàng)目舉例，為了不被騷擾，這里我隱藏了手機(jī)號。看看下面的gif,這里我在輸入密碼后，點(diǎn)擊登錄，在網(wǎng)絡(luò)請求結(jié)束后，dialog已經(jīng)消失了，還沒有跳轉(zhuǎn)到我們的首頁，如圖，此時有明顯的卡頓

?

在我們logcat里過濾關(guān)鍵字：Displayed 可以看到我們程序中每個Activity的啟動時間，此時我的啟動時間是996，接近1s（fuck,這樣都有996，擦）：

這個時候我們用第二種方式去嘗試解決這個卡頓，根據(jù)我們的Top Down分析，根絕Total的耗時時間，我們一直往下點(diǎn)，首先來到如下（假設(shè)我們還不知道是跳轉(zhuǎn)Activity卡頓）：

這時候到了2個方法，dispatchMessage()和next();
我們先將dispatchMessage點(diǎn)到底，看到了setContentView()里的loadDrawable()。可以看到這個是元兇

?

將next()點(diǎn)到底，如圖，在nativePollOnce(),后子方法里，沒有耗時項(xiàng)，根據(jù)方法名也能猜測到，這是系統(tǒng)方法。

由上面的分析，最終問題定在了setContentView()里的loadDrawable()。也就是說明我們MainActivity的layout里，不管是src還是background,有一個非常耗時的bitmap。這里我照下來之后，確實(shí)發(fā)現(xiàn)了根布局的background里背景大圖，我這里直接取消這張圖后，運(yùn)行程序，如下，可以發(fā)現(xiàn)不再卡頓了，而且跳轉(zhuǎn)速度大大提升了：

打印下時間，啟動時間由原來的996，變成了447：

這里我只是舉了個小例子，希望對學(xué)習(xí)性能優(yōu)化的朋友有幫助。如果覺得有用，就贊一個吧！！

技術(shù)交流粉絲群：

總結(jié)

以上是生活随笔為你收集整理的Andorid性能优化之traceview的使用（不懂揍我）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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