UITableView 在移动开发中常常是必不可少的，并且是动态的加载，要很好的滚动显示效果，就必须更多的了解UITableView的实现机制，更好的优化。
UITableView的优化分两块:布局优化、渲染优化、异步操作。(也可以理解为平衡CPU和GPU的负载，这就要理解为什么会造成卡顿的原因了)
一、布局优化
布局优化包括：布局优化和高度优化
1、布局有两种方式，第一种是AutoLayout(storyboard、xib或Masonry)，第二种是frame。使用AutoLayout布局的话可以省去人工计算成本和灵活多变，相对的就会增加CPU的负载，而使用frame对CPU来说就很简单，唯一的缺点就是可扩展性差。以下是引用Draveness的一张图，展示两种布局的性能差别
补充：
（1）在开发的过程中，本人会优先考虑使用AutoLayout的方式，原因有两个：第一，AutoLayout布局容易且快，在开发中优先考虑就是完成功能；第二是现在的手机硬件越来越好，性能堪比电脑，如果不是特别复制的界面一般TableView滑动的流畅度都是没问题的。
（2）Frame布局方式，这里特别推荐Yang2333的文章，他的实现方式挺新颖的，并且对于tableView的优化方式也是信息量满满的
2、高度优化
UITableView是UIScrollView的子类，所以也是要计算其ContentSize,UITableView的contentSize的高度是全部Cell的高度和。设置UITableView的高度有两种方式
第一种是直接设置tableView的属性rowHeight(这种方式只适合设置固定高度的Cell，并且也是设置固定高度的推荐方式)；
第二种是通过代理方法
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath.
因为UITableView 实现机制的原因，每显示一个Cell都需要执行N次这个方法(并且包括显示在屏幕或还没显示的)，如果在这个方法中添加计算Cell的复杂算法，可想而知这对CPU而言是非常重的负担。优化的方向是怎么获取Cell的高度并减少计算的难度。
本人的做法：关于UITableView布局的优化，一直都是在使用Masonry和UITableView+FDTemplateLayoutCell两个框架，对于一般的项目来说都是没什么问题的。
UITableView+FDTemplateLayoutCell优化原理
补充：
对于不是固定高度的Cell，这里还有一个小技巧，对提高UITableView的流畅度很有帮助的。
在tableView:cellForRowAtIndexPath: 方法中需要为每一个Cell 调用一次，它应该快速执行，要尽可能块的返回重用Cell实例。Cell还没显示到屏幕上，不再这里执行数据绑定
tableView:willDisplayCell:forRowAtIndexPath: 在Cell要显示时调用，在这里执行数据绑定
补充设置圆角的正确姿势：bestswifter
二、渲染优化
讲渲染优化这里有几个概念需要先提的：混合操作、离屏渲染，像素对齐。
混合操作
渲染最慢的操作之一，是由GPU完成，我们的目的就是减少混合操作的次数。
查看混合操作的方式如下图
离屏渲染
iOS-离屏渲染详解
离屏渲染优化详解：实例示范+性能测试
关于离屏渲染上面两篇文章已经写得很详细了，这里再推荐一种查看离屏渲染的调试技巧，如下图
像素对齐
有了Retain屏后，CocoTouch环境下，可以使用屏幕点来取代像素了，并且屏幕点可以是浮点值，
当屏幕点是浮点数时，iOS 将会执行子像素渲染，这技术在特定类型的内容(如文本)时很有意义，但是当绘制
平滑直线时则没有必要了，这会让iOS 执行一些不必要的任务，从而降低FPS
查看方式：在iOS模拟器上运行程序，在”Debug“菜单中选中”Color Misaligned Image“。
有两种高亮区域：品红色区域会执行子像素渲染，而黄色区域是图片大小没有对齐的情况。
建议：对所有像素相关的数据做四舍五入处理，包括点坐标，UIView的高度和宽度。
跟踪你的图像资源：图片必须是像素完美的，否则在Retina屏幕上渲染时，它会做不必要的抗锯齿处理。
还有一个是opaque值，opaque是一个渲染性能的开关标识符，并不代表视图的透明度（aphal 才是视图的透明度属性值)，opaque默认值是YES，如果opaque的值为NO，则是合成渲染，加大了GPU合成计算视图显示的计算难度。
第三：异步操作
异步操作主要是为了尽快返回Cell，通常是异步操作读写数据库和网络请求。
