我要评论界面渲染
uiview继承自uiresponder，可以处理系统传递过来的事件，如：uiapplication、uiviewcontroller、uiview，以及所有从uiview派生出来的uikit类。每个uiview内部都有一个calayer提供内容的绘制和显示，并且作为内部rootlayer的代理视图。
下图为calayer的结构图：
runloop有一个60fps的回调，即每16.7ms绘制一次屏幕，所以view的绘制必须在这个时间内完成，view内容的绘制是cpu的工作，然后把绘制的内容交给gpu渲染，包括多个view的拼接（compositing）、纹理的渲染(texture)等等，最后显示在屏幕上。但是，如果无法是16.7ms内完成绘制，就会出现丢帧的问题，一般情况下，如果帧率保证在30fps以上，界面卡顿效果不明显，那么就需要在33.4ms内完成view的绘制，而低于这个帧率，就会产生卡顿的效果，影响体验。
渲染的过程
uiview的layer层有一个content，指向一块缓存，即backing store
uiview绘制时，会调用drawrect方法，通过context将数据写入backing store
在backing store写完后，通过render server交给gpu去渲染，将backing store中的bitmap数据显示在屏幕上
渲染的过程
ios离屏渲染
on-screen rendering:当前屏幕渲染，指的是 gpu 的渲染操作是在当前用于显示的屏幕缓冲区中进行
off-screen rendering:离屏渲染，分为 cpu 离屏渲染和 gpu 离屏渲染两种形式。gpu 离屏渲染指的是 gpu 在当前屏幕缓冲区外新开辟一个缓冲区进行渲染操作
为什么会使用离屏渲染
当使用圆角，阴影，遮罩的时候，图层属性的混合体被指定为在未预合成之前不能直接在屏幕中绘制，所以就需要屏幕外渲染被唤起。
gpu 离屏渲染的代价是很大的
离屏渲染之所以会特别消耗性能，是因为要创建一个屏幕外的缓冲区，然后从当屏缓冲区切换到屏幕外的缓冲区，然后再完成渲染；其中，创建缓冲区和切换上下文最消耗性能，而绘制其实不是性能损耗的主要原因。
上下文之间的切换这个过程的消耗会比较昂贵，涉及到 opengl的 pipeline 跟 barrier，而且 offscreen-render 在每一帧都会涉及到，因此处理不当肯定会对性能产生一定的影响。另外由于离屏渲染会增加 gpu 的工作量，可能会导致 cpu+gpu 的处理时间超出 16.7ms，导致掉帧卡顿。
离屏渲染的场景和优化
圆角优化
方法一：
一般情况下我们会用这个方法去设置圆角：
iv.layer.cornerradius = 30; iv.layer.maskstobounds = yes;
使用cornerradius进行切圆角，在ios9之前会产生离屏渲染，比较消耗性能，而之后系统做了优化，则不会产生离屏渲染，但是操作最简单
方法二：
利用mask设置圆角，利用的是uibezierpath和cashapelayer来完成
cashapelayer *mask = [[cashapelayer alloc] init]; mask1.opacity = 0.3; mask1.path = [uibezierpath bezierpathwithovalinrect:iv.bounds].cgpath; iv.layer.mask = mask;
方法三：
利用coregraphics画一个圆形上下文，然后把图片绘制上去，得到一个圆形的图片
- (uiimage *)drawcircleimage:(uiimage*)image
{
cgfloat side = min(image.size.width, image.size.height);
uigraphicsbeginimagecontextwithoptions(cgsizemake(side, side), false, [uiscreen mainscreen].scale);
cgcontextaddpath(uigraphicsgetcurrentcontext(), [uibezierpath bezierpathwithovalinrect:cgrectmake(0, 0, side, side)].cgpath);
cgcontextclip(uigraphicsgetcurrentcontext());
cgfloat marginx = -(image.size.width - side) * 0.5;
cgfloat marginy = -(image.size.height - side) * 0.5;
[image drawinrect:cgrectmake(marginx, marginy, image.size.width, image.size.height)];
cgcontextdrawpath(uigraphicsgetcurrentcontext(), kcgpathfillstroke);
uiimage *newimage = uigraphicsgetimagefromcurrentimagecontext();
uigraphicsendimagecontext();
return newimage;
}三种方法里面，方法三是性能最好的。
当然了，直接让美工画一个圆角的图效率是最高的。
shadow优化
我们可以通过设置shadowpath来优化性能，能大幅提高性能
imageview.layer.shadowcolor=[uicolorgraycolor].cgcolor; imageview.layer.shadowopacity=1.0; imageview.layer.shadowradius=2.0; uibezierpath *path=[uibezierpathbezierpathwithrect:imageview.frame]; imageview.layer.shadowpath=path.cgpath;
组不透明
开启calayer的 allowsgroupopacity 属性后，子 layer 在视觉上的透明度的上限是其父 layer 的 opacity (对应uiview的 alpha )，并且从 ios 7 以后默认全局开启了这个功能，这样做是为了让子视图与其容器视图保持同样的透明度。
所以，可以关闭 allowsgroupopacity 属性，按产品需求自己控制layer透明度。
关闭抗锯齿
allowsedgeantialiasing属性为yes(默认为no)
离屏渲染的检测
instruments的core animation工具中有几个和离屏渲染相关的检查选项：
color offscreen-rendered yellow
开启后会把那些需要离屏渲染的图层高亮成黄色，这就意味着黄色图层可能存在性能问题。
color hits green and misses red
如果shouldrasterize被设置成yes，对应的渲染结果会被缓存，如果图层是绿色，就表示这些缓存被复用；如果是红色就表示缓存会被重复创建，这就表示该处存在性能问题了。
ios版本上的优化
ios 9.0 之前uiimageview跟uibutton设置圆角都会触发离屏渲染
ios 9.0 之后uibutton设置圆角会触发离屏渲染，而uiimageview里png图片设置圆角不会触发离屏渲染了，如果设置其他阴影效果之类的还是会触发离屏渲染的。
善用离屏渲染
尽管离屏渲染开销很大，但是当我们无法避免它的时候，可以想办法把性能影响降到最低。优化思路也很简单：既然已经花了不少精力把图片裁出了圆角，如果我能把结果缓存下来，那么下一帧渲染就可以复用这个成果，不需要再重新画一遍了。
calayer为这个方案提供了对应的解法：shouldrasterize。一旦被设置为true，render server就会强制把layer的渲染结果（包括其子layer，以及圆角、阴影、group opacity等等）保存在一块内存中，这样一来在下一帧仍然可以被复用，而不会再次触发离屏渲染。有几个需要注意的点：
shouldrasterize的主旨在于降低性能损失，但总是至少会触发一次离屏渲染。如果你的layer本来并不复杂，也没有圆角阴影等等，打开这个开关反而会增加一次不必要的离屏渲染
离屏渲染缓存有空间上限，最多不超过屏幕总像素的2.5倍大小
一旦缓存超过100ms没有被使用，会自动被丢弃
layer的内容（包括子layer）必须是静态的，因为一旦发生变化（如resize，动画），之前辛苦处理得到的缓存就失效了。如果这件事频繁发生，我们就又回到了“每一帧都需要离屏渲染”的情景，而这正是开发者需要极力避免的。针对这种情况，xcode提供了“color hits green and misses red”的选项，帮助我们查看缓存的使用是否符合预期
其实除了解决多次离屏渲染的开销，shouldrasterize在另一个场景中也可以使用：如果layer的子结构非常复杂，渲染一次所需时间较长，同样可以打开这个开关，把layer绘制到一块缓存，然后在接下来复用这个结果，这样就不需要每次都重新绘制整个layer树了
什么时候需要cpu渲染
绝大多数情况下，得益于gpu针对图形处理的优化，我们都会倾向于让gpu来完成渲染任务，而给cpu留出足够时间处理各种各样复杂的app逻辑。为此core animation做了大量的工作，尽量把渲染工作转换成适合gpu处理的形式（也就是所谓的硬件加速，如layer composition，设置backgroundcolor等等）。
但是对于一些情况，如文字（coretext使用coregraphics渲染）和图片（imageio）渲染，由于gpu并不擅长做这些工作，不得不先由cpu来处理好以后，再把结果作为texture传给gpu。除此以外，有时候也会遇到gpu实在忙不过来的情况，而cpu相对空闲（gpu瓶颈），这时可以让cpu分担一部分工作，提高整体效率。
一个典型的例子是，我们经常会使用coregraphics给图片加上圆角（将图片中圆角以外的部分渲染成透明）。整个过程全部是由cpu完成的。这样一来既然我们已经得到了想要的效果，就不需要再另外给图片容器设置cornerradius。另一个好处是，我们可以灵活地控制裁剪和缓存的时机，巧妙避开cpu和gpu最繁忙的时段，达到平滑性能波动的目的。
但要注意的是:
渲染不是cpu的强项，调用coregraphics会消耗其相当一部分计算时间，并且我们也不愿意因此阻塞用户操作，因此一般来说cpu渲染都在后台线程完成（这也是asyncdisplaykit的主要思想），然后再回到主线程上，把渲染结果传回coreanimation。这样一来，多线程间数据同步会增加一定的复杂度
同样因为cpu渲染速度不够快，因此只适合渲染静态的元素，如文字、图片（想象一下没有硬件加速的视频解码，性能惨不忍睹）
作为渲染结果的bitmap数据量较大（形式上一般为解码后的uiimage），消耗内存较多，所以应该在使用完及时释放，并在需要的时候重新生成，否则很容易导致oom
如果你选择使用cpu来做渲染，那么就没有理由再触发gpu的离屏渲染了，否则会同时存在两块内容相同的内存，而且cpu和gpu都会比较辛苦。
以上就是ios离屏渲染过程示例解析的详细内容，更多关于ios离屏渲染的资料请关注代码网其它相关文章！
发表评论