屏幕成像过程
- 将需要显示的图像，由CPU和GPU通过总线连接起来，在CPU中输出的位图经总线在合适的时机上传给GPU ，GPU拿到位图做相应位图的图层渲染、纹理合成。
- 将渲染后的结果，存储到帧缓存区，帧缓存区中存储的格式是位图
-
由视屏控制器根据Vsync（垂直同步信号）在指定时间之前去提取对应帧缓冲区当中的屏幕内容，交由显示器，从左上角逐行扫描进行显示
如图所示:
图像显示原理图
屏幕卡顿
屏幕卡顿是指图形图像的在显示时出现了撕裂（即图片错位显示）、掉帧（重复显示同一帧数据）等问题，导致用户能直观的从屏幕上看到的一种异常现象。
接下来解释屏幕卡顿以及为什么会出现这种现象。
屏幕卡顿原因
由图像的显示原理，我们知道一帧的显示是由CPU和GPU共同决定的。一般来说，页面滑动流畅是60fps，也就是1s有60帧更新，即每隔16.7ms就要产生一帧画面，而如果CPU和GPU加起来的处理时间超过了16.7ms，从缓存区获取位图显示时，下一帧数据还没准备好，获取的仍是上一帧的数据，产生
，掉帧就会导致屏幕卡顿。
-
苹果官方为解决屏幕撕裂问题，目前使用的方案是
，可以从根本上防止和解决屏幕撕裂，但是同时也导致了新的问题掉帧。虽然我们采用了双缓存区，但是我们并不能解决CPU和GPU处理图形图像的速度问题，导致屏幕在接收到垂直信号时，数据尚未准备好，缓存区仍是上一帧的数据，因此导致掉帧
如图所示:
卡顿、掉帧原因图 在垂直同步+双缓存区方案的基础上，提出将双缓存区，改为
的优化，但是这样并不能从根本解决掉帧问题，只是比双缓存区掉帧的概率小很多，用户可能无感知。
垂直同步与双缓存区
- VSync（垂直同步信号）：是指给帧缓冲加锁，当电子光束扫描的过程中，只有扫描完成了才会读取下一帧的数据，而不是只读取一部分
- 双缓存区：采用两个帧缓冲区用来存储GPU处理的结果，当屏幕显示其中一个缓存区内容时，另一个缓冲区继续等待下一个缓冲结果，两个缓冲区依次进行交替
渲染流程
iOS中的渲染流程如下图所示:
iOS渲染流程图
- App通过CoreGraphics、CoreAnimation、CoreImage等框架的接口调用来触发图形渲染操作
- CoreGraphics、CoreAnimation、CoreImage等框架将渲染交由OpenGL ES，由OpenGL ES来驱动GPU做渲染，最后显示到屏幕上
- 由于OpenGL ES 是跨平台的，所以在他的实现中，没有任何窗口相关的代码，而是让各自的平台为OpenGL ES提供载体。在iOS中，如果需要使用OpenGL ES，就是通过CoreAnimation提供窗口，让App可以去调用。
渲染框架总结
1、UIKit
- 通过设置UIKit组件的布局和相关属性来绘制界面；
- UIKit本身并不具备屏幕成像的能力，是通过组件底层的layer来实现；
- 负责对用户事件的响应、界面展示、runloop的需求方;
- UIView属于UIKit
2、CoreAnimation
源自Layer Kit，是一个复合引擎
- 苹果官方描述：Render、Compose、and animate visual elements，主要职责是渲染 + 构建 + 动画；
- 本质：CALayer是屏幕上用户可见内容的基础，主要是由于可视化内容到最后都会被分解成独立的图层(layer)，被存储在图层树中
- CALayer属于CoreAnimation
3、CoreGraphics
基于Quartz发高级绘图引擎，提供了非常强大的轻量级2D渲染能力
- 运行时绘制图像
- 可以处理基于路径的绘图、转换、颜色处理、离屏渲染、图案、渐变和阴影等
- CG大头的类都属于CoreGraphics Framework
4、CoreImage
拥有一系列线程的图像过滤器，可以对已经存在的图像进行高效处理
- 运行前绘制图像，与CoreGraphics正好相反，大部分情况会在GPU中完成工作，如果GPU很忙，会使用CPU处理
5、OpenGL ES
是 OpenGL 的子集
- 在iOS中要使用OpenGL ES ，需要CoreAnimation对外提供窗口
- 因为OpenGL ES是跨平台的，其内部的实现是不能有任何窗口相关的功能，需要不同平台为OpenGL ES提供载体
6、Metal
一套是由Apple实现的第三方标准
- 在iOS开发中，大部分开发者都没有直接使用过Metal，但是都或多或少的间接使用过
- CoreAnimation、CoreImage 、SceneKit 、SpritKit等渲染框架都是基于Metal构建的
