iOS优化(三)没错我还是滑动优化

Gboy· 2019-03-22
本文来自 大灰灰iOS ,作者 Gboy

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

一.滑动优化的玄学

为什么说是玄学呢,因为大部分情况下的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缓存不同多个带圈儿的图;
然而...神奇的产品第二版给我整出了无数个各种不同大小、间距、透明度的圈。这样就意味着我得缓存无数带着各色圈儿的图。

后来突然灵光一闪,单独设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的图。


  • 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


作者:大灰灰iOS

链接:https://www.jianshu.com/p/f3e18bab841e
来源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。