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