前言
刚开始学习iOS开发的时候就有前辈说，国内的iOS程序员在国外被戏称为UITableView开发者。不管是为了适配4S以下机型的屏幕比例，还是Cell重用机制对内存负荷的降低等原因，都让我们无数次在UIViewController新建完成后立刻添加一个UITableView上去。无论如何，UITableView的开发技巧是任何iOS程序员必须掌握的基本功，对它的优化知识也大部分能间接推演到整个APP的优化中去。在这里结合本人平时收集的一些资料，对这些UITableView的优化手段做一下总结。
一、入门优化
-
使用Cell重用机制
UITableViewCell的重用机制是UITableView的核心。UITableView只会创建控件可视范围数量的UITableViewCell，每当UITableViewCell滑出范围时，就会放入到一缓存池当中，当要显示新的UITableViewCell时，先去缓存池中取，若没有可用的，才会重新创建。这样可以极大的减少内存的开销。
//注册cell
[tableView registerClass:[UITableViewCell class] forCellReuseIdentifier:@"UITableViewCell"];
//获取cell
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"UITableViewCell"];
推演至APP优化：
尽量利用lazy initialize (延迟加载) 推迟对象创建的时间，并把对象的创建分散到多个任务中去。如果对象可以复用，并且复用的代价比释放、创建新对象要小，那么这类对象应当尽量放到一个缓存池里复用。
-
异步加载并缓存Cell所需的网络资源
之后再切换到回dispatch_get_main_queue进行设置，将资源缓存到内存和本地待复用(如图片资源SDWebImage，视频资源等)，不可以阻塞主线程影响交互体验。
-
不要在
cellForRowAtIndexPath中执行addSubview或addSublayer
当列表中 cell 的样式随数据源产生变化时，有时候我们会利用addSubview、addSublayer、viewWithTag、removeFromSuperview等手段进行控制，这对内存和CPU都会产生一点负荷。如果 Cell 样式变化很大，直接创建新的自定义 Cell 来解决这个问题；如果样式变化不大，使用hidden属性进行样式控制。
-
Cell高度计算(阶段一)
如果 rowHeight , sectionFooterHeight 和 sectionHeaderHeight 固定，则直接按参数设定行高，不要请求delegate。
遇到 cell 高度动态变化的列表，使用 UITableView+FDTemplateLayoutCell 框架+AutoLayout进行Cell的高度计算。
作者使用和每个 Cell 重用标识UITableViewCell ReuseID一一对应的临时 Cell ，利用iOS6的APIsystemLayoutSizeFittingSize进行Cell的高度计算并缓存起来，提升 cell 高度计算的效率，使用起来也非常简单。
需要注意的是对 cell 的约束要做到保证cell 的 contentView 内部上下左右所有方向都有约束支撑，这是systemLayoutSizeFittingSize计算出内容 size 的依托。作者在这篇博客详细介绍了框架的实现原理和研发的历程。 -
** 尽可能让 Cell 的所有 Subview 不透明**
透明视图的存在让GPU需要进行更多混合图层的计算(多层layer叠加时应在像素点上显示的颜色)以得出最终要显示的效果。在UIScrollView上进行滑动时，如果视图上有透明 layer ，GPU需要不停地做更多的工作。
所以应尽可能避免让视图的alpha值不等于 1 或 0 ，并设置非透明视图的layer.opaque属性为YES，避免无用的透明度通道合成。
推演至APP优化：
同理如上。
以上都是优化UITableView的一些初步手段，特点是实现过程的工作量不大、迭代更改源代码效率高，对付一般的 Cell 可以说绰绰有余。
二、进阶优化
-
弃用 AutoLayout
Autolayout是苹果官方推荐使用提升开发效率的重要工具，但是Autolayout对于复杂视图来说常常会产生严重的性能问题。随着视图数量的增长和UITableView的滑动，Autolayout对控件的重新布局带来的 CPU 消耗会呈指数级上升。
所以如果你对UITableView的性能有很高要求，应该尽量避免使用AutoLayout，用手工计算和改变frame的方式来控制视图。 -
Cell高度计算(阶段二)
Cell高度计算阶段一的方案虽然方便且减少了一定的损耗，但是当 Cell 内容繁杂时，你会明显感觉到列表滑动时的卡顿感(特别是未缓存 Cell 高度时)。
这是因为systemLayoutSizeFittingSize方案终究是AutoLayout的产物，在静态页面对所有视图的重新布局只会在控制器初始化时阻塞主线程，用户体验不会收到太多影响。但在UIScrollView的滑动过程中阻塞主线程，就很蛋疼了。
所以最好的方案，还是在获取到 Cell 对应的 Model 之后，手工计算 Cell 的高度并缓存起来。
在这里提供一个思路：在 Model 里添加一个cellHeight属性，计算 Cell 高度的方法作为 Cell 的类方法，在对应需要设置或更新 Cell 高度的时候调用并对cellHeight赋值。
看过一篇文章把计算高度的方法放在 Model 中，这样做不好的原因是，一方面不利于架构分层，计算 Cell 高度并不是 Model 的任务；另一方面一个 Model 可能要对应用来显示多种 Cell ，总不能添加一种 Cell 就在 Model 里添加一个计算高度的方法。 -
Cell中不需要交互的视图，用
CALayer代替UIView来绘制
UIView很重，创建和销毁都比CALayer要耗费资源。我见过无数份新手的代码，生成height为 1 的UIView来绘制分割线。对于没有触控响应事件需求的视图，尽量用CALayer代替UIView来节省损耗。
推演至APP优化：
整个APP都应该遵循这个原理，尽量用轻量级的对象来代替重量级的对象实现功能。
-
避免触发图片缩放
首先我们开启模拟器->Debug->Color Misaligned Images 选项，会看到项目里所有触发了图片缩放的视图上都多了一层黄色的遮罩，这些视图大部分都是图片与视图大小比例不同，而系统进行这些调整相当耗费资源。
最好的解决方案当然是让UI切出各种尺寸和比例不同图片，一步到位，但是这会让项目包的大小剧增，而且大部分情况要显示的图片都是从服务器获取的，大小比例根本不可控。
所以一般我们使用折中方案：后台绘制对应视图大小和所需UIViewContentMode的图片，再切换到主线程进行设置。 -
避免离屏渲染
尽量避免使用 CALayer 的 border、圆角、阴影、遮罩（mask）等属性，对此我特地写了这篇文章阐述大部分会导致离屏渲染的操作和对应的解决方案，欢迎阅读。 -
重用时间处理类
NSDateFormatter和NSCalendar是常用的时间处理类，然而他们的初始化过程十分长久。将他们用单例模式缓存起来并在APP启动时进行初始化，以优化时间转换过程的耗时。
进阶优化的手段适用于比较复杂的 Cell 设计，或是入门优化后仍然感觉到卡顿和低帧数现象的情况。
三、锱铢必较优化
以下的UITableView优化手段，非到万不得已或是对性能有极致要求的地步，不推荐使用，过早和过度的优化是完全没有必要的。做性能优化时，也最好是走修改代码 -> Profile -> 修改代码这样一个流程，优先解决最值得优化的地方。
-
Cell高度计算(阶段三)
前面阶段二，我们提前计算了 Cell 的高度并缓存在 Model 中，提升了计算高度的效率。然而在cellForRowAtIndexPath回调中，对 Cell 进行绘制时，我们仍然需要对 Cell 中的 Subviews 例如UILabel等进行文字高度计算，如果这种需要动态计算高度类型的视图数量太多，仍然会阻塞线程对用户体验有所影响。
所以我们可以把 Cell 内部所有动态变化的控件高度用一个 CellSubViewsModel 缓存下来并动态管理，就在阶段二计算 Cell 高度时，一定会涉及到其 Subviews 的尺寸计算，这个时候就可以初始化这个 CellSubViewsModel 并将它赋值作为数据源 Model 的一部分，在cellForRowAtIndexPath回调中直接读取Cell各 Subviews 的尺寸并进行赋值，使数据源赋值和视图绘制成为cellForRowAtIndexPath中唯二的工作。 - **使用 CoreText 异步绘制文本 **
屏幕上能看到的所有文本内容控件，在底层都是通过 CoreText 排版、绘制为 Bitmap 显示的。常见的文本控件 （UILabel、UITextView等），其排版和绘制都是在主线程进行的，当显示大量文本时，CPU 的压力会非常大。对此解决方案只有一个，那就是用最底层的 CoreText 对文本异步绘制。尽管这实现起来非常麻烦，但其带来的优势也非常大，CoreText 对象创建好后，能直接获取文本的宽高等信息，避免了多次计算（调整UILabel大小时算一遍、UILabel绘制时内部再算一遍）；CoreText 对象占用内存较少，可以缓存下来以备稍后多次渲染。 - **使用 CoreGraphic 异步解码+绘制图片 **
当图片设置到 UIImageView 或者 CALayer.contents 中去，并且 CALayer 被提交到 GPU 前，CGImage 中的数据会进行数据解码。这一步是发生在主线程的，并且不可避免。
所以我们可以走在后台线程先把图片绘制到CGBitmapContext中，然后从 Bitmap 直接创建图片这样的流程，把主线程的解码和绘制工作利用 CoreGraphic 放到后台来执行。
- (void)display {
dispatch_async(backgroundQueue, ^{
CGContextRef ctx = CGBitmapContextCreate(...);
// draw in context...
CGImageRef img = CGBitmapContextCreateImage(ctx);
CFRelease(ctx);
dispatch_async(mainQueue, ^{
layer.contents = img;
});
});
}
- **异步绘制+及时取消绘制 **
当列表滑动过快时，使用异步绘制有时候会出现异步绘制过程还没触发，Cell 就已经离开了屏幕显示范围的情况，此时应及时取消绘制动作。
网友评论
UIView很重，创建和销毁都比CALayer要耗费资源。我见过无数份新手的代码，生成 height 为 1 的UIView来绘制分割线。