iOS|iOS UI帧率优化经验

序言

开始之前, 简要介绍一下移动客户端的动态化排版方案.为满足UI布局的灵活和后端可控性, 移动端开发了基于Card的动态排版渲染引擎:前后端制定好协议, 客户端解析后端下发的描述信息,构建和拼接不同UI元素。 相较于Native客户端固化布局, 动态化方案由于事先不知道UI属性和确切尺寸,需要动态创建并计算UI元素显示区域。 这对代码性能优化提出了更高的要求. 本文就帧率测试方法和优化经验做下总结.
工具选择
检测帧率,使用CADisplayLink API
检测函数执行耗时情况,使用XCode自带的TimeProfiler工具
检测渲染问题,使用模拟器Debug菜单下自带的离屏及图层颜色混合检测工具
大家平时检测帧率可能常用TimeProfile。该工具虽然功能强大,但不够轻量、准确。应用复杂时,由于这个工具需要跟设备通讯,会频繁读取设备状态,收集代码堆栈信息,产生的数据量非常大.我们测试时几分钟有时产生上GB数据。如果只是获取帧率,建议大家使用轻量的CADisplayLink,只有当需要获取更详尽的信息时,才考虑使用TimeProfile。
如何优化
可以把这个阶段分成两阶段: 定位主线程耗时代码和针对渲染问题优化。前者可通过TimeProfile统计到每个函数的耗时情况。先解决可能阻塞主线程的代码,比如有无读写IO操作(将其放入非主线程执行),有无耗时较为明显的函数,最后再通过模拟器定位离屏渲图层混合的问题,寻找优化方案。
阶段一:下面介绍下我们优化过程中统计出来的一些开销较高的系统API (可能你也遇到过)
1.字符格式化操作 +(instancetype)stringWithFormat:(NSString *)format, …
当代码中调用该接口较少时,你可以略过这个问题。但当主线程中大量的使用该API时,这个函数的耗时会变得明显, 因为这个函数的执行效率并不高。
解决方案:使用C函数,比如asprintf,snprintf等创建char,然后用char构建NSString。
2.图片资源访问 +(UIImage *)imageNamed:(NSString *)name
调用该接口加载图片后,系统会缓存该图片,以加快下次访问。但在系统压力较大的低端机型上,反复调用该接口获取某张固定图片,时间还是会很长。我们用TimeProfile也抓到了该函数取占位图时耗时较长的情况。从原理上看,该接口要考虑不同扩展名、不同机型下最佳适配资源(2x,3x分辨率图片),根据传入的文件名做模糊匹配。所以其效率也不是很高。
【iOS|iOS UI帧率优化经验】解决方案:1.使用分辨率更小的图片,这有助于缩短第一次加载时间。2.如果该图片属于公共访问非常频繁的资源(比如占位图),通过该接口获取到图片内存地址后,用全局指针保存起来。再次访问时可以直接使用保存好的指针,完全不会占用主线程时间。
3.文本绘制区域计算 -(CGRect)boundingRectWithSize:(CGSize)size options:(NSStringDrawingOptions)options context:(NSStringDrawingContext *)context;
- (CGSize)sizeThatFits:(CGSize)size;
当文本控件较多,滑动过程中频繁使用这类接口计算文本显示区域,会占用较多主线程时间。
解决方案:
从UI设计上给定一个固定显示区域,让系统对过长的文本自动截断,从而避免调用显示接口。
2.如果方案1行不通,可以在调用一次后把计算结果缓存起来。用户再次访问时,直接使用已计算好的数值。这个方案需要考虑影响计算结果的因素,比如字体、字号、限定的宽高、行数、行距、截断方式等。如果将这么多变动的因素组合起来查询,效率会比较低。 我们的方法是将这些数据打包成一个对象,相当于计算结果跟原始的属性绑定到同一个指针指向的空间里了,这样使用时不需查询,通过指针就可直接访问。
4.UIView层级调整有关的代码
- (void)insertSubview:(UIView*)view belowSubview:(UIView *)siblingSubview; - (void)insertSubview:(UIView*)view aboveSubview:(UIView *)siblingSubview; - (void)removeFromSuperview; -(void)bringSubviewToFront:(UIView *)view; -(void)sendSubviewToBack:(UIView *)view; …

解决方案:如果你的程序运行过程中有较多调用这类动态插入或者调整View层级的代码,可以在创建view时将层级固定下来,并对临时用不到的view设置为隐藏,再在合适的时机显示出来。
5.NSScan的使用
数字跟字母混合情况下,有很多人会选用这个API做数值转换,用来分离出数值部分,但经测试,该API性能并不好。
解决方案:1.大多简单的数字跟字母混合字符串,直接转换即可。比如要取出字符16px里的16出来,使用intvalue就可以。2.也可使用strtoul(const char *nptr,char **endptr,int base ),比如一个色值数据#6C6C6C,使用该接口配合位运算,能很高效的分离出RGB3个10进制数值来。
阶段二:渲染优化
渲染层面,影响流畅性的因素主要有离屏渲染和图层混合。系统也提供了一些优化开关,默认的优化开关是关闭的,需要根据UI特点,验证后再决定是否开启。下面介绍这方面的知识。
1.关于离屏渲染Off-Screen Rendering vs On-Screen Rendering
Off-Screen Rendering(离屏渲染)需要先创建屏幕外缓冲区做渲染,然后将渲染结果写入存储像素信息的帧缓冲区中。这个过程除了要创建额外的缓存,还涉及两次较为耗时的上下文切换:从当前屏切到屏幕外缓冲区,再切换回当前屏缓冲区,所以如果有大量离屏渲染会影响帧率。
引起离屏渲染的常见原因有:
重写drawRect,并调用Core Graphics接口,会在CPU上执行离屏渲染
UI中有圆角且masksToBounds=YES时,阴影,组透明allowsGroupOpacity=true,光栅化shouldRasterize=true等情况时,会在GPU上进行离屏渲染
我们对常见的情况做了下总结:
a.圆角问题的处理,总结了五种方案
1.通过CALayer的masksToBounds = true组合cornerRadius来实现圆角效果。这种方案虽然会产生离屏渲染,但在圆角图层上覆盖新的图层不会出现圆角被新图层覆盖的问题,较为通用
2.只设置cornerRadius,可以避免离屏渲染,但可能被新加的图层覆盖,导致圆角出不来,应用场景有限
3.通过后台线程自绘,生成图片,方案较为通用,而且可以解决系统圆角的某些显示问题(下面会讲),但绘制函数较为耗时。
4.用图片遮罩来处理圆角:制作一张四周圆角外带颜色中间透明的图片,遮到需要圆角的VIEW上。渲染时只需要进行图层混合,相比离屏渲染性能好的多。但由于各处圆角尺寸不固定,而且要求透明色区域外的颜色跟圆角的superview背景色一致,很难做成通用方案。
  1. 后端提供带圆角的图片,这个方案性能最好,前端无工作量,但比较依赖后端服务能力。
当圆角是一个整圆,并且指定了宽线条外框时(比如头像处理成一个圆形的),系统绘制的圆圈(上文提到的方案1)周边可能会显示出不太明显的杂色点,用自绘(上文提到的方案3)就没有这个问题.我们基础库需要考虑通用性,所以组合了1、3两种方案,优先使用系统实现,有显示杂色情况时使用方案3.
b.阴影:阴影会降低流畅性。解决方案:1.跟UED要一张不带中间内容的阴影外框图贴到最底层。 2.如果layer尺寸是固定的,不需要频繁更改其尺寸,可以使用shadowpath代替shadowoffset。
c.组透明度allowsGroupOpacity:IOS7之后默认是开启的。开启后会使子Layer继承其父layer的透明度。如果不用处理透明,可以关闭它,以提高性能。
d.光栅化shouldRasterize:光栅化即将渲染过的layer临时缓存为位图,以供将来渲染使用。这个选项会增加内存的使用,导致渲染时间变长。但如果VIEW层级较多效果复杂,且内容不变,开启后有利于增强性能。
2.关于Blending图层像素混合
Blending概念:可以想象你手里拿着几张塑料卡片。当前面的塑料片不透明时,我们看到的只是离你最近那张的颜色(系统只绘制最顶层VIEW颜色);但当卡片是半透明时,我们看到的可能是多张卡片的混合色(系统对多个layer内的像素值做叠加合成处理)。所以设计时建议优先考虑用不透明的图层。
3.如果你重写了UIView的drawRect方法,考虑是否打开以下两个开关
a. clearsContextBeforeDrawing
这个值可以决定在drawRect调用时是否清理之前显示的内容。系统默认开启,以保证你在重绘时渲染区是“干净”的,即被刷新为(R:0,G:0,B:0,A:0)黑透明色。有时我们只需更新一小部分区域,此时这个清理步骤并不是必须的,我们可以设置属性=NO来提高绘制性能。
b. drawsAsynchronously异步绘制开关
开启后drawRect,drawInContext虽然仍在主线程调用,但这里的代码不会做任何事情,真正的绘制会异步化到后台线程。由于异步化系统需要做更多的处理,需要测试对比开启关闭的效果后再决定是否开启。
4.CGRect
这是个容易被忽略的优化点。由于我们card化大多UI元素frame是经计算得出的,很多CGRect存储的浮点型转化到屏幕像素点后也不是整数。这个问题可能导致图形边缘模糊,还会导致GPU做更多的抗锯齿运算。应尽量保证其映射为屏幕像素点后还为整数值。
5.检查后台返回的图片
显示区域和后台给的图片尺寸应基本一致。图片分辨率过高不仅解码慢,内存占用高(比如一张3x3图片解码成位图后将会是2x2分辨率图片的2.25倍),渲染时对图像放缩也会耗费性能。
6.其他
如果使用SDWebimage下载图片,并且下载完成后需要对图片重绘(比如圆角化,模糊化后再展示,可以在请求图片的时候,设置SDWebImageAvoidAutoSetImage,防止sd设置一张并不需要展示的图片。
对于重用的cell,设置数据前,判断使用的model与重用前的是否相同,再决定是否需要再执行UI重新布局。
检查下有无过于复杂的VIEW层级,尽量减少或合并一些VIEW层级;如果不需处理触摸事件,可以用layer代替UIView。
针对特定低端机型做优化, 比如降低动画效果,减少阴影, 关闭圆角。
检查有无线程锁操作,避免主线程对锁的访
总结
随着APP代码的复杂,流畅问题逐步演化为多因素叠加一起相互影响的问题.比如剩余内存量,APP线程数量,CPU频率,操作系统版本(即使不降频,这几年IOS每个版本新系统整体性能比旧版本要差)。业内也有不少探索,通过将UI相关的计算并行化,提供线程调度管理及预加载等机制来保证流畅性,欢迎就此多做交流。此文抛砖引玉,以供参考。
更多文章 CocoaPods开源库的搭建
CocoaPods搭建私有库
CocoaPods搭建私有库遇到问题
CocoaPods私有库的升级维护
SKStoreReviewController之程序内评价
App应用程序图标的动态更换
开源框架 MGJRouter_Swift
iOS的MVP设计模式
iOS插件化
iOS FMDB的使用
Swift之ReactiveSwift
OC之ReactiveCocoa
OC之ReactiveCocoa进阶
iOS 性能考虑
iOS|iOS UI帧率优化经验
文章图片

    推荐阅读