Ⅰ “android渲染”图像是怎样显示到屏幕上的
我们每天花很多时间盯着手机屏幕，不知道你有没有好奇过：
这时候来了一位Android程序员(当然也可以是iOS或者是前端程序员)说: 这里显示的其实是一个View树，我们看到的都是大大小小的View。
。。。听起来很有道理，我们也经常指着屏幕说这个View怎么怎么样，可问题又来了:
程序员老兄又来了： 屏幕当然不能识别View，它作为一个硬件，只能根据收到的数据改变每个像素单元的数据，这样整体来看，用户就发现屏幕上的内容变化了。至于View的内容是如何一步一步转化成屏幕可是识别的数据的，简单讲可以分成三步:
。。。听起来很有道理，可问题又来了:
那可就说来话长了。。。
对于 measure layout 和 draw ，Android工程师(大都)非常熟悉，我们常常在执行了 onDraw() 方法后，一个让人自豪的自定义View就显示出来了。在实际的Android绘制流程中，第一步就是通过 measure layout 和 draw 这些步骤准备了下面的材料：
在Android的绘制中，我们使用Canvas API进行来告诉表示画的内容，如 drawCircle() drawColor() drawText() drawBitmap() 等，也是这些内容最终呈现在屏幕上。
在当前应用中，View树中所有元素的材料最终会封装到 DisplayList 对象中(后期版本有用 RenderNode 对 DisplayList 又做了一层封装，实现了更好的性能)，然后发送出去，这样第一阶段就完成了。
当然就有一个重要的问题：
会将Bitmap复制到下一个阶段(准确地讲就是复制到GPU的内存中)。
现在大多数设备使用了GPU硬件加速，而GPU在渲染来自Bitmap的数据时只能读取GPU内存中的数据, 所以需要赋值Bitmap到GPU内存，这个阶段对应的名称叫 Sync&upload 。另外，硬件加速并不支持所有Canvas API，如果自定义View使用了不支持硬件加速的Canvas API(参考 Android硬件加速文档 )，为了避免出错就需要对View进行软件绘制，其处理方式就是生成一个Bitmap，然后复制到GPU进行处理。
这时可能会有问题：如果Bitmap很多或者单个Bitmap尺寸很大，这个过程可能会时间比较久，那有什么办法吗？
当然有(做作。。。)
关于Bitmap这里再多说一句:
Bitmap的内存管理一直是Android程序员很关心的问题，毕竟它是个很占内存的大胖子，在Android3.0~Android7.0，Bitmap内存放在Java堆中，而android系统中每个进程的Java堆是有严格限制的，处理不好这些Bitmap内存，容易导致频繁GC，甚至触发Java堆的 OutOfMemoryError 。从Android8.0开始，bitmap的像素数据放入了native内存，于是Java Heap的内存问题暂时缓解了。
Tip:
现在材料已经备好，我们要真正地画东西了。
接下来就要把东西画出来了，画出来的过程就是把前面的材料转化成一个堆像素数据的过程，也叫 栅格化 ，那这个活儿谁来干呢？
候选人只有两个:
大部分情况下，都是GPU来干这个活儿，因为GPU真的特别快！！！
所谓的“画”，对于计算机来讲就是处理图像，其实就是根据需要(就是DisplayList中的命令)对数据做一些特定类型的数学运算，最后输出结果的过程。我们看到的每一帧精美界面，(几乎)都是GPU吭哧吭哧"算"出来的，这个就有疑问了：
我们简单地聊聊CPU与GPU的区别：
CPU的核心数通常是几个，单个核心的主频高，功能强大，擅长串行处理复杂的流程；
GPU ( Graphics Processing Unit ) 有成百上千个核心，单个核心主频低，功能有限，擅长(利用超多核心)大量并行简单运算；正如它的名字一样，GPU就是为图像绘制这个场景量身定做的硬件(所以使用GPU也叫硬件加速)，后来也被用到挖矿和神经网络中。
图片肯定没有视频直观，我们从感性的角度感受一下GPU到底有多快，我想下面的视频看过就不会忘掉，你会被GPU折服:
Mythbusters Demo GPU versus CPU
看这个视频，我们对于“加速”应该有了更深刻的印象，这里不再进一步分析CPU和GPU更微观的差别(因为不懂)，我想已经讲明白为什们GPU更快了。
另外，在GPU开始绘制之前，系统也做了一些优化(对DisplayList中的命令进行预处理)，让整个绘制流程更加高效:
第二步的具体过程还是很复杂的，比如涉及到Alpha绘制，相关的优化会失效，详情查看文章 为什么alpha渲染性能低 .
至于画在哪里，我们现在理解为一个缓冲(Buffer)中就可以了，具体的机制放在第三步讲。
到此，我们已经画(绘制)完了图像内容，把这个内容发送出去，第二步的任务就完成了。
Tip:
我们知道，除了我们的应用界面，手机屏幕上同时显示着其他内容，比如SystemUI(状态栏、导航栏)或者另外的悬浮窗等，这些内容都需要显示到屏幕上。所以要先 把这些界面的内容合成，然后再显示到屏幕 。
在讲合成图像之前，我们有必要知道这些界面图像(Buffer)是怎么传递的：
Android图形架构中，使用生产者消费者模型来处理图像数据，其中的图像缓冲队列叫 BufferQueue , 队列中的元素叫 Graphic Buffer ，队列有生产者也有消费者；每个应用通常会对应一个 Surface ，一个 Surface 对应着一个缓冲队列，每个队列中 Graphic Buffer 的数量不超过3个, 上面两步后绘制的图像数据最终会放入一个 Graphic Buffer ，应用自身就是队列的生产者( BufferQueue 在Android图形处理中有广泛的应用，当前只讨论界面绘制的场景)。
每个 Graphic Buffer 本身体积很大，在从生产者到消费者的传递过程中不会进行复制的操作，都是用匿名共享内存的方式，通过句柄来跨进程传递。
我们可以通过以下命令来查看手机当前用到的 Graphic Buffer 情况:
关于上面的命令，你可能会好奇这个 SurfaceFlinger 是什么东西啊？
上文提到过每个应用(一般)对应一个 Surface ，从字面意思看， SurfaceFlinger 就是把应用的 Surface 投射到目的地。
实际上， SurfaceFlinger 就是界面(Buffer)合成的负责人，在应用界面绘制的场景， SurfaceFlinger 充当了 BufferQueue 的消费者。绘制好的 Graphic Buffer 会进入(queue)队列， SurfaceFlinger 会在合适的时机(这个时机下文讨论)，从队列中取出(acquire)Buffer数据进行处理。
我们知道，除了我们的应用界面，手机屏幕上同时显示着其他内容，比如SystemUI(状态栏、导航栏)或者另外的悬浮窗等，这些部分的都有各自的Surface，当然也会往对应的 BufferQueue 中生产 Graphic Buffer 。
如下图所示， SurfaceFlinger 获取到所有Surface的最新Buffer之后，会配合HWComposer进行处理合成，最终把这些Buffer的数据合成到一个 FrameBuffer 中，而FrameBuffer的数据会在另一个合适的时机(同样下文讨论)迅速地显示到屏幕上，这时用户才观察到屏幕上的变化。
关于上图中的 HWComposer ，它是Android HAL接口中的一部分，它定义了上层需要的能力，让由硬件提供商来实现，因为不同的屏幕硬件差别很大，让硬件提供商驱动自己的屏幕，上层软件无需关心屏幕硬件的兼容问题。
事实上，如果你观察足够仔细的话，可能对上图还有疑问:
同学你观察很仔细(...)，事实上，这是 SurfaceFlinger 合成过程中重要的细节，对于不同 Surface 的Buffer, 合成的方法有两种:
显然第一种方法是最高效的，但为了保证正确性，Android系统结合了两种方法。具体实现上， SurfaceFlinger 会询问( prepare ) HWComposer 是否支持直接合成，之后按照结果做对应处理。
有的朋友憋不住了:
Good question! (太做作了。。。)
为了保证最好的渲染性能，上面各个步骤之间并不是串行阻塞运行的关系，所以有一个机制来调度每一步的触发时机，不过在此之前，我们先讲介绍一个更基础的概念:
屏幕刷新率
刷新率是屏幕的硬件指标，单位是Hz(赫兹)，意思是屏幕每秒可以刷新的次数。
回到问题，既然屏幕这个硬件每隔一段时间(如60Hz屏幕是16ms)就刷新一次，最佳的方案就是屏幕刷新时开始新一轮的绘制流程，让一次绘制的流程尽可能占满整个刷新周期，这样掉帧的可能性最小。基于这样的思考，在Android4.1(JellyBean)引入 VSYNC(Vertical Synchronization - 垂直同步信号)
收到系统发出的VSYNC信号后， 有三件事会同时执行(并行) ：
下图描述了没有掉帧时的VSYNC执行流程，现在我们可以直接回答问题了: 合适的时机就是VSYNC信号 。
从上图可以看出，在一次VSYNC信号发出后，屏幕立即显示2个VSYNC周期(60Hz屏幕上就是32ms)之前开始绘制的图像，这当然是延迟，不过这个延迟非常稳定， 只要前面的绘制不掉链子 ，界面也是如丝般顺滑。当然，Android还是推出一种机制让延迟可以缩小到1个VSYNC周期，详情可参考 VSYNC-offset 。
实际上，系统只会在需要的时候才发出VSYNC信号，这个开关由SurfaceFlinger来管理。应用也只是在需要的时候才接收VSYNC信号，什么时候需要呢？也就是应用界面有变化，需要更新了，具体的流程可以参考 View.requestLayout() 或 View.invalidate() 到 Choreographer (编舞者)的调用过程。这个过程会注册一次VSYNC信号，下一次VSYNC信号发出后应用就能收到了，然后开始新的绘制工作；想要再次接收VSYNC信号就需要重新注册，可见，应用界面没有改变的时候是不会进行刷新的。
我们可以看到，无论是VSYNC开关，还是应用对VSYNC信号的单次注册逻辑，都是秉承着按需分配的原则，这样的设计能够带来Android操作系统更好的性能和更低的功耗。
Tip:
终于。。。说完了
我们简单回顾一下，
更形象一点就是:
之所以有这一节，是因为随着Android版本的更替，渲染方案也发生了很多变化。为了简化表达，我们前文都以当前最新的方案来讲解，事实上，部分流程的实现方式在不同版本可能会有较大的变化，甚至在之前版本没有实现方案，这里我尽可能详细地列出Android版本更迭过程中与渲染相关的更新(包括监控工具)。
如果你居然能读到这里，那我猜你对下面的参考文章也会感兴趣：
https://source.android.com/devices/graphics
https://hencoder.com/tag/hui-/
https://www.youtube.com/watch?v=wIy8g8yNhNk&feature=emb_logo
https://www.youtube.com/watch?v=v9S5EO7CLjo
https://www.youtube.com/watch?v=zdQRIYOST64&t=177s
https://www.youtube.com/watch?v=we6poP0kw6E&index=64&list=
https://developer.android.com/topic/performance/rendering
https://developer.android.com/guide/topics/graphics/hardware-accel
https://developer.android.com/topic/performance/rendering/profile-gpu#su
https://mp.weixin.qq.com/s/0OOSmrzSkjG3cSOFxWYWuQ
Android Developer Backstage - Android Rendering
Android Developer Backstage - Graphics Performance
https://elinux.org/images/2/2b/Android_graphics_path--chis_simmonds.pdf
Ⅱ Android图形渲染原理上
对于Android开发者来说，我们或多或少有了解过Android图像显示的知识点，刚刚学习Android开发的人会知道，在Actvity的onCreate方法中设置我们的View后，再经过onMeasure，onLayout，onDraw的流程，界面就显示出来了；对Android比较熟悉的开发者会知道，onDraw流程分为软件绘制和硬件绘制两种模式，软绘是通过调用Skia来操作，硬绘是通过调用Opengl ES来操作；对Android非常熟悉的开发者会知道绘制出来的图形数据最终都通过GraphiBuffer内共享内存传递给SurfaceFlinger去做图层混合，图层混合完成后将图形数据送到帧缓冲区，于是，图形就在我们的屏幕显示出来了。
但我们所知道的Activity或者是应用App界面的显示，只属于Android图形显示的一部分。同样可以在Android系统上展示图像的WebView，Flutter，或者是通过Unity开发的3D游戏，他们的界面又是如何被绘制和显现出来的呢？他们和我们所熟悉的Acitvity的界面显示又有什么异同点呢？我们可以不借助Activity的setView或者InflateView机制来实现在屏幕上显示出我们想要的界面吗？Android系统显示界面的方式又和IOS，或者Windows等系统有什么区别呢？……
去探究这些问题，比仅仅知道Acitvity的界面是如何显示出来更加的有价值，因为想要回答这些问题，就需要我们真正的掌握Android图像显示的底层原理，当我们掌握了底层的显示原理后，我们会发现WebView，Flutter或者未来会出现的各种新的图形显示技术，原来都是大同小异。
我会花三篇文章的篇幅，去深入的讲解Android图形显示的原理，OpenGL ES和Skia的绘制图像的方式，他们如何使用，以及他们在Android中的使用场景，如开机动画，Activity界面的软件绘制和硬件绘制，以及Flutter的界面绘制。那么，我们开始对Android图像显示原理的探索吧。
在讲解Android图像的显示之前，我会先讲一下屏幕图像的显示原理，毕竟我们图像，最终都是在手机屏幕上显示出来的，了解这一块的知识会让我们更容易的理解Android在图像显示上的机制。
图像显示的完整过程，分为下面几个阶段：
图像数据→CPU→显卡驱动→显卡（GPU）→显存（帧缓冲）→显示器
我详细介绍一下这几个阶段：
实际上显卡驱动，显卡和显存，包括数模转换模块都是属于显卡的模块。但为了能能详细的讲解经历的步骤，这里做了拆分。
当显存中有数据后，显示器又是怎么根据显存里面的数据来进行界面的显示的呢？这里以LCD液晶屏为例，显卡会将显存里的数据，按照从左至右，从上到下的顺序同步到屏幕上的每一个像素晶体管，一个像素晶体管就代表了一个像素。
如果我们的屏幕分辨率是1080x1920像素，就表示有1080x1920个像素像素晶体管，每个橡素点的颜色越丰富，描述这个像素的数据就越大，比如单色，每个像素只需要1bit，16色时，只需要4bit，256色时，就需要一个字节。那么1080x1920的分辨率的屏幕下，如果要以256色显示，显卡至少需要1080x1920个字节，也就是2M的大小。
刚刚说了，屏幕上的像素数据是从左到右，从上到下进行同步的，当这个过程完成了，就表示一帧绘制完成了，于是会开始下一帧的绘制，大部分的显示屏都是以60HZ的频率在屏幕上绘制完一帧，也就是16ms，并且每次绘制新的一帧时，都会发出一个垂直同步信号（VSync）。我们已经知道，图像数据都是放在帧缓冲中的，如果帧缓冲的缓冲区只有一个，那么屏幕在绘制这一帧的时候，图像数据便没法放入帧缓冲中了，只能等待这一帧绘制完成，在这种情况下，会有很大了效率问题。所以为了解决这一问题，帧缓冲引入两个缓冲区，即 双缓冲机制 。双缓冲虽然能解决效率问题，但会引入一个新的问题。当屏幕这一帧还没绘制完成时，即屏幕内容刚显示一半时，GPU 将新的一帧内容提交到帧缓冲区并把两个缓冲区进行交换后，显卡的像素同步模块就会把新的一帧数据的下半段显示到屏幕上，造成画面撕裂现象。
为了解决撕裂问题，就需要在收到垂直同步的时候才将帧缓冲中的两个缓冲区进行交换。Android4.1黄油计划中有一个优化点，就是CPU和GPU都只有收到垂直同步的信号时，才会开始进行图像的绘制操作，以及缓冲区的交换工作。
我们已经了解了屏幕图像显示的原理了，那么接着开始对Android图像显示的学习。
从上一章已经知道，计算机渲染界面必须要有GPU和帧缓冲。对于Linux系统来说，用户进程是没法直接操作帧缓冲的，但我们想要显示图像就必须要操作帧缓冲，所以Linux系统设计了一个虚拟设备文件，来作为对帧缓冲的映射，通过对该文件的I/O读写，我们就可以实现读写屏操作。帧缓冲对应的设备文件于/dev/fb* ，*表示对多个显示设备的支持， 设备号从0到31，如/dev/fb0就表示第一块显示屏，/dev/fb1就表示第二块显示屏。对于Android系统来说，默认使用/dev/fb0这一个设帧缓冲作为主屏幕，也就是我们的手机屏幕。我们Android手机屏幕上显示的图像数据，都是存储在/dev/fb0里，早期AndroidStuio中的DDMS工具实现截屏的原理就是直接读取/dev/fb0设备文件。
我们知道了手机屏幕上的图形数据都存储在帧缓冲中，所以Android手机图像界面的原理就是将我们的图像数据写入到帧缓冲内。那么，写入到帧缓冲的图像数据是怎么生成的，又是怎样加工的呢？图形数据是怎样送到帧缓冲去的，中间经历了哪些步骤和过程呢？了解了这几个问题，我们就了解了Android图形渲染的原理，那么带着这几个疑问，接着往下看。
想要知道图像数据是怎么产生的，我们需要知道 图像生产者 有哪些，他们分别是如何生成图像的，想要知道图像数据是怎么被消费的，我们需要知道 图像消费者 有哪些，他们又分别是如何消费图像的，想要知道中间经历的步骤和过程，我们需要知道 图像缓冲区 有哪些，他们是如何被创建，如何分配存储空间，又是如何将数据从生产者传递到消费者的，图像显示是一个很经典的消费者生产者的模型，只有对这个模型各个模块的击破，了解他们之间的流动关系，我们才能找到一条更容易的路径去掌握Android图形显示原理。我们看看谷歌提供的官方的架构图是怎样描述这一模型的模块及关系的。
如图， 图像的生产者 主要有MediaPlayer，CameraPrevier，NDK，OpenGl ES。MediaPlayer和Camera Previer是通过直接读取图像源来生成图像数据，NDK（Skia），OpenGL ES是通过自身的绘制能力生产的图像数据； 图像的消费者 有SurfaceFlinger，OpenGL ES Apps，以及HAL中的Hardware Composer。OpenGl ES既可以是图像的生产者，也可以是图像的消费者，所以它也放在了图像消费模块中； 图像缓冲区 主要有Surface以及前面提到帧缓冲。
Android图像显示的原理，会仅仅围绕 图像的生产者 ， 图像的消费者 ， 图像缓冲区 来展开，在这一篇文章中，我们先看看Android系统中的图像消费者。
SurfaceFlinger是Android系统中最重要的一个图像消费者，Activity绘制的界面图像，都会传递到SurfaceFlinger来，SurfaceFlinger的作用主要是接收图像缓冲区数据，然后交给HWComposer或者OpenGL做合成，合成完成后，SurfaceFlinger会把最终的数据提交给帧缓冲。
那么SurfaceFlinger是如何接收图像缓冲区的数据的呢？我们需要先了解一下Layer（层）的概念，一个Layer包含了一个Surface，一个Surface对应了一块图形缓冲区，而一个界面是由多个Surface组成的，所以他们会一一对应到SurfaceFlinger的Layer中。SurfaceFlinger通过读取Layer中的缓冲数据，就相当于读取界面上Surface的图像数据。Layer本质上是 Surface和SurfaceControl的组合 ，Surface是图形生产者和图像消费之间传递数据的缓冲区，SurfaceControl是Surface的控制类。
前面在屏幕图像显示原理中讲到，为了防止图像的撕裂，Android系统会在收到VSync垂直同步时才会开始处理图像的绘制和合成工作，而Surfaceflinger作为一个图像的消费者，同样也是遵守这一规则，所以我们通过源码来看看SurfaceFlinger是如何在这一规则下，消费图像数据的。
SurfaceFlinger专门创建了一个EventThread线程用来接收VSync。EventThread通过Socket将VSync信号同步到EventQueue中，而EventQueue又通过回调的方式，将VSync信号同步到SurfaceFlinger内。我们看一下源码实现。
上面主要是SurfaceFlinger初始化接收VSYNC垂直同步信号的操作，主要有这几个过程：
经过上面几个步骤，我们接收VSync的初始化工作都准备好了，EventThread也开始运转了，接着看一下EventThread的运转函数threadLoop做的事情。
threadLoop主要是两件事情
mConditon又是怎么接收VSync的呢？我们来看一下
可以看到，mCondition的VSync信号实际是DispSyncSource通过onVSyncEvent回调传入的，但是DispSyncSource的VSync又是怎么接收的呢？在上面讲到的SurfaceFlinger的init函数，在创建EventThread的实现中，我们可以发现答案—— mPrimaryDispSync 。
DispSyncSource的构造方法传入了mPrimaryDispSync，mPrimaryDispSync实际是一个DispSyncThread线程，我们看看这个线程的threadLoop方法
DispSyncThread的threadLoop会通过mPeriod来判断是否进行阻塞或者进行VSync回调，那么mPeriod又是哪儿被设置的呢？这里又回到SurfaceFlinger了，我们可以发现在SurfaceFlinger的 resyncToHardwareVsync 函数中有对mPeriod的赋值。
可以看到，这里最终通过HWComposer，也就是硬件层拿到了period。终于追踪到了VSync的最终来源了， 它从HWCompser产生，回调至DispSync线程，然后DispSync线程回调到DispSyncSource，DispSyncSource又回调到EventThread，EventThread再通过Socket分发到MessageQueue中 。
我们已经知道了VSync信号来自于HWCompser，但SurfaceFlinger并不会一直监听VSync信号，监听VSync的线程大部分时间都是休眠状态，只有需要做合成工作时，才会监听VSync，这样即保证图像合成的操作能和VSync保持一致，也节省了性能。SurfaceFlinger提供了一些主动注册监听VSync的操作函数。
可以看到，只有当SurfaceFlinger调用 signalTransaction 或者 signalLayerUpdate 函数时，才会注册监听VSync信号。那么signalTransaction或者signalLayerUpdate什么时候被调用呢？它可以由图像的生产者通知调用，也可以由SurfaceFlinger根据自己的逻辑来判断是否调用。
现在假设App层已经生成了我们界面的图像数据，并调用了 signalTransaction 通知SurfaceFlinger注册监听VSync，于是VSync信号便会传递到了MessageQueue中了，我们接着看看MessageQueue又是怎么处理VSync的吧。
MessageQueue收到VSync信号后，最终回调到了SurfaceFlinger的 onMessageReceived 中，当SurfaceFlinger接收到VSync后，便开始以一个图像消费者的角色来处理图像数据了。我们接着看SurfaceFlinger是以什么样的方式消费图像数据的。
VSync信号最终被SurfaceFlinger的onMessageReceived函数中的INVALIDATE模块处理。
INVALIDATE的流程如下：
handleMessageTransaction的处理比较长，处理的事情也比较多，它主要做的事情有这些
handleMessageRefresh函数，便是SurfaceFlinger真正处理图层合成的地方，它主要下面五个步骤。
我会详细介绍每一个步骤的具体操作
合成前预处理会判断Layer是否发生变化，当Layer中有新的待处理的Buffer帧（mQueuedFrames>0），或者mSidebandStreamChanged发生了变化， 都表示Layer发生了变化，如果变化了，就调用signalLayerUpdate，注册下一次的VSync信号。如果Layer没有发生变化，便只会做这一次的合成工作，不会注册下一次VSync了。
重建Layer栈会遍历Layer，计算和存储每个Layer的脏区， 然后和当前的显示设备进行比较，看Layer的脏区域是否在显示设备的显示区域内，如果在显示区域内的话说明该layer是需要绘制的，则更新到显示设备的VisibleLayersSortedByZ列表中，等待被合成
rebuildLayerStacks中最重要的一步是 computeVisibleRegions ，也就是对Layer的变化区域和非透明区域的计算，为什么要对变化区域做计算呢？我们先看看SurfaceFlinger对界面显示区域的分类：
还是以这张图做例子，可以看到我们的状态栏是半透明的，所以它是一个opaqueRegion区域，微信界面和虚拟按键是完全不透明的，他是一个visibleRegion，除了这三个Layer外，还有一个我们看不到的Layer——壁纸，它被上方visibleRegion遮挡了，所以是coveredRegion
对这几个区域的概念清楚了，我们就可以去了解computeVisibleRegions中做的事情了，它主要是这几步操作：