我们每天花很多时间盯着手机屏幕，不知道你有没有好奇过：
手机屏幕上的这些东西是怎么显示出来的？
这时候来了一位Android程序员(当然也可以是iOS或者是前端程序员)说: 这里显示的其实是一个View树，我们看到的都是大大小小的View。
。。。听起来很有道理，我们也经常指着屏幕说这个View怎么怎么样，可问题又来了:
屏幕认识View吗？
我们把一个View发给屏幕，它就显示出来了？
程序员老兄又来了： 屏幕当然不能识别View，它作为一个硬件，只能根据收到的数据改变每个像素单元的数据，这样整体来看，用户就发现屏幕上的内容变化了。至于View的内容是如何一步一步转化成屏幕可是识别的数据的，简单讲可以分成三步:
- 准备材料
- 画出来
- 显示到屏幕
。。。听起来很有道理，可问题又来了:
这也太简单了吧，能详细一点吗？
那可就说来话长了。。。
1. 准备材料
对于measure layout 和draw，Android工程师(大都)非常熟悉，我们常常在执行了onDraw()方法后，一个让人自豪的自定义View就显示出来了。在实际的Android绘制流程中，第一步就是通过measure layout 和draw这些步骤准备了下面的材料：
- 画什么
- 画的参数
画什么
在Android的绘制中，我们使用Canvas API进行来告诉表示画的内容，如drawCircle() drawColor() drawText() drawBitmap()等，也是这些内容最终呈现在屏幕上。
画的参数
-
画的坐标
坐标系: Android图像坐标系以左上角为0点，x轴左负右正，y轴上负下正，z轴内负外正；
View的layout基准点是父容器的左上角，View的draw内容基准点是View的左上角。根节点父容器是当前
Window的DecorView，它的布局信息由WindowManger来管理。到此，当前应用所有View放在哪个位置就确定了。
-
画的层级(重叠时的覆盖关系)
View之间并不是井水不犯河水，经常出现重叠的情况，重叠时该怎样覆盖和显示正确的View大体遵循以下规则:
- 指定
z-order情况下，数值最大的显示在最上层，剩下的降序显示。 - 在没有指定
z-order的情况下，子View覆盖父容器，相同父容器View后添加的显示在最上层。
- 指定
-
特定参数
不同的方法需要的参数不同，比如
drawCircle()会有圆心和半径，drawText()需要对应的text资源，drawBitmap()需要对应的Bitmap资源等等。
在当前应用中，View树中所有元素的材料最终会封装到DisplayList对象中(后期版本有用RenderNode对DisplayList又做了一层封装，实现了更好的性能)，然后发送出去，这样第一阶段就完成了。
当然就有一个重要的问题：
这个阶段怎么处理Bitmap呢？
会将Bitmap复制到下一个阶段(准确地讲就是复制到GPU的内存中)。
现在大多数设备使用了GPU硬件加速，而GPU在渲染来自Bitmap的数据时只能读取GPU内存中的数据, 所以需要赋值Bitmap到GPU内存，这个阶段对应的名称叫Sync&upload。另外，硬件加速并不支持所有Canvas API，如果自定义View使用了不支持硬件加速的Canvas API(参考Android硬件加速文档)，为了避免出错就需要对View进行软件绘制，其处理方式就是生成一个Bitmap，然后复制到GPU进行处理。
这时可能会有问题：如果Bitmap很多或者单个Bitmap尺寸很大，这个过程可能会时间比较久，那有什么办法吗？
当然有(做作。。。)
-
使用
Hardware-Only Bitmap(from Android 8.0 - Oreo)从Android 8.0 开始，支持了
Hardware-Only Bitmap类型，这种类型的Bitmap的数据只存放在GPU内存中，这样在Sync&upload阶段就不需要upload这个Bitmap了。使用很简单，只需要将Options.inPreferredConfig赋值为Bitmap.Config.HARDWARE即可。这种方式能实现特定场景的极致性能，提供便利的同时，这种Bitmap的某些操作是受限的(毕竟数据存储只存储在GPU内存中)，可以查看Glide的总结(为啥不是google？。。。)
关于Bitmap这里再多说一句:
Bitmap的内存管理一直是Android程序员很关心的问题，毕竟它是个很占内存的大胖子，在Android3.0~Android7.0，Bitmap内存放在Java堆中，而android系统中每个进程的Java堆是有严格限制的，处理不好这些Bitmap内存，容易导致频繁GC，甚至触发Java堆的OutOfMemoryError。从Android8.0开始，bitmap的像素数据放入了native内存，于是Java Heap的内存问题暂时缓解了。
Tip:
第一步的所有操作都在应用进程的UI Thread中执行。
2. 画出来
现在材料已经备好，我们要真正地画东西了。
谁来画
接下来就要把东西画出来了，画出来的过程就是把前面的材料转化成一个堆像素数据的过程，也叫栅格化，那这个活儿谁来干呢？
候选人只有两个:
- CPU: 软件绘制，使用
Skia方案实现，绘制慢。 - GPU: 硬件加速绘制，使用
OpenGL ES或Vulkan方案实现，绘制快很多。
大部分情况下，都是GPU来干这个活儿，因为GPU真的特别快！！！
怎么画
所谓的“画”，对于计算机来讲就是处理图像，其实就是根据需要(就是DisplayList中的命令)对数据做一些特定类型的数学运算，最后输出结果的过程。我们看到的每一帧精美界面，(几乎)都是GPU吭哧吭哧"算"出来的，这个就有疑问了：
既然是运算，CPU也能算啊，为什么GPU更快呢？
我们简单地聊聊CPU与GPU的区别：
CPU的核心数通常是几个，单个核心的主频高，功能强大，擅长串行处理复杂的流程；
GPU (Graphics Processing Unit) 有成百上千个核心，单个核心主频低，功能有限，擅长(利用超多核心)大量并行简单运算；正如它的名字一样，GPU就是为图像绘制这个场景量身定做的硬件(所以使用GPU也叫硬件加速)，后来也被用到挖矿和神经网络中。
图片肯定没有视频直观，我们从感性的角度感受一下GPU到底有多快，我想下面的视频看过就不会忘掉，你会被GPU折服:
Mythbusters Demo GPU versus CPU
看这个视频，我们对于“加速”应该有了更深刻的印象，这里不再进一步分析CPU和GPU更微观的差别(因为不懂)，我想已经讲明白为什们GPU更快了。
另外，在GPU开始绘制之前，系统也做了一些优化(对DisplayList中的命令进行预处理)，让整个绘制流程更加高效:
-
增量更新：两帧图像之间只是个别View改变了，那么只绘制更新的View即可，实现方案是
DisplayList的Damaged Area -
指令重排序(reordering)、指令合并(merging)、批处理(batching)
在硬件绘制之前，第一步中输出的信息会转化成
OpenGL ES中对应的绘制命令(gl commands)，这些命令原本是按照View树的层级关系来递归输出的。可这些命令中有很多(看起来)相同的操作，比如我们在绘制一个列表时，同样属性的文字(标题，内容，昵称等)要绘制十几次，这时候如果把绘制命令重新排序、进行一定的合并和批处理，性能会提升很多。如下图:-
未经优化, 按顺序绘制
-
优化后，一次绘制出所有的文字
-
第二步的具体过程还是很复杂的，比如涉及到Alpha绘制，相关的优化会失效，详情查看文章为什么alpha渲染性能低.
画在哪里
至于画在哪里，我们现在理解为一个缓冲(Buffer)中就可以了，具体的机制放在第三步讲。
到此，我们已经画(绘制)完了图像内容，把这个内容发送出去，第二步的任务就完成了。
Tip:
在Android L 之前，第二步的操作在应用进程的UI Thread中执行；
在Android L 之后, 第二步的操作在应用进程的RenderThread中执行。
3. 显示到屏幕
我们知道，除了我们的应用界面，手机屏幕上同时显示着其他内容，比如SystemUI(状态栏、导航栏)或者另外的悬浮窗等，这些内容都需要显示到屏幕上。所以要先把这些界面的内容合成，然后再显示到屏幕。
在讲合成图像之前，我们有必要知道这些界面图像(Buffer)是怎么传递的：
BufferQueue
Android图形架构中，使用生产者消费者模型来处理图像数据，其中的图像缓冲队列叫BufferQueue, 队列中的元素叫Graphic Buffer，队列有生产者也有消费者；每个应用通常会对应一个Surface，一个Surface对应着一个缓冲队列，每个队列中Graphic Buffer的数量不超过3个, 上面两步后绘制的图像数据最终会放入一个Graphic Buffer，应用自身就是队列的生产者(BufferQueue在Android图形处理中有广泛的应用，当前只讨论界面绘制的场景)。
每个Graphic Buffer本身体积很大，在从生产者到消费者的传递过程中不会进行复制的操作，都是用匿名共享内存的方式，通过句柄来跨进程传递。
BufferQueue工作周期
我们可以通过以下命令来查看手机当前用到的Graphic Buffer情况:
adb shell dumpsys SurfaceFlinger
这个命令会输出很多内容，尾部会有当前正在使用的
GraphicBuffer信息，从上图中我们看到，当前正在使用的微信共有3个Graphic Buffer，所有的Buffer共占用接近90MB的内存，这些内存在应用不再显示后就马上回收。
关于上面的命令，你可能会好奇这个SurfaceFlinger是什么东西啊？
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部分，
为什么有的Buffer是直接发到HWComposer合成，
而有的Buffer需要通过GPU合并成一个新的Buffer才能合成。
同学你观察很仔细(...)，事实上，这是SurfaceFlinger合成过程中重要的细节，对于不同Surface的Buffer, 合成的方法有两种:
- 把Buffer发到
HWComposer，直接写到FrameBuffer的对位置 - 由于某些操作
HWComposer不能支持直接写(但是GPU知道)，部分Buffer的内容需要通过写到一个临时的Buffer中(HWComposer知道这个临时的Buffer该怎么写)，最终把这临时的Buffer写到FrameBuffer的对应位置。
显然第一种方法是最高效的，但为了保证正确性，Android系统结合了两种方法。具体实现上，SurfaceFlinger会询问(prepare)HWComposer是否支持直接合成，之后按照结果做对应处理。
有的朋友憋不住了:
你上面说合成的触发、
FrameBuffer显示到屏幕上都需要合适的时机，
到底是什么时机？
Good question! (太做作了。。。)
为了保证最好的渲染性能，上面各个步骤之间并不是串行阻塞运行的关系，所以有一个机制来调度每一步的触发时机，不过在此之前，我们先讲介绍一个更基础的概念:
屏幕刷新率
刷新率是屏幕的硬件指标，单位是Hz(赫兹)，意思是屏幕每秒可以刷新的次数。
这里稍微展开一下，我们之所以在屏幕上看到东西在"动"(看视频或者滑动列表)，其原理是屏幕在快速地播放不同的帧，相邻帧的图像只有很小的位移，加上大脑的残留效应，我们感官上就觉得这个东西在连续地动；有时候我们觉得手机界面卡顿，原因是两个帧之前的时间太长了，大脑残留内容消失了。
想要达到(看起来)流畅的效果，就要确保帧率足够大，一般电影(视频)的帧率不小于24帧，手机屏幕上不小于40帧，人眼就不易察觉卡顿了。
在2021年的今天，Android旗舰手机通常配置了90Hz~120Hz的高刷新率屏幕，iPhone与其他Android中低端手机会配置60Hz的屏幕。用60Hz来计算，1000 ➗ 60 ≈ 16.7ms。这就是要求每一帧数据在16ms之内绘制完成的原因。
当然，人眼的分辨能力还是远超60Hz，如果用一段时间90Hz或者120Hz的设备，再回到60Hz，就会觉得不爽。人眼也能适应越来越高的分辨率，现在大部分手机屏幕的分辨率超过了400ppi，有些上了2k屏已经超过了500ppi，再回到乔帮主在iPhone4定义的视网膜屏幕(指在距离屏幕10inch的距离，超过300ppi的分辨率是人眼难以分辨的，iPhone4/5/6/7/8的分辨率都是326ppi)，会察觉到明显的颗粒感。
回到问题，既然屏幕这个硬件每隔一段时间(如60Hz屏幕是16ms)就刷新一次，最佳的方案就是屏幕刷新时开始新一轮的绘制流程，让一次绘制的流程尽可能占满整个刷新周期，这样掉帧的可能性最小。基于这样的思考，在Android4.1(JellyBean)引入VSYNC(Vertical Synchronization - 垂直同步信号)
收到系统发出的VSYNC信号后，有三件事会同时执行(并行)：
- (第一步和第二步)应用开始绘制Graphic Buffer
- (第三步)SurfaceFlinger 开始合成FrameBuffer
- 屏幕刷新: 显示FrameBuffer中的数据
下图描述了没有掉帧时的VSYNC执行流程，现在我们可以直接回答问题了: 合适的时机就是VSYNC信号。
VSYNC信号调度下的Android绘制工作流
从上图可以看出，在一次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:
第3步的操作执行在系统进程中
终于。。。说完了
我们简单回顾一下，
- 准备材料
- 画出来
- 显示到屏幕
更形象一点就是:
Android渲染的演进
之所以有这一节，是因为随着Android版本的更替，渲染方案也发生了很多变化。为了简化表达，我们前文都以当前最新的方案来讲解，事实上，部分流程的实现方式在不同版本可能会有较大的变化，甚至在之前版本没有实现方案，这里我尽可能详细地列出Android版本更迭过程中与渲染相关的更新(包括监控工具)。
Android 3.0 (Honeycomb)
- 硬件加速
- DisplayList
Android 4.0 (Ice Cream Sandwich)
- 默认开启硬件加速
Android 4.1 (Jelly Bean)
-
Project Butter (黄油计划)
-
VSYNC
-
Triple-Buffering(3缓冲)
Android应用的BufferQueue中的Graphic Buffer数量经历了1个到2个再到3个的变化。一次次地提升了性能。
单Buffer时代，Buffer没有锁机制，也没有VSYNC来协调绘制的节奏，可能Buffer绘制到一半屏幕刷新了，结果就出现屏幕上下两部分界面错位的问题(如下图)。为了解决这个问题，于是锁机制与双Buffer就来了。
双Buffer时代，锁机制的加入就带来了对锁的争夺，加上没有VSYNC机制，界面上下错位的问题倒是没有了，但界面卡顿依然严重。
ProjectButter 项目带来了VSYNC, 与 三Buffer，这是因为CPU(第一步)、GPU(第二步)、与SurfaceFlinger(第三步)都会抢占Buffer，如果上一次的GPU渲染(第二步)比较耗时，此时下一次的VSYNC信号来了，那么系统会分配第三个Buffer给CPU。(有能力三Buffer，但非默认)
-
-
Systrace: 功能强大的采集工具
Android 4.2 (Jelly Bean)
Android 5.0 (Lollipop)
-
RenderThread
Android5.0之后，绘制阶段移到了单独线程RenderThread(渲染线程)中，进一步提升渲染性能。
-
RenderNode
Android 7.0 (Nougat)
- 支持Vulkan
Android 8.0 (Oreo)
- Bitmap内存转移至native内存
- Hardware-Only Bitmap
如果你居然能读到这里，那我猜你对下面的参考文章也会感兴趣：
Reference
https://source.android.com/devices/graphics
https://hencoder.com/tag/hui-zhi/
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=PLWz5rJ2EKKc9CBxr3BVjPTPoDPLdPIFCE
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
网友评论