过度绘制的解决

2017-12-12  本文已影响45人  锅里的饽饽

背景:

《Google的性能优化典范》一文是Android程序内存优化的指导,分别从渲染、电量、运算和内存几个方面阐述了优化方向。
本文关注渲染方向:


渲染其实是指GPU渲染,是App计算--绘制--渲染 过程中的最后一步。CPU负责Measure Layout,Execute GPU负责Rasterization(栅格化)。
CPU通常存在的问题是 非必需的视图组件、视图层级;GPU的问题是过度绘制。

Overdraw 过度绘制:
定义:屏幕上的某个像素在同一帧的时间内被绘制了多次
例如UI是层叠的,看不见的UI也做绘制操作,就是多余的。当设计效果上更加华丽炫酷时,堆叠视图层级是常见的情况,但这很容易产生性能问题。

怎么过度绘制打开开关和如何看,不介绍了就。


解决方案:

1.写合理而高效的布局
Android的布局可以通过xml来实现,这使得开发者布局时较为随意,只以实现功能为目的,忽略性能问题的累积效应。
在开发设计之初,就应该考虑布局的效率问题,以免出现后期修改的高成本。
降低Layout层级,有很多方法 不列举了。

2.移除非必须的background: Activity的DecorView有默认的背景色,可以改为透明
getWindow().getDecorView().setBackgroundColor(getResources().getColor(R.color.transparent));
这个颜色从ActivityTheme设置,被decorView所持有

<style name="Theme">
    ...
    <!-- Window attributes -->
    <item name="windowBackground">@drawable/screen_background_selector_dark</item>
    ...
</style>

screen_background_selector_dark在sdk中定义为纯黑色
所以也可以android:windowbackground="null"方法来修改

后续会在Theme自定义,或BaseActivity 统一优化

3.View BackGround 优化:

  1. 所有的View都可以设置Background,ImageView除了可以设置BackGround外,还可以设置imageResource
    在使用ImageView时,尤其是ListView ViewHolder中,可能imageView设置默认bitmap给background,然后
    真正的bitmap给imageResource,导致了重复绘制。解决方法是都通过imageResource设置
  2. 有时采用selector背景,可以normal状态设置为transparent

4.移除不必要的背景色
比如Activity中含Fragment,如果Fragment有背景色而且是全屏的,Activity就不必要。
又比如ViewPager中含fragment ViewPager的背景色是不必要的

5.ClipRect
在ViewGroup的drawChild方法中,
protected boolean drawChild(Canvas canvas, View child, long drawingTime)
在ViewGroup的Canvas上绘制子child,不同的child都在同一个canvas绘制,如果view相互遮盖,则重复绘制难免。
Canvas的clipRect方法,提供了限定绘制区域的功能,在某个child 绘制时,可以限定绘制区域为自己的显示区域,解决了这个问题。
v4包中的DrawerLayout,就专门做了ClipRect优化

@Override
    protected boolean drawChild(Canvas canvas, View child, long drawingTime) {
        final int height = getHeight();
        final boolean drawingContent = isContentView(child);//是否mainContent
        int clipLeft = 0, clipRight = getWidth();

        //如果是绘制mainContent,则先canvas.save 再 canvas.restore
        //并拿到drawerContent的right作为自己绘制的left,通过canvas.clipRect限定绘制区域
        final int restoreCount = canvas.save();
        if (drawingContent) {
            final int childCount = getChildCount();
            //此for循环找到drawerCotnent,
            for (int i = 0; i < childCount; i++) {
                final View v = getChildAt(i);
                //注意此处对于drawerContent的筛选条件:
                //visible,背景非透明!hasOpaqueBackground(v)
                //如果drawerContent无背景色,此优化直接continue,因为mainContent要全显示
                if (v == child || v.getVisibility() != VISIBLE ||
                        !hasOpaqueBackground(v) || !isDrawerView(v) ||
                        v.getHeight() < height) {
                    continue;
                }
                if (checkDrawerViewAbsoluteGravity(v, Gravity.LEFT)) {
                    final int vright = v.getRight();
                    if (vright > clipLeft) clipLeft = vright;
                } else {
                    final int vleft = v.getLeft();
                    if (vleft < clipRight) clipRight = vleft;
                }
            }
            canvas.clipRect(clipLeft, 0, clipRight, getHeight());
        }
        final boolean result = super.drawChild(canvas, child, drawingTime);
        canvas.restoreToCount(restoreCount);

pilot端的问题就在于DrawerContent没有背景,而是把背景设置在了里面的Fragment,导致DrawerLayout优化没有生效
此优化一般用于自定义view中,而且控件交互存在View之间重叠的情况

Android中每个Window对应一个Canvas,window下所有view绘制公用一个canvas,viewtree的父节点在调用child.draw之前都会根据child的layout边界对canvas进行裁剪,这也是为什么超过view边界的内容不会被显示的原因。
但是对于各child大部分重叠的控件,会产生过度绘制,就需要clipRect优化。大部分容易重叠的控件FrameLayout RelativeLayout本身没有优化,需要开发者根据实际情况对自定义控件进行优化。

优化前:[图片上传失败...(image-5fc76c-1513077609721)]
优化后:[图片上传失败...(image-87aa6e-1513077609721)]

6.善用9patch,背景图如果只显示边框,选用9patch,中间的透明会被2D渲染器优化overdraw


过度绘制的原因无外乎:复杂的Layout层级、重叠的背景、重叠的View几种。开发人员在设计之初就要充分考虑过度绘制等性能敏感地带,要知道等到功能实现之后再去改Layout层级,onDraw方法等,成本和风险都会指数型提高。

上一篇 下一篇

猜你喜欢

热点阅读