前言
本文是一种解决tableview快速滚动时引起的掉帧方案,如果有更好的思路可以指出.
本文参考和学习了YY大佬的文章链接和这个异步绘制cell的项目链接.看本文前请至少看完YY前辈的这篇文章!
造成卡顿的原因
屏幕显示图像的原理
通常来说，计算机系统中 CPU、GPU、显示器是以上面这种方式协同工作的。CPU 计算好显示内容提交到 GPU，GPU 渲染完成后将渲染结果放入帧缓冲区，随后视频控制器会按照 VSync 信号逐行读取帧缓冲区的数据，经过可能的数模转换传递给显示器显示。
为了解决显示的效率问题,显示系统引入了多重缓冲机制.在双重缓冲机制下,GPU 会预先渲染好一帧放入一个缓冲区内，让视频控制器读取，当下一帧渲染好后，GPU 会直接把视频控制器的指针指向第二个缓冲器。如此一来效率会有很大的提升。
但这会造成一个新的问题,那就是画面撕裂,如下图所示:
为了解决这种现象,引入了一个垂直同步的机制,玩游戏的小伙伴应该不会陌生.GPU会等显示器的VSync信号发出后再渲染下一帧,但这就会消费更多的计算资源,所以在一些配置较低的设备上游戏时为了提高FPS不建议开启垂直同步的原因.
卡顿造成的原因
根据上面介绍的图像显示原理,我们可以对卡顿的原因做一些分析.CPU负责计算内容,GPU负责变换,渲染等等,当显示器发出VSync信号时,这两者的总计算任务没有计算完,没有的到新的一帧的话,那么这一帧就会被丢弃,等待下一次的显示机会,而显示屏会保留之前的内容不变,这就是造成卡顿的原因.
那么我们接下来就来分析一下什么样的任务会给GPU和CPU带来负担呢.
CPU卡顿的任务
- 对象创建
- 对象修改
- 对象销毁
- 布局计算
- Autolayout
- 文本计算
- 文本渲染
- 图片的解码
- 图像的绘制
GPU卡顿的任务
- 纹理的渲染
- 视图的混合
- 图形的生成
解决思路
整体思路上就是在时间上提前计算,在空间上减少计算量,高效利用CPU资源!
- 1 不使用
AutoLayout,直接使用Frame布局 - 2 减少控件数量
- 3 将圆角切割这样的事情不要使用离屏渲染这样的做法,而是直接画出来
- 4 将异步请求url的图片利用
CALayer绘制 - 5 将其他控件利用
异步绘制到一张图片,最后回到主线程展现图片 - 6 控制异步绘制线程
数量,因为大量的切换线程实际上是一个极其消耗资源的过程 - 7 快速滚动时提供一种机制能取消绘制
- 8 其他可以采用的优化本文却没有使用的,欢迎补充
1 不使用AutoLayout,直接使用Frame布局
一般在MVC中tableView绘制,在数据源代理中会给cell传入Model,然后通过计算AutoLayout对应的Frame展示数据,我们可以把这个计算提前,在获取数据的时候就把布局,cell高度,展示内容计算好,渲染的时候直接拿来用就好了.思想上其实类似MVVM中cell的VM,只不过这个"VM"专门负责计算数据位置以及展示内容罢了.
如何使用请查看demo中CellLayout文件,下面举个例子:
2 减少控件数量
我的做法是,除了需要异步加载的图片使用CALayer,其他的全部成一张图片,这样渲染的时候就不会对层级进行计算了.
3 将圆角切割这样的事情不要使用离屏渲染这样的做法,而是直接画出来
直接使用CGContext把他画出来,不要用离屏渲染这样的做法,他十分的消耗性能!
4 将异步请求url的图片利用CALayer绘制
我们这里的图片仅仅是展示就足够了,所以用消耗资源较少的CALayer是一个不错的思路,另外在YYKit中对CALayer异步加载图片提供了一个类似SDWebimage的方法,不同的是加载的时候限制了开启并发线程的数量,这样不会因为开辟大量线程而造成资源浪费.
5 将其他控件利用异步绘制到一张图片,最后回到主线程展现图片
这一步是这个优化方案中最核心的一步,利用CPU的多核优势,对本来应该展现的控件做一个异步的绘制,最后绘制完毕后回到主线程进行渲染,这里只截取部分关键代码,我把其他一些重复动作会删除掉.做完这一步其实已经能保证在iPhone6上是60帧了,下面的优化也只是为了能做的更好一些.
6 控制异步绘制线程数量,因为大量的切换线程实际上是一个极其消耗资源的过程
这一步上面在异步请求url图片时提到过,这里我主要是为了控制异步绘制线程的数量,这个数量和CPU的核心数相等,例如A11给到了6个线程.
7 快速滚动时提供一种机制能取消绘制
这里使用了一个全局变量来控制,我们每绘制一个控件都会判断这个BOOL值,如果已经不需要绘制了,那么这个他就会被Return掉,所以你在一些性能较低的手机上运行本Demo,在极快速滑动时会发现有的cell是空白的,这表示他在绘制的过程中就已经被停止掉了.这里可能交互上不是很美观,在第八条中会提供相应的解决方案.
8 其他可以采用的优化本文却没有使用的
我们可以在快速滚动时使用一个外壳来展示,例如这样的效果
代码和思路大致如下,这里因为没有相关素材就没有去写了
Instuments优化
上面的八条算是针对这个场景做的一些极限的优化,但我们一般的优化却不是这么做的,而是利用Instuments工具,检测哪里的代码执行时间比较长,哪里的代码会对CPU和GPU造成过多负担,这里主要介绍一下关于优化卡顿常用的的一些检测手段.
Color Blended Laters
这个选项主要是观察视图的混合,说得通俗一点就是视图的堆叠,视图堆叠由少到多,会从绿到红,如下图所示:
Color Misaligned Images
这个选项主要是检测素材是否被压缩或者拉伸.
Color Offscreen-Rendered Yellow
会将离屏渲染的部分变为黄色,需要去优化.
后记
目前的所学知识暂时只能优化到这里了,有什么好的方案欢迎大家指出,另外我们平时的优化也绝对不是这样去做的,而是应该先写出来,再利用一些性能优化工具对一些消耗性能的地方进行逐步优化,我这里只是为了学习和总结做的一个demo.
再来看一下这里的效率问题,毫无疑问在没有特别的需求要求下,利用AutoLayout明显开发速度,以及项目的维护性上是高于我这样的做法的,所以具体怎样做要看取舍了.
在绘制上想再优化的话大概就只有用Metal或者OpegnGL ES去做了,iOS11后渲染全部已经是Metal了.
