前言
在软件开发领域里经常能听到这样一句话，“过早的优化是万恶之源”，不要过早优化或者过度优化。我认为在编码过程中时刻注意性能影响是有必要的，但凡事都有个度，不能为了性能耽误了开发进度。在时间紧急的情况下我们往往采用“quick and dirty”的方案来快速出成果，后面再迭代优化，即所谓的敏捷开发。与之相对应的是传统软件开发中的瀑布流开发流程。
卡顿产生的原因
image
在 iOS 系统中，图像内容展示到屏幕的过程需要 CPU 和 GPU 共同参与。CPU 负责计算显示内容，比如视图的创建、布局计算、图片解码、文本绘制等。随后 CPU 会将计算好的内容提交到 GPU 去，由 GPU 进行变换、合成、渲染。之后 GPU 会把渲染结果提交到帧缓冲区去，等待下一次 VSync 信号到来时显示到屏幕上。由于垂直同步的机制，如果在一个 VSync 时间内，CPU 或者 GPU 没有完成内容提交，则那一帧就会被丢弃，等待下一次机会再显示，而这时显示屏会保留之前的内容不变。这就是界面卡顿的原因。
因此，我们需要平衡 CPU 和 GPU 的负荷避免一方超负荷运算。为了做到这一点，我们首先得了解 CPU 和 GPU 各自负责哪些内容。
image
上面的图展示了 iOS 系统下各个模块所处的位置，下面我们再具体看一下 CPU 和 GPU 对应了哪些操作。
CPU 消耗型任务
布局计算
布局计算是 iOS 中最为常见的消耗 CPU 资源的地方，如果视图层级关系比较复杂，计算出所有图层的布局信息就会消耗一部分时间。因此我们应该尽量提前计算好布局信息，然后在合适的时机调整对应的属性。还要避免不必要的更新，只在真正发生了布局改变时再更新。
对象创建
对象创建过程伴随着内存分配、属性设置、甚至还有读取文件等操作，比较消耗 CPU 资源。尽量用轻量的对象代替重量的对象，可以对性能有所优化。比如 CALayer 比 UIView 要轻量许多，如果视图元素不需要响应触摸事件，用 CALayer 会更加合适。
通过 Storyboard 创建视图对象还会涉及到文件反序列化操作，其资源消耗会比直接通过代码创建对象要大非常多，在性能敏感的界面里，Storyboard 并不是一个好的技术选择。
对于列表类型的页面，还可以参考 UITableView 的复用机制。每次要初始化 View 对象时先根据 identifier 从缓存池里取，能取到就复用这个 View 对象，取不到再真正执行初始化过程。滑动屏幕时，会将滑出屏幕外的 View 对象根据 identifier 放入缓存池，新进入屏幕可见范围内的 View 又根据前面的规则来决定是否要真正初始化。
Autolayout
Autolayout 是苹果在 iOS6 之后新引入的布局技术，在大多数情况下这一技术都能大大提升开发速度，特别是在需要处理多语言时。比如阿拉伯语下布局是从右往左，通过 Autolayout 设置 leading 和 trailing 即可。
但是 Autolayout 对于复杂视图来说常常会产生严重的性能问题，对于性能敏感的页面建议还是使用手动布局的方式，并控制好刷新频率，做到真正需要调整布局时再重新布局。
文本计算
如果一个界面中包含大量文本（比如微博、微信朋友圈等），文本的宽高计算会占用很大一部分资源，并且不可避免。
一个比较常见的场景是在 UITableView 中，heightForRowAtIndexPath这个方法会被频繁调用，即使不是耗时的计算在调用次数多了之后也会带来性能损耗。这里的优化就是尽量避免每次都重新进行文本的行高计算，可以在获取到 Model 数据后就根据文本内容计算好布局信息，然后将这份布局信息作为一个属性保存到对应的 Model 中，这样在 UITableView 的回调中就可以直接使用 Model 中的属性，减少了文本的计算。
文本渲染
屏幕上能看到的所有文本内容控件，包括 UIWebView，在底层都是通过 CoreText 排版、绘制为 Bitmap 显示的。常见的文本控件 （UILabel、UITextView 等），其排版和绘制都是在主线程进行的，当显示大量文本时，CPU 的压力会非常大。
这一部分的性能优化就需要我们放弃使用系统提供的上层控件转而直接使用 CoreText 进行排版控制。
Wherever possible, try to avoid making changes to the frame of a view that contains text, because it will cause the text to be redrawn. For example, if you need to display a static block of text in the corner of a layer that frequently changes size, put the text in a sublayer instead.
上面这段话引用自 iOS Core Animation: Advanced Techniques，翻译过来的意思就是说包含文本的视图在改变布局时会触发文本的重新渲染，对于静态文本我们应该尽量减少它所在视图的布局修改。
图像的绘制
图像的绘制通常是指用那些以 CG 开头的方法把图像绘制到画布中，然后从画布创建图片并显示的过程。前面的模块图里介绍了 CoreGraphic 是作用在 CPU 之上的，因此调用 CG 开头的方法消耗的是 CPU 资源。我们可以将绘制过程放到后台线程，然后在主线程里将结果设置到 layer 的 contents 中。代码如下：
- (void)display {
dispatch_async(backgroundQueue, ^{
CGContextRef ctx = CGBitmapContextCreate(...);
// draw in context...
CGImageRef img = CGBitmapContextCreateImage(ctx);
CFRelease(ctx);
dispatch_async(mainQueue, ^{
layer.contents = img;
});
});
}
图片的解码
Once an image file has been loaded, it must then be decompressed. This decompression can be a computationally complex task and take considerable time. The decompressed image will also use substantially more memory than the original.
图片被加载后需要解码，图片的解码是一个复杂耗时的过程，并且需要占用比原始图片还多的内存资源。
为了节省内存，iOS 系统会延迟解码过程， 在图片被设置到 layer 的 contents 属性或者设置成 UIImageView 的 image 属性后才会执行解码过程，但是这两个操作都是在主线程进行，还是会带来性能问题。
如果想要提前解码，可以使用 ImageIO 或者提前将图片绘制到 CGContext 中，这部分实践可以参考 iOS Core Animation: Advanced Techniques
这里多提一点，常用的 UIImage 加载方法有 imageNamed 和 imageWithContentsOfFile。其中 imageNamed 加载图片后会马上解码，并且系统会将解码后的图片缓存起来，但是这个缓存策略是不公开的，我们无法知道图片什么时候会被释放。因此在一些性能敏感的页面，我们还可以用 static 变量 hold 住 imageNamed 加载到的图片避免被释放掉，以空间换时间的方式来提高性能。
GPU消耗型任务
相对于 CPU 来说，GPU 能干的事情比较单一：接收提交的纹理（Texture）和顶点描述（三角形），应用变换（transform）、混合并渲染，然后输出到屏幕上。宽泛的说，大多数 CALayer 的属性都是用 GPU 来绘制。
以下一些操作会降低 GPU 绘制的性能，
大量几何结构
所有的 Bitmap，包括图片、文本、栅格化的内容，最终都要由内存提交到显存，绑定为 GPU Texture。不论是提交到显存的过程，还是 GPU 调整和渲染 Texture 的过程，都要消耗不少 GPU 资源。当在较短时间显示大量图片时（比如 TableView 存在非常多的图片并且快速滑动时），CPU 占用率很低，GPU 占用非常高，界面仍然会掉帧。避免这种情况的方法只能是尽量减少在短时间内大量图片的显示，尽可能将多张图片合成为一张进行显示。
另外当图片过大，超过 GPU 的最大纹理尺寸时，图片需要先由 CPU 进行预处理，这对 CPU 和 GPU 都会带来额外的资源消耗。
视图的混合
当多个视图（或者说 CALayer）重叠在一起显示时，GPU 会首先把他们混合到一起。如果视图结构过于复杂，混合的过程也会消耗很多 GPU 资源。为了减轻这种情况的 GPU 消耗，应用应当尽量减少视图数量和层次，并且减少不必要的透明视图。
离屏渲染
离屏渲染是指图层在被显示之前是在当前屏幕缓冲区以外开辟的一个缓冲区进行渲染操作。
离屏渲染需要多次切换上下文环境：先是从当前屏幕（On-Screen）切换到离屏（Off-Screen）；等到离屏渲染结束以后，将离屏缓冲区的渲染结果显示到屏幕上又需要将上下文环境从离屏切换到当前屏幕，而上下文环境的切换是一项高开销的动作。
会造成 offscreen rendering 的原因有：
- 阴影（UIView.layer.shadowOffset/shadowRadius/…）
- 圆角（当 UIView.layer.cornerRadius 和 UIView.layer.maskToBounds 一起使用时）
- 图层蒙板
- 开启光栅化（shouldRasterize = true）
使用阴影时同时设置 shadowPath 就能避免离屏渲染大大提升性能，后面会有一个 Demo 来演示；圆角触发的离屏渲染可以用 CoreGraphics 将图片处理成圆角来避免。
CALayer 有一个 shouldRasterize 属性，将这个属性设置成 true 后就开启了光栅化。开启光栅化后会将图层绘制到一个屏幕外的图像，然后这个图像将会被缓存起来并绘制到实际图层的 contents 和子图层，对于有很多的子图层或者有复杂的效果应用，这样做就会比重绘所有事务的所有帧来更加高效。但是光栅化原始图像需要时间，而且会消耗额外的内存。
光栅化也会带来一定的性能损耗，是否要开启就要根据实际的使用场景了，图层内容频繁变化时不建议使用。最好还是用 Instruments 比对开启前后的 FPS 来看是否起到了优化效果。
注意：
shouldRasterize = true 时记得同时设置 rasterizationScale
Instruments 使用
image
Instruments 是一系列工具集，我们这里只演示 Core Animation 的使用。在 Core Animation 选项右下方会看到如下选项，
image
Color Blended Layers
这个选项选项基于渲染程度对屏幕中的混合区域进行绿到红的高亮显示，越红表示性能越差，会对帧率等指标造成较大的影响。红色通常是由于多个半透明图层叠加引起。
Color Hits Green and Misses Red
当 UIView.layer.shouldRasterize = YES 时，耗时的图片绘制会被缓存，并当做一个简单的扁平图片来呈现。这时候，如果页面的其他区块(比如 UITableViewCell 的复用)使用缓存直接命中，就显示绿色，反之，如果不命中，这时就显示红色。红色越多，性能越差。因为栅格化生成缓存的过程是有开销的，如果缓存能被大量命中和有效使用，则总体上会降低开销，反之则意味着要频繁生成新的缓存，这会让性能问题雪上加霜。
Color Copied Images
对于 GPU 不支持的色彩格式的图片只能由 CPU 来处理，把这样的图片标为蓝色。蓝色越多，性能越差。
Color Immediately
通常 Core Animation Instruments 以每毫秒 10 次的频率更新图层调试颜色。对某些效果来说，这显然太慢了。这个选项就可以用来设置每帧都更新（可能会影响到渲染性能，而且会导致帧率测量不准，所以不要一直都设置它）。
Color Misaligned Images
这个选项检查了图片是否被缩放，以及像素是否对齐。被放缩的图片会被标记为黄色，像素不对齐则会标注为紫色。黄色、紫色越多，性能越差。
Color Offscreen-Rendered Yellow
这个选项会把那些离屏渲染的图层显示为黄色。黄色越多，性能越差。这些显示为黄色的图层很可能需要用 shadowPath 或者 shouldRasterize 来优化。
Color OpenGL Fast Path Blue
这个选项会把任何直接使用 OpenGL 绘制的图层显示为蓝色。蓝色越多，性能越好。如果仅仅使用 UIKit 或者 Core Animation 的 API，那么不会有任何效果。
Flash Updated Regions
这个选项会把重绘的内容显示为黄色。不该出现的黄色越多，性能越差。通常我们希望只是更新的部分被标记完黄色。
演示
上述几个选项中常用来检测性能的是 Color Blended Layers、Offscreen-Rendered Yellow 和 Color Hits Green and Misses Red。下面我重点演示一下离屏渲染和光栅化的检测，写了一个简单的 Demo 设置了阴影效果，代码如下：
view.layer.shadowOffset = CGSizeMake(1, 1);
view.layer.shadowOpacity = 1.0;
view.layer.shadowRadius = 2.0;
view.layer.shadowColor = [UIColor blackColor].CGColor;
// view.layer.shadowPath = CGPathCreateWithRect(CGRectMake(0, 0, 50, 50), NULL);
shadowPath 没有设置时用 Instruments 检测 FPS 基本在 20 以下（iPhone6设备），设置了 shadowPath 后基本维持在 55 左右，性能提升十分明显。
下面来看一下光栅化的检测，代码如下，
view.layer.shouldRasterize = YES;
view.layer.rasterizationScale = [UIScreen mainScreen].scale;
勾选 Color Hits Green and Misses Red 选项后显示如下：
image
我们可以看到在静止时缓存都生效了，在快速滑动时缓存基本不起作用，因此是否要开启光栅化还是得根据具体场景，用 Instruments 检测开启前后的性能来决定。
总结
本文主要总结了性能调优的一些理论知识，后面还介绍了 Instruments 中 Core Animation 的一些性能检测指标用法。性能优化最重要的是要使用工具来检测而不是猜测，先查看是否有离屏渲染等问题，再用 Time Profiler 分析一下耗时的函数调用。修改后再用工具分析是否有改善，一步一步执行，小心仔细。
建议大家也实际动手分析一下自己的应用，加深一下印象，enjoy~
参考资料
- http://blog.ibireme.com/2015/11/12/smooth_user_interfaces_for_ios/
- http://www.samirchen.com/use-instruments/
- http://apprize.info/apple/ios_5/13.html
https://www.jianshu.com/p/1b5cbf155b31