关于“输入”事件：记不记得当我们查看systrace并且发现，当处理触摸事件的时候会有些卡顿？现在，是时候来追踪这个 问题了，traceview是我们去明晰系统正在做什么的最好工具。 Traceview是一个记录应用在调用某个方法花费多少时间的虚拟机分析器。可以在ADT的DDMS视图或者monitor中启动他， 在Devices tab中选择你应用进程，然后点击Start method profiling按钮。红色环绕的三个箭头。 在开启追踪之后，我来回滑动主时间轴，并且重新点击按钮来结束trace。你也可以下载我的追踪记录： 结果如下图截屏所示。 
点击第#21，ViewRootImpl.draw().高亮绘制时间。表格中最后一行给你一个建议关于如何平均花在这个方法和起子方法 的时间。如你使用高亮来仔细看这时间轴，你将会注意到在连续frames之间的间隙。 一个最简单找出这些在这些间隙中到底发生了什么方法就是（选择他们其中一个的开始部分进行放大，然后点击你能发 现的最大色块）你追踪父子链（parent chain）直到找到你可以辨识出来的东西。在我的例子中，我追踪一个花费了平 均时间的0.5ms的叫Patter.compileImpl，所有都指向了DBListAdapter.bindView。 显然每次一旦有新的item被绑定或者滑动主时间轴时，应用都会重新一遍一遍的编译这相同的正则表达式。Traceview展 示了绑定一个View平均花费38ms并且有56%的时间花费在解析HTML文本上。这看起来某些东西可以被可以在后台实现而不 是阻塞UI线程，正则表达式不应该每次都要重新编译。 接下来看你的了！ 我留下最后一个trace作为练习。这个应用在两边有两个菜单，可以通过敲击时间线的左边或者右边来显示。（在显示这 菜单时GPU overdraws 高亮了过度绘制的部分，我已经使用Tracer for OpenGL来获取了这个问题的几帧。下载我的 trace然后看看你是否能找到什么导致了overdraw(作者提示go to frame #34)。 提示就不翻译了： Hints: the application should use hardware layers by calling View.setLayerType() to simplify drawing. There are also extraneous backgrounds that can be optimized away with clever use of 9-patches. Clipping could also be very helpful. Finally, maybe a ColorFilter set on a Paint passed to setLayerType() could help remove the last drawing command. 【后语：最好使用Monitor，鄙人在使用ADT的时候老出错。   |
