做过性能优化的人对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就能看到如下界面
图片1.png
选择要分析的应用进程并点击按钮
图片2.png
图片3.png
根据需要选择相应的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文件可以看到类似下面的图
图片4.png
其中需要重点关注带有F的圆点，表示一帧，即frame，流畅的界面显示需要保证每秒60帧的速率，即要求每一帧花费的时间不能超过16ms，否则就会造成卡顿和掉帧，只用圆点为绿色的时候才表示这一帧没有超过16ms，其他都是大于16ms，变红则表示严重超时，可以点击对应的按钮并按M键看到精确的时间消耗，然后就可以定位到具体耗时的地方并加以优化
图片5.png
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);
}
}
网友评论