离屏渲染探究
本文地址: http://coderperson.com/2015/11/28/iOS-offScreen/
欢迎转载，请注明出处，谢谢。
概念学习
OpenGL中，GPU屏幕渲染有以下两种方式：
- On-Screen Rendering
意为当前屏幕渲染，指的是GPU的渲染操作是在当前用于显示的屏幕缓冲区中进行。
- Off-Screen Rendering
意为离屏渲染，指的是GPU在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作。
机制
GPU渲染机制：
CPU 计算好显示内容提交到 GPU，GPU
渲染完成后将渲染结果放入帧缓冲区，随后视频控制器会按照 VSync
信号逐行读取帧缓冲区的数据，经过可能的数模转换传递给显示器显示。
原因
当使用圆角，阴影，遮罩的时候，图层属性的混合体被指定为在未预合成之前不能直接在屏幕中绘制，所以就需要屏幕外渲染被唤起。
屏幕外渲染并不意味着软件绘制，但是它意味着图层必须在被显示之前在一个屏幕外上下文中被渲染（不论CPU还是GPU）。
性能优劣
相比于当前屏幕渲染，离屏渲染的代价是很高的，主要体现在两个方面：
创建新缓冲区
要想进行离屏渲染，首先要创建一个新的缓冲区。上下文切换
离屏渲染的整个过程，需要多次切换上下文环境：先是从当前屏幕（On-Screen）切换到离屏（Off-Screen）；等到离屏渲染结束以后，将离屏缓冲区的渲染结果显示到屏幕上又需要将上下文环境从离屏切换到当前屏幕。而上下文环境的切换是要付出很大代价的。
注意：触发离屏渲染后，上面两步会发生在每一帧，如果在界面的滚动过程中有大量的离屏渲染发生时会严重影响帧率。
另一种特殊的“离屏渲染”
按照之前的说法，如果将不在GPU的当前屏幕缓冲区中进行的渲染都称为离屏渲染，那么就还有另一种特殊的“离屏渲染”方式：CPU渲染。
如果我们重写了drawRect方法，并且使用任何Core Graphics的技术进行了绘制操作，就涉及到了CPU渲染。整个渲染过程由CPU在App内同步地完成，渲染得到的bitmap最后再交由GPU用于显示。
离屏渲染的触发机制
- shouldRasterize（光栅化）
- masks（遮罩）
- shadows（阴影）
- edge antialiasing（抗锯齿）
- group opacity（不透明）
- 复杂形状设置圆角等
- 渐变
其中shouldRasterize（光栅化）是比较特别的一种：
光栅化概念：将图转化为一个个栅格组成的图象。
光栅化特点：每个元素对应帧缓冲区中的一像素。
shouldRasterize = YES在其他属性触发离屏渲染的同时，会将光栅化后的内容缓存起来，如果对应的layer及其sublayers没有发生改变，在下一帧的时候可以直接复用。shouldRasterize = YES，这将隐式的创建一个位图，各种阴影遮罩等效果也会保存到位图中并缓存起来，从而减少渲染的频度（不是矢量图）。
相当于光栅化是把GPU的操作转到CPU上了，生成位图缓存，直接读取复用。
当你使用光栅化时，你可以开启“Color Hits Green and Misses Red”来检查该场景下光栅化操作是否是一个好的选择。绿色表示缓存被复用，红色表示缓存在被重复创建。
如果光栅化的层变红得太频繁那么光栅化对优化可能没有多少用处。位图缓存从内存中删除又重新创建得太过频繁，红色表明缓存重建得太迟。可以针对性的选择某个较小而较深的层结构进行光栅化，来尝试减少渲染时间。
注意：
对于经常变动的内容,这个时候不要开启,否则会造成性能的浪费
例如我们日程经常打交道的TableViewCell,因为TableViewCell的重绘是很频繁的（因为Cell的复用）,如果Cell的内容不断变化,则Cell需要不断重绘,如果此时设置了cell.layer可光栅化。则会造成大量的离屏渲染,降低图形性能。
官方优化
iOS 9.0 之前UIimageView跟UIButton设置圆角都会触发离屏渲染
iOS 9.0 之后UIButton设置圆角会触发离屏渲染，而UIImageView里png图片设置圆角不会触发离屏渲染了，如果设置其他阴影效果之类的还是会触发离屏渲染的。
这可能是苹果也意识到离屏渲染会产生性能问题，所以能不产生离屏渲染的地方苹果也就不用离屏渲染了。
其它
UIImage加载图片方式一般有两种:
A：imagedNamed初始化
B：imageWithContentsOfFile初始化
二者不同之处在于,imageNamed默认加载图片成功后会内存中缓存图片,这个方法用一个指定的名字在系统缓存中查找并返回一个图片对象.如果缓存中没有找到相应的图片对象,则从指定地方加载图片然后缓存对象，并返回这个图片对象.
而imageWithContentsOfFile则仅只加载图片,不缓存.
大量使用imageNamed方式会在不需要缓存的地方额外增加开销CPU的时间来做这件事.当应用程序需要加载一张比较大的图片并且使用一次性，那么其实是没有必要去缓存这个图片的，用imageWithContentsOfFile是最为经济的方式,这样不会因为UIImage元素较多情况下，CPU会被逐个分散在不必要缓存上浪费过多时间.
使用场景需要编程时，应该根据实际应用场景加以区分，UIimage虽小，但使用元素较多问题会有所凸显.
如何提高性能
- 当我们需要圆角效果时，可以使用一张中间透明图片蒙上去
- 使用ShadowPath指定layer阴影效果路径
- 使用异步进行layer渲染（Facebook开源的异步绘制框架AsyncDisplayKit）
- 设置layer的opaque值为YES，减少复杂图层合成
- 尽量使用不包含透明（alpha）通道的图片资源
- 尽量设置layer的大小值为整形值
- 直接让美工把图片切成圆角进行显示，这是效率最高的一种方案
- 很多情况下用户上传图片进行显示，可以让服务端处理圆角
- 使用代码手动生成圆角Image设置到要显示的View上，利用UIBezierPath（CoreGraphics框架）画出来圆角图片
总结
当项目中需要离屏渲染的地方不多时，性能的影响并不是很大，基本也能保持在60fps左右，但
是一旦超过一定数目的圆角，滑动起来就会有明显的卡顿现象。所以，没必要为了不影响体验的情况下强行进行优化，这样做效果并不是很明显。只有当需要优化的时候采取一定的优化方案，才能得到最大的收益。
我们都是热爱移动开发的程序猿，加入我们，共同提高：
