UIView 以及 CALayer 这两个 iOS 中最基础的类的相关知识。了解渲染知识，是为了在遇到 App 卡顿以及掉帧问题的时候，我们可以通过界面渲染的原理迅速定位到原因，从而更快的解决问题。
在阅读这篇文章之前，建议先了解屏幕成像的原理，可以参考 iOS 保持界面流畅的技巧 | Garan no dou 和图形图像渲染原理。UIResponder, 主要负责事件响应，属于 UIKit 框架。UIView 的职责是创建并管理图层，以确保当子视图在层级关系中添加或被移除时，其关联的图层在图层树中也有相同的操作，即保证视图树和图层树在结构上的一致性。
UIView 本身不具备图像渲染能力的，拥有一个 layer 属性用来持有一个 CALayer 实例，我们平时操作的 UIView 的绝大部分绘图属性内部其实都是操作其拥有的 layer 属性，比如 frame、hidden 等。open class UIView : UIResponder open var layer: CALayer { get } open class var layerClass: AnyClass { get } }
layerClass 属性，均为只读属性，其中：layer 属性返回的是 UIView 所持有的主 Layer(RootLayer) 实例，我们可以通过其来设置 UIView 没有封装的一些 layer 属性；layerClass 则返回 RootLayer 所使用的类，我们可以通过重写该属性，来让 UIView 使用不同的 CALayer 来显示。之所以设计成 UIView 和 CALayer 提供两个平行的层级关系，原因在于要做 职责分离，这样也能避免很多重复代码。在 iOS 和 Mac OS X 两个平台上，事件和用户交互有很多地方的不同，基于多点触控的用户界面和基于鼠标键盘的交互有着本质的区别，这就是为什么 iOS 有UIKit和UIView，对应 Mac OS X 有AppKit和NSView的原因。它们在功能上很相似，但是在实现上有着显著的区别。
NSObject, 负责图像渲染，属于 QuartzCore 框架。CALayer 视图结构类似 UIView 的子 View 树形结构，它们分别可以有自己的 SubView 和 SubLayer，可以向它的 RootLayer 上添加子 layer，来完成一些页面效果，比如说渐变等。
Layer 相对 View 来说是更加轻量的，所以当显示部分不需要事件响应时，我们可以优先考虑使用 layer。
为什么 CALayer 可以呈现可视化内容呢？因为 CALayer 基本等同于一个 纹理。纹理是 GPU 进行图像渲染的重要依据。 CALayer 包含一个 contents 属性指向一块缓存区，称为 backing store，可以存放位图（Bitmap）。iOS 中将该缓存区保存的图片称为 寄宿图。而当设备屏幕进行刷新时，会从 CALayer 中读取生成的 bitmap ，进而呈现到屏幕上。
图形渲染流水线支持从顶点开始进行绘制（在流水线中，顶点会被处理生成纹理），也支持直接使用纹理（图片）进行渲染。相应地，在实际开发中，绘制界面也有两种方式：一种是 手动绘制；另一种是 使用图片。UIImageView 显示的形式，我们通过 CALayer 的 contents 属性来配置图片。contents 属性的类型为 id，在这种情况下，可以给 contents 属性赋予任何值，项目仍可以编译通过。但是在实践中，如果 content 的值不是 CGImage ，得到的图层将是空白的。之所以将contents的属性类型定义为id而非CGImage。这是因为在 Mac OS 系统中，该属性对CGImage和NSImage类型的值都起作用，而在 iOS 系统中，该属性只对CGImage起作用。
Core Graphics 直接绘制寄宿图。实际开发中，一般通过继承 UIView 并实现 -drawRect: 方法来自定义绘制。具体什么时候会调用 -drawRect: ，我们在下面渲染流程中会说到。
layer tree。
Metal/Core GraphicsCore Graphics负责处理 CPU 渲染。
Graphics HardWare
Core Graphics、Core Animation、Core Image 等框架来绘制可视化内容，这些软件框架相互之间也有着依赖关系。这些框架都需要通过 OpenGL 来调用 GPU 进行绘制，最终将内容显示到屏幕之上。
Core Animation 处理显示内容，比如布局计算、图片解码等，之后把计算好的图层树 layer tree 编码打包发给 Render Server，这一步工作在 CPU 上。
3. Decode
Render Server 收到打包好的图层树，调用 Core Animation 进行解码，这一步工作在 CPU 上。
4. Draw Calls
解码完成后，Core Animation 会调用下层渲染框架（OpenGL ES / Metal）生成 Draw Calls 绘制调用，告诉 GPU 需要渲染的信息，包含 primitives 图元信息，由 CPU 发起。
了解 Draw Calls，可以看这个 视频 。
5. Render
渲染，准备 frame buffer/back buffer 缓冲区数据，等待下一个垂直信号 VSync 来读取 frame buffer/back buffer 缓冲区数据，这一步工作在 GPU 上。
6. Display
屏幕显示，视频控制器读取帧缓冲区的数据，交给显示器显示。
layoutSubviews 方法addSubview 方法添加子视图primitives 数据，通常是三角形、线段、顶点等：drawRect: 方法，那么会调用重载的 drawRect: 方法，在 drawRect: 方法中手动绘制得到 bitmap 数据，从而自定义视图的绘制。primitives 信息，而位图 bitmap 是在 GPU 中根据图元信息绘制得到的。但是如果重写了 drawRect: 方法，这个方法会直接调用 Core Graphics 绘制方法得到 bitmap 数据，同时系统会额外申请一块内存，用于暂存绘制好的 bitmap。
由于重写了 drawRect: 方法，导致绘制过程从 GPU 转移到了 CPU，这就导致了一定的效率损失。与此同时，这个过程会额外使用 CPU 和内存，因此需要高效绘制，否则容易造成 CPU 卡顿或者内存爆炸。Render Server 收到 Commit Transaction 提交过来的图层树 layer tree 之后，会先交给 Core Animation 的 Decode 解码，再调用 Metal/OpenGL 生成 Draw Calls 绘制调用，交给 GPU，执行 Render。
接下来我们看下 Render 的具体过程，如下图：
Command Buffer，即OpenGL/Metal的渲染指令，包含图元 primitives 信息。Parameter Buffer中。bitmap，存储到Render Buffer。Display显示。LayoutIfNeed 将会立即触发布局的更新。
通过 Layout 的流程我们知道在这之后会调用重载的 layoutSubviews 方法，创建视图，并通过 addSubview 方法添加子视图，计算视图布局，即所有的 Layout Constraint。
为什么说直接代码设置 frame 的方式性能要好于使用 autoLayout，主要原因是直接设置 frame 我们已经提前计算好了 Layer 的位置和大小，如果不重写 layoutSubviews，那么系统的 layoutSubviews 什么都不需要做。而使用 autolayout，用代码将布局的规则描述出来，具体的计算交给系统去做，自然会多消耗一些性能。
setNeedsDisplay 之后，会调用 layer 的 setNeedsDisplay 方法。display 方法。displayLayer：方法来实现异步绘制。displayLayer： 方法，则继续系统的绘制流程。drawRect: 方法中实现我们的内容绘制。
kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 之间。每次检测时设置标记位为 YES，然后派发任务到主线程中将标记位设置为 NO。接着子线程沉睡超时阙值时长，判断标志位是否成功设置成 NO，如果没有说明主线程发生了卡顿，详细的原理和实现可以参考 使用RunLoop原理监控卡顿。
