最近,我準備好好研究一下Android性能優化方面的相關知識,準備從應用流暢度開始,邊看《移動App性能評測與優化》邊自己實踐,希望可以補足一下自己在優化這方面的空白。
工欲善其事必先利其器,我先學習了TraceView這個大神器的使用方法。下面就來總結一下。
為了節省你的時間,本文主要内容如下:
- TraceView兩種使用方法
- TraceView各項資料的含義
TraceView使用方法
TraceView有兩種使用方法,一種是在DDMS上手動操作進行使用,還有一種方法是使用代碼生成trace檔案,然後在使用DDMS打開檔案。我們以檢測一個啟動很慢的Activity為例來介紹。在應用中點選個人中心按鈕,跳轉到個人中心頁面,但是這個過程有明顯的卡頓。我們分别使用兩個方法來檢測這個過程。
第一種方法是最簡單也是最常用的使用方法。點選DDMS左側的Start Method Profiling按鈕(具體位置如圖1,三個小箭頭和紅點的那個按鈕)。
圖1:TraceView啟動按鈕位置
然後點選個人應用中心按鈕,等待個人中心頁面顯示出來,然後再次點選那個按鈕,DDMS就會自動顯示出如圖2的界面。
第一種方法很友善,但是精準度不夠,當你希望有更加精确的檢測時,你就可以使用第二種方法。在你要檢測的代碼過程中開始調用
android.os.Debug.startMethodTracing()
方法,然後在過程的末尾調用
android.os.Debug.stopMethodTracing()
方法。等到這段代碼執行完之後,系統就會在手機的
/sdcard
檔案夾下生成一個trace檔案。你可以使用DDMS或者adb将其複制到你的電腦上,然後用DDMS工具打開。
圖2:TraceView資料展示
TraceView各項資料分析
我很久之前就接觸過TraceView,但是當時并沒有完全了解它所展示的所有資料的具體含義,沒有感受到它的強大之處。下面,我總結一下它的各項資料的含義和自己的了解。
首先,我們可以看到一行表頭,其中不同的項代表不同的内容。我們接下來一一進行解釋。
Incl Cpu Time
Incl Cpu Time
表示這個函數從開始被執行到執行結束的時間。這個時間包括這個函數中調用其他函數所花費的時間。也就是說,這個函數和函數中所有子函數的一共執行時間。舉個例子:
public void example() {
a();
b();
}
Incl Cpu Time
就表示
example
函數執行的總時間,假如說
example
方法執行的時間為10ms,函數a執行了3ms,方法b執行了6ms,調用
example
方法的函數執行的總時間為100ms。最終計算出來的
Incl Cpu Time
比率為:
- example 10%
- a 30%
- b 60%
通過這個名額,我們可以看到一個函數的所有時間的占比,這個名額一般不會用到,因為我們一般都先檢視所有函數的
Excl Cpu Time
名額。但是當你需要精确了解各個函數總執行時間并優化時,你還是需要先從這個函數入手。比如說優化應用冷啟動時間,這個時候并沒有明顯的有較長
Excl Cpu Time
的函數,你需要對目标函數進行一點一點的分析和優化。而不是像尋找明顯示卡頓原因時的直接找
Excl Cpu Time
名額最大的函數。
Excl Cpu Time
了解了
Incl Cpu Time
,我們就可以輕易了解這個名額的含義啦。還是上邊那個例子。我們可以計算出各個函數的
Incl Cpu Time
比例。
- example (10 - 3 -6)/100 = 1%
- 從例子上來看,一個方法的
等于它的Excl Cpu Time
減去它所有子函數的Incl Cpu Time
。Incl Cpu Time
Incl Real Time 和 Excl Real Time
對這兩條名額的了解主要涉及到對
Cpu time
和
Real time
的了解。Cpu Time 應該是某個方法占用CPU的時間;而Real Time 應該是這個方法的實際運作時間。因為Cpu的上下文切換,阻塞,等待等原因,Real Time 一般長于Cpu Time。
Calls+Recur Calls/Total
這個名額表示這個方法執行的總次數。Calls表示這個函數的調用次數,而Recur Calls表示遞歸調用次數。
Cpu Time/Calls Real Time/Calls
這兩個名額表示方法的每次調用的平均執行時間。
後記
有關TraceView的内容就介紹到這裡,了解工具的使用隻是開始,我們還需多在實踐中應用這些工具,比如開發過程中發現有頁面比較卡頓,那麼我們就可以使用TraceView去檢測一下!!!