一、简介
Systrace是分析Android性能问题的神器，Google IO 2017上更是对其各种强推. 是分析卡顿掉帧问题核心工具，只要能提供卡顿现场，systrace就能很好定位问题，但是有一定上手难度，所以会稍微花比较多的篇幅来学习，当然systrace配合traceView使用效果更佳，之后也会介绍traceView。
二、原理
在介绍使用之前，先简单说明一下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.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 | 指定trace数据文件的输出路径，如果不指定就是当前目录的trace.html |
| -t N, –time=N | 执行时间，默认5s。绝对不要把时间设的太短导致你操作没完Trace就跑完了，这样会出现Did not finish 的标签，分析数据就基本无效了 |
| -b N, –buf-size=N | buffer大小（单位kB),用于限制trace总大小，默认无上限 |
| -k ，–ktrace= | 追踪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
四、工具简单使用介绍
使用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
