性能优化工具（二）-Systrace

1、简介

Systrace是分析Android性能问题的神器，Google IO 2017上更是对其各类强推. 是分析卡顿掉帧问题核心工具，只要能提供卡顿现场，systrace就能很好定位问题，可是有必定上手难度，因此会稍微花比较多的篇幅来学习，固然systrace配合traceView使用效果更佳，以后也会介绍traceView。

2、原理

在介绍使用以前，先简单说明一下Systrace的原理：它的思想很朴素，在系统的一些关键链路（好比System Service，虚拟机，Binder驱动）插入一些信息（我这里称之为Label），经过Label的开始和结束来肯定某个核心过程的执行时间，而后把这些Label信息收集起来获得系统关键路径的运行时间信息，进而获得整个系统的运行性能信息。Android Framework里面一些重要的模块都插入了Label信息（Java层的经过android.os.Trace类完成，native层经过ATrace宏完成），用户App中能够添加自定义的Label，这样就组成了一个完成的性能分析系统。另外说明的是：Systrace对系统版本有一个要求，就是须要Android 4.1以上。系统版本越高，Android Framework中添加的系统可用Label就越多，可以支持和分析的系统模块也就越多；所以，在可能的状况下，尽量使用高版本的Android系统来进行分析。

3、日志获取

3.1 AndroidStudio 抓取：

1）打开Android Device Monitor，选择要分析的进程(好比com.google.process.gapps)，点击Capture system wide trace using Android systrace（下图右上角箭头所指的地方）

2）配置须要抓取Systrace的内容

Trace duration 默认5秒，
Trace Buffer Size 默认2M，理论上，时间越长，须要的buffer越大
Enable Application Traces from : 选择要监控的app， 若是没有就选none
根据须要勾选要展现数据的内容。
生成trace.html 文件后，直接在浏览器中打开就能够。

3.2 命令行抓取（推荐）
命令行
python systrace.py [options] [category1] [category2] ... [categoryN]

配置好adb，python。

1）保持ADB device的链接；
2）cd 到systrace的目录下：如cd Library/Android/sdk/platform-tools/systrace;
3）好比我执行以下操做：

python systrace.py --time=10 -o mytrace.html sched gfx view wm

时间默认是5秒，在这5秒过程当中作对应的操做，mytrace.html即我生成的检测结果，在systrace中找到并用chrome打开。

抓取的过程就是：在执行以上命令以后，开始你对应的手机操做，最终生成trace的html文件供分析，固然咱们也发现了，命令后面带了一串参数：sched gfx view wm ，它决定了你的trace输出的数据包含哪些内容，若是trace数据太繁杂会让你眼花缭乱，因此缩小须要分析的数据集合会有助于咱们定位问题，所以下面来了解下这些参数有哪些，都是干吗的，对应的分析场景应该使用哪些。

先来了解下这些参数有哪些：

参数分为两个部分options和category

options可取值：

options	解释
-o <FILE>	指定trace数据文件的输出路径，若是不指定就是当前目录的trace.html
-t N, –time=N	执行时间，默认5s。绝对不要把时间设的过短致使你操做没完Trace就跑完了，这样会出现Did not finish 的标签，分析数据就基本无效了
-b N, –buf-size=N	buffer大小（单位kB),用于限制trace总大小，默认无上限
-k <KFUNCS>，–ktrace=<KFUNCS>	追踪kernel函数，用逗号分隔
-a <APP_NAME>,–app=<APP_NAME>	这个选项能够开启指定包名App中自定义Trace Label的Trace功能。也就是说，若是你在代码中使用了Trace.beginSection("tag"), Trace.endSection；默认状况下，你的这些代码是不会生效的，所以，这个选项必定要开启
–from-file=<FROM_FILE>	从文件中建立互动的systrace
-e <DEVICE_SERIAL>,–serial=<DEVICE_SERIAL>	指定设备，在特定链接设备上进行跟踪，由设备序列号标识 。
-l, –list-categories	这个用来列出你分析的那个手机系统支持的Trace模块，通常来讲，高版本的支持的模块更多

category可取值：

category	解释
gfx	Graphic系统的相关信息，包括SerfaceFlinger，VSYNC消息，Texture，RenderThread等；分析卡顿很是依赖这个。
input	Input
view	View绘制系统的相关信息，好比onMeasure，onLayout等。。
webview	WebView
wm	Window Manager
am	ActivityManager调用的相关信息；用来分析Activity的启动过程比较有效。
sm	Sync Manager
audio	Audio
video	Video
camera	Camera
hal	Hardware Modules
app	Application
res	Resource Loading
dalvik	虚拟机相关信息，好比GC停顿等。
rs	RenderScript
bionic	Bionic C Library
power	Power Management
sched	CPU调度的信息，很是重要；你能看到CPU在每一个时间段在运行什么线程；线程调度状况，好比锁信息。
binder_driver	Binder驱动的相关信息，若是你怀疑是Binder IPC的问题，不妨打开这个。
core_services	SystemServer中系统核心Service的相关信息，分析特定问题用。
irq	IRQ Events
freq	CPU Frequency
idle	CPU Idle
disk	Disk I/O
mmc	eMMC commands
load	CPU Load
sync	Synchronization
workq	Kernel Workqueues
memreclaim	Kernel Memory Reclaim
regulators	Voltage and Current Regulators

[options] 是一些命令参数，[category] 是你感兴趣的系统模块，好比view表明view系统（包含绘制流程），am表明ActivityManager（包含Activity建立过程等）；分析不一样问题的时候，能够选择不一样你感兴趣的模块。须要重复的是，尽量缩小须要Trace的模块，其一是数据量小易与分析；其二，虽然systrace自己开销很小，可是缩小须要Trace的模块也能减小运行时开销。好比你分析卡顿的时候，power, webview 就几乎是无用的。

经常使用的比较通用的命令：
./systrace.py -t 10 -a <package_name> -o xxtrace.html app sched gfx view am wm dalvik binder_driver freq idle load sync

4、工具简单使用介绍

使用Web浏览器打开HTML报告

该报告列出了呈现UI帧并指示沿时间线的每一个渲染帧的每一个进程。用绿色框架圆圈表示在16.6毫秒内渲染以保持每秒60帧稳定所需的帧。渲染时间超过16.6毫秒的帧用黄色或红色框架圆圈表示。

注意：
在运行Android 5.0（API级别21）或更高版本的设备上， UI 渲染的工做是在UI Thread和RenderThread两个线程完成。 在以前的版本中，建立框架的全部工做都是在UI Thread上完成的。

单击框架圆圈会突出显示它，并提供有关系统完成该框架所作工做的其余信息，包括警报。它还会向您显示系统在渲染该帧时执行的方法，所以您能够调查这些方法以获取UI jank的缘由。

点击黄色或红色帧按钮，会分析提示此帧卡顿的信息

选择慢帧后，您可能会在报告的底部窗格中看到警报。 上图中显示的Alert提出，框架的主要问题是在ListView回收和从新绑定中花费了太多的时间。 跟踪中有相关事件的连接能够解释更多关于系统在这段时间内正在作什么的事情。

要查看工具在trace中发现的每一个Alert以及设备触发Alert的次数，请单击窗口最右侧的Alerts选项卡，以下图所示。

Alerts面板可帮助您查看发生了哪些问题，以及发生的频率。 将Alert面板看做是要修复的错误列表， 一般状况下，一个区域的微小变化或改进能够消除应用程序中的所有警报。

若是你在UI Thread上作太多的工做，你须要找出哪些方法消耗了太多的CPU时间。

一种方法是添加跟踪标记到您认为会致使这些瓶颈的方法，以查看这些函数调用是否显示在systrace中。 若是您不肯定哪些方法可能会在UI线程上形成瓶颈，请使用Android Studio的内置CPU分析器，或者生成跟踪日志并使用Traceview查看它们。

固然除了看frame 红 黄 绿状态以及系统给出的描述以外，还有其余值得关注的点：

从app角度出发：

1）发现黄色 尤为是红色的帧，这种颜色表示超过了16ms的绘制要求了，那就看看两帧之间都作了些什么，缺乏信息的就打点trace进去。或者结合Traceview去排查方法耗时的问题。
2）systrace上task的运行状态:
灰色：Sleeping
蓝色：Runnable （它能够运行，可是须要等待调度程序唤醒)
绿色：Running
橙色：Uninterruptible sleep 因为 I/O 负载而不可中断休眠

尤为关注Runnable， 颇有可能wake by pid xxx , cpu此时被xxx进程抢占着，去看看这个进程是否有什么异常。

从framework层面出发：

这个流程是Surfaceflinger每隔16ms接收vsync信号进行layer合成的操做，看看这个操做自己是否就超过了16ms
SurfaceFlinger不了解的能够先看看这个系列的问题：Android图形系统篇总结

 

五 、Android 官方案例分析

最后给一个官方案例的分析来给点分析启发吧
https://source.android.com/devices/tech/debug/systrace