UITableView 性能优化

首先，UITableViewCell的创建是很消耗性能的，所以cell一定要重用，以及上面的各种控件尽可能的重用。

如果用不到就隐藏，别删除留着用。

其次，我们在iOS开发中UITableView的使用频率很高，UITableView使用中tableView:heightForRowAtIndexPath的使用率很高。很多时候感觉卡顿其实就是因为这个函数的执行占用太多的资源（假设你的重用是做好了的）。因为一进入就会计算所有cell的高度，而且以后每次滑到相应的cell的时候还要再次计算cell的高度。所以我们经常在这个函数上会做很多的优化工作。

iOS7提供了一个新的代理函数tableView:estimatedHeightForRowAtIndexPath他会在第一次进入的时候调用，我们可以在这个函数中给每个cell预估一个高度，然后当滑动到相应的cell的时候才会去调用tableView:heightForRowAtIndexPath这样就可以避免第一次就计算所有的cell的高度的问题，尽可能快的加载。

但是这样做会带来一些问题，就是用户没有滑动到全部的cell的话，那么整个tableview的展示高度就是不准确的，因为里面含有你预估的cell高度。所以这个时候，如果使用函数滑动到指定的坐标的时候就会出问题。所以尽量避免这个问题。


可是实现开发中我们是需要兼容iOS6的，所以光是这个方法不行的。
我们给每个cell的数据model（mvc中的m）添加一个height的属性，每次tableView:heightForRowAtIndexPath执行的时候，首先去cell对应的model中拿height值，如果没有就计算然后存进去。这样就可以保证每个cell的高度只会算一遍，以后都只是取值而已。如果你的cell存在展开收缩这种高度会变的情况，在执行完展开的逻辑后先把height属性置空，再去刷新这个cell，就可以保证cell高度的正确性。



优化的思路就是缓存、重用