iOS 优化界面流畅度的探讨

界面流畅度 大都跟list scrollView有紧密关联

流畅的视觉:就是如丝般顺滑

不流畅视觉:”卡顿”,”抖动”,”迟顿感”

以上两种状态的描述 都是基于主观感受,对于开发者来讲 确实应该有一个临界指标来参考,本身写的东西是否还有优化的空间呢.

 Frames per Second(每秒帧数)   这个指标 能够经过Instruments 工具中的 Core Animation来观察.(xCode -> Tools -> Instrument)

帧数为 0 说明页面处于静止 只要页面一动起来,这个帧数就会有变化 而后再趋于静止.也就是说页面 滚动起来帧数是一个呈”非对称”抛物线的走势.

因此达到峰值的帧数 会呈现连续变化的一个状态 那么这个就是是它的流畅度 ,通常普通的一个list 滚动起来 流畅度 达到60左右 (亲测本身的app的一个普通页面),一个复杂页面53 - 60(亲测).网上有人这么说”45帧每秒，这个帧率已经让人感受到不那么顺滑了，若是低于40帧每秒，普通用户就会察觉明显的不流畅了”.因此你们能够根据这些作参考,或者 是 测试本身的应用 比较几个普通页面 和一个复杂页面也能够有一个相对的参照.就可从理论上分析 是否这个相对比较复杂的页面是否值得优化呢. 

 

能够优化的地方(就是日常拍脑门能想到的地方)

1.CPU:能够经过Instruments里面的工具检测cpu等 查出 究竟是实现的哪一个功能比较增长CPU的负担

2.若是是tableView. 组织数据很繁琐没有用model来映射? 是否cell重用? 绘制高度的方法是否是很冗长,不断的在重复计算? 须要刷新tableView 使用了不恰当地方式?

3.在滚动视图中 圆角的处理

通常状况下咱们会这样作:

.layer.masksToBounds = YES;

.layer.cornerRadius = imageView.size.width * 0.5;

这个方法在滚动视图中会是特别影响性能

缘由:

致使拖慢帧率的缘由其实都是Off-Screen Rendering（离屏渲染).

离屏渲染:是指CPU在当前屏幕缓冲区之外再开辟一个新的缓冲区进行渲染操做.

离屏渲染是一个很好优化性能的方式，可是频繁发生离屏渲染(滚动屏幕 就会很频繁啊)是很是耗时的。若是是一个圆角几乎不会对帧率有太大影响,关键数量要是好多个.经过上面的定义能够看出”离屏渲染”关键不是渲染 而是 离屏.

离屏代价:主要是建立缓冲区和上下文切换的缘由。建立新的缓冲区代价都不算大，付出最大代价的是上下文切换!!!!!(满纸荒唐言 一把辛酸泪  谁被坑过 谁知道)

关于上下文切换:

上下文切换在哪都是一个至关耗费时间的操做,不管是 CPU渲染或是进程切换.其过程:

(1)咱们要保证当前屏幕渲染环境

(2)切换到一个新的绘制环境—>申请绘制资源—>初始化环境—>开始绘制—>绘制结束—>销毁绘制环境

(3)回到主屏幕呈现 或者 再开辟一个新的离屏渲染重复(2)

解决:

那么如何应对这个问题呢？不要在滚动视图使用cornerRadiu 可使用下面的方法

(1)非要做死使用layer.ornerRadius,记得还要添加下面方法

.layer.shouldRasterize = YES;  //这样大部分状况下能够立刻挽救你的帧数在55帧每秒以上。shouldRasterize = YES会使视图渲染内容被缓存起来，下次绘制的时候能够直接显示缓存，固然要在视图内容不改变的状况下。(具体解释  layer的头文件,进入查看这个属性的英文说明  不觉明厉)

.layer.rasterizationScale = [UIScreen mainScreen].scale;//须要适当设置"抗锯齿"  不然在retina的设备上这些视图会出现锯齿状。(具体了解参看 layer 属性)

(2)若是能够用切图遮罩代替的话 会效率很高

(3)预先缓存住 圆角的图片(预处理圆角图片在后台处理，处理完毕后缓存起来，再在主线程显示),来避免了离屏渲染

 

参考资源

http://www.zhihu.com/question/20382396  (知乎)

http://www.cnblogs.com/ioriwellings/p/5011993.html (更具体的解决方案)