TableView性能优化是一个老生常谈的问题了，最近也正在做TableView的性能优化，在此我也做一个总结：
UITableView只会创建一屏幕（或者一屏幕多一点）的cell，其他都是取出来重用的。每当cell滑出屏幕的时候，就会放到一个集合中，当要显示某一位置的cell时，会先去集合中取，有的话，就直接拿出来显示，没有在创建。
cell赋值内容时，会根据内容设置布局，也就可以知道cell的高度，若有1000行，就会调用1000次 cellForRow方法，而我们对cell的处理操作，都是在这个方法中赋值，布局等等，开销很大。
3.优化方法
3.1优化：heightForRow方法处理cell高度。
思路：赋值和计算布局分离。cellForRow负责赋值，heightRorRow负责计算高度。
3.2自定义cell绘制：
各个信息都是根据之前算好的布局进行绘制的。需要异步绘制。重写draeRect方法就不需要异步绘制了，因为drawRect本来就是异步绘制的。图文混排的绘制，coreText绘制。
3.3按需加载（UIScrollView方面）：
如果目标行与当前行相差超过指定行数，只在目标滚动范围的前后制定n行加载。滚动很快时，只加载目标范围内得cell，这样按需加载，极大地提高了流畅性。
1.提前计算并缓存好高度，因为heightForRow最频繁的调用。
2.cellForRow方法里尽量减少计算量和代码量。
3.滑动时按需加载，这个在大量图片展示，网络加载时，很管用。（SDWebImage已经实现异步加载）。
4.重用cells。
5.如果cell内显示得内容来自web，使用异步加载，缓存结果请求。
6.少用或不用透明图层，使用不透明视图，少使用圆角、阴影等。
7.用代码代替xib文件，用手动设置frame方式代替自动布局。（xib和自动布局比较耗时）
8.cell文件里边能提前算好的尽量缓存起来，避免多次计算。
9.少用addView给cell动态添加view，可以初始化的时候就添加，然后通过hide控制是否显示。
当上边这些基本的优化都做过之后，发现自己的tableView还是有些卡顿，那你就需要考虑下边的这些高级优化方案了。
1.异步绘制，遇到复杂界面，性能瓶颈时，可能是突破口。
2.模仿或者使用YYKit的设计思想，从底层图像绘制原理层面，去进行界面的绘制和布局。
3.图片解码。解码的原理也很简单，提前把图片绘制到一个CGContext中，再从Context获取图片，这样能够强制图片解码。通常三方库（KingFisher,SDWebImage）都自带后台解码。
4.预加载cell。提前创建cell并且缓存到内存中，这时候要做好内存管理，不要让内存太大导致APP崩溃。
5.从图像渲染、CPU和GPU处理图像操作方面做优化。
引用其他博主的总结：
1.性能分析就是一句话：能放到后台的就放到后台，不能放到后台的要么预加载，要么拆分。另外还有一个Facebook出品的三方库非常推荐：Texture，这个是一个异步显示框架，会省去很多事。
界面顿卡主要从两个角度考虑
CPU限制：
对象的创建，释放，属性调整。这里尤其要提一下属性调整，CALayer的属性调整的时候是会创建隐式动画的，是比较损耗性能的。
视图和文本的布局计算，AutoLayout的布局计算都是在主线程上的，所以占用CPU时间也很多 。U
文本渲染，诸如UILabel和UITextview都是在主线程渲染的
图片的解码，这里要提到的是，通常UIImage只有在交给GPU之前的一瞬间，CPU才会对其解码。
GPU限制：
视图的混合。比如一个界面十几层的视图叠加到一起，GPU不得不计算每个像素点药显示的像素
离屏渲染。视图的Mask，圆角，阴影。
半透明，GPU不得不进行数学计算，如果是不透明的，CPU只需要取上层的就可以了
浮点数像素
建议使用成熟的”轮子”，因为作为一个开发者，你的工作是写出高质量的App，那么为什么不用那些已经验证成功的框架呢？如果真的轮子不能实现，或者你有闲下来的时间，再造轮子未尝不可。
使用FaceBook出品的AsyncDisplayKit来写复杂的界面。能够获得异步绘制，预先加载等诸多好处。不过，需要一定的学习成本，前段时间看了下网易新闻的安装包，就使用了AsyncDisplayKit
大多数性能要求较高的界面就是图文混排，比如微博Feed，微信朋友圈等界面。建议使用成熟的图文混排引擎，因为这些引擎一般支持异步绘制，并且做了大量优化。推荐两个
把复杂的界面，放到后台线程里绘制成一个bitmap，然后再显示。虽然有些延迟，不过换来的却是平滑的界面。
建议使用成熟的库，比如SDWebImage等，能够在后台进行图片解码，减少CPU的使用。
对于复杂的TableView，可以对Cell视图的各个控件的大小，位置后台进行预计算，并且缓存起来。这样保证在heightForRow和cellForRow中不进行大量的计算。
因为Layer是一个轻量级的视图结构，它不接受通知，不接受触摸，不在响应链。所以，相对于UIView来说，它的性能较好。并且CALayer及其子类是可以使用GPU渲染的，能够硬件加速。
将两个CALayer的内容合成到一个Bitmap里，然后显示。能够减轻GPU的压力
转:https://blog.csdn.net/u013602835/article/details/79413649
