Android性能优化之渲染

提高用户体验首先要提高app的性能

造成卡顿的原因

Android的CPU和GPU同时工作,在屏幕上绘制图片 如果手机的刷新频率为60hz,则代表每秒会刷新60次屏幕,即绘制60张图片,这也是大部分手机的刷新频率。 这个刷新频率也称为fps(帧率),即每秒钟的帧数,一个帧数就是一张图片,如果1000ms绘制了60帧,则代表每隔 1000 / 60 = 16.666ms 时,就需要绘制一个帧

你一定玩过fps游戏,在fps游戏中,当fps的值 >= 60时,则说明这个游戏可以流畅的运行,在Android中也是一样

当帧率大于60时,画面会很流畅,而一旦低于60,画面就会变得卡顿,用户体验就会很差,动画就会变得很卡顿

前面我们说过,每隔16ms系统就会发送VSYNC信号绘制一个帧,如果我们在这16ms内,没有完成所需要的逻辑操作,当系统想要绘制一个新的帧时,发现我们的程序没有准备好,就会自动跳过此帧,不再绘制,所以这张图片在屏幕上待了32ms,造成了卡顿的视觉效果

CPU和GPU共同工作绘制图片

渲染操作依赖CPU与GPU。 CPU负责Measure、Layout、Record、Excute的计算操作, GPU则负责Rasterization格栅化操作

CPU通常存在的问题的原因是存在非必需的视图组件,它不仅仅会带来重复的计算操作,而且还会占用额外的GPU资源。

Activity是如何被绘制到屏幕上的?

我们通常在xml上设置布局,或者使用java代码写一个View,这些字符串、符号、路径甚至时一些高级对象都是通过格栅化操作,将它们拆分成不同的像素到屏幕上进行显示,这个格栅化操作是相当耗时的,所以引入了一个硬件GPU,用来专门处理格栅化操作。

GPU要进行格栅化操作,首先要接受一些简单的指令,这些指令由CPU提供,CPU将字符串、对象等转化为多边形和纹理(即图片,也就是GPU所需的指令),这一过程通常使用的API 就是 Android OpenGL ES,GPU接收到指令后就进行格栅化的操作。这样图片就被显示出来了。

上述过程中一共有三处耗时操作:

  1. 格栅化操作

  2. 将代码、对象转化为GPU所需的多边形纹理的转化操作

  3. 将多边形纹理上传给GPU的上传操作

由此可见,渲染机制是如此的复杂和耗时。

针对1:使用了GPU加快了格栅化操作的速度 针对2和3:OpenGL ES API 允许数据上传到GPU以后,对数据进行保存,这样下次需要绘制同一种按钮时,只需要在GPU的存储器中引用它即可 并且,你的所有Bitmap、Drawable等都会被打包到统一的纹理中,然后使用网格工具上传到GPU,这样当你需要使用这些东西时,就不需要做任何的转换,它们已经存储在GPU中了

综上所述: 渲染机制的优化就是:

  1. 尽可能快的上传数据到GPU

  2. 上传后尽可能在不修改的条件下保存数据

GPU已经被优化的很强大了,所以我们在一般情况下不会遇到GPU的问题,但是有一个GPU的问题需要我们避免:Overdraw 过度绘制

过度绘制Overdraw

什么是过度绘制? 比如给你的hourse粉刷,第一次你将墙壁全部粉刷为白色,粉刷完成后,又继续粉刷为绿色,之前的白色被完全遮挡了,那么我么就浪费了许多白漆。 过度重绘类似这个过程,如果我们在同一个位置堆叠了许多卡片,那么在绘制时,系统就会绘制这些看不到的卡片,这样就做了许多无用功,也就造成了过度绘制的问题,影响到应用的性能。 比如常见的,堆叠布局实现动画、变换等效果,这是极其损耗资源的一件事情。

颜色越深,说明过度绘制的情况就越严重。

剪辑Clipping

幸运的时,Android为了保持流畅,如果发现一个View完全被遮挡,则系统不会去绘制这个View,这个操作称作剪辑clipping 而且,如果你的View设置为不可见,系统同样也不会取绘制它。

但是,对于复杂的自定义View,系统则不能检测它在onDraw方法中进行了什么操作,所以,系统也就没有能力去除那些被覆盖的View

为了解决这类问题,Canvas中提供了如下方法: canvas.clipRect方法,帮助你识别View的绘制区域,区域之外的任何绘制都会被忽略(比如View的padding就可以用这种方法实现),发生如下情况时,这个方法尤其好用:

[外链图片转存中...(img-EtTom1Fs-1639376752358)]

扑克叠在一起,这种情况我们往往会将扑克图片一一绘制,如下:

由图我们发现,中间部分因为图片的重叠造成了不必要的绘制,解决办法很简单,只需要这样绘制即可:

效果如下,成功的使用了clipRect解决了过度绘制的问题!

还有一种方法,boolean quickReject(Rect r)方法,这个方法可以判断r区域是否完全在剪辑区域之外,如果是,可以忽略r区域内的所有的绘制操作

优化建议

  • 移除Window默认的Background

  • 移除XML布局文件中非必需的Background

  • 按需显示占位背景图片

布局优化

GPU的过度绘制问题解决了,但是CPU也存在一些问题: 前面我们说过,CPU需要将对象,xml等转化为GPU可以识别的多边形和纹理,这个操作实际上是在DisplayList(一个cpu缓存区) 帮助下完成的,这些多边形和纹理被包含在为Display List中。

DisplayList持有所有要将交给GPU的数据,这些数据包含了GPU要绘制的全部对象的信息列表,还有执行绘制操作的OpenGL命令列表,当某个对象需要被渲染时,Display对象就会被创建

  • 当任何对象发生改变时,比如大小变化、文字的改变,填充图片等 都要重建DisplayList, 重新执行一遍流程 measure-layout等操作 [外链图片转存中...(img-XJccIu5Z-1639376752361)]

所以,当你的布局中有太多的无用的View,则会造成没用的measure、layout拖累应用的性能,而且还会占用不必要的内存空间

可以很清楚的看到Android的布局的层次,检查是否有不需要的layout。

优化建议

  • 尽量使用扁平化布局(层次低)

  • 使用merge标签删减视图层级,系统会自动忽略merge节点

  • 使用ViewStub,需要时才会加载,不会影响UI初始化时的性能

探索相对布局和线性布局的优劣

<?xml version="1.0" encoding="utf-8"?>

<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:orientation="horizontal">

        <ImageView
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:src="@mipmap/ic_launcher"/>

        <LinearLayout
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:orientation="vertical">
            <TextView
                android:layout_width="wrap_content"
                android:layout_height="wrap_content"
                android:text="我是标题"/>
            <TextView
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:text="我是内容"/>
        </LinearLayout>
    </LinearLayout>

    <RelativeLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content">

        <ImageView
            android:id="@+id/iv"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:src="@mipmap/ic_launcher"/>
        <TextView
            android:id="@+id/tv"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="我是标题"
            android:layout_toRightOf="@id/iv"/>
        <TextView
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:text="我是内容"
            android:layout_toRightOf="@id/iv"
            android:layout_below="@id/tv"/>
    </RelativeLayout>

</LinearLayout>

我在屏幕上绘制了两个相同效果的布局,但是一个使用LinnearLayout实现,而一个使用RelativeLayout实现,在Hierarchy Viewer中我们看到有三个点、三种颜色

  • 左边的点代表渲染测量阶段

  • 中间的点代表布局阶段

  • 右边的点代表绘图阶段

  • 颜色代表相对于其他颜色的点的性能

  • 红色性能低于黄色、黄色则低于绿色

[外链图片转存中...(img-eiVSCJgE-1639376752362)]

从图片上我们可以看出,LinearLayout在性能方面是低于RelativeLayout的

学习课程:https://classroom.udacity.com/courses/ud825/lessons/3729268966/concepts/37461894070923#

最后更新于