2025年超过16ms就让页面卡顿了？

大家好，我是讯享网，很高兴认识大家。

码个蛋(codeegg)第 806 次推文

作者：LooperJing

博客：https://www.jianshu.com/p/9ac

码妞看世界

写在前面

优化性能一般从渲染，运算与内存，电量三个方面进行。

今天聊一聊Android的渲染机制，我们要知道Android系统每隔 16ms 就重新绘制一次Activity，也就是说，我们的应用必须在16ms内完成屏幕刷新的全部逻辑操作，即每一帧只能停留16ms，渲染机制说完之后，然后在说如何去优化UI。

16ms意味着1000/60hz，相当于60fps。

这是因为人眼与大脑之间的协作无法感知超过60fps的画面更新。

12fps大概类似手动快速翻动书籍的帧率，这明显是可以感知到不够顺滑的。

24fps使得人眼感知的是连续线性的运动，这其实是归功于运动模糊的效果。24fps是电影胶圈通常使用的帧率，因为这个帧率已经足够支撑大部分电影画面需要表达的内容，同时能够最大的减少费用支出。

但是低于30fps是无法顺畅表现绚丽的画面内容的，此时就需要用到60fps来达到想要的效果，超过60fps就没有必要了。如果我们的应用没有在16ms内完成屏幕刷新的全部逻辑操作，就会发生卡顿。

2、为什么16ms没完成绘制就会卡顿？

Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，VSync是Vertical Synchronization(垂直同步)的缩写，是一种在PC上很早就广泛使用的技术，可以简单的把它认为是一种定时中断。而在Android 4.1(JB)中已经开始引入VSync机制。

上图所示是VSync机制下的绘制过程。

从上图可以看出，CPU和GPU的处理时间都少于一个VSync的间隔，即16.6ms。如果每个间隔都有绘制的情况下，当前的FPS即为60帧。

当CPU和GPU处理时间都很慢，或因为其他的原因，如在主线程中干活太多，那么就会出现如下图这样的状况。

从上图可以看到，CPU和GPU的处理时间因为各种原因都大于一个VSync的间隔（16.6ms），所以在第二个VSync还在处理1区域的绘制时，不可能实现理论上的FPS60，同时也出现了丢帧(SF: Skipped Frame)情况。

试想用户盯着同一张图看了32ms而不是16ms，当然很容易察觉出卡顿感，哪怕仅仅出现一次掉帧，用户都会发现动画不是很顺畅，大家在察觉到APP卡顿的时候，可以看看logcat控制台，会有drop frames类似的警告，那么是什么原因导致16ms没能完成绘制的操作呢？

上面说了CPU和GPU的处理时间因为各种原因都大于一个VSync的间隔（16.6ms），导致了卡顿。

渲染操作通常依赖于两个核心组件：CPU与GPU。

CPU负责包括Measure，Layout，Record，Execute的计算操作，

GPU 负责Rasterization(栅格化)操作。

何为栅格化，我也是第一次听到这词，看下图。

所谓的栅格化就是绘制那些Button，Shape，Path，String，Bitmap等组件最基础的操作。

它把那些组件拆分到不同的像素上进行显示，说的俗气一点，就是解决那些复杂的XML布局文件和标记语言，使之转化成用户能看懂的图像，但是这不是直接转换的，XML布局文件需要在CPU中首先转换为多边形或者纹理，然后再传递给GPU进行格栅化，对于栅格化，跟OpenGL有关，格栅化是一个特别费时的操作。

分析到这里，16毫秒的时间主要被两件事情所占用，

第一件：将UI对象转换为一系列多边形和纹理；

第二件：CPU传递处理数据到GPU。

所以很明显，我们要缩短这两部分的时间，也就是说需要尽量减少对象转换的次数，以及上传数据的次数，对否？

我们再看一图，这图简单说明CPU和GPU的职责工作，以及可能发生的问题和解决方案。

列名	解释
PIPELINE	管道
PROBLEM	发生的问题
TOOLS	用什么工具来解决
SOLUTION	解决方案时什么

在CPU方面，最常见的性能问题是不必要的布局和失效，这些内容必须在视图层次结构中进行测量、清除并重新创建，引发这种问题通常有两个原因：

一是重建显示列表的次数太多，

二是花费太多时间作废视图层次并进行不必要的重绘。

这两个原因在更新显示列表或者其他缓存GPU资源时导致CPU工作过度。在GPU方面，最常见的问题是我们所说的过度绘制（overdraw），通常是在像素着色过程中，通过其他工具进行后期着色时浪费了GPU处理时间。下面我们对GPU和CPU产生的两大问题进行优化。

CPU产生的问题：不必要的布局和失效
GPU产生的问题：过度绘制（overdraw）

Overdraw(过度绘制)

描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。

在多层次的UI结构里面，如果不可见的UI也在做绘制的操作，这就会导致某些像素区域被绘制了多次。这就浪费大量的CPU以及GPU资源。

按照以下步骤打开Show GPU Overrdraw的选项：

设置 -> 开发者选项 -> 调试GPU过度绘制 -> 显示GPU过度绘制

蓝色，淡绿，淡红，深红代表了4种不同程度的Overdraw情况，

蓝色：
意味着overdraw 1倍。
像素绘制了两次。大片的蓝色还是可以接受的（若整个窗口是蓝色的，可以摆脱一层）。
绿色：
意味着overdraw 2倍。
像素绘制了三次。中等大小的绿**域是可以接受的但你应该尝试优化、减少它们。
淡红：
意味着overdraw 3倍。
像素绘制了四次，小范围可以接受。
深红：
意味着overdraw 4倍。
像素绘制了五次或者更多。这是错误的，要修复它们。

我们的目标就是尽量减少红色Overdraw，看到更多的蓝**域。

Overdraw 的处理方案一：去掉window的默认背景。
当我们使用了Android自带的一些主题时，window会被默认添加一个纯色的背景，这个背景是被DecorView持有的。
当我们的自定义布局时又添加了一张背景图或者设置背景色，那么DecorView的background此时对我们来说是无用的，但是它会产生一次Overdraw，带来绘制性能损耗。
Overdraw 的处理方案二：去掉其他不必要的背景
再比如如果采用的是selector的背景，将normal状态的color设置为“@android:color/transparent”,也同样可以解决问题。
这里只简单举两个例子，我们在开发过程中的一些习惯性思维定式会带来不经意的Overdraw，所以开发过程中我们为某个View或者ViewGroup设置背景的时候，先思考下是否真的有必要，或者思考下这个背景能不能分段设置在子View上，而不是图方便直接设置在根View上。

Overdraw 的处理方案三：clipRect的使用
这个方法可以指定一块矩形区域，只有在这个区域内才会被绘制，其他的区域会被忽视。这个API可以很好的帮助那些有多组重叠组件的自定义View来控制显示的区域。
同时clipRect方法还可以帮助节约CPU与GPU资源，在clipRect区域之外的绘制指令都不会被执行，那些部分内容在矩形区域内的组件，仍然会得到绘制。
Overdraw 的处理方案四：ViewStub
只有在特定的某些较少条件下，此时ViewStub所指向的布局文件才需要被inflate。且此布局文件直接将当前ViewStub替换掉，具体是通过 viewStub.infalte()或 viewStub.setVisibility(View.VISIBLE) 来完成。

<?xml version="1.0" encoding="utf-8"?> <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent"> <ListView android:id="@+id/listview" android:layout_width="match_parent" android:layout_height="match_parent" /> <ViewStub android:id="@+id/network_error_layout" android:layout_width="match_parent" android:layout_height="match_parent" android:layout="@layout/empty_view" /> </RelativeLayout>

讯享网

讯享网 private void showNetError() { // not repeated infalte if (networkErrorView != null) { networkErrorView.setVisibility(View.VISIBLE); return; } ViewStub stub = (ViewStub)findViewById(R.id.network_error_layout); networkErrorView = stub.inflate(); Button networkSetting = (Button)networkErrorView.findViewById(R.id.network_setting); Button refresh = (Button)findViewById(R.id.network_refresh); } private void showNormal() { if (networkErrorView != null) { networkErrorView.setVisibility(View.GONE); } }

Overdraw 的处理方案五：Merge标签
Merge的作用很明显，但是也有一些使用条件的限制。有两种情况下我们可以使用Merge标签来做容器控件。
第一种子视图不需要指定任何针对父视图的布局属性，就是说父容器仅仅是个容器，子视图只需要直接添加到父视图上用于显示就行。
另外一种是假如需要在 LinearLayout 里面嵌入一个布局（或者视图），而恰恰这个布局（或者视图）的根节点也是 LinearLayout，这样就多了一层没有用的嵌套，无疑这样只会拖慢程序速度。而这个时候如果我们使用merge根标签就可以避免那样的问题。
另外Merge只能作为XML布局的根标签使用，当Inflate以开头的布局文件时，必须指定一个父ViewGroup，并且必须设定attachToRoot为true。

allprojects { repositories { jcenter() maven { url "https://jitpack.io" } } }

第二步，在Module的build.gradle文件中加入

讯享网dependencies { ................................... compile 'com.github.romainguy:ViewServer:017c01cd512cac3ec054d9eee05fc48c5a9d2de' }

第三步，加**问网络权限，在Activity添加下列代码

public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // Set content view, etc. ViewServer.get(this).addWindow(this); } public void onDestroy() { super.onDestroy(); ViewServer.get(this).removeWindow(this); } public void onResume() { super.onResume(); ViewServer.get(this).setFocusedWindow(this); }

它只能在root过的机器才能使用，可以帮我们减少View的层，在Hierarchy Viewer窗口中，所有的子View上面都有了3个圈圈（取色范围为红、黄、绿色），这三个圈圈分别代表measure 、layout、draw的速度，并且你也可以看到实际的运行的速度。

没有用的父布局指没有背景绘制或者没有大小限制的父布局，这样的布局不会对UI效果产生任何影响。
我们可以把没有用的父布局，通过 <merge/> 标签合并来减少UI的层次；
使用线性布局LinearLayout排版导致UI层次变深。
如果有这类问题，我们就使用相对布局 RelativeLayout 代替 LinearLayout，减少UI的层次；
不常用的UI被设置成 GONE，比如异常的错误页面。
如果有这类问题，我们需要用 <ViewStub/> 标签，代替 GONE 提高UI性能。

参考链接：
http://www.cnblogs.com/krislight1105/p/5352517.html
http://www.csdn.net/article/2015-01-20/-android-performance-patterns

相关文章：

滴滴老司机开车：启动速度优化
因一纸设计稿，我把竞品APP扒得裤衩不
周末复习 Android & Java 面试题

今日问题：

专属升级社区：《这件事情，我终于想明白了》

2025年超过16ms就让页面卡顿了？

相关推荐