Android性能个案研究

该Photoshop文档以每一个视图一个层次的方式展示了该应用。每一层都被标记为可见或不可见，可以通过View.getVisibility()的返回值来查看。每一层都以它所属的视图来命名，或者是android:id 或者是类名。我曾经尝试添加分组支持来重建视图树…我真应当好好完成该功能。

通过检查层级列表,我们可以快速的确认至少一个过度绘制的原因：多重全屏背景。第一个背景是第一层视图，称为DecorView。该视图是Android系统创建的，包含了主题中定义的背景。系统中渐变的默认设置是不可见的，所以可以安全的把它去除掉。

进一步减少过度绘制

Photoshop文档有助于理解应用是如何构建的，但是用它来消除小区域的过度绘制时就有些困难了。现在我们必须转向Tracer for OpenGL。打开ADT (或监视器)中的同名视图，然后点击工具条中的箭头图标。输入你app的包名和主Activity的名称，然后选择一个目标文件并点击Trace。

建议: 获取OpenGL跟踪是大任务并且很耗时。要使该任务更轻便更快，请勿勾选所有的Data Collection Ooptions 复选框。

Activity 名称: 当你运行一个应用时，logcat会展示包和Activity的名称。这就是我怎么知道在Tracer for OpenGL中该敲入些什么的原因。

当应用启动起来，打开前两个设置。

• Collect Framebuffer contents on eglSwapBuffers()
• Collect Framebuffer contents on glDraw*()

第一个有用的选项能帮助你快速的找到感兴趣的帧。第二个选择让我们看到每个帧由绘图命令绘制命令。第二个选项是解决透支问题的关键。

这两个选项使我开始滚动主时间轴。它将消耗很长时间去捕捉每一帧（不出意外是30秒）所有我建议你直接下载我的捕获跟踪.你可以通过点击工具栏上的第一个按钮在Tracer for OpenGL打开文件。