Android System trace分析

Posted maykea

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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的两种方法:

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分析的主要内容,如果未能解决你的问题,请参考以下文章

Android ANR log trace日志文件分析

??????????????????????????????????????????Android System Trace???

Android Runtime | Trace文件的生成机制

Android Runtime | Trace文件的生成机制

工利其器工具使用之Android System Trace篇官网翻译

工利其器工具使用之Android System Trace篇官网翻译