1 systrace工具版本升级
升级入口：Androidstudio-->Tools-->Android-->SDK Manager
这个是当前的版本，经过测试，老版本的sdk tools抓出来的trace用chrome浏览器打开的时候存在各种问题，建议升级一下。
2 打开Monitor
monitor入口:
（1）Android studio-->Tools-->Android-->Android Device Monitor
（2）进入sdk路径/tools，双击monitor.bat脚本
3 抓systrace文件
确认手机连上以后，点击上面的图标，出现：
滑动需要检测的应用，5s后会生成trace.html文件。
4 trace文件分析
生成trace文件以后，直接拖拽到浏览器中即可打开，若打开失败，可以尝试先在浏览器中输入: chrome://tracing/，然后load对应的trace文件即可。
载入后，初始情况大概是上面这样，主要分析一下两个进程：
（1）SurfaceFlinger进程:pid 283
（2）小米商店com.xiaomi.market进程:pid 6363
常用快捷键，在网页的右上角有一个问号，点击问号会列出所有的快捷键：
其中有几个比较重要的快捷键：
图中是点击了g和v以后的效果，其中红色的竖线代表的是60hz线，固定的每个间隔是16.6ms，可以将鼠标模式设置为Timing mode(键盘4)，然后鼠标点击，可以看出每个点的具体时间。
右侧的Alerts标签，代表的自动检测出来的卡顿原因：
点检这些Alerts标签会在下方给出解释。
最后，对于每一个应用而言，在对应的UI
Thread中会有一个”F”标签，鼠标点击一下变成黄色，再按”m”键会出现下面的情况。
被黑色框圈出来的部分，就是应用在当前帧中处理的事情，从这里可以看出大致的卡顿原因，具体的耗时还要结合method trace去看。
上面”F”标记共有红、黄、绿三种颜色：
其中红色代表的是严重卡顿，黄色代表卡顿，绿色代表还能处理。
5 说明
本文只是简单的介绍systrace的简单分析方法，防止后面再用的时候出现遗忘，具体相关的VSYNC的原理可以参照我的两篇博客，这里不做说明：
（1）Android垂直同步信号VSync的产生及传播结构详解
注意点：
系统最原始VSYNC信号是由硬件产生的，SurfaceFlinger进程接收到该信号后，会将信号发给需要重绘的应用，应用接收到信号后UI线程开始重绘(CPU处理)，然后将重绘的请求发送至RenderThread(触发GPU处理？这一点未确认…)，注意应用重绘的这一帧最早也要到下一个刷新周期才能展示；同时SF自身开始合成当前帧，最终送到Display展示，这里SF使用的是上一帧应用重绘的缓冲区；这里应该是引入的双缓冲机制（但是有关GPU的处理比较复杂，还是没有对应上，这里的理解可能不对，欢迎拍砖）。
