iOS优化（三）没错我还是滑动优化

近期把滑动优化的一些经验整理了一下，在公司做了一次技术分享，和我之前的文章有一小部分重叠。现摘要如下，希望大家不吝赐教，共同讨论进步。

一.滑动优化的玄学

为什么说是玄学呢，因为大部分情况下的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高度预计算/缓存

• 一般情况下，不要用estimatedRowHeight，不然容易鬼畜；
• systemLayoutSizeFittingSize:这个方法，就是大部分cell布局库采用的方法，只要从上至下布局全部生效，就能计算高度，不要多次调用；
• 由于UITableView绘制过程中多次调用绘制，所以缓存高度计算结果，可以有效的增加滑动流畅度；
• 当cell高度改变，记得及时替换缓存；

三.离屏渲染

触发条件：CALayer 的 border、圆角、阴影、遮罩（mask），CASharpLayer 的矢量图形显示。
主要问题：GPU占满，CPU空闲
解决方法：
1.开启CALayer.shouldRasterize ，转嫁到CPU上；
2.粗暴画图/截图实现border和圆角；
3.砍死设计师。

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

拖延症晚期患者.png

曾经的需求是这样的：

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

初期方案是图片下载完成后，裁成圆形，然后外面用贝塞尔画一个圈，根据不同的UI缓存不同多个带圈儿的图；
然而...神奇的产品第二版给我整出了无数个各种不同大小、间距、透明度的圈。这样就意味着我得缓存无数带着各色圈儿的图。

此时的心情.png

后来突然灵光一闪，单独设layer的圆角貌似不引发离屏渲染（有说法是iOS8之后）。所以后来方案变成，UIView嵌套一个UIImageView，只缓存裁剪过的图片。

但是这样的话，其实UIKit的创建要比读取画好的图更耗性能。所以这是个终极的问题，时间/空间，究竟选哪个。

四.图片的处理

1.SDWebImage的外层干了啥

喜闻乐见的拖延症晚期

这篇文章写了1/4的样子，详细的会在这篇文章里，十分心疼自己。下面简单说说SDWebImage的外层都干了啥：

• 重用cell的时候，cancel之前下载operation；
• 二级缓存：memory/disk；
• 合并回调，多次调用只回调一次；

2.项目中实际遇到的问题

我们做了个类似SDWebImage的东西，来实现神奇的需求，过程中遇到了一些问题：

• 从disk读取需要时间，在memory没有的情况下，导致image = nil的一瞬间闪动：我把SDWeb的demo改了改，左边按钮ReloadData，右边按钮清除内存（memory）缓存，在reload的一瞬间，展示了placeHolder的图。

  
  SDWebFlash.gif

• UICollectionView, reloadData 迷之移位闪烁问题：当reloadData的时候，重用的cell神奇的变换了次序，此时memory里只要一图片不存在，就会有一瞬间的闪动。

• 上面两个问题的解决方法有：

  • 尽量避免reloadData，可以找到visibleCells，一一更换换图片；
  • 优化细节，在发现disk里面有图的时候，image不设为nil，避免闪动；
  • 保证memory缓存的大小和数量，能满足界面需求；

• 请求没有合并/回调没有合并；
  这个比较好解决，就是请求之前判断该请求是否在执行，若在执行，则将回调暂存到该请求下，等完成后一并调用。

五.ScrollView滑动优化

1.滑动时的代理

• scrollViewDidScroll：实际上就是contentOffset的KVO
• scrollViewWillBeginDragging:
• scrollViewWillEndDragging: withVelocity: （points/millisecond这实际上是个速度的参数）targetContentOffset:(这是一个可以传值的指针，可以控制最后的减速动画)
• scrollViewDidEndDragging: willDecelerate:（拖动结束，如果仍有速度，会执行后面两个方法）
• scrollViewWillBeginDecelerating:
• scrollViewDidEndDecelerating:
• 需要注意scrollView的dragging属性在decelerate的过程中仍然为YES

2.特殊情况

drag完，正decelerating时（didEndDecelerating尚未调用），强行再次drag（单指停止滑动，双指连环滑）

• 单指停止滑动：没有decelerate ，willBeginDecelerating不会被调用，但前一次留下的 didEndDecelerating 会被调用（后面会结合VVWeibo的例子讲述这里怎么处理）
• 双指连环滑动：willBeginDecelerating会先于didEndDecelerating调用，就是说这种情况didEndDecelerating会在你手指离开屏幕且屏幕停止的情况下调用。

3.VVWeibo的做法

• scrollViewWillEndDragging: withVelocity: targetContentOffset:时，可以从targetContentOffset判断即将加载的那一页cell，从而预先加载，UITableView有传入rect返回cells的方法，UICollectionView得强行取两个点获得这两个点cell的IndexPath，然后得到cells。
• 遇到前文单指停止的处理，VVWeibo是在UITableView的子类捕获了touchEvent，然后reloadData，我就没有做子类了。最后做了一系列神奇的判断，然后reload。但是仍然遇到了 reloadData 迷之移位闪烁问题；后来我加入了速度的判断，这个已经不会触发了，我就暂时注销掉了，等待下一步优化。

4.最迷的问题

UICollectionViewLayout的prepareLayout调用了过多次数，是因为shouldInvalidateLayoutForBoundsChange:这个方法灾难的调用了多次，newBounds的x和y实际上随着滑动一直在变，return YES的话就一直重新布局，最后用magicNumber存他的size，当size变化才返回YES，就很强行的解决了。

六.魔鬼般的视频播放

这里涉及业务逻辑过多，我也不方便多写，就写一些过程中遇到的问题：

• scrollViewDidEndDecelerating的VisibleItems为nil。换个线程/延时去取，就能取到。

• 缩小播放区域，跟前面的取点找目标cell的操作类似，找出首尾点，中间的cell，即是需要播放的cell。

• 多个等待播放的AVPlayerItemVideoOutput，会导致一部分失效，内存越小的机子上越明显。
  解决方法：播放前再把url赋给playerItem，一定程度避免过多playerItem失败的问题；

• 出入页面找到所有playerItem并干掉，避免影响其他播放；

• GLKView的reuse在狂滑的时候十分耗内存，而不reuse的话，重用的时候，会显示上一个页面的残影，解决方法是先用图片盖住残影，在播前，清理上一次播放的残余；

• 加入一个Timer，通过记录偏移量来控制滑动速度，高速度的时候，不绘制/下载图片。这样也解决了双指狂滑的时候，无法很好的判断当前是否绘制的问题。

Conference

http://wereadteam.github.io/2016/05/03/WeRead-Performance/ 微信读书 iOS 性能优化总结
http://blog.ibireme.com/2015/11/12/smooth_user_interfaces_for_ios/ iOS 保持界面流畅的技巧
http://blog.sunnyxx.com/2015/05/17/cell-height-calculation/ 优化UITableViewCell高度计算的那些事
http://tech.glowing.com/cn/practice-in-uiscrollview/ UIScrollView 实践经验
《High Performance iOS Apps》这本真是神书，有兴趣深入学习优化的可以去看看，中文的貌似有美团技术团队翻译的

简书已经弃用，欢迎移步我的小专栏：
https://xiaozhuanlan.com/dahuihuiiOS