iOS 视图，动画渲染机制探究

终端的开发，首当其冲的就是视图、动画的渲染，切换等等。用户使用 App 时最直接的体验就是这个界面好不好看，动画炫不炫，滑动流不流畅。UI就是 App 的门面，它的体验伴随着用户使用 App 的整个过程。如果UI失败，用户是不会有打开第二次的欲望的。

iOS 为开发者提供了丰富的 Framework（UIKit，Core Animation，Core Graphic，OpenGL 等等）来满足开发从上层到底层各种各样的需求。不得不说苹果很牛逼，很多接口你根本不需要理解背后的原理就能上手使用并且满足你大部分的需求，但是，如果遇到性能问题就容易抓瞎。易用性跟优化就是个矛盾体，就像 ARC 一样，当你没有遇到内存问题的时候用得很爽，一旦遇到了，就要要求你比在用 MRC 的时候更加了解 iOS 的内存机制。UI 亦是如此。况且，作为鹅厂的员工当然不能仅限于知道怎么用。我们要知其然还要知其所以然。好了，废话不说，我们进入主题：看看 iOS 是如何渲染视图和动画的，以及在我们遇到渲染的性能问题时怎么做优化。

（注意：以下内容是笔者的一些踩坑经验和总结, 欢迎探讨！）

先来看看官方对 Core Animation 的一段说明：

可以看出iOS渲染视图的核心是 Core Animation。从底层到上层依此是 GPU->(OpenGL、Core Graphic) → Core Animation → UIKit。

在 iOS上，动画和视图的渲染其实是在另外一个进程做的（下面我们叫这个进程 render server），在 iOS 5 以前这个进程叫 SpringBoard，在 iOS 6 之后叫 BackBoard。

下面这幅图是使用项目录制视频的时候（大量视图渲染），整个系统的进程情况：

可以很清楚地看到 BackBoard 这个进程的情况。

iOS 上视图或者动画渲染的各个阶段：

在 APP 内部的有4个阶段：

布局：在这个阶段，程序设置 View / Layer 的层级信息，设置 layer 的属性，如 frame，background color 等等。
创建 backing image：在这个阶段程序会创建 layer 的 backing image，无论是通过 setContents 将一个 image 传給 layer，还是通过 [drawRect:] 或 [drawLayer: inContext:] 来画出来的。所以 [drawRect:] 等函数是在这个阶段被调用的。
准备：在这个阶段，Core Animation 框架准备要渲染的 layer 的各种属性数据，以及要做的动画的参数，准备传递給 render server。同时在这个阶段也会解压要渲染的 image。（除了用 imageNamed：方法从 bundle 加载的 image 会立刻解压之外，其他的比如直接从硬盘读入，或者从网络上下载的 image 不会立刻解压，只有在真正要渲染的时候才会解压）。
提交：在这个阶段，Core Animation 打包 layer 的信息以及需要做的动画的参数，通过 IPC（inter-Process Communication）传递給 render server。

在 APP 外部的2个阶段：

当这些数据到达 render server 后，会被反序列化成 render tree。然后 render server 会做下面的两件事：

根据 layer 的各种属性（如果是动画的，会计算动画 layer 的属性的中间值），用 OpenGL 准备渲染。
渲染这些可视的 layer 到屏幕。

如果做动画的话，最后的两个步骤会一直重复直到动画结束。

我们都知道 iOS 设备的屏幕刷新频率是 60Hz。如果上面的这些步骤在一个刷新周期之内无法做完（1/60s），就会造成掉帧。

我们看看有哪些操作可能会过度消耗 CPU 或者 GPU，从而造成掉帧。

视图上有太多的 layer 或者几何形状：如果视图的层级结构太复杂的话，当某些视图被渲染或者 frame 被修改的话，CPU 会花比较多得时间去重新计算 frame。尤其如果用 autolayout 的话，会更消耗 CPU。同时过多的几何结构会大大增多需要渲染的 OpenGLl triangles 以及栅格化的操作（将 OpenGL 的 triangles 转化成像素）
太多的 overdraw：overdraw 是指一个像素点被多次地用颜色填充。这个主要是由于一些半透明的 layer 相互重叠造成的。GPU 的 fill-rate（用颜色填充像素的速率）是有限的。如果 overdraw 太多的话，势必会降低 GPU 的性能。
视图的延后载入： iOS 只有在展示 viewcontroller 的 view 或者访问 viewcontroller 的 view，比如说 someviewcontroller.view 的时候才会加载view。如果在用户点击了某个 button，并且在 button 的响应函数里做了很多消耗 cpu 的工作，这个时候如果 present 某个 viewcontroller 的话，会容易卡顿，尤其是如果 viewcontroller 要从 database 里获取数据，或者从 nib 文件初始化 view 或者加载图片会更卡。
离屏的绘制：离屏的绘制有两种情况：1. 有些效果（如 rounded corners，layer masks，drop shadows 和 layer rasterization）不能直接的绘制到屏幕上，必须先绘制到一个 offscreen 的 image context 上，这种操作会引入额外的内存和 CPU 消耗。2. 实现了 drawRect 或者 drawLayer:inContext:，为了支持任意的绘制，core graphic 会创建一个大小跟要画的 view 一样的 backing image。并且当画完的以后要传输到 render server 上渲染。所以没事不要重载 drawRect 等函数却什么都不做。
图片解压：用 imageNamed：从 bundle 里加载会立马解压。一般的情况是在赋值给 UIImageView 的 image 或者 layer 的 contents 或者画到一个 core graphic context 里才会解压。

渲染性能优化的注意点：

隐藏的绘制：catextlayer 和 uilabel 都是将 text 画入 backing image 的。如果改了一个包含 text 的 view 的 frame 的话，text 会被重新绘制。

Rasterize：当使用 layer 的 shouldRasterize 的时候（记得设置适当的 laye r的 rasterizationScale），layer 会被强制绘制到一个 offscreen image 上，并且会被缓存起来。这种方法可以用来缓存绘制耗时（比如有比较绚的效果）但是不经常改的 layer，如果 layer 经常变，就不适合用。

离屏绘制：使用 Rounded corner， layer masks， drop shadows 的效果可以使用 stretchable images。比如实现 rounded corner，可以将一个圆形的图片赋值于 layer 的 content 的属性。并且设置好 contentsCenter 和 contentScale 属性。

Blending and Overdraw ：如果一个 layer 被另一个 layer 完全遮盖，GPU 会做优化不渲染被遮盖的 layer，但是计算一个 layer 是否被另一个 layer 完全遮盖是很耗 cpu 的。将几个半透明的 layer 的 color 融合在一起也是很消耗的。

我们要做的：