Android系统显示原理简介

更新：最近发现该篇文章阅读的人数挺多，并且也发现了更好的关于Android显示系统的文章，所以将关于Android显示系统更好的两篇博客链接更新上来：Android图形显示系统（一）,强烈推荐看下该篇博客，强烈推荐看下该篇博客，强烈推荐看下该篇博客，该文深入浅出的介绍Android显示系统，看完之后会对显示系统整体有一个很清晰的认识，可惜该系列文章作者没有继续写下去。Android图形系统篇总结，该系列博客对Android系统从底层到上层进行介绍，对照源码看比较好，就是会感觉很枯燥，想深入了解显示系统推荐该系列博客。

Android系统的显示过程简单概括为Android应用程序把经过测量、布局绘制后的surface缓存数据，通过SurfaceFlinger把数据渲染到显示屏幕上，通过Android的刷新机制来刷新数据，也就是应用层负责绘制，系统层负责渲染，通过进程间通信把应用层需要绘制的数据传递给系统层服务，系统层服务通过刷新机制把数据更新到屏幕上。Android应用程序的显示过程包含了两个部分（应用侧绘制、系统侧渲染）、两个机制（进程间通讯机制、显示刷新机制）。

Android系统的绘制原理

绘制任务由应用发起，最终通过系统层绘制到硬件屏幕上，也就是说应用进程绘制后，通过跨进程通信机制把需要显示的数据传到系统层，由系统层中的SurfaceFlinger服务绘制到屏幕上；

1.应用层

一个Android应用程序窗口里面包含了很多UI元素，这些UI元素是以树形结构来组织的，即它们存在着父子关系，其中，子UI元素位于父UI元素里面，如下图： View.png

在绘制一个Android应用程序窗口的UI之前，我们首先要确定它里面的各个子UI元素在父UI元素里面的大小以及位置。确定各个子UI元素在父UI元素里面的大小以及位置的过程又称为测量过程和布局过程。Android每个View绘制的三个核心步骤：通过Measure和Layout确定当前需要绘制View的大小和位置，通过绘制到surface，在Android系统绘制源码是在ViewRootImpl的performTraversals方法开始的，通过该方法会执行Measure和layout和draw方法；Measure和layout都是递归获取View的大小和位置，都是以深度为优先级，可以看出层级越深元素越多，耗时也就越长；
测量、布局没有太多要说的，这里要着重说一下绘制。Android目前有两种绘制模型：基于软件的绘制模型和硬件加速的绘制模型（从Android 3.0开始全面支持）。
基于软件的绘制模型下，CPU主导绘图，视图按照两个步骤绘制
（1）让View层次结构失效;
（2） 绘制View层次结构；
当应用程序需要更新它的部分UI时，都会调用内容发生改变的View对象的invalidate()方法。无效（invalidation）消息请求会在View对象层次结构中传递，以便计算出需要重绘的屏幕区域（脏区）。然后，Android系统会在View层次结构中绘制所有的跟脏区相交的区域。不幸的是，这种方法有两个缺点：
（1）绘制了不需要重绘的视图（与脏区域相交的区域）；
（2）掩盖了一些应用的bug（由于会重绘与脏区域相交的区域）；
注意：在View对象的属性发生变化时，如背景色或TextView对象中的文本等，Android系统会自动的调用该View对象的invalidate()方法。
基于硬件加速的绘制模式下，GPU主导绘图，绘制按照三个步骤绘制：
（1）让View层次结构失效
（2）记录、更新显示列表
（3）绘制显示列表
这种模式下，Android系统依然会使用invalidate()方法和draw()方法来请求屏幕更新和展现View对象。但Android系统并不是立即执行绘制命令，而是首先把这些View的绘制函数作为绘制指令记录一个显示列表中，然后再读取显示列表中的绘制指令调用OpenGL相关函数完成实际绘制。另一个优化是，Android系统只需要针对由invalidate()方法调用所标记的View对象的脏区进行记录和更新显示列表。没有失效的View对象则能重放先前显示列表记录的绘制指令来进行简单的重绘工作。使用显示列表的目的是，把视图的各种绘制函数翻译成绘制指令保存起来，对于没有发生改变的视图把原先保存的操作指令重新读取出来重放一次就可以了，提高了视图的显示速度。而对于需要重绘的View，则更新显示列表，以便下次重用，然后再调用OpenGL完成绘制。硬件加速提高了Android系统显示和刷新的速度，但它也不是万能的，它有三个缺陷：
耗电：GPU功耗比CPU高；
兼容问题：某些接口或者函数不支持硬件加速；
内存大：使用OpenGL接口至少需要8MB内存；
所以是否使用硬件加速需要考虑接口是否支持，通过结合产品形态，如TV版本不需要考虑功耗问题，TV屏幕大，使用硬件加速实现更好的显示效果；

2.系统层：

真正把需要显示器的数据渲染到屏幕上，是通过系统级进程汇总的SurfaceFlinger服务来实现的，SurfaceFlinger主要工作：
（1）响应客户端事件，创建Layer与客户端Surface建立连接；
（2）接收客户端数据及属性，修改Layer属性，如尺寸、颜色、透明度等；
（3）将创建的layer内容刷新到屏幕上；
（4）维持layer序列，并对Layer最终输出做出裁剪计算；
既然是两个不同进程，那么肯定需要跨进程通信机制来实现数据传输，Android显示系统使用匿名共享内存：SharedClient，每个应用和SurfaceFlinger之间都会创建一个SharedClient，如下图所示，在每个SharedClient中，最多会创建31个SharedBufferStack，每个Surface对应一个SharedBufferStack，也就是一个Window；一个SharedClient对应一个Android应用程序，而一个Android应用程序可能包含多个窗口，即Surface，也就是说SharedClient包含的是SharedBufferStack集合，因为最多可以创建31个SharedBufferStack,也就意味着一个Android应用最多可以还包含31个窗口，同时每个SharedBufferStack中又包含两个（低于4.1版本）或者三个（4.1及以上版本）缓冲区，即显示刷新机制中双缓冲和三重缓冲机制；

Android显示框架.png

最后总结起来显示整体流程分为三个模块：应用层绘制到缓存区，SurfaceFlinger把缓存区数据渲染到屏幕，由于是两个不同的进程，所以Android使用匿名共享内存SharedClient缓存需要显示的数据来达到目的；SurfaceFlinger把缓存区的数据渲染到屏幕主要是驱动层的事情。

3.Android是如何将view绘制到屏幕？

大致流程如下：
（1）首先是CPU准备数据，TextView,Button等等控件通过cpu计算转换为内存中的polygons（多边图形）和texture(纹理)。
（2）其次，cpu通过OpenGL的接口将纹理数据传递给GPU渲染处理,由于图形API不允许CPU直接与GPU通信，而是通过中间图形驱动层来连接两部分，驱动层维护了一个队列，CPU把display list添加到队列中，GPU从这个队列去除数据进行绘制，最终在屏幕上显示出来；在这个过程中,由DisplayList这个结构负责保存绘制用到的所有信息,在Displaylist无需重新创建或改变的情况下,GPU可以直接使用这里的数据进行渲染.当View中的某些可见组件，那么之前的DisplayList就无法继续使用了，我们需要回头重新创建一个DisplayList并且重新执行渲染指令并更新到屏幕上。
（3）最后，GPU对图形数据进行渲染，然后硬件负责把渲染后的内容呈现到屏幕上，他们两者不停的进行协作。
名词解释：
栅格化：栅格化把button、textview等组件拆分到不同的像素上进行显示。这是一个很费时的操作，GPU的引入就是为了加快栅格化的操作。
DisplayList：DisplayList持有所有将要交给GPU绘制到屏幕上的数据信息。

4. Why 60fps?

知道了绘制流程之后，那么到底绘制一个单元多长时间才合理，我们通常都会提到60fps与16ms，可是知道为何会是以程序是否达到60fps来作为App性能的衡量标准吗？这是因为人眼与大脑之间的协作无法感知超过60fps的画面更新。12fps大概类似手动快速翻动书籍的帧率，这明显是可以感知到不够顺滑的。24fps使得人眼感知的是连续线性的运动，这其实是归功于运动模糊的效果。24fps是电影胶圈通常使用的帧率，因为这个帧率已经足够支撑大部分电影画面需要表达的内容，同时能够最大的减少费用支出。但是低于30fps是无法顺畅表现绚丽的画面内容的，此时就需要用到60fps来达到想要的效果，当然超过60fps是没有必要的。开发app的性能目标就是保持60fps，这意味着每一帧你只有16ms=1000/60的时间来处理所有的任务。Android系统每隔16ms发现VSYNC信号，触发对UI的进行渲染，如果每次渲染都成功，就可以达到流畅画面所需要的60FPS；如果某个操作话费时间超过16ms，那么得到VSYNC信号时就无法进行正常的渲染，就样就会发生丢帧；刷新不及时是引起卡顿的一个主要原因，下边接收系统怎么刷新以及在什么情况下会导致卡顿发生；

5.显示刷新机制

Android系统一直在不断的优化、更新，但直到4.0版本发布，有关UI显示不流畅的问题仍未得到根本解决；从Android4.1版本开始，Android对显示系统进行了重构，引入了三个核心元素：VSYNC, Tripple Buffer和Choreographer。VSYNC是Vertical Synchronized的缩写，是一种定时中断；Tripple Buffer是显示数据的缓冲区；Choreographer起调度作用，将绘制工作统一到VSYNC的某个时间点上，使应用的绘制工作有序进行。
名词解释：
双缓冲：显示内容的数据内存，双缓冲意味着要使用两个缓冲区（SharedBufferStack中），其中一个称为Front Buffer，另外一个称为Back Buffer。UI总是先在Back Buffer中绘制，然后再和Front Buffer交换，渲染到显示设备中。
三缓冲：即Triple Buffer。利用CPU/GPU的空闲时间准备数据，用于弥补在VSYNC+双缓冲配合使用的缺陷；
VSYNC：当双缓冲的介绍了解到，只有当另外一个buffer准备好之后，才能去刷新，这就需要CPU以主动查询方式来保证数据是否准备好，因为这种机制效率很低，引入VSYNC，一旦受到VSYNC定时中断，CPU就开始处理各帧数据；没有VSYNC信号，CPU不知道何时去处理UI绘制，引入VSYNC核心目的就是解决刷新不同步的问题；
Choreographer：收到VSYNC信号时，调用用户设置的回调函数，一种有三种类型的回调：
CALLBACK_INPUT：优先级最高，与输入事件有关；
CALLBACK_ANIMATON:第二优先级，与动画有关；
CALLBACK_TRAVERSAL：最低优先级，与UI控件绘制有关；
View的onclick、onDraw等等都是从Choreographer.doFrame开始执行的；关于Choreographer可以参考Android Choreographer 源码分析，讲的特别好；

5.1.没有VSYNC信号同步

没有VSYNC信号同步.png

（1）第一个16ms开始：Display显示第0帧，CPU处理完第一帧后，GPU紧接其后处理继续第一帧。三者都在正常工作。
（2）进入第二个16ms：因为早在上一个16ms时间内，第1帧已经由CPU，GPU处理完毕。故Display可以直接显示第1帧。显示没有问题。但在本16ms期间，CPU和GPU却并未及时去绘制第2帧数据（前面的空白区表示CPU和GPU忙其它的事），直到在本周期快结束时，CPU/GPU才去处理第2帧数据。
（3）进入第三个16ms，此时Display应该显示第2帧数据，但由于CPU和GPU还没有处理完第2帧数据，故Display只能继续显示第一帧的数据，结果使得第1帧多画了一次（对应时间段上标注了一个Jank），导致错过了显示第二帧。
通过上述分析可知，此处发生Jank的关键问题在于，为何第1个16ms段内，CPU/GPU没有及时处理第2帧数据？原因很简单，CPU可能是在忙别的事情，不知道该到处理UI绘制的时间了。可CPU一旦想起来要去处理第2帧数据，时间又错过了。 为解决这个问题，Android 4.1中引入了VSYNC，核心目的是解决刷新不同步的问题。

5.2.有VSYNC信号同步

有VSYNC信号同步.png

在加入VSYNC信号同步后，每收到VSYNC中断，CPU就开始处理各帧数据。已经解决了刷新不同步的问题。
但是上图中仍然存在一个问题：CPU和GPU处理数据的速度似乎都能在16ms内完成，而且还有时间空余，也就是说，CPU/GPU的FPS（帧率）要高于Display的FPS。由于CPU/GPU只在收到VSYNC时才开始数据处理，故它们的FPS被拉低到与Display的FPS相同。但这种处理并没有什么问题，因为Android设备的Display FPS一般是60，其对应的显示效果非常平滑。
但如果CPU/GPU的FPS小于Display的FPS，情况又不同了，将会发生如下图的情况：

VSYNC.png

（1）在第二个16ms时间段，Display本应显示B帧，但却因为GPU还在处理B帧，导致A帧被重复显示。
（2）同理，在第二个16ms时间段内，CPU无所事事，因为A Buffer被Display在使用。B Buffer被GPU在使用。注意，一旦过了VSYNC时间点，CPU就不能被触发以处理绘制工作了。

5.3.引入Triple Buffer

为什么CPU不能在第二个16ms处开始绘制工作呢？原因就是只有两个Buffer（Android 4.1之前）。如果有第三个Buffer的存在，CPU就能直接使用它，而不至于空闲。于是在Android4.1以后，引出了第三个缓冲区：Tripple Buffer。Tripple Buffer利用CPU/GPU的空闲等待时间提前准备好数据，并不一定会使用。
引入Triple Buffer效果如下图所示：

三重缓存机制.png
上图中，第二个16ms时间段，CPU使用C Buffer绘图。虽然还是会多显示A帧一次，但后续显示就比较顺畅了。
是不是Buffer越多越好呢？回答是否定的。由上图可知，在第二个时间段内，CPU绘制的第C帧数据要到第四个16ms才能显示，这比双Buffer情况多了16ms延迟。所以，Buffer最好还是两个，三个足矣。，目前基本都是这么解释的，但是这个解释我认为不对，如果不引入Triple Buffer，使用双缓冲技术，第二个阶段那一帧数据也是需要到第四个16ms才显示，使用双缓冲显示过程如下：第二个16ms还是显示第一帧A；因为发生丢帧，第二个16ms也是显示第一帧A；第三个16ms应该显示第二帧B；所以第三帧最早也是显示在第四个16ms，和引入Triple Buffer效果一样，所以我认为目前网上的解释都不对。需要管理的缓存越多，管理起来越复杂，所以并不是缓存越多越好；
从以上分析，Android系统在显示机制上解决了AndroidUI不流畅问题，但在实际应用开发过程中仍然存在卡顿现象，因为VSYNC中断处理的线程游戏那几一定要高，否则接收到VSYNC终端不能及时处理，也是徒劳无功；

6.卡顿根本原因

从Android显示原理可以看到，影响绘制的根本原因有以下两方面：
（1）绘制任务太重，绘制一帧内容耗时过长；
（2）主线程太忙，导致VSYNC信号到来时还没有准备好数据导致丢帧；
耗太长，需要从UI布局和绘制上来具体分析；
绘制工作是在主线程，主线程的主要职责是处理用户交互，在屏幕上绘制像素，并加载显示相关的数据，主线主要做以下几方面的工作：
（1）UI生命周期控制
（2）系统事件处理
（3）消息处理
（4）界面布局
（5）界面绘制
（6）界面刷新
除了这些之外，尽量避免将其他处理放到主线程中，特别是复杂的数据计算和网络请求；
更多卡顿问题可参考Android性能优化-App卡顿

参考资料：
《Android应用性能优化最佳实践》
Android 显示原理简介
胡凯-Android性能优化典范
Android Choreographer 源码分析
UI优化之-GPU Rendering Profile