图像渲染原理

iOS图形渲染底层结构

iOS图层渲染底层结构.png

最底层是图形硬件(GPU)；上层是Metal和CoreGraphics，提供一些接口来访问GPU；再上层的CoreAnimation是OpenGL ES和Metal在窗口显示的载体，在此基础上封装了一套动画的API。最上面的UIKit属于应用层，处理与用户的交互。

渲染流程.png

iOS 的渲染是在一个单独的进程 RenderServer 做的，App 会把 Render Tree 编码打包给 RenderServer，RenderServer 再调用渲染框架(Metal/OpenGL ES)来生成 bitmap（位图），放到帧缓冲区里，硬件根据时钟信号读取帧缓冲区内容，完成屏幕刷新。CATransaction 就是把一组 UI 上的修改，合并成一个事务，通过 commit 提交。

CoreAnimation渲染流水线

Handle Events 事件处理。如：用户的点击操作，在此过程中 app 可能需要更新视图树，相应地，图层树也会被更新。
Commit Transaction 可以细分为
- 布局（Layout）: 这是准备你的视图/图层的层级关系，以及设置图层属性（位置，背景色，边框等等）的阶段，这时候 UIViewController 的 viewDidLoad 和 LayoutSubViews 会调用，autolayout 也是在这一步生效
- 显示（Display）: 这是图层的寄宿图片被绘制的阶段。绘制有可能涉及你的 - drawRect: 和 -drawLayer:inContext: 方法的调用路径，该步骤使用 CPU 与 内存
- 准备（Prepare）: 主要处理图像的 解码 与 格式转换 等操作
- 提交（Commit）: 将 Layer 递归打包通过 IPC（内部处理通信）并发送到 Render Server
Render Server 负责渲染工作，会解析上一步 Commit Transaction 中提交的信息并反序列化成渲染树（render tree)，随后根据layer的各种属性生成绘制指令，并在下一次 VSync 信号到来时调用 OpenGL 进行渲染。主要执行 OpenGL(Metal)、Core Graphics 相关程序，并调用 GPU。

Render Server操作分析
GPU 会等待显示器的VSync信号发出后才进行OpenGL渲染管线，将3D几何数据转化成2D的像素图像和光栅处理，随后进行新的一帧的渲染，并将其输出到缓冲区。
上图流程：CoreAnimation -> OpenGL(Metal)/Core Graphics -> GPU -> 渲染流程（顶点数据->顶点着色->图元装配->片元着色器-> runloop ->显示）
Display GPU 通过帧缓冲（Frame Buffer）、视频控制器等相关部件，将图像显示在屏幕上。GPU 进行渲染->帧缓存区里->视频控制器->读取帧缓存区信息（位图）->数模转换（数字信号->模拟信号）->（逐行扫描）显示

总结一下具体流程如下：

CPU: 计算视图 frame，图片解码，需要绘制纹理图片通过数据总线交给GPU
GPU:纹理混合，顶点变换与计算，像素点的填充计算，渲染到帧缓冲区。
时钟信号:垂直同步信号 V-Sync / 水平同步信号 H-Sync.
iOS设备双缓冲机制:显示系统通常会引入两个帧缓冲区，双缓冲机制(掉帧)

渲染过程.png

帧缓冲（Frame Buffer）

几种不同类型的屏幕缓冲：用于写入颜色值的颜色缓冲，用于写入深度信息的深度缓冲，以及允许我们基于一些条件丢弃指定片段的模板缓冲。把这几种缓冲结合起来叫做帧缓冲，它被储存于内存中。OpenGL给了我们自己定义帧缓冲的自由，我们可以选择性的定义自己的颜色缓冲、深度和模板缓冲。

虽然帧缓冲区的名称中包含了一个“缓冲区”字眼，但是其实他们根本不是缓冲区。实际上，并不存在与一个帧缓冲区对象(FBO)相关联的真正内存存储空间。相反，帧缓冲区对象(FBO)是一种容器，它可以保存其他确实有内存存储并且可以进行渲染的对象，例如纹理或渲染缓冲区。采用这种方式，帧缓冲区对象(FBO)能够在保存OpenGL管线的输出时将需要的状态和表面绑定到一起。

我们目前所做的渲染操作都是是在默认的帧缓冲之上进行的。当你创建了你的窗口的时候默认帧缓冲就被创建和配置好了（GLFW为我们做了这件事）。通过创建我们自己的帧缓冲我们能够获得一种额外的渲染方式。

你也许不能立刻理解应用程序的帧缓冲的含义，通过帧缓冲可以将你的场景渲染到一个不同的帧缓冲中，可以使我们能够在场景中创建镜子这样的效果，或者做出一些炫酷的特效。

渲染缓冲（Render Buffer）

渲染缓冲对象(RBO)是一种图像表面，它是专门为了绑定到FBO而设计的。它可以是一个颜色表面、模板表面、或者深度/模板组合表面。也是一个缓冲，它可以是一堆字节、整数、像素或者其他东西。渲染缓冲对象的一大优点是，它以OpenGL原生渲染格式储存它的数据，因此在离屏渲染到帧缓冲的时候，这些数据就相当于被优化过的了。

渲染缓冲对象(RBO)将所有渲染数据直接储存到它们的缓冲里，而不会进行针对特定纹理格式的任何转换，这样它们就成了一种快速可写的存储介质了。然而，渲染缓冲对象通常是只写的，不能修改它们（就像获取纹理，不能写入纹理一样）。可以用glReadPixels函数去读取，函数返回一个当前绑定的帧缓冲的特定像素区域，而不是直接返回附件本身。

因为它们的数据已经是原生格式了，在写入或把它们的数据简单地到其他缓冲的时候非常快。当使用渲染缓冲对象时，像切换缓冲这种操作变得异常高速。我们在每个渲染迭代末尾使用的那个glfwSwapBuffers函数，同样以渲染缓冲对象实现：我们简单地写入到一个渲染缓冲对象，最后交换到另一个里。渲染缓冲对象对于这种操作来说很完美。

屏幕撕裂

当我们使用单缓冲区的时候，帧缓存区里面是旧的数据，显示在屏幕上，GPU显示的时候是逐行扫描显示的，显示到一半的时候，然后又来了下一帧的数据，然后显示到屏幕上，所以就会出现下图所产生的屏幕撕裂。

屏幕撕裂

那么如何解决屏幕撕裂呢？苹果就运用了垂直同步Vsync + 双缓冲区 DoubleBuffering，iOS会一直使用这种策略。
垂直同步Vsync ：扫描过程中会有一个垂直信号表示扫描完毕，这样就不会出现扫描到一半的时候下一帧的数据过来显示了，没有显示完毕一张图片的时候，我们会一直等待扫描完毕，扫描完毕之后，垂直扫描信号会发出来，让我们扫描下一帧数据。所以垂直同步就是对帧缓存区加锁，来防止出现屏幕撕裂。
双缓冲区 DoubleBuffering：就是两个缓冲区同时渲染，屏幕上显示的是第一个缓冲区的数据，另外一个缓冲区就会等待下一个缓冲结果进行显示。屏幕缓冲区是存在显存中。

这样屏幕撕裂问题解决了，说那是又会出现一个新的问题——掉帧

掉帧

当我们启用了垂直同步Vsync + 双缓冲区 DoubleBuffering的时候，当我们接收到垂直信号Vsync的时候，CPU和GPU还没有准备好图片数据，所以视频控制器拿不到帧缓冲数据（Frame Buffer），所以就会出现掉帧现象。

掉帧

当我们视频控制器显示A数据的时候，下一个渲染流程（runloop）过来的时候，我们的CPU和GPU还没有渲染好B数据，所以我们的视频控制器显示的还是A数据，然后B数据显示到屏幕上的时候，A数据又没有渲染完毕，继续显示B数据，所以就会出现我们经常看到的卡屏现象，其实就是我们所说的掉帧。
为了解决掉帧现象，就出现了三缓冲区。

三缓冲区

三缓冲区使用一个前置缓存和两个后置缓存。在着色完第一个后置缓冲区的数据后，立即开始处理第二个后置缓冲区。就是A数据显示到屏幕上，两个后置缓冲区会帮我们去渲染B数据和C数据。但是即便这样，也还是有可能出现掉帧的，不过其掉帧几率会比双缓冲区好很多。

屏幕卡顿原因

CPU和GPU渲染流水线耗时过长导致掉帧
垂直同步Vsync + 双缓冲区 DoubleBuffering以掉帧为代价来解决屏幕撕裂问题
三缓冲区合理使用CPU和GPU减少掉帧次数，但还是不能解决掉帧问题