Andorid性能優化之traceview的使用（不懂揍我）

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

這2種方式能夠根據場景，去選擇哪種方式。最終效果是同樣的

• 經過手動埋點
• Profile

1.一、經過手動埋點。

步驟1: 好比咱們知道在點擊一個按鈕的時候，會有卡頓，那麼就能夠用

//能夠用如下代碼測試你的代碼。
//開始埋點，「app」是最後生成的性能分析文件
Debug.startMethodTracing("App");

//埋點結束，期間start 到 stop 之間的代碼，就是你要測試的代碼範圍
Debug.stopMethodTracing();
複製代碼

步驟2: 運行完測試代碼後，咱們點開studio右下角的Device Explorer，在下圖的「第一步」，打開以後咱們要找到咱們生成的trace文件，路徑在sdcard/Android/data/項目包名/files,如圖：

步驟3： 直接左鍵雙擊能夠打開咱們的文件如圖：

部分1：是時間選擇範圍，整段就是咱們剛剛用代碼埋點指定的。上面的時間標誌是時間戳。
部分2：表示當前埋點的代碼有5個線程。能夠點擊任何一個線程查看
部分3：這裏有4個按鈕

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

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

1.1.一、Top Down

點開咱們的Top Down，以下：

紅色框1： 表示main裏的一些狀況。

• Total：表示main函數全部執行須要的時間
• Self: 表示main函數裏，除了調用別的函數方法外，本身方法內代碼的執行時間
• Children: 表示mian函數裏，調用別的函數所執行的時間
  
  

紅色框2： 裏面有2個選項，能夠切換成Wall Clock Time或者Thread Time

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

爲何這兩個時間會不同？舉個不恰當的比喻，好比運行一個方法，由於鎖的緣由，線程等待。這個時候等待時間也算在了Wall Clock Time裏。 可是Thread Time是CPU的執行時間，線程閒置的時候並無消耗CPU，固然這個等待時間也就不算在Thread Time裏了。

紅色框3： 表示方法的依次調用。及每一個子方法調用所消耗的時間。這裏也能夠當作是Call Chart表的「代碼化」。

1.1.二、Call Chart

點開Call Chart以下：

這裏注意要注意幾點：

• 這裏的圖標表示，好比2個方法A和B。方法A調用方法B，那麼方法A就在方法B的上方。
• 橙色：表示系統API方法調用
• 綠色：表示自身方法調用
• 藍色：表示第三方調用

1.1.三、Flame Chart

點開Flame Chart後，以下:

這裏的意思是會把類似或相同的方法統計在一塊兒，好比A方法調用B方法調用C方法：A->B->C,那麼他會將全部按此順序的方法收集在一塊兒，或者將A->B->D也會收集在上，橫軸表示的是相對時間。

1.1.四、Bottom Up

點開Bottom Up以下

這裏點開initX5web() -> 顯示了main();也就是說誰調用了我。main()方法裏調用initX5web();

1.二、經過Andorid studio 的Profile

點擊Profile運行項目

運行後以下圖：

鼠標移動到CPU那裏後，左鍵雙擊CPU後，如圖:

能夠看到，這裏和咱們上面用代碼埋點界面幾乎相同了，這裏有個按鈕，Record,點擊後，文案會變成stop;咱們就能夠在APP裏操做，來到咱們以爲卡頓或者有問題的功能裏。點擊stop就造成了咱們trace同樣的文件裏。裏面的操做都是同樣的

2、咱們來舉個小例子，來解決一項卡頓

拿之前作的一個項目舉例，爲了避免被騷擾，這裏我隱藏了手機號。看看下面的gif,這裏我在輸入密碼後，點擊登陸，在網絡請求結束後，dialog已經消失了，尚未跳轉到咱們的首頁，如圖，此時有明顯的卡頓

在咱們logcat裏過濾關鍵字：Displayed 能夠看到咱們程序中每一個Activity的啓動時間，此時個人啓動時間是996，接近1s（fuck,這樣都有996，擦）：

這個時候咱們用第二種方式去嘗試解決這個卡頓，根據咱們的Top Down分析，根絕Total的耗時時間，咱們一直往下點，首先來到以下（假設咱們還不知道是跳轉Activity卡頓）：

這時候到了2個方法，dispatchMessage()和next();
咱們先將dispatchMessage點到底，看到了setContentView()裏的loadDrawable()。能夠看到這個是元兇

將next()點到底，如圖，在nativePollOnce(),後子方法裏，沒有耗時項，根據方法名也能猜想到，這是系統方法。

由上面的分析，最終問題定在了setContentView()裏的loadDrawable()。也就是說明咱們MainActivity的layout裏，不論是src仍是background,有一個很是耗時的bitmap。這裏我照下來以後，確實發現了根佈局的background裏背景大圖，我這裏直接取消這張圖後，運行程序，以下，能夠發現再也不卡頓了，並且跳轉速度大大提高了：

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

這裏我只是舉了個小例子，但願對學習性能優化的朋友有幫助。若是以爲有用，就贊一個吧！！