UITableViewCell复用与高度计算

UITableViewCell的重用机制

为了减少内存开销，UITableView只会创建一屏幕（或一屏幕多一点）的UITableViewCell，当Cell滑出屏幕时，就会放入到一个集合（或数组）中（这里就相当于一个重用池），当要显示某一位置的Cell时，会先去集合（或数组）中取，如果有，就直接拿来显示；如果没有，才会创建。

UITableView最主要的两个回调方法是：

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

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath

UITableView继承自UIScrollView，要先确定它的contentSize及每个Cell的位置，然后才把重用的Cell放置到对应的位置。所以UITableView的回调顺序是先多次调用tableView:heightForRowAtIndexPath:以确定contentSize及Cell的位置，然后才会调用tableView:cellForRowAtIndexPath:，从而来显示在当前屏幕的Cell。
例：要显示100个Cell，当前屏幕显示5个。
刷新（reload）UITableView，先调用100次tableView:heightForRowAtIndexPath:方法，然后调用5次tableView:cellForRowAtIndexPath:方法；
滚动屏幕时，每当Cell滚入屏幕，都会调用一次tableView:heightForRowAtIndexPath:、tableView:cellForRowAtIndexPath:方法。

TableViewCell的高度计算

1、固定高度
针对所有Cell具有固定高度的情况，通过：

self.tableView.rowHeight = 88;

上面的代码指定了一个所有cell都是88高度的UITableView，对于定高需求的表格，强烈建议使用这种（而非下面的）方式保证不必要的高度计算和调用。rowHeight属性的默认值是44

2、动态高度
另一种方式就是实现UITableViewDelegate中的：

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
    // return xxx
}

需要注意的是，实现了这个方法后，rowHeight的设置将无效。这个方法适用于具有多种cell高度的UITableView。

3、估算高度
UITableView是个UIScrollView，就像平时使用UIScrollView一样，加载时指定contentSize后它才能根据自己的bounds、contentInset、contentOffset等属性共同决定是否可以滑动以及滚动条的长度。而UITableView在一开始并不知道自己会被填充多少内容，于是询问dataSource个数和创建cell，同时询问delegate这些cell应该显示的高度，这就造成它在加载的时候浪费了多余的计算在屏幕外边的cell上。和上面的rowHeight很类似，设置这个估算高度有两种方法：

self.tableView.estimatedRowHeight = 88;
// or
- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
    // return xxx
}

即使面对种类不同的cell，依然可以使用estimatedRowHeight属性赋值，只要整体估算值接近就可以，比如大概有一半cell高度是44，一半cell高度是88，那就可以估算一个66，基本符合预期。

iOS8的算高机制

相同的代码在iOS7和iOS8上滑动顺畅程度完全不同，iOS8莫名奇妙的卡。很大一部分原因是iOS8上的算高机制大不相同。
研究后发现这么多次额外计算有下面的原因：

不开启高度估算时，UITableView上来就要对所有cell调用算高来确定contentSize。
dequeueReusableCellWithIdentifier:forIndexPath: 相比不带“forIndexPath”的版本会多调用一次高度计算。
iOS7计算高度后有“缓存”机制，不会重复计算；而iOS8不论何时都会重新计算cell高度。
iOS8把高度计算搞成这个样子，从WWDC也倒是能找到点解释，cell被认为随时都可能改变高度（如从设置中调整动态字体大小），所以每次滑动出来后都要重新计算高度。

UITableView优化

主要从三个方面入手：

提前计算并缓存好高度（布局），因为heightForRowAtIndexPath:是调用最频繁的方法；
异步绘制，遇到复杂界面，遇到性能瓶颈时，可能就是突破口；
滑动时按需加载，这个在大量图片展示，网络加载的时候很管用！（SDWebImage已经实现异步加载，配合这条性能杠杠的）。

一些熟知的优化点：

正确使用reuseIdentifier来重用Cells
尽量使所有的view opaque，包括Cell自身
尽量少用或不用透明图层
如果Cell内现实的内容来自web，使用异步加载，缓存请求结果
减少subviews的数量
在heightForRowAtIndexPath:中尽量不使用cellForRowAtIndexPath:，如果你需要用到它，只用一次然后缓存结果
尽量少用addView给Cell动态添加View，可以初始化时就添加，然后通过hide来控制是否显示。

当我们在cellForRowAtIndexPath中创建自定义的tableViewCell时，为什么cell的高度总是44？
我们在tableView:cellForRowAtIndexPath:中创建的tableViewCell默认的高度是44；虽然tableView:heightForRowAtIndexPath:中返回了高度，但是这个时候cell并没有渲染到tableView上，所以只有在tableViewCell被渲染后，才能拿到tableView:heightForRowAtIndexPath:中返回到高度。
因此，我们在tableViewCell的drawRect或layoutSubViews方法中获取到cell的高度。当cell被渲染之后，高度变成了tableView:heightForRowAtIndexPath:中返回的值，这时候即便是复用，也能在tableView:cellForRowAtIndexPath:拿到正确的高度。