想想自己写的什么垃圾代码导致Vsync不能及时处理#(不高兴)
想不开？
实际开发中性能问题不好复现？这你就可能需要一些工具来帮你检测这种情况。
首先是Android系统自带的工具（4.1之后的版本），Profile GPU rending（GPU呈现分析），点击打开“以条形展示”之后，手机屏幕下方和上方会出现频谱，这个图有四个颜色的柱子，分别对应：
蓝色：绘制时间，即创建和更新DisplayList的时间。蓝色线较高的地方，代表有可能有些任务需要重新绘制，或者onDrow方法中处理的事情太多了。
红色：执行时间，即Android进行2D渲染DisplayList中的任务的时间。红线较高时，可能是因为重新提交了视图。
橙色：处理时间，即CPU告诉GPU需要渲染一帧的时间，这是一个阻塞调用，因为CPU会一直等GPU的回复命令。如果橙线很高，代表GPU繁忙或者处理任务多
紫色：将资源转移到渲染线程的时间。仅在Android 4.0以上提供。
效果大概如图：
其中的绿线代表16ms，那么，每个柱状图超过绿线，说明又一次卡顿（jank）。
这种效果虽然看起来很直观，但是在开发中难以用于分析。我们可以通过：
adb shell dumpsys gfxinfo xxx.xxx.xxx（包名）来输出日志。其实偶尔丢失几帧很正常，但是我们要找出是什么UI问题导致绘制时间较长的。然后就可以找到你的垃圾代码了啦，是不是很厉害呢？
接下来还有更厉害的工具：TraceView
TraceView是AndroidSDK自带的工具，用来查看Trace文件视图。会产生一个图标，可以分析到每个应用每个方法所用的时间。使用TraceView需要先有个Trace日志文件，这个文件的获取方法有两种：
1.在DDMS中使用
首先打开DDMS。AndroidStudio则为Android Device Monitor。但是在AndroidStudio3.0+版本中，ADM已经被弃用了。我们需要在
android-sdk/tools/目录的命令行中输入monitor。注意，这里必须安装JDK环境。链接设备后，点击Start Method Profiling。在监控完成之后，点击Stop Method Profiling即可。结束后会自动跳转到TraceView。
2.在代码中使用
这个方法更简单，但是却没有那么方便。直接在代码中需要开始监控的地方调用startMethodTracing()方法，在结束的时候调用stopMethodTracing()方法即可。startMethodTracing需要输入文件名参数，例如
startMethodTracing("logs")，将会在SD卡目录下生成名为log.trace的文件。在Android4.4+的版本中，降低了对Trace文件分析次数，从而降低对性能的影响。但是精准度缺不会有很大的偏差。
我们再来说一下，TraceView工具怎么使用。