一、tableview通用工作流程

一个tableView需要显示内容的时候，首先会发送网络请求，向服务器请求数据，然后将数据转为我们可以使用的model或dictionary后进行reload操作。

接下来会向delegate和dataSource发送数据。这时候会先调用- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section这个方法（假设section为1）。根据model获取cell的行数然后调用-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath，根据model计算出cell的高度。由于tableView是继承自scrollView，所以tableView也会有contentSize属性。它的contentSize取决于所有cell的高度和。和scrollView有一点不同，tableView只会管理可视的cell高度，这样做的目的是避免不必要的性能开销。

大多数情况下我们是将model直接传给cell然后在cell里进行计算各控件的相对位置（利用AutoLayout和xib）比如：

来自互联网

但是这样做假如滑动比较快，且内部控件比较复杂会导致CPU的计算量过大，从而导致掉帧。肯定会有人疑惑为什么会掉帧，这是因为GPU 一个机制叫做垂直同步（简写也是 V-Sync），当开启垂直同步后，GPU 会等待显示器的 VSync 信号发出后，才进行新的一帧渲染和缓冲区更新。这样能解决画面撕裂现象，也增加了画面流畅度，但需要消费更多的计算资源，也会带来部分延迟。当GPU发出垂直同步即VSync信号后，CPU开始进行内部控件的创建、布局、解码和控件的相对位置计算。然后将计算好的内容交给GPU进行变换、合成、渲染。然后等待下一个VSync信号。（这段理论部分来自于YY大神）假如在VSync信号发出后，CPU进行计算的时间过长，或者GPU进行渲染的时间过长导致两段时间加起来超过了1个VSync周期，就会将这一帧动画丢弃，并维持上一帧的画面从而导致掉帧。

二、优化

tableview优化最主要：复用cell，header，footer实例；使用约束布局cell子控件时不多次添加约束；图片不过大，尽量不使用透明视图；避免阻塞主线程；计算高度方法不做大量逻辑处理。

避免快速滑动情况下开过多线程

cell中的图片开线程异步加载，相信每个人都会想到。线程开过多了会造成资源浪费，内存开销过大。图片过多时可以不要一滚动就走cellForRow方法，可以在scrollview的代理方法中做限制，当滚动开始减速的时候才加载显示在当前屏幕上的cell（通过tableview的dragging和declearating两个状态也能判断）:

来自互联网

图片处理

1）后台下载图片后再回主线程刷新UI，避免阻塞主线程。

2）图片过大回造成GPU负担过大，可以在图片下载后压缩尺寸后显示

3）避免对layer做过多的操作，尽量设置图片为不透明

tips: 简单的设置cornerRadius是不会影响性能的，但是设置了maskToBounds，会导致离屏渲染，应减少设置图层 maskToBounds = YES ；

使用懒加载图片的方式避免重复下载图片，浪费资源。图片下载后并做压缩处理后将其保存到缓存中，下次加载此图片之前先从缓存中取，如果取不到该图片就在后台下载保存。（传送门）

使用Core Graphics实现圆角等功能。

重写drawRect方法会离屏渲染，导致内存急剧上升，即使在这个方法里面不写一句代码，也会让内存升高。

三、平衡CPU和GPU

平衡CPU和GPU的压力。正确地利用了CPU和GPU资源，使它们均匀地负载，这样子做FPS会保持在60帧。避免出现CPU满载GPU低负载或者GPU满载CPU低负载的情况。

如何避免出现CPU满载GPU低负载呢？

1. 不要用AutoLayout，不要用AutoLayout，不要用AutoLayout（这里的情景是子视图较多的情况下），重要的事情说3遍。

我们进行手动布局可能会没那么方便，但是通过简单的加减乘除就可以获取控件相对位置和cell的高度。尽管苹果推荐使用AutoLayout。但是对于那些比较古老的设备比如我的5S，CPU通过AutoLayout计算布局会比较吃力，尤其是cell内部的控件数量较多的时候。使用的子视图越多，AutoLayout的效率越低，这是事实。那么为什么AutoLayout相对低效呢。是因为它要根据底层“Cassowary”的约束求解系统进行约束计算，从而得到一个唯一解，这时AutoLayout才不会报警告或错误（相信拖控件的同学肯定遇到过各种黄色警告和红包约束冲突吧）。假如内部的子控件越多，它需要进行的线性或非线性计算量越大，需要求解的约束越多，CPU计算耗费大量时间从而导致超过了一个VSync周期。相反的，假如我们进行手动布局，都是非常简单的线性计算，CPU就不用浪费那么时间，CPU的压力不会很大，从而平衡了CPU的负载。性能差异：

来自互联网

由此可以看出Autolayout和frame的性能差异。

tips ：我们可以在tableView进行网络请求成功后立刻进行后台的布局计算。比如是我，利用AFN请求数据成功后会在success 的block里面进行后台的计算：

来自互联网

上面代码会将请求到的JSON数组转换为model数组，然后将model数组里的model转换为modelFrame（就是根据model的各个属性计算出frame）:

来自互联网

提前计算好各个控件的frame并把cell的高度提前缓存起来等到调用-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath时直接return _cellHeight，没有任何计算量，从而减轻CPU的负载。

假如想进一步优化，可以尝试调用控件的view.layer.displaysAsynchronously属性为YES。

之前我们调用了dataSource和delegate的两个关于row和height的方法，接下来tableView会调用- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath这个返回创建并返回特定row的cell。在这个方法内部，我们对cell里的每个控件进行赋值并计算各个控件的布局。只需要把各个控件的frame指向之前已经计算好的各个modelFrame就可以了，不需要进行多余的布局计算，然后对每个控件的内容进行一一赋值，这样子就能在调用cellForRowAtIndexPath这个方法的时候迅速的返回一个cell。

tips: 当网络请求成功返回来数据后通过AFNetworking会将json转换成字典（绝大多数情况会这么做，除非指定了AFNetworking的其他序列化方式），我们可能会直接利用MJExtension或者YYmodel之类的工具，将字典映射为model。假如为了更好的性能，可以采取去model化，直接对dictionary进行取值，避免了利用runtime进行取遍历ivar，property等操作。这样子性能会好一些，弊端是可扩展性差一些。

如何避免出现GPU满载CPU低负载呢？

1.当多个视图重叠时，GPU会对其进行合成渲染，而渲染最慢的操作之一是混合，因此当视图结构太复杂就会消耗大量GPU资源，所以当一个控件本身是不透明的，注意设定opaque = YES，这样子可以避免无用的alpha通道合成，降低GPU负载。

2.对控件设置cornerRadius后对其进行clip或mask操作时，会导致offscreen rendering，而这个是在GPU中进行的，所以快速滑动tableView时，假如圆角对象较多，会导致GPU负载大增。这时候我们可以设置layer的shouldRasterize属性为YES，可以将负载转移给CPU。更为彻底的做法是直接在后台绘制圆角图片然后输出到主线程显示，避免使用圆角、阴影、遮罩等属性。（这种最彻底的做法我没试过）

3.将GPU的部分渲染转接给CPU，那么如何转接呢？我们可以在单个控件中重载drawRect:方法（异步绘制）,直接将文字和图片绘制然后输出到主线程上。

来自互联网

也可以设置Dictionary给Attributes赋值达到自己想要的文字效果。这段代码禁用了一些混合操作，减轻了GPU的负担，从而使UITableView滑动更加流畅。

注意：同时，也要慎重调用drawRect方法，因为调用这方面之前，CALayer会创建一个与 （宽x高 x 4字节）大小的一个的图形上下文，假如是7plus的尺寸，那么就是1920×1080x4 = 8M内存，假如是内存敏感的界面，需要斟酌一下，避免内存开销太大。

总之，性能优化要注意平衡CPU和GPU的负载。

声明：本文仅作为学习笔记，摘抄自网络，并非原创