探究iOS离屏渲染原理

一、什么是离屏渲染？

在上一篇中对图像是如何显示到屏幕上有了详细的解读 传送门，这里在简单回顾下：

显示原理

主要有以下三步：

• CPU计算需要显示的内容，然后通过数据总线传给GPU
• GPU拿到数据之后开始渲染数据并保存在帧缓存区中
• 随后视频控制器会按照VSync信号逐行读取帧缓冲区的数据，经过可能的数模转换传递给显示器显示。

iOS 高级图形和渲染架构：

在WWDC的Advanced Graphics and Animations for iOS Apps中有一个非常重要的图：

image.png

我们可以看到，在Application这一层中主要是CPU在操作，而到了Render Server这一层，CoreAnimation会将具体操作转换成发送给GPU的draw calls（以前是OpenGL ES，现在慢慢转到了Metal），显然CPU和GPU双方同处于一个流水线中，协作完成整个渲染工作。

屏幕渲染的两种方式：

• On-Screen Rendering: 即当前屏幕渲染，指的是GPU的渲染操作是在当前用于显示的屏幕缓冲区中进行。当前屏幕渲染显示都是直接从帧缓存区中读取数据然后直接显示。

• Off-Screen Rendering 意为离屏渲染，指的是GPU在当前屏幕缓冲区以外新开辟一个缓冲区(离屏缓存区)进行渲染操作。等所有数据都在离屏渲染区完成渲染后才会提交到帧缓存区，然后再被显示。
  

  image.png

CPU渲染:

如果我们重写了drawRect方法，并且使用任何Core Graphics的技术进行了绘制操作，就涉及到了CPU渲染。整个渲染过程由CPU在App内 同步地完成，渲染得到的bitmap最后再交由GPU用于显示。

CoreGraphic通常是线程安全的，所以可以进行异步绘制，显示的时候再放回主线程，一个简单的异步绘制过程大致如下：

-(void)display { 
      dispatch_async(backgroundQueue, ^{ 
            CGContextRef ctx = CGBitmapContextCreate(...); // draw in context...         
            CGImageRef img = CGBitmapContextCreateImage(ctx);
            CFRelease(ctx); 
            dispatch_async(mainQueue, ^{ 
                  layer.contents = img; 
            }); 
       }); 
}

但是根据苹果工程师的说法，CPU渲染并非真正意义上的离屏渲染。如果你的view实现drawRect，此时打开Xcode调试的Color offscreen rendered yellow开关，你会发现这片区域不会被标记为黄色，说明Xcode并不认为这属于离屏渲染。

其实通过CPU渲染就是俗称的软件渲染，而真正的离屏渲染发生在GPU。

GPU离屏渲染

在上面的渲染流水线示意图中我们可以看到，主要的渲染操作都是由CoreAnimation的Render Server模块，通过调用显卡驱动所提供的OpenGL/Metal接口来执行的。通常对于每一层layer，Render Server会遵循“画家算法”，按次序输出到frame buffer，后一层覆盖前一层，就能得到最终的显示结果（值得一提的是，与一般桌面架构不同，在iOS中，设备主存和GPU的显存共享物理内存，这样可以省去一些数据传输开销）。

画家算法

然而有些场景并没有那么简单。作为“画家”的GPU虽然可以一层一层往画布上进行输出，但是无法在某一层渲染完成之后，再回过头来擦除/改变其中的某个部分——因为在这一层之前的若干层layer像素数据，已经在渲染中被永久覆盖了。这就意味着，对于每一层layer，要么能找到一种通过单次遍历就能完成渲染的算法，要么就不得不另开一块内存，借助这个临时中转区域来完成一些更复杂的、多次的修改/剪裁操作。

如果要绘制一个带有圆角并剪切圆角以外内容的容器，就会触发离屏渲染。其流程如下：

• 开辟一块独立于frame buffer的空白内存，
• 把容器以及其所有子layer依次画好
• 把四个角“剪”成圆形
• 把结果画到frame buffer

二、触发离屏渲染的常见场景

1.需要进行裁剪的 layer

使用圆角时候搭配使用layer.masksToBounds / view.clipsToBounds：
下图为CALayer的结构图：

image

如果你只是使用layer.cornerRadius:

layer.cornerRadius = 4;

只会设置backguroundColor和border的圆角，不会设置content的圆角，除非同时设置layer.masksToBounds或者view.clipsToBounds：

//二者效果相同，使用任意一个即可
layer.masksToBounds = YES;
view.clipsToBounds = YES;

这个时候才会触发离屏渲染，所以并不是多个层级就一定会触发离屏渲染。

2.设置了group opacity（组透明度）

开启组透明度，并且透明度不为 1 的layer(layer.allowsGroupOpacity/ layer.opacity)；
其实从名字就可以猜到，alpha并不是分别应用在每一层之上，而是只有到整个layer树画完之后，再统一加上alpha，最后和底下其他layer的像素进行组合。显然也无法通过一次遍历就得到最终结果。

3.使用了mask的layer（layer.mask）；

和group opacity的原理类似，在使用 mask的时候，会分别绘制mask的内容和layer的内容并放入离屏缓存区，然后将二者混合给帧缓存区，然后再进行显示。
WWDC中苹果的解释，mask需要遍历至少三次。

mask.png

4.添加了投影的layer (layer.shadow)；

其原因在于，虽然layer本身是一块矩形区域，但是阴影默认是作用在其中”非透明区域“的，而且需要显示在所有layer内容的下方，因此根据画家算法必须被渲染在先。但矛盾在于此时阴影的本体（layer和其子layer）都还没有被组合到一起，怎么可能在第一步就画出只有完成最后一步之后才能知道的形状呢？这样一来又只能另外申请一块内存，把本体内容都先画好，再根据渲染结果的形状，添加阴影到frame buffer，最后把内容画上去（这只是我的猜测，实际情况可能更复杂）。不过如果我们能够预先告诉CoreAnimation（通过shadowPath属性）阴影的几何形状，那么阴影当然可以先被独立渲染出来，不需要依赖layer本体，也就不再需要离屏渲染了。

image.png

5. UIBlurEffect

同样无法通过一次遍历完成，其原理在WWDC中提到：

UIBlurEffect.png

6.采用了光栅化的layer (layer.shouldRasterize)：

在苹果官方文档中对layer.shouldRasterize有如下解释：

When the value of this property is YES, the layer is rendered as a bitmap in its local coordinate space and then composited to the destination with any other content.

意思简单理解就是说，当开启这个属性后， 这个layer会渲染成位图存起来，需要等所有的要显示的内容全部渲染完毕后，再混合才能够显示到屏幕上。那layer的位图和其它渲染完成的内容放在哪里呢？只能放在离屏缓存区中了，所以光栅化也会触发离屏渲染。

layer.shouldRasterize使用建议如下：

• 如果layer不能被复用，则没有必要打开光栅化；
• 如果layer不是静态的，需要被频繁修改，比如处于动画之中。这样的情况下开启光栅化反而影响效率。在比如：我们日程经常打交道的TableViewCell,因为TableViewCell的重绘是很频繁的（因为Cell的复用）,如果Cell的内容不断变化,则Cell需要不断重绘,如果此时设置了cell.layer可光栅化。则会造成大量的离屏渲染,降低图形性能。
• 离屏渲染缓存的内容是有时间限制的，缓存的内容100ms内如果没有使用，那么它就会被丢弃，无法进行复用了；
• 离屏渲染的缓存空间有限，超过屏幕像素大小2.5倍的话，也会失效，且无法进行复用了。

7.绘制了文字的layer (UILabel, CATextLayer, Core Text 等)

三、GPU离屏渲染的性能影响

相比于当前屏幕渲染，离屏渲染的代价是很高的，主要体现在两个方面：

• 创建新缓冲区：要想进行离屏渲染，首先要创建一个新的缓冲区。
• 上下文切换：离屏渲染的整个过程，需要多次切换上下文环境：先是从当前屏幕（On-Screen）切换到离屏（Off-Screen）；等到离屏渲染结束以后，将离屏缓冲区的渲染结果显示到屏幕上有需要将上下文环境从离屏切换到当前屏幕。而上下文环境的切换是要付出很大代价的。

GPU的操作是高度流水线化的。本来所有计算工作都在有条不紊地正在向frame buffer输出，此时突然收到指令，需要输出到另一块内存，那么流水线中正在进行的一切都不得不被丢弃，切换到只能服务于我们当前的“切圆角”操作。等到完成以后再次清空，再回到向frame buffer输出的正常流程。

在tableView或者collectionView中，滚动的每一帧变化都会触发每个cell的重新绘制，因此一旦存在离屏渲染，上面提到的上下文切换就会每秒发生60次，并且很可能每一帧有几十张的图片要求这么做，对于GPU的性能冲击可想而知（GPU非常擅长大规模并行计算，但是我想频繁的上下文切换显然不在其设计考量之中）

四、善用离屏渲染：

尽管离屏渲染开销很大，但是部分场景仍然需要使用。当我们无法避免它的时候，可以想办法把性能影响降到最低。

针对部分常见场景，可以使用以下方式尝试解决：

• 对于图片的圆角，使用CoreGraphics为图片裁剪圆角，而不是由当前的容器去执行裁剪；
• 对于视频的圆角，可以使用四个白色弧形的layer后者UI切图盖住四个角，从视觉上制造圆角的效果；
• 对于View的圆形边框，如果没有BackgroundColor，可以放心使用CornerRadius来做
• 对于所有的阴影，使用shadowPath来规避离屏渲染
• 对于特殊形状的View，使用layer mask并打开shouldRasterize来对渲染结果进行缓存
• 对于模糊效果，不采用系统提供的UIVisualEffect，而是另外实现模糊效果（CIGaussianBlur）