iOS滑动优化

iOS优化（三）没错我还是滑动优化2017-07-05 11:58iOS　　近期把滑动优化的一些经验整理了一下，在公司做了一次技术分享，和我之前的文章有一小部分重叠。现摘要如下，希望大家不吝赐教，共同讨论进步。

一。滑动优化的玄学

为什么说是玄学呢，因为大部分情况下的APP，用不到这些优化的点，过早的优化是恶魔，当真正出现性能问题的时候，再考虑这些方面的优化。

1.多个透明元素重叠显示的性能问题。

解决方案：合并成一张图显示

原理：CPU方面，减少了UIKit的创建消耗，GPU方面，避免了合成渲染产生的消耗。

AsyncDisplayKit（现在叫Texture），针对多个透明元素的重叠，预合并无点击响应，不改变动画的图层。

Texture的保持流畅的原理：UIKit不是线程安全的，所以必须在主线程改动。Texture利用中间变量存储改动，保证线程安全，在合适的机会将并发操作同步到主线程。

暂时不用Texture的原因：需要用Texture Node Container替换UIKit元素，成本较大。

2.静态cell、多图待加载的优化

解决方案：合并成一张图显示；

原理：提升I/O速度，一个大文件的读取速度，通常比多个小文件要快。

3.展示适合界面尺寸图片，不进行拉伸缩放。

解决方案：从服务器拉取合适尺寸的图片（例如七牛的服务就带裁剪/压缩参数）；

原理：过大图片对内存消耗巨大（图片占用内存 = 图像高×图像宽×像素位数）；不符合UIImageView尺寸的图片，进行重新缩减/放大尺寸的消耗是非常巨大的。

4.imageNamed和imageWithContentsOfFile

这个知道的人比较多，因为缓存图片的消耗通常是肉眼可见的多。

常用的元素例如icon之类的，采用imageNamed：，系统会有缓存。

如果是较大或者不常用的图片资源，采用imageWithContentsOfFile：。

5.减少autolayout的使用

解决方案：页面元素多的时候，减少autolayout布局，采用frame。

原理：元素多时，autolayout的消耗非常惊人（http://pilky.me/36/） ，之前看过搜狗的iOS分享，搜狗输入法键盘弹出狂卡即是此原因；

6.获取文件大小

解决方案：不要使用NSFileManager，用C的stat来获取文件信息。

实例：获取一个目录下所有文件大小，进行多次递归计算，stat几乎瞬间完成，NSFileManager耗时较长。

7.NSDateFormatter产生较大消耗

解决方案：。缓存NSDateFormatter结果，不多次创建，及时释放。

做过类似日历的同学应该都懂��

8.图片解码：

解决方案：CALayer 被提交到 GPU 前，CGImage 中的数据才会得到解码，GPU执行，卡主线程。常见的做法是在后台线程先把图片绘制到 CGBitmapContext 中，然后从 Bitmap 直接创建图片。

SDWebImage/YYImage等图片库都是这么做的，有兴趣的同学可以去看下源码。如果你是自己做图片下载，就要考虑到相关优化。

二.cell高度预计算/缓存

解决方案：。缓存NSDateFormatter结果，不多次创建，及时释放。

做过类似日历的同学应该都懂��

一般情况下，不要用estimatedRowHeight，不然容易鬼畜；

systemLayoutSizeFittingSize：这个方法，就是大部分cell布局库采用的方法，只要从上至下布局全部生效，就能计算高度，不要多次调用；

由于UITableView绘制过程中多次调用绘制，所以缓存高度计算结果，可以有效的增加滑动流畅度；

当cell高度改变，记得及时替换缓存；

三。离屏渲染

触发条件：CALayer 的 border、圆角、阴影、遮罩（mask），CASharpLayer 的矢量图形显示。

主要问题：GPU占满，CPU空闲

解决方法：

1.开启CALayer.shouldRasterize ，转嫁到CPU上；

2.粗暴画图/截图实现border和圆角；

3.砍死设计师。

最近拖延症有点厉害，这篇文章想写了很久都没写出来，我先摘要一部分思路出来。

曾经的需求是这样的：

注意需求的圈和头像之间是有空隙的

初期方案是图片下载完成后，裁成圆形，然后外面用贝塞尔画一个圈，根据不同的UI缓存不同多个带圈儿的图；

然而。。.神奇的产品第二版给我整出了无数个各种不同大小、间距、透明度的圈。这样就意味着我得缓存无数带着各色圈儿的图。