Android 的性能工具用法 I-渲染分析工具

概述:

将像素放到屏幕上涉及到了硬件的四个主要部分. 简单来说, CPU计算要显示的列表, GPU渲染要显示的图像, 内存保存图像和数据, 然后电池为它们提供能量. 硬件的每个部分都是有限的: 超出这些限制会使得你的APP运行速度减慢, 并拥有不良的显示性能, 或者更容易耗尽电量.

想要发现是什么导致了你的APP的性能问题, 你需要观察一下在APP幕后都发生了什么, 使用工具来收集APP执行的行为, 并用列表和图形来显示数据, 理解并分析你看到的数据, 然后提高你的代码性能. Android Studio和你的设备都提供了工具来记录和可视化这些数据, 包括渲染, 计算, 内存和电池性能.

渲染分析工具:

可以可视化APP的渲染行为和性能. 包括:

l  调试GPU超量绘制操作实例: 使用颜色编码器来显示每个像素被重绘了多少次, 通过这来减少重绘以提高性能.

l  GPU性能分析渲染操作实例: 在设备上覆盖一张图表, 用来表示渲染UI的时间.

l  Hierarchy Viewer的设置;

l  Hierarchy Viewer实例: 可视化的View层可以帮你简化自己的APP.

下面逐一介绍;

 

 

调试GPU超量绘制操作实例:

这个实例演示了如何在设备上通过颜色编码来可视化超量绘制. 这样做的好处是:

l  展示一个APP在何处做了不必要的渲染.

l  帮助你查看在哪里可以减少渲染.

先决条件:

一个开启了开发选项的移动设备.

在设备上开启超量绘制视图:

1.      在设备上打开Settings并点击Developer Options.

2.      在Hardware accelerated rendering中, 选择Debug GPUOverdraw.

3.      在Debug GPU overdraw弹出窗口中, 选择Show overdraw areas.

         图1, 设置开启Debug GPUOverdraw.

4.      屏幕这时候会变得花花绿绿的. 这些颜色是用来帮助你诊断应用程序的显示行为的.

         图2, Debug GPUOverdraw输出的例子.

5.      这些颜色用于表示每个像素被重绘的次数, 含义如下:

a)        真实颜色: 没有被重绘.

b)        蓝色: 重绘一次.

c)        绿色: 重绘两次.

d)        粉色: 重绘三次.

e)        红色: 重绘四次或更多次.

图3, Debug GPUOverdraw输出的颜色说明.

6.      有些重绘是不可避免的. 你应该调整你的APP的用户界面, 目标是让大部分的屏幕都是真实的颜色以及重绘一次的蓝色.

         图4, Debug GPUOverdraw不建议和建议的输出.

分析GPU渲染操作实例:

这个实例演示了如何使用移动设备上的Profile GPU Rendering. Profile GPU Rendering会为你提供一个快速的可视化方法来表明渲染UI的帧所需要的时间(是相对于16ms/帧的基准, 而不是绝对的时间). 这可以提供这些好处:

l  可以快速的看出UI执行速度(相对于16ms/帧的基础速度).

l  识别出任何渲染管道是否存在超出处理时间的情况.

l  找出与用户或程序动作相关的帧渲染时间的峰值.

先决条件:

一个移动设备, 运行着至少Android 4.1的系统并开启开发者选项.

使用Profile GPU Rendering:

1.      在设备上选择Settings>Developer Options.

2.      在Monitoring选项中, 选择Profile GPU Rendering.

3.      在Profile GPU Rendering弹出菜单中, 选择On screen as bars来覆盖在屏幕上的图片.

4.      到想要分析的APP中.

图5, 打开Profile GPU Rendering.

你会看到:

l  该工具会为每个可见的APP显示一个图表.

l  水平轴显示时间流逝, 垂直轴表示每帧经过的时间,单位是毫秒.

l  随着你跟你的APP交互, 垂直栏会显示在屏幕上, 从左到右移动, 随着时间推移绘制帧的性能.

l  每个垂直栏表示渲染了一帧.更高的栏表示渲染的时间更长.

l  绿色的线是用于标记16毫秒的分隔线. 每次有一帧超过了绿线, 你的APP就会丢失一帧, 这时你的用户可能会看到一帧卡顿的图片.

图6, 当Profile GPU Rendering开启时的屏幕.

Profile GPU Rendering图表:

图7, 放大并注释的Profile GPU Rendering图.

在上面这张放大的图片中, 你可以看到图形的彩色部分, 并看到每种渲染的线代表什么.

l  绿线表示16毫秒基线. 要获得60帧每秒的帧率, 每帧的垂直线则应该在16毫秒基线以下. 任何超出这条线的情况, 都可能会导致动画的卡顿.

l  每条线都有一个蓝色, 紫色(只能在Android4.0及以上使用), 红色, 和橙色的组成部分.

l  线的蓝色的部分表示创建和更新View显示列表所需要的时间. 如果这部分很高的话, 意味着可能有很多的自定义绘制或者在onDraw()方法中做了过多的事情.

l  在Android 4.0及更高版本中, 紫色的部分表示花费在转换资源到渲染线程所需要的时间.

l  红色部分则表示Android的2D renderer发出的OpenGL绘制和重绘显示列表的命令所需要的时间. 这部分的高度则表示每个显示列表的执行时间的和, 更多显示列表意味着更高的红色线.

l  橙色的部分表示CPU正在等待GPU完成它的工作. 如果这部分过高, 则意味着APP让GPU做了太多的工作了.

注意: 这个工具叫做Profile GPU Rendering, 所有被监测的过程实际上都是发生在CPU中的. 渲染通过提交命令给GPU而实现, GPU异步渲染屏幕. 在某些情况下, GPU可能得执行过于繁重的任务,这时候你的CPU不得不等待GPU完成才能提交新的任务. 当这样的情况发生时, 你将会在Process部分(橙色)和执行部分(红色)看到峰值, 并且命令的提交在GPU命令队列腾出更多空间之前会阻塞.

Hierarchy Viewer的设备设置:

这个实例展示了Hierarchy Viewer的基本用法和使用流程. Hierarchy Viewer工具视觉化APP的view层并分析相关view的渲染速度. 它可以提供的好处有:

l  简化你的View层, 减少超量绘制, 并使得它更加容易管理.

l  找到你的view层中可能存在渲染性能瓶颈的相关结构和形状.

先决条件:

l  一个支持HierarchyView工作的移动设备:

n  你必须在移动设备上启用开发者选项. 你必须使用一个物理设备来得到准确的测量值.

n  在连接到移动设备的桌面设备上设置一个ANDROID_HVPROTO环境变量. 在Windows下可以这样设置: 打开环境变量, 添加名称ANDROID_HVPRORO, 值:ddm, 点击OK.

n  如果设备运行在加锁的Android4.0或者更低版本中, 需要安装并配置ViewServer. 否则将无法连接.

l  可调式的APP代码, 并有view层. 使用你自己的代码, 或者Sunshine栗子中的代码.

Hierarchy Viewer基本介绍:

1.      连接设备跟电脑.

2.      打开Android Studio, 编译源码并在设备上运行.

3.      在Android Studio中选择Tools>Android>Android Device Monitor来打开Monitor.

4.      在设备上选择USB Debugging(如果询问了的话).

图1(太长了, 重新用图1), 启动Android Device Monitor.

5.      图2显示了Device Monitor工具在最开始的时候显示的样子. 这取决于你的设置.

        

         图2, AndroidDevice Monitor.

确保你的设备和APP包显示在了Device(DDMS模式)或者Windows(HierarchyView模式)页面中. 你可以选择Window>Reset Perspective来回到默认的布局.

6.      在Android Device Monitor(ADM)中, 在菜单栏里选择Window>OpenPerspective并在弹出的的窗口中点击Hierarchy View.

图3

7.      打开之后会显示一个这样的面板:

         图4, HierarchyViewer 布局.

8.      双击Windows页面中你的APP. 这会使APP的view层信息显示在面板上. 这会显示一个APP的静态完整View层. 可以调整尺寸来显示更多的布局.

图5, Hierarchy Viewer.

9.      如果必要的话, 点击Layout View页面来隐藏控制台并显示一个layout的框. 当前选中的view的边框是红色的. 点击一个边框来选择它.

图6, Hierarchy Viewer面板.

10.  其余的面板:

a)        右上角的Tree Overview为你提供一个APP完整View层的鸟瞰视角.

b)        在Tree Overview中, 移动灰色的矩形窗口来改变你想要看到的部分.

c)        在TreeView中, 你可以用鼠标来拖拽和缩放tree.

11.  点击一个View节点来显示详情. 这是某个节点注释的特写以及详情.

图7, View节点的一部分.

12.  点击右上角的View Properties页面(挨着Windows页)来查看选中的View节点的属性.

         图8, ViewProperties页

13.  双击Tree View中的一个View节点来在一个弹出窗口中渲染它.

图9, 在弹出窗口中渲染一个View.

14.  Tree View中的节点会显示一个类型, 这个类型描述了View类和ID.

图10, 节点的类型和ID.

使用Hierarchy Viewer分析:

1.      启动Hierarchy Viewer.

2.      在Tree View或者LayoutView中, 点击想要分析的View节点.

3.      要开始分析, 点击Tree View顶部的三色小按钮.

4.      对于较大的View层, 分析可能会稍微有点慢.

5.      每个View都有三个点, 可以是绿色, 黄色, 或者红色. 其中,

a)        左边的点表示渲染通道的绘制过程.

b)        中间的点表示Layout阶段.

c)        右边的点表示Execute阶段.

图11, 用于分析的View层.

6.      这些点大概对应测量, 布局, 和绘制阶段.

7.      这些点的颜色代表处理的效率.

a)        绿色表示View渲染至少比其它的一半的view快.

b)        黄色表示View渲染比其它View的较慢的那一半要快.

c)        红色表示View是最慢的那一半的View.

图12, 点的颜色对应的渲染通道.

解读Hierarchy Viewer分析结果:

Hierarchy Viewer测量的是节点的相对性能, 所以在一个分析文件里总是会有红点, 这并不一定就意味着view运行速度太慢. Hierarchy Viewer会用软件光栅化(rasterizes)你的Activity来获取时间信息. 光栅化就是将顶点数据转换成片元的过程, 比如一个圆形或一个矢量字体, 并将其转换为屏幕上的像素. 通常, 光栅化由GPU完成, 但是在一些软件化的光栅化过程中, 渲染是由CPU使用普通软件完成的. 这意味着绝对计时报告相对于彼此是正确的, 但是会根据设备和PC而有所不同. 需要多次分析来获取平均测量值. 下面是解读Hierarchy Viewer输出的分析.

红色的节点在任何APP运行缓慢的情况下都是可能的问题. 咋相关的设置中, 总有一个最慢的节点; 确保它是你期待的节点. 下面的栗子演示了如何解读红色节点:

l  查找叶节点或者view组中只有少量children的红色节点. 这可能会指出一个问题. 你的APP或许并不慢, 或者是在你的设备上并不慢,但是你需要小心为啥它是红的, Systrace或者Traceview可以给你一些额外的建议.

l  如果你拥有一个有很多children的view组和一个红色的测量值, 在children中查看一下, 它们是如何执行的.

l  一个拥有黄点或者红点的View可能并不会在设备上执行的很慢. 这就是实际数据有帮助的地方. Systrace或者Traceview可以为你提供更多的信息.

l  如果view层的根节点拥有一个红色的测量值, 红色的layout值, 和黄色的绘制值, 那么这在某种程度上是一个典型的现象, 因为它是所有其它的view的parent.

l  如果一个拥有20+个view的叶节点并拥有一个红色的绘制值, 那么这是一个问题. 应该检查你的onDraw()方法.

 

参考: http://developer.android.com/tools/performance/index.html

http://developer.android.com/tools/performance/hierarchy-viewer/index.html