本系列文章的重点是关注在总结iOS图形图像的原理和性能优化的常规解决方案。
事先声明，本文绝大多数概念和内容均来源于已有素材，但是均经过作者消化后总结归纳。如果你不想麻烦地自己去网络一一搜索资料，那么本文将是一个很好的总结笔记。阅读前提是读者已经基本了解View和Layer的操作。如果你对iOS 2D图像优化已经熟练，可以忽略本文。
前一段时间在review code的时候，看到一段对于Collection View的滑动性能有一定影响的处理代码，以前对于UI性能这部分有一些了解，但是比较粗浅，于是就想系统学习下iOS关于2D 图形图像性能的资料，结果一翻不得了，相关内容越挖越深，扩展开来感觉进入了一个浩大的领域。这个话题的火热程度可以举个简单例子：在简书上搜索“Quartz 2D” 或者 “Core Graphic”就有大约5、6百篇文章，如果搜索“iOS 优化”甚至有超过1万条记录。经过前后大约2-3周的零碎时间，我仔细搜集整理了20余篇优秀资料总结出本文，给自己留个研究笔记，也希望能帮助到需要的人。
知己知彼，百战不殆。
掌握任何一件事情都需要从原理入手。我们先来巩固iOS 2D Graphic相关的基本概念和知识。
1. 关于iOS 图像处理的基本概念
1.1 Graphic Frameworks
首先看一张来自Apple的描述图形处理模块的经典（烂大街）图：
最上层是UIKit框架，这是服务于Application的最前端框架，封装了所有“UI*”空间类和操作；在其之下是Core Animation框架，借助与这个框架，Apple向开发人员提供了非常方便的动画处理功能和图像渲染功能。再往下，分离成基于GPU绘图的OpenGL ES层和基于CPU绘图的Core Graphic层。最底层的就是支持最终绘图的硬件平台，包括GPU，CPU，缓存，总线等等。
虽然在Apple的文档里，看起来Core Graphic的层级在Core Animation之下，和OpenGL是同一个level，但其实它们三者之间的关系非常紧密，App和它们之间的交互也更加自由，并非被CA层完全拦截在中间。各个部分之间的工作关系如下图：
GPU Driver 是直接和 GPU 交流的代码块，使不同的GPU在下一个层级上显示的更为统一，典型的下一层级有 OpenGL/OpenGL ES. OpenGL(Open Graphics Library) 是一个提供了 2D 和 3D 图形渲染的 API。OpenGL 和 GPU 密切的工作以提高GPU的能力，并实现硬件加速渲染。OpenGL 之上扩展出很多东西。在 iOS 上，几乎所有的东西都是通过 Core Animation 绘制出来，然而在 OS X 上，绕过 Core Animation 直接使用 Core Graphics 绘制的情况并不少见。对于一些专门的应用，尤其是游戏，程序可能直接和 OpenGL/OpenGL ES 交流。
顺便提一下，也许你会在网上看到类似这样一幅图：
我个人觉得这幅图是有一定问题的，因为这会给人一个错觉，好像图形的处理对于CPU和GPU而言是分离的，但是实际上，CPU处理完的数据最终都需要提交到GPU。不管是iOS还是Mac，最终所有的绘图操作都会通过OpenGL层去操作GPU。
但是这个图也有一个好处，是它通常意义上诠释了：Core Animation操作基于GPU进行“硬绘图”的OpenGL ES，和基于CPU进行“软绘图”的Core Graphic。使用Core Graphic绘制会让Core Animation 使用CPU创建一张Content"图片"，CPU处理生成这张图片后交给GPU进行显示。一般来说，GPU做Rendering，Tilering，Compositing，而CPU更多的时候是做图层布局处理和协助GPU做预处理（预绘制，动画准备，动画提交，计算动画中间值等等）。根据这张图你可以有个直观的印象就是：调用CG开头的API会触发CPU去处理图像，也就是说这个会涉及到后文中关于影响性能的一个重要概念：CPU密集型（CPU bound）操作。
CPU和GPU之间真正的关系可以看下图：
GPU 需要将每一个 frame 的纹理(位图)合成在一起(一秒60次)。每一个纹理会占用 VRAM(video RAM)，所以需要给 GPU 同时保持纹理的数量做一个限制。GPU 在合成方面非常高效，但是某些合成任务却比其他更复杂，并且 GPU在 16.7ms(1/60s)内能做的工作也是有限的。为了让 GPU 访问数据，需要将数据从 RAM 移动到 VRAM 上，一些大型的纹理却会非常耗时。
举个例子，比如显示文本，对 CPU来说会调用 Core Text 和 Core Graphics 框架更紧密的集成来根据文本生成一个位图。一旦准备好，它将会被作为一个纹理上传到 GPU 并准备显示出来。当你滚动或者在屏幕上移动文本时，同样的纹理能够被复用，CPU 只需简单的告诉 GPU 新的位置就行了，所以 GPU 就可以重用存在的纹理了。CPU 并不需要重新渲染文本，并且位图也不需要重新上传到 GPU。
在这里，有必要再讨论下Quartz。Quartz这个名词其实是一个从Mac上过来的历史遗留物，而其本身是Apple窗口服务器和描画技术的一般叫法。在Apple的《Quartz 2D Programming Guide》中，开篇一句话已经基本解释了Quartz和Core Graphic的关系：
Quartz 2D is an advanced, two-dimensional drawing engine available for iOS application development and to all Mac OS X application environments outside of the kernel. The Quartz 2D API is part of the Core Graphics framework, so you may see Quartz referred to as Core Graphics or, simply, CG.
Quartz 2D是iPhone OS和Mac OS X环境下的二维绘图引擎。它其实是Core Graphic的一个核心部分。使用Quartz 2D API，你可以：基于路径的绘图，透明度绘图，遮盖，阴影，透明层，颜色管理，防锯齿渲染，生成PDF，以及PDF元数据相关处理。在Mac OS X下，Quartz 2D能与其它图形图像技术相结合——Core Image，Core Video，OpenGL，以及Quick Time。类似的，在iPhone OS下的Quartz 2D也能与其它的图像和动画技术相结合——Core Animation，OpenGL ES，以及UIKit类。
另外，这篇回答详细的讨论了和Quartz/Core Graphic相关的framework的列表：
- CoreGraphics.framework
Quartz 2D : API manages the graphic context and implements drawing.
Quartz Services : API provides low level access to the window server. This includes display hardware, resolution, refresh rate, and others.
- QuartzCore.framework
Core Animation : Objective-C API to do 2D animation.
Core Image: image and video processing (filters, warp, transitions).iOS 5
- Quartz.framework （OS X only）
Image Kit: display and edit images.
PDF Kit: display and edit PDFs.
Quartz Composer: display Quartz Composer compositions.
QuickLookUI: preview media elements.
- 其它一些Quartz技术：
Quartz Extreme: GPU acceleration for Quartz Composer.
QuartzGL (aka "Quartz 2D Extreme"): GPU acceleration for Quartz 2D.
只需要记住一点，从某种意义上来说，Quartz 和CG可以互相混淆，事实上，上文的作者也嘲笑了一句“如果Apple的目的是想把大家给搞糊涂那么他们成功地做到了！”
上面主要针对的是CA层，CG层和GPU、CPU之间的关系，那么我们再从CA层往上走，来看看CA层和UI层之间的关系。
1.2 UIView 和 CALayer
“每一个成功的男人背后都有一个女人！”
你在iOS上能看到的，触碰到的所有东西，都是UIView展示出来的。你刚开始接触iOS开发的时候，使用的最多的，也是UIView，看起来UIView无限风光。但是如果认为UIView是绘制出的图像那你就错了！在iOS中，每一个UIView的背后都有一个默认的CALayer，真正为图像做出贡献的，其实是这个layer，UIView只是作为一个视窗容器，用来精简封装layer并对外提供响应操作而已。
iOS中UIView和CALayer的关系如下图：
CALayer是UIView的基础，所有实际的绘图工作都是Layer向其backing store里绘制bit map完成的。而操作View的绝大多数图形属性，其实都是直接操作的其拥有的layer属性，比如frame，bounds，backgroundColor等等。
UIView和CALayer都有自己的树状结构，它们都可以有自己的SubView和SubLayer：
对于每一个使用Core Animation的App来说，系统实际上维护这3套不同的Layer 树状层级：
- layer tree （modal tree）：这里是App的代码直接操纵的tree，你所修改的各种属性值都是反映在这个tree里;
- presentation tree：这是一个中间层，系统在做动画时，所有动画中间态就都在这一层上更改属性来完成动画的分动作；
- render tree：这是直接对应于提交到render server上进行显示的树，屏幕上的内容对应于该层。
这让我想起了一句老话：“每一个成功的男人背后都有一个成功的女人”，UIView的无限风光其实离不开CALayer在其背后的支持。但是这种每个View的背后都有一个Layer的设定在OS X上并不总是成立。Apple把support layer的View称作** “layer backed view” ，在OS X上还有一种叫做 "layer hosting view" **。iOS默认的都是layer backed view。其它在此不表。
“既生瑜何生亮？！”
到这里你可能会问，既然有了CALayer为啥还要UIView，这不多余么？！事实上，这种看似多余的设计，其背后的艺术确是非常精妙的，关于这个问题，网上有很多介绍，但是我仍然认为，在设计精髓上，这篇风趣的文章是解释的最深刻的，简单的说，UIView和CALayer既是把Respond和Drawing分离，把Content和Action分离，把机制和策略分离。Layer能够使得iOS更有效的处理绘图，高帧率的动画，UIView能够更方便的处理事件和响应链。它们彼此合作，互相依赖，缺一不可。另外这篇文章在事件响应和修改属性参数的效果上稍微更进一步的解释了两者的区别。
关于它们的更多内容，可以参考Apple文档《Core Animation Programming Guide》
这里再提一个特殊的UIView： UIImageView。UIImageView继承自UIView，但是其有一个特殊的属性UIImage。在上面我们提到过，每一个UIView的Layer都有一个对应的Backing Store作为其存储Content的实际内容，而这些内容其实就是一个CGImage数据（更确切的说，是bitmap数据），以供GPU读取展示。而UIImage其实是CGImage的一个轻量级封装，于是很自然的，在UIImageView中的UIImage对象直接将自己的CGImage图片数据作为UIVIew的Content，提供给CALayer。
2. iOS UI上进行Graphic和Animation绘制的原理
现在我们已经了解了关于Graphic的一些基本对象结构，接下来我们看看Graphic的基本工作原理。
2.1 图像的绘制
* 2.1.1 Core Animation Pipeline *
前文中的Graphic Framework一节已经说到App通过Core Animation调度GPU和CPU，最终绘制图像到屏幕上。那么具体到绘制细节中，都需要经过哪些具体的步骤呢？2014年的WWDC上Apple向我们提供了一些技术细节可以让我们管窥一斑。从App调用Core Animation开始，一直到最终显示，是一个严格遵循时间顺序的管道（Pipeline）过程，叫做Core Animation Pipeline：
可以看到除Display之外几个关键的参与者：App， Render Server, GPU。前两者中Core Animation都有介入，App中Core Animation的作用是做具体绘制前的准备工作，在Render server中Core Animation更多的是负责具体的绘制。GPU主要负责硬件阶段的具体渲染。Render server其实是一个独立的进程，在 iOS 5 以前这个进程叫 SpringBoard，在 iOS 6 之后叫 BackBoard。
图中的每一个竖线代表的是一个VSync信号。一般而言视频控制器都是通过VSync信号来进行显示同步的，每一个VSync信号间隔是固定的，这个时间是16.67ms，也就是1秒钟刷新60帧。在 VSync 信号到来后，系统图形服务会通过 CADisplayLink 等机制通知 App，App 主线程开始在 CPU 中计算显示内容，比如视图的创建、布局计算、图片解码、文本绘制等。随后 CPU 会将计算好的内容提交到 GPU 去，由 GPU 进行变换、合成、渲染。随后 GPU 会把渲染结果提交到帧缓冲区去，等待下一次 VSync 信号到来时显示到屏幕上。
* 2.1.2 Core Animation Commit Transaction *
针对准备阶段的Commit Transaction部分，可以细分为4个步骤：
-
布局Layout：在这个阶段，程序设置 View / Layer 的层级信息，设置 layer 的属性，如 frame，background color 等等。
[UIView layoutSubViews]和[CALayer layoutSublayers]就是在这个阶段调用的。 -
显示Display：在这个阶段程序会创建 layer 的 backing image，无论是通过 setContents 将一个 image 传給 layer，还是通过
drawRect:或drawLayer: inContext:来画出来的。所以drawRect:等函数是在这个阶段被调用的。注意不要混淆这里的Display和最终的显示Display；
关于使用drawRect和使用ImageView
-
使用 -drawRect :
如果你的视图类实现了-drawRect:，他们将像这样工作:- 当你调用
-setNeedsDisplay，UIKit 将会在这个视图的图层上调用-setNeedsDisplay。这为图层设置了一个标识，标记为 dirty，但还显示原来的内容。它实际上没做任何工作，所以多次调用-setNeedsDisplay并不会造成性能损失。 - 下面，当渲染系统准备好，它会调用视图图层的
-display方法.此时，图层会装配它的后备存储。 - 然后建立一个 Core Graphics 上下文(
CGContextRef)，将后备存储对应内存中的数据恢复出来，绘图会进入对应的内存区域，并使用CGContextRef绘制。当你使用 UIKit 的绘制方法，例如:UIRectFill()或者-[UIBezierPath fill]代替你的-drawRect:方法，他们将会使用这个上下文。此时，UIKit 将后备存储的 CGContextRef 推进他的 graphics context stack，也就是说，它会将那个上下文设置为当前的。（UIGraphicsGetCurrent()将会返回那个对应的上下文），这样，UIKit 使用当前上下文将绘图绘入到图层的后备存储。如果你想直接使用 Core Graphics 方法，你可以自己调用UIGraphicsGetCurrent()得到相同的上下文，并且将这个上下文传给 Core Graphics 方法。 - 从现在开始，图层的后备存储将会被不断的渲染到屏幕上。直到下次再次调用视图的
-setNeedsDisplay，将会依次将图层的后备存储更新到视图上。
- 当你调用
-
不使用 -drawRect:
当你用一个 UIImageView 时，事情略有不同，这个视图仍然有一个 CALayer，但是图层却没有申请一个后备存储。取而代之的是使用一个 CGImageRef 作为他的内容，并且渲染服务将会把图片的数据绘制到帧的缓冲区，比如，绘制到显示屏。在这种情况下，将不会继续重新绘制。我们只是简单的将位图数据以图片的形式传给了 UIImageView，然后 UIImageView 传给了 Core Animation，然后轮流传给渲染服务。
-
准备Prepare：在这个阶段，Core Animation 框架准备要渲染的 layer 的各种属性数据，以及要做的动画的参数，准备传递給 render server。同时在这个阶段也会解压要渲染的 image。（除了用 imageNamed：方法从 bundle 加载的 image 会立刻解压之外，其他的比如直接从硬盘读入，或者从网络上下载的 image 不会立刻解压，只有在真正要渲染的时候才会解压）。在这个阶段你可以看到类似
CA::Layer::prepare_commit和Render::prepare_image,Render::copy_image,Render::create_image等等这样的操作； -
提交Commit：在这个阶段，Core Animation 打包 layer 的信息以及需要做的动画的参数，通过 IPC（inter-Process Communication）传递給 render server。这是一个递归操作，根据打包的Layer层级复杂度来决定递归的次数。大量连续递归的
CA::Layer::commit_if_needed调用是这个阶段的显著特征。
* 2.1.3 GPU Rendering *
当App调用Core Animation（甚至是Core Graphic）将所有准备工作完成后，将参数和数据提交到下层OpenGL层，再传输给GPU做真正的渲染处理：
- 块渲染 Tile Based Rendering
块渲染的根本思路是将设备屏幕分割为包含N*N个像素的块状（Tile）区域。每一个Tile可以适配到SoC的cache中。
每一个屏幕上的图像对象，都将被这些Tile再次切割成独立的碎块，然后针对每一个碎块进行三角形顶点着色。
块渲染是目前移动GPU的主流渲染方式，因为这种方式更好地适配了移动设备的耗电和性能的平衡问题。究其原因，是因为GPU在运算时对数据带宽消耗的极高要求：OPENGL的虚拟管线需要大量的显存带宽来支持, 为了减少这个凶残的带宽需求，大多数移动GPU都使用了tiled-based渲染。在最基础的层面，这些GPU将帧缓存（framebuffer），包括深度缓存，多采样缓存等等，从主内存移到了一块超高速的on-chip存储器上，计算芯片就能以远低于常规消耗的电能来读写存储器。但是on-chip的存储器都不可能很大，否则GPU芯片的大小将大的吓人，在有些GPU中小到只能容纳16x16个像素，于是将OPENGL的帧缓存切割成16x16的小块（这就是tile-based渲染的命名由来），然后一次就渲染一块。对于每一块tile: 将有用的几何体提交进去，当渲染完成时，将tile的数据拷贝回主内存。这样，带宽的消耗就只来自于写回主内存了，那是一个较小的消耗，消耗极高的深度/模板测试和颜色混合完全的在计算芯片上就完成了。
有关Tile Based Rendering的更多内容，有兴趣可以简单翻一下这篇译文《Performance Tunning for Tile-Based Architecture》
- 渲染通道（流水线） Render Pass
Core Animation将包装的好的数据提交给OpenGL之后，后续的流程基本上就属于OpenGL ES的范畴了，你在这里可以看到顶点着色器(Vertex Shader)和像素着色器（Pixel Shader）。
顶点着色器定义了在 2D 或者 3D 场景中几何图形是如何处理的。一个顶点指的是 2D 或者 3D 空间中的一个点。顶点着色器设置顶点的位置，并且把位置和纹理坐标这样的参数发送到Pixel Shader。然后 GPU 使用Pixel Shader在对象或者图片的每一个像素上进行计算，最终计算出每个像素的最终颜色。
能够实现Vertex Shader和Pixel Shader的显卡的图形处理流水线被称作为是可编程的，相对而言，在此之前的图形处理流水线被称作为是固定功能（fixed function）。虽然如此，但是实际上可编程的只有流水线的一部分，正如Vertex Shader 和Pixel Shader的字面意思一样，现在可编程的部分只有处理顶点的和处理象素的单元。但是这两个着色器是OpenGL ES 2.0定义的两个缺一不可的单元。
Vertex Shader 和 Pixel Shader在不同的文档里面有不同的叫法，Nvidia在自己的OpenGL扩展中把Vertex Shader叫做Vertex Program、把Pixel Shader叫做Texture Shader，3Dlabs在自己提出一份OpenGL 2.0的提议里面把这两者分别叫做Vertex Shader和Fragment（片段）Shader
《GPU-Accelerated Image Processing》 和 这段回答 或许能给你更多关于GPU Shader的内容。
- 多通道渲染（Render Passes）示例：Masking
在实际绘图过程中，由于多个Layer的存在，最终图像实际上是由多个Render Pass并发绘制后再组合渲染的（Compositing and Blending）。以一个带有蒙板的组合图像为例,实际发生的Render pass有3个，mask layer和content layer各自渲染，最后再做一次Render pass组合出最终图像：
2.2 图层的动画 Animation
到此为止，我们已经基本了解了在iOS上，从App递交一个绘图请求开始一直到图像出现在屏幕上的基本过程，但这都是静态的图片的绘制，那么动画Animation是怎么做到的呢？
Apple的做法很简单直接，对于每一个Animation，前期的准备阶段和单独的图像提交基本相同，但是Render Server在渲染时，将根据Core Animation的动画参数自动计算出动画所需要的每一帧图像，然后一帧一帧的渲染显示，最终呈现的就是动画效果。也就是说App只需要告诉Render Server动画的起始和终止状态，它自动将
中间过程计算出来并替你完成commit的动作。联想到前文中关于Layer Tree的3份不同Copy，你只需要操作起始和终止状态的Modal Layer属性，在Presentation Layer中即完成所有中间过程的计算。
我不知道Core Animation的这套机制和老乔的Pixar动画公司是否有着千丝万缕的关系，但是无论如何你都能在这套机制设计看到传统动画制作的思路。
一个Animation的完整过程如下图：
3. iOS Graphic的性能考量
我们现在已经了解了iOS 2D图形绘制的基本过程了。在这些内容中，你或许已经看到了时间对于图形绘制的重要性，尤其让你注意到的，应该是那个“VSync”信号。
上面一节已经提到的Pipeline过程是序列化同步进行的，在每一个VSync信号开始时，所有的参与者都会并发的执行下一个序列，如果在一个 VSync 时间内（16.67ms）每一个步骤都有条不紊的完整执行，那么整个显示过程就能顺利的执行下去：
但是，如果应为某种原因导致某一步或者多步处理时间过长，CPU 或者 GPU 没有完成内容提交，则那一帧就会被丢弃，等待下一次机会再显示，而这时显示屏会保留之前的内容不变。这就是界面卡顿的原因。对应到上图，就是某个时间条超长而越过了VSync信号的边界，这就是掉帧：
另外，上一节中，我们提到过Animation的3个步骤，对于普通动画而言，只需要一次1-2步的计算，Render Server在后续的第3步中，保证每一帧能够在16ms内提交到GPU就OK了，但是对于Scrolling来说，有一个特殊的地方是，每一次Scroll的动作，都会单独触发上述1-3步的完整过程：也就是说，Scrolling要求每次1-3步都必须在16ms内完成：
对于TableView而言，这就意味着每一个新的行（new row）的处理都至少要在16ms内完成，最坏情况下，当快速滑动的时候，Render需要在1帧（16ms）内更新整个屏幕的内容！这就是为什么关于ScrollView和TableView的滑动性能一直是大家关注的热点。
掉帧引起的卡顿感，或许是手机用户最敏感的体验，iOS用户一直对Android引以为豪的体验感，其实就来自于iOS针对图形图像和系统设计的优化。（关于这一点，其实除了iOS本身图像渲染的设计有关，另一个重要的因素其实是和Runloop的调度机制有关，这点有时间可以再为Runloop单开一篇）不管怎样，作为iOS App开发的你，应当不遗余力的优化你的App的性能，改善用户的体验。
这部分内容，请看下篇 ——《iOS 2D Graphic （2）— Performance 性能优化》。
希望对你有所帮助。
[参考资料]：
- WWDC2012 Session 238 《iOS App Performance: Graphic and Animation》
- [WWDC2014 Session 419《Advanced Graphics and Animation Performance》
- iOS Developer Library:《Drawing and Printing Guide for iOS》
- iOS Developer Library:《Core Animation Programming Guide》
- 《iOS UIView 详解》
- 《iOS 事件处理机制与图像渲染过程》
- 《iOS 视图---动画渲染机制探究》
- 《WWDC心得与延伸:iOS图形性能》
- 《Tile-Based架构下的性能调校》
- 《Getting Pixels onto the Screen》
- StackOverflow: What's the difference between Quartz Core, Core Graphics and Quartz 2D?
2016.7.1 完稿于南京。
