Android System trace分析 _Android

知识养成了思想,思想同时又在融化知识。这篇文章主要讲述Android System trace分析相关的知识，希望能为你提供帮助。
Systrace的原理：它的思想很朴素，在系统的一些关键链路（比如System Service，虚拟机，Binder驱动）插入一些信息（我这里称之为Label），通过Label的开始和结束来确定某个核心过程的执行时间，然后把这些Label信息收集起来得到系统关键路径的运行时间信息，进而得到整个系统的运行性能信息。android Framework里面一些重要的模块都插入了Label信息（java层的通过android.os.Trace类完成，native层通过ATrace宏完成），用户App中可以添加自定义的Label，这样就组成了一个完成的性能分析系统。
Systrace对系统版本有一个要求，就是需要Android 4.1以上，最好是Android 4.3以上（我相信这个已经不是什么问题了）；但是系统版本越高，Android Framework中添加的系统可用Label就越多，能够支持和分析的系统模块也就越多；因此，在可能的情况下，尽可能使用高版本的Android系统来进行分析；然后对待分析的App也有一个限制——需要是debuggable的。
一、生成Systrace的两种方法：
【Android System trace分析】1、使用命令

cd $ANDROID_HOME/platform-tools/systrace
./systrace.py -t 10 sched gfx view wm am app webview -a < package-name>

这样，`systrace.py` 这个脚本就通过adb给手机发送了收集trace的通知；与此同时，切换到手机上进行你需要分析的操作，比如点击Launcher中App的Icon启动App，或者进入某个Activity开始滑动ListView/RecyclerView。经过你指定的时间之后（以上是10s），就会有trace数据生成在当前目录，默认是 `trace.html`；用Chrome浏览器打开即可。
`systrace.py`命令的一般用法是：

systrace.py [options] [category1 [category2 ...]]

其中，`[options]` 是一些命令参数，`[category]` 等是你感兴趣的系统模块，比如view代表view系统（包含绘制流程），am代表ActivityManager（包含Activity创建过程等）；分析不同问题的时候，可以选择不同你感兴趣的模块。需要重复的是，尽可能缩小需要Trace的模块，其一是数据量小易与分析；其二，虽然systrace本身开销很小，但是缩小需要Trace的模块也能减少运行时开销。比如你分析卡顿的时候，`power`, `webview` 就几乎是无用的。
2、使用Monitor
打开/sdk/tools/monitor,点击Systrace图标，填写需要的信息，点击“OK”，开始抓取。

文章图片

文章图片

`[option]` 中比较重要的几个参数如下：

-a < package_name> ：这个选项可以开启指定包名App中自定义Trace Label的Trace功能。也就是说，如果你在代码中使用了`Trace.beginSection("tag")`, `Trace.endSection`；默认情况下，你的这些代码是不会生效的，因此，这个选项一定要开启！
-t N：用来指定Trace运行的时间，取决于你需要分析过程的时间；还是那句话，在需要的时候尽可能缩小时间；当然，绝对不要把时间设的太短导致你操作没完Trace就跑完了，这样会出现`Did not finish` 的标签，分析数据就基本无效了。
-l：这个用来列出你分析的那个手机系统支持的Trace模块；也就是上面命令中 `[category1]`能使用的部分；不同版本的系统能支持的模块是不同的，一般来说，高版本的支持的模块更多。
-o FILE：指定trace数据文件的输出路径，如果不指定就是当前目录的`trace.html`。

`systrace.py -l` 可以输出手机能支持的Trace模块，而且输出还给出了此模块的用途；常用的模块如下：

`sched`: CPU调度的信息，非常重要；你能看到CPU在每个时间段在运行什么线程；线程调度情况，比如锁信息。
`gfx`：Graphic系统的相关信息，包括SerfaceFlinger，VSYNC消息，Texture，RenderThread等；分析卡顿非常依赖这个。
`view`: View绘制系统的相关信息，比如onMeasure，onLayout等；对分析卡顿比较有帮助。
`am`：ActivityManager调用的相关信息；用来分析Activity的启动过程比较有效。
`dalvik`: 虚拟机相关信息，比如GC停顿等。
`binder_driver`: Binder驱动的相关信息，如果你怀疑是Binder IPC的问题，不妨打开这个。
`core_services`: SystemServer中系统核心Service的相关信息，分析特定问题用。

二、Systrace跟踪代码
(1).应用层代码添加systrace跟踪方式:

Trace.beginSection(“TEST”);
Trace.endSection();

(2).framework的java层代码添加systrace跟踪方式:

Trace.traceBegin(Trace.TRACE_TAG_VIEW, “performTraversals”);
Trace.traceEnd(Trace.TRACE_TAG_VIEW);

也可以使用：

ATRACE_BEGIN(“TEST”);
ATRACE_END();

(3).framework的native代码添加systrace跟踪方式:

ATRACE_INIT();
ATRACE_CALL();

三、生成的trace如下所示：

文章图片

基本操作：W、A、S、D（左右移动、放大缩小）

这样，我们就学会了Systrace的使用；命令本身并不复杂，不过与TraceView相比，易用性差远了——但这是值得的，使用上的不便换来了极低运行时开销，而这对分析性能问题尤为重要。

参考文档：手把手教你使用Systrace（一）https://blog.csdn.net/weixin_38570262/article/details/78479064