Android System trace分析

标签：java   卡顿   img   一般来说   cti   frame   选择   work   包含   

　　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的两种方法：

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

Android System trace分析

标签：java   卡顿   img   一般来说   cti   frame   选择   work   包含   

原文地址：https://www.cnblogs.com/maykea/p/10249781.html