最近看了很多关于IOS优化的文章，现在大概来总结一下.

列表优化：

卡顿产生的原因

首先我们要了解优化任务的底层运行原理是什么，因为只有了解了运行原理。才可以知道着手从哪里优化。事半功倍。

我们知道iOS设备大部分情况下，屏幕刷新频率是60hz，每隔16.67ms会进行一次屏幕刷新。每次刷新时，需要CPU和GPU配合完成一次图像显示。其主要流程如下：

1.CPU创建View 设置其属性(frame, background,color等)

2.创建backImages setContents将image传给layer，或者通过draw绘制图形。

3.准备。core animation将layer发送到 render server前的一些准备工作，比如图片解码等

4.提交 coreanimation将layers打包通过ipc发送到render server

render server：

设置用来渲染的OpenGL triangles 如果有动画，还需要计算动画的参数

渲染这些可见的triangles 将结果提交到视频缓冲区

视图控制器以60hz品读读取缓冲区内容显示到显示器，如果在16.67ms内没有完成提交，则会被丢弃。

得出的结论就是，无论是GPU还是CPU都有各自的任务，无论哪个压力过大，都会造成卡顿。

通过instrument等测试工具可以发现，tableview在滑动过程中，cpu占用率高，而在空闲的时候 cpu占用率低。

主线程cpu占用率高，子线程cpu占用率低

解决方案

预加载：

滑动时CPU占用过高，16.67ms内无法完成内容提交—>导致卡顿

滑动时CPU占用率高，但空闲时CPU占用率底—>CPU占用分布特点

利用CPU空闲时间预加载，降低滑动时CPU占用峰值—>解决卡顿

如何预加载：

创建列表前找时机预加载。如启动时候，viewDidLoad runloop空闲时等

加载内容：列表将要滑动的时候会加载到的本地缓存图片等，需要耗时的资源。

动态预加载：

在IOS10以后，UITableView和UICollectionView提供了预加载机制，IOS12开始prefeatching做了优化，不再是和cell同时并发进行，而是cell加载完成之后串行开始prefeatch，从而优化了流畅度。

在IOS10以前我们可以用UIScrollview的代理方法进行预加载的操作

加载内容：

cell的高度， subView的布局计算。（cell少用autolayout）

拉取网络数据

网络图片

其他耗时的资源

线程优化

为什么要用多线程：

因为在IOS中,UIKit大部分的API都需要在主线程中调用，特别是一些耗时的操作，如view的创建，布局和渲染默认都是在主线程上完成的。如果主线程的任务过多，就会影响到开发的效率，造成卡顿。将非主线程必须的任务，移到子线程中，减轻主线程的负担。

推荐在子线程中进行的任务：

1.图片解码

2.文本渲染 UILabel和UITextView都是在主线程渲染的，当显示大量文本的时候 CPU的压力会非常大 用TextKit或最底层的CoreText对文本异步绘制。它的优势非常大，CoreText对象创建好后，能直接获取文本的宽高等信息，避免了多次计算。

缓存：

缓存的内容可以是

UIView,view的创建代价很大，一些可以服用的view可以cache，例如UITableView为我们实现的cell的服用。

图片，图片涉及磁盘IO和解码，十分耗时，可以考虑缓存。

布