ios-tableView的行高计算

如果我们设置了预估的行高也就是

tableView.estimatedRowHeight = 200

以及实现了计算行高的方法

-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
    NSLog(@"%d",indexPath.row);
    return 200;
    
}

这样的话，当前显示的行高会被调用2次的

如果我们没有设置预估的行高，就会把多个cell的行高算三遍。然后再算进入屏幕范围的Cell的高度，就比如说我们屏幕显示有四个cell

当第5个cell从屏幕外面出现的时候会去调用获取行高的方法。

为什么要调用这么多次的计算行高的方法，那是因为UITableView继承自UIScrollView，所以需要去计算个contentSize

我们都知道如果scrollView没有contentSize是滚动不了的，所以没有预估行高的话就会多去调用计算行高的方法

如果我们设置了预估行高，如果设置的预估行高不同，计算几个cell的行高的数量也就不同。

我们设置了预估行高，就会使用预估的行高去计算出预估的contentSize。

计算行高的次数就会根据我们设定的预估行高的值来决定。

如果我们设置的预估行高比较小的话，那就会算的次数多一点，会顺序的去计算，然后再去更新contentSize。

就比如说我们这里设置预估行高为10，计算行高的方法就去调用了60多次

 self.tableView.estimatedRowHeight=10;

如果预估的行高比较大的话，就会去计算当前显示cell的行高方法

如果我们使用预估行高，每个cell显示之前要去计算，相对于单个Cell来说效率比较低，但是如果有多个Cell的话效率是高的。

因为如果我们没有使用预估行高的话，会一下子算出很多来，这样的话我们就需要等待的时候比较长，而且用户也不一定会去点到那么多行。

设置了预估行高的话，行高，cell 和计算行数的执行顺序分别是 行数 -> Cell ->行高

如果没有设置预估行高的话，就是行数 -> 行高 ->cell

如果行高是固定值，我们就不要去实现行高的代理方法，因为行高的代理方法会被调用很多次，而行高如果是固定的，就没有必要去调用很多次，这样会影响性能