做過性能優化的人對systrace應該都不陌生,systrace簡直是這方面的神器,systrace的特點十分明顯
- 優點
相比于traceview,systrace的結果表現更為直觀和精確,打開生成的html文件可以知道在相應的時間段內,哪里的函數執行時間較長,是否導致UI線程上發生阻塞,造成掉幀或是卡頓 - 缺點
systrace的結果輸出依賴代碼中的trace,雖然Android系統中的關鍵函數都加上的trace,但是分析道具體應用的時候也需要在代碼上加上trace,trace越多,結果輸出也就越詳細,分析起來也更容易定位具體的耗時點,當然代碼中加trace也是挺麻煩
Trace.traceBegin("my tag");
try {
...
} finally {
Trace.traceEnd();
}
而且必須保證traceBegin和traceEnd成對出現并在一個線程中,生成trace文件的前期準備工作還是比較拿麻煩的
systrace也不是每次都必須要用的,有時候程序卡頓可能只是一段函數執行的次數太多,那么就可以直接去優化相應的函數,不需要再使用systrace了
所以,推薦先使用traceview尋找當前程序有否有重復調用或者執行時間較長的函數,其次是代碼分析,尋找可疑點,如果前面兩步都不能準確定位的話,這時候就可以考慮用systrace了
1.Android Studio使用systrace
對于一般的應用開發者,android studio已經把功能都集成好了,可以十分方便的使用systrace,打開Android Device Monitor就能看到如下界面選擇要分析的應用進程并點擊按鈕
根據需要選擇相應的TAG就可以了,完成之后生成一個html文件,用chrome打開
2.源碼環境使用systrace
雖然源碼環境下也會使用Android studio來開發,但是Android Device Monitor生成的trace文件常常有問題,里面沒有包含需要的信息,目前還不確定具體的原因,所以一般都是使用命令行來生成trace文件
進入sdk下的platform-tools/systrace/,可以看到systrace實際上是一個python腳本,也就是說使用命令行需要安裝python環境
使用命令行的一般格式是
python systrace.py -option
其中option可以使用
python systrace.py --help
來獲得,一般來說我們只需要使用 -o ,-b, -t,-a 對應輸出文件路徑,buffersize,time,需要分析的應用程序包名
獲取可用的tag,輸入
python systrace.py -l
會提示當前可以用的tag,也會包含具體的釋義
舉個例子
python systrace.py -t 3 -o ~/mytrace.html -a com.android.test gfx view wm am res sync
3.查看trace文件
chrome打開trace文件可以看到類似下面的圖其中需要重點關注帶有F的圓點,表示一幀,即frame,流暢的界面顯示需要保證每秒60幀的速率,即要求每一幀花費的時間不能超過16ms,否則就會造成卡頓和掉幀,只用圓點為綠色的時候才表示這一幀沒有超過16ms,其他都是大于16ms,變紅則表示嚴重超時,可以點擊對應的按鈕并按M鍵看到精確的時間消耗,然后就可以定位到具體耗時的地方并加以優化
4.異步trace
Android其實是支持異步trace的,源碼中應用的比較多,在代碼中打上異步trace就不需要保證在一個線程之中,也不要求一定要把一段代碼包起來,在普通應用中使用會報錯找不到對應的方法,由于沒有使用過,具體的原因沒有深究,附上源碼的使用例子和方法定義
if (!mBootAnimationStopped) {
// Do this one time.
Trace.asyncTraceBegin(Trace.TRACE_TAG_WINDOW_MANAGER, "Stop bootanim", 0);
try {
IBinder surfaceFlinger = ServiceManager.getService("SurfaceFlinger");
if (surfaceFlinger != null) {
//Slog.i(TAG_WM, "******* TELLING SURFACE FLINGER WE ARE BOOTED!");
Parcel data = Parcel.obtain();
data.writeInterfaceToken("android.ui.ISurfaceComposer");
surfaceFlinger.transact(IBinder.FIRST_CALL_TRANSACTION, // BOOT_FINISHED
data, null, 0);
data.recycle();
}
} catch (RemoteException ex) {
Slog.e(TAG_WM, "Boot completed: SurfaceFlinger is dead!");
}
mBootAnimationStopped = true;
}
if (!mForceDisplayEnabled && !checkBootAnimationCompleteLocked()) {
if (DEBUG_BOOT) Slog.i(TAG_WM, "performEnableScreen: Waiting for anim complete");
return;
}
EventLog.writeEvent(EventLogTags.WM_BOOT_ANIMATION_DONE, SystemClock.uptimeMillis());
Trace.asyncTraceEnd(Trace.TRACE_TAG_WINDOW_MANAGER, "Stop bootanim", 0);
/**
* Writes a trace message to indicate that a given section of code has
* begun. Must be followed by a call to {@link #asyncTraceEnd} using the same
* tag. Unlike {@link #traceBegin(long, String)} and {@link #traceEnd(long)},
* asynchronous events do not need to be nested. The name and cookie used to
* begin an event must be used to end it.
*
* @param traceTag The trace tag.
* @param methodName The method name to appear in the trace.
* @param cookie Unique identifier for distinguishing simultaneous events
*
* @hide
*/
public static void asyncTraceBegin(long traceTag, String methodName, int cookie) {
if (isTagEnabled(traceTag)) {
nativeAsyncTraceBegin(traceTag, methodName, cookie);
}
}
/**
* Writes a trace message to indicate that the current method has ended.
* Must be called exactly once for each call to {@link #asyncTraceBegin(long, String, int)}
* using the same tag, name and cookie.
*
* @param traceTag The trace tag.
* @param methodName The method name to appear in the trace.
* @param cookie Unique identifier for distinguishing simultaneous events
*
* @hide
*/
public static void asyncTraceEnd(long traceTag, String methodName, int cookie) {
if (isTagEnabled(traceTag)) {
nativeAsyncTraceEnd(traceTag, methodName, cookie);
}
}