iOS Tableview性能优化

说起tableview优化，简直是博大精深。

有时候遇到这样一种场景：每次滑动页面的时候，就会出现卡顿严重的情况。那么问题来了，为什么会出现卡顿情况呢？那就要从UITableViewCell重用机制说起。

1.UITableViewCell重用机制

UITableView只会创建一屏幕（或者一屏幕多一点）的cell，其他都是取出来重用的。每当cell滑出屏幕的时候，就会放到一个集合中，当要显示某一位置的cell时，会先去集合中取，有的话，就直接拿出来显示，没有在创建。

2.tableView滑动为什么会卡顿

cell赋值内容时，会根据内容设置布局，也就可以知道cell的高度，若有1000行，就会调用1000次 cellForRow方法，而我们对cell的处理操作，都是在这个方法中赋值，布局等等，开销很大。

3.优化方法

3.1优化：heightForRow方法处理cell高度。

     思路：赋值和计算布局分离。cellForRow负责赋值，heightRorRow负责计算高度。

3.2自定义cell绘制：

     遇到比较复杂的界面的时候，如复杂点的图文混排，上面的那种优化行高的方式可能就不能满足要求了，当然了，由于我的开发经验尚短，说实话，还没遇到要将自定义的Cell重新绘制。至于这方面，大家可以参考这篇博客，绝对是开发经验十足的大神，分享足够多的UITableView方面的性能优化，好多借鉴自这里，我都不好意思了。http://www.cocoachina.com/ios/20150602/11968.html

3.3按需加载（UIScrollView方面）：

     开发的过程中，自定义Cell的种类千奇百怪，但Cell本来就是用来显示数据的，不说100%带有图片，也差不多，这个时候就要考虑，下滑的过程中可能会有点卡顿，尤其网络不好的时候，异步加载图片是个程序员都会想到，但是如果给每个循环对象都加上异步加载，开启的线程太多，一样会卡顿，我记得好像线程条数一般3-5条，最多也就6条吧。这个时候利用UIScrollViewDelegate两个代理方法就能很好地解决这个问题。

4.总结

1.提前计算并缓存好高度，因为heightForRow最频繁的调用。

- (UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath;

2.异步绘制，遇到复杂界面，性能瓶颈时，可能是突破口。

3.滑动时按需加载，这个在大量图片展示，网络加载时，很管用。（SDWebImage已经实现异步加载）。

4.重用cells。

5.如果cell内显示得内容来自web，使用异步加载，缓存结果请求。当cell中的部分View是非常独立的，并且不便于重用的，而且“体积”非常小，在内存可控的前提下，我们完全可以将这些view缓存起来。当然也是缓存在模型中。

6.少用或不用透明图层，使用不透明视图。对于不透明的View，设置opaque为YES，这样在绘制该View时，就不需要考虑被View覆盖的其他内容（尽量设置Cell的view为opaque，避免GPU对Cell下面的内容也进行绘制）

7.减少subViews。分析Cell结构，尽可能的将 相同内容的抽取到一种样式Cell中，前面已经提到了Cell的重用机制，这样就能保证UITbaleView要显示多少内容，真正创建出的Cell可能只比屏幕显示的Cell多一点。虽然Cell的’体积’可能会大点，但是因为Cell的数量不会很多，完全可以接受的

8.少用addView给cell动态添加view，可以初始化的时候就添加，然后通过hide控制是否显示。只定义一种Cell，那该如何显示不同类型的内容呢？答案就是，把所有不同类型的view都定义好，放在cell里面，通过hidden显示、隐藏，来显示不同类型的内容。毕竟，在用户快速滑动中，只是单纯的显示、隐藏subview比实时创建要快得多。

其它可参考以下链接：https://www.jianshu.com/p/fdd7eeefdc71