在产生的日志中，你会发现一个标题为： Profile data in ms. 这一节包含为每个窗口所属应用产生的3列表格。 为了使用这些数据, 简单的复制表格到你喜欢的电子表格软件中就会生成一个堆叠柱状图表。下面的图是我的测量结果 (原始表格数据 可以在线查看.)
每列给出渲染每帧大概需要多长时间:
该图显然证实了我的怀疑:通常应用运行良好，不过有时候会运行帧率下降。 进一步观察
尽管我们收集的数据显示，应用有时候花费太久去渲染，但是这并不是全部的事实。帧刷新率也能够被没有调度或者错误调度的帧所影响。例如，一个应用总是以少于16ms的时间来画图，但是有时候在帧之间展现更长的任务，有时他将失去一个帧。 Systrace 是用于检查，一个Falcon Pro 是否在遭受这个问题最简单的工具。这个工具是一个具有非常低开销的系统分析工具。它的时域分析相当精确，并且给你展示了整个系统在做什么，包括你的应用。
为了让systrace起作用,进入Developer options并且选择Enable traces。一个对话框出现，并且让你选择你想要分析什么类型的事件。我们只关心Graphics 和 View。
为了使用systrace，打开一个终端，并从Android SDK的tools/systrace下运行systrace.py: $ ./systrace.py
默认该工具将捕获5秒钟的事件。我只是上下滚动主时间轴。跟踪结果是一个独立的HTML文件。
一个systrack文件展示了很多有趣的信息。比如，它表明你是否有一个进程计划在CUP。如果你放大到名为10440: m.jv.falcon.pro的最后一行，你能看到应用做了些什么。如果你查看performTraversals中的一块，你能看到应用绘制一帧消耗了多长时间。
虽然大多数的performtraversals低于16毫秒的临界值，但是有些需要更多的时间，这也证实了先前获得的测量结果（放大在935 MS标记看到这样一块。） 更有意思的是，你可以看到应用有时候会丢失一帧，因为它没有安排一个绘制操作。放大到标记为270毫秒的地方，找到deliverInputEvent 块，消耗25毫秒。这些块表示应用消耗25毫秒来响应用户触摸事件。由于应用程序是使用ListView，这可能是由于在适配器的一个问题，我们随后会回过头来讨论。 Systrace十分有用，不仅是它能检查应用消耗过多的是在绘制上，而且也能帮助我们找到其他的性能瓶颈。尽管它很有用，但是也存在自身的局限性。它只提供了高层次的数据，我们需要利用其他的工具才能明白它真正发生了什么。 可视化的透支
绘制性能问题可能有很多根本原因，但是其中一个常见的是透支。透支发生在应用每次向系统请求在其他物体上绘制内容。想像一个最简单的应用问题：一个白色背景的窗口，在它的上面一个按钮。当系统绘制按钮时，要绘制已存在的白色背景上。这就是透支。
透支是不可避免的，但是过多的透支就会产生问题。设备具有有限的内存带宽，如果透支导致你的应用请求资源超过了可用带宽，就是造成性能下降。不同设备可以明确负担透支的数量是变化的。
透支的存在也通常表示其他问题：太多的视图，层次结构复杂，通胀时间较长，等 Android提供了三个工具来识别和修复过度绘制: Hierarchy Viewer, Tracer for OpenGL 和 Show GPU overdraw。前两个可以在ADT或者独立的监控工具中找到。最后一个是开发这选项的一部分。 Show GPU overdraw 使用不用的颜色来绘制屏幕，来指示过度绘制在哪里发生以及程度如何。打开此选项然后别忘了关闭你自己的应用 – 未来的Android版本中将不再需要这样做。 |
