• 0

  • 486

离屏渲染

1星期前

离屏渲染和正常渲染

下面的流程图可以很好的描述离屏渲染和正常渲染的流程区别 离屏渲染比正常渲染多了一个离屏缓冲区环节。

正常渲染

App内的数据经过CPU计算以及GPU的渲染后,将结果存储到帧缓冲区。然后视频控制器从帧缓冲区取出来显示到屏幕上。

  • 在GPU渲染到帧缓冲区的过程中,遵循的"画家算法",对于每一层layer,由远到近(由下往上)的按次序输出到frame buffer。后一层覆盖前一层,就能得到最终的显示结果。

离屏渲染

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

  • 离屏缓冲区的空间并不是无限大的, 它是存在上限的,最大只能是屏幕的2.5倍。

CPU”离屏渲染“

大家知道,如果我们在UIView中实现了drawRect方法,就算它的函数体内部实际没有代码,系统也会为这个view申请一块内存区域,等待CoreGraphics可能的绘画操作。

对于类似这种“新开一块CGContext来画图“的操作,有很多文章和视频也称之为“离屏渲染”(因为像素数据是暂时存入了CGContext,而不是直接到了frame buffer)。进一步来说,其实所有CPU进行的光栅化操作(如文字渲染、图片解码),都无法直接绘制到由GPU掌管的frame buffer,只能暂时先放在另一块内存之中,说起来都属于“离屏渲染”。

自然我们会认为,因为CPU不擅长做这件事,所以我们需要尽量避免它,就误以为这就是需要避免离屏渲染的原因。但是根据苹果工程师的说法,CPU渲染并非真正意义上的离屏渲染。另一个证据是,如果你的view实现了drawRect,此时打开Xcode调试的“Color offscreen rendered yellow”开关,你会发现这片区域不会被标记为黄色,说明Xcode并不认为这属于离屏渲染。

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

常见离屏渲染场景分析

cornerRadius+clipsToBounds。

如果要绘制一个带有圆角并剪切圆角以外内容的容器,就会有可能触发离屏渲染,也有可能不会触发离屏渲染。
下面的代码不会触发离屏渲染:

UIButton *btn = [UIButton buttonWithType:UIButtonTypeCustom];
btn.frame = CGRectMake(100, 180, 100, 100);
btn.layer.cornerRadius = 50;
btn.backgroundColor = [UIColor blueColor];
[self.view addSubview:btn];
btn.clipsToBounds = YES;
复制代码

但是如果在上面代码的基础上给btn设置图片或者设置title就会导致触发离屏渲染。 经过Xcode的Debug View Hierarchy视图层次调试发现,给btn设置title后,发现视图层次中在btn上面添加了一个Label子视图用来承载title。同样给btn设置了图片后,给btn添加了一个ImageView来承载image图片。这样我们不难猜测是因为设置了title或者image后,btn已经不止一层layer,所以设置圆角后,无法通过一次遍历就能完成圆角的处理,因此需要使用到离屏缓冲区。 依次推断,在上面代码的基础上给btn添加一个子视图,同样也会引起离屏渲染。

shadow

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

group opacity

如下图所示,一个UIView上添加UILabel。view和label的背景颜色都是白色,view的Alpha为0.5,label的alpha为1.0。左边是View的allowsGroupOpacity=true,右边的为false。发现左边开启了组透明度的触发了离屏渲染,右边未触发离屏渲染。

同样的两个view,左边打开group opacity(默认行为)的被标记为Offscreen rendering 原理:alpha并不是分别应用在每一层之上,而是只有到整个layer树画完之后,再统一加上alpha,最后和底下其他layer的像素进行组合。显然也无法通过一次遍历就得到最终结果。

mask

我们知道mask是应用在layer和其所有子layer的组合之上的,而且可能带有透明度,那么其实和group opacity的原理类似,不得不在离屏渲染中完成。

光栅化

当我们开启光栅化时,会将layer渲染成位图保存在离屏渲染缓存中,这样在下次使用时,就可以直接复用,提高效率。 针对光栅化的使用,有以下几个建议:

  • 如果layer不能被复用,则没有必要开启光栅化;
  • 如果layer不是静态,需要被频繁修改(例如动画过程中),此时开启光栅化反而影响效率;
  • 离屏渲染缓存内容有时间限制,如果100ms内没有被使用,那么就会丢弃,无法进行复用;
  • 离屏渲染的缓存空间有限,是屏幕的2.5倍,超过2.5倍屏幕像素大小的话也会失效,无法实现复用。

UIBlurEffect

同样无法通过一次遍历完成

GPU离屏渲染的性能影响

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

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

那为什么我们明知有性能问题时,还是要使用离屏渲染呢?

  • 可以处理一些特殊的效果,这种效果并不能一次就完成,需要使用离屏缓冲区来保存中间状态,不得不使用离屏渲染,例如经常使用的圆角、阴影、高斯模糊、光栅化等。
  • 可以提升渲染的效率,如果一个效果是多次实现的,可以提前渲染,保存到离屏缓冲区,以达到复用的目的。这种情况是需要开发者手动触发的。

如果避免离屏渲染

  • 直接更换资源,让UI提供带圆角的图片;
  • 【UIBezierPath】使用贝塞尔曲线绘制闭合圆角的矩形,在上下文中设置只有内部可见,再将不带圆角的 layer 渲染成图片,添加到贝塞尔矩形中。这种方法效率更高,但是 layer 的布局一旦改变,贝塞尔曲线都需要手动地重新绘制,所以需要对 frame、color 等进行手动地监听并重绘;
  • AsyncDisplayKit(Texture)作为主要渲染框架,对于文字和图片的异步渲染操作交由框架来处理;
  • 对于图片的圆角,统一采用“precomposite”的策略,也就是不经由容器来做剪切,而是预先使用CoreGraphics为图片裁剪圆角;
  • 对于所有的阴影,使用shadowPath来规避离屏渲染;
  • 对于特殊形状的view,使用layer mask并打开shouldRasterize来对渲染结果进行缓。

参考文档

免责声明:文章版权归原作者所有,其内容与观点不代表Unitimes立场,亦不构成任何投资意见或建议。

ios

486

相关文章推荐

未登录头像

暂无评论