最近项目需要测试游戏，就开始学习app客户端性能方面的知识，经过一段时间的的学习和研究，有初步的测试方案，今天正好是周末，就抽出时间来进行总结一下，内容分为系列来写，这是系列开头篇，性能指标之一的过度绘制，后面会陆续补写其它内容
1、什么叫做过度绘制
屏幕上某一像素点在一帧中被重复绘制多次，就是过度绘制
过度绘制就是在同一个区域中叠加了多个控件，也就是说一个像素点上会出现多个像素的叠加，实际上呈现在我们眼前的只是最上面的一个，往往造成这种现象的原因是产品或者视觉过多繁琐的建议和交互，或者是开发人员自己不注意造成的，这样就会浪费大量的CPU以及GPU资源。过度绘制最直观的影响就是会导致APP卡顿
2、过度绘制的原理
先看下客户端界面显示的过程，这个过程告诉我们,一个App产品开始设计之初，或者说开始开发的时候，合理的布局是多么的重要
(1)布局文件是一个xml文件，inflate布局文件其实就是解析xml，根据标签信息创建相应的布局对象并做关联。xml中的标签和属性设置越多，节点树的深度越深，在解析时要执行的判断逻辑、函数的嵌套和递归就越多，所以时间消耗越多；
(2)inflate操作只是布局影响的第一个环节，一个界面要显示出来，在requestLayout后还要执行一系列的measure、layout、draw的操作，每一步的执行时间都会受到布局本身的影响。而界面的最终显示是所有这些操作完成后才实现的，所以如果布局质量差，会增加每一步操作的时间成本，最终显示时间就会比较长
Android系统是如何处理UI组件的更新操作的，主要包含以下4个步骤：
（1）Android需要把XML布局文件转换成GPU能够识别并绘制的对象。这个操作是在DisplayList的帮助下完成的。DisplayList持有所有将要交给GPU绘制到屏幕上的数据信息。
（2）CPU负责把UI组件计算成Polygons，Texture纹理，然后交给GPU进行栅格化渲染。
（3）GPU进行“栅格化（转化为像素）”渲染。
（4）硬件展示在屏幕上。
每次从CPU转移到GPU是一件很麻烦的事情，所幸的是OpenGL ES可以把那些需要渲染的文理Hold在GPU的Memory里面，在下次需要渲染的时候直接进行操作。Android里面那些由主题所提供的资源，例如Bitmap，Drawables都是一起打包到统一的Texture文理当中， 然后再传递到GPU里面，这意味着每次你需要使用这些资源的时候，都是直接从文理里面进行获取渲染的。当然随着UI组件的越来越丰富，有了更多演变的形态。例如显示图片的时候，需要先经过CPU的计算加载到内存中，然后传递到GPU进行渲染。文字的显示更加复杂，需要先经过CPU换算成纹理，然后再交给GPU进行渲染，回到CPU绘制单个字符的时候，再重新引用经过GPU渲染的内容。动画则是一个更加复杂的流程。
接下来看下Goolge官网的一个解释
3、测试的时候查看App是否存在过度绘制
（1）点击进入“设置”；
（2）点击进入“开发者选项”
（3）选中“调试GPU过度绘制”
（4）选中“显示过度绘制区域”
接着我拿一个竞品和我们自己的产品进行分析了一下（相同手机下进行相同的扫描返回主界面后的效果）
先看下竞品的
再看下我们自己的（哈哈，非常严重的过度绘制，性能稍微差点的手机，我们的产品比竞品卡顿多了，这是有原因的）
屏幕上不同的颜色代表的含义，这是官网给的解释
一般App的验收标准：
（1）控制过度绘制为2x
（2）不允许存在4x过度绘制
（3）不允许存在面积超过屏幕1/4区域的3x过度绘制（淡红色区域）
4、怎么避免过度绘制
下面引用一位开发者的建议
作者：Gracker
本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
即是要尽量减少屏幕上的红色区域，增加屏幕上的蓝色和绿色区域。我们的目标是要控制界面最多被过度绘制2次（不出现粉色和红色）
1. 尽量多使用RelativeLayout和LinearLayout, 不要使用绝对布局AbsoluteLayout，
1. 在布局层次一样的情况下， 建议使用LinearLayout代替RelativeLayout, 因为LinearLayout性能要稍高一点.
2. 在完成相对较复杂的布局时,建议使用RelativeLayout,RelativeLayout可以简单实现LinearLayout嵌套才能实现的布局.
2. 将可复用的组件抽取出来并通过include标签使用；
3. 使用ViewStub标签来加载一些不常用的布局；
4. 动态地inflation view性能要比SetVisiblity性能要好.当然用VIewStub是最好的选择.
5. 使用merge标签减少布局的嵌套层次
6. 去掉多余的背景颜色
当我们使用了Android自带的一些主题时，window会被默认添加一个纯色的背景，这个背景是被DecorView持有的。当我们的自定义布局时又添加了一张背景图或者设置背景色，那么DecorView的background此时对我们来说是无用的，但是它会产生一次Overdraw，带来绘制性能损耗。去掉window的背景可以在onCreate()中setContentView()之后调用
getWindow().setBackgroundDrawable(null);
或者在theme中添加
android:windowbackground="null"；
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
7. 对于有多层背景颜色的Layout来说,留最上面一层的颜色即可,其他底层的颜色都可以去掉
8. 对于使用Selector当背景的Layout(比如ListView的Item,会使用Selector来标记点击,选择等不同的状态),可以将normal状态的color设置为”@android:color/transparent”,来解决对应的问题
9. 内嵌使用包含layout_weight属性的LinearLayout会在绘制时花费昂贵的系统资源，因为每一个子组件都需要被测量两次。在使用ListView与GridView的时候，这个问题显的尤其重要，因为子组件会重复被创建.所以要尽量避免使用Layout_weight
10. 使得Layout宽而浅，而不是窄而深（在Hierarchy Viewer的Tree视图里面体现）
建议
太多重叠的背景
这个问题其实最容易解决，建议就是检查你在布局和代码中设置的背景，有些背景是被隐藏在底下的，它永远不可能显示出来，这种没必要的背景一定要移除，因为它很可能会严重影响到app的性能。如果采用的是selector的背景，将normal状态的color设置为”@android:color/transparent”,也同样可以解决问题。
太多重叠的view
第一个建议是：使用ViewStub来加载一些不常用的布局，它是一个轻量级且默认不可见的视图，可以动态的加载一个布局，只有你用到这个重叠着的view的时候才加载，推迟加载的时间。第二个建议是：如果使用了类似viewpager+Fragment这样的组合或者有多个Fragment在一个界面上，需要控制Fragment的显示和隐藏，尽量使用动态地Inflation view，它的性能要比SetVisiblity好。
复杂的Layout层级
这里的建议比较多一些，首先推荐用Android提供的布局工具Hierarchy Viewer来检查和优化布局。第一个建议是：如果嵌套的线性布局加深了布局层次，可以使用相对布局来取代。第二个建议是：用标签来合并布局，这可以减少布局层次。第三个建议是：用标签来重用布局，抽取通用的布局可以让布局的逻辑更清晰明了。记住，这些建议的最终目的都是使得你的Layout在Hierarchy Viewer里变得宽而浅，而不是窄而深。
网友评论