systrace的简单使用
1.安装python并配置python环境变量
注意：
- Systrace.py的使用需要安装python 2.7，不能用python 3.x。
安装完成后输入python systrace.py -l如下图所示证明安装成功。
- 若提示
ImportError: No module named win32con则输入pip install pypiwin32
安装win32con模块。
2.输入命令，执行待分析的操作，获取trace.html文件
在android sdk下trace目录下执行形如python systrace.py [options] [category1] [category2] ... [categoryN]的命令，同时打开待分析app并执行相应操作，便能得到可供分析的trace.html文件。
命令用法
python systrace.py [options] [category1] [category2] ... [categoryN]
options
其中options可取值：
category
category可取值：
[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的相关信息，分析特定问题用。
示例：
3.用浏览器打开并分析trace.html文件
浏览器打开trace文件后如下图所示：
横坐标是以时间为单位，纵坐标是以进程-线程的方式来划分，同一进程的线程为一组放在一起，可收缩/展开。 systrace会记录下所有进程在所给时间内的表现。
Frames
在每个app进程，都有一个Frames行，正常情况以绿色的圆点表示。当圆点颜色为黄色或者红色时，意味着这一帧超过16.6ms（即发现丢帧），这时需要通过放大那一帧进一步分析问题。
Alerts
Systrace能自动分析trace中的事件，并能自动高亮性能问题作为一个Alerts，建议调试人员下一步该怎么做。比如对于丢帧是，点击黄色或红色的Frames圆点便会有相关的提示信息；另外，在systrace的最右上方，有一个Alerts tab可以展开，这里记录着所有的的警告提示信息。
模式切换
- Select mode: 双击已选定区能将所有相同的块高亮选中；（对应数字1）
- Pan mode: 拖动平移视图（对应数字2
- Zoom mode:通过上/下拖动鼠标来实现放大/缩小功能；（对应数字3）
- Timing mode:拖动来创建或移除时间窗口线。（对应数字4）
可通过按数字1~4，用于切换鼠标模式； 另外，按住alt键，再滚动鼠标滚轮能实现放大/缩小功能。
如何定位到自己打个tag
/ 搜索关键字搜索到后，再m定位到区域。
Systrace小结
特性
- 结合Android内核的数据，生成Html报告。
- 系统版本越高，Android Framework中添加的系统可用Label就越多，能够支持和分析的系统模块也就越多。
- 必须手动缩小范围，会帮助你加速收敛问题的分析过程，进而快速地定位和解决问题。
作用
- 主要用于分析绘制性能方面的问题。
- 分析系统关键方法和应用方法耗时。
如何分析非Debug的App
systrace官方文档说待trace的App必须是debuggable的，但是官方又说，debuggable的App与非debuggable的性能有较大差别；因为系统为了支持debug开启了一些列功能并且关闭掉了某些重要的优化，如果我们想要待分析的App尽可能接近真实情况，那么必须要在非Debug的App中能启用systrace功能；因为相同情况下Debug的App性能比非Debuggable的差，你无法确保在debuggable版本上分析出来的结论能准确推广到非debuggable的版本上。
分析systrace源码之后 ，发现这个条件只是个障眼法而已；我们可以手动开启App的自定义Label的Trace功能，方法也很简单，调用一个函数即可；但是这个函数是SDK @hide的，我们需要反射调用：
Class<?> trace = Class.forName("android.os.Trace");
Method setAppTracingAllowed = trace.getDeclaredMethod("setAppTracingAllowed", boolean.class);
setAppTracingAllowed.invoke(null, true);
把这段代码放在Application的attachBaseContext 中，这样就可以手动开启App自定义Label的Trace功能，在非debuggable的版本中也适用！
