iOS-谈谈UITableView中estimatedRowHeight到底该不该禁用

Providing a nonnegative estimate of the height of rows can improve the performance of loading the table view. If the table contains variable height rows, it might be expensive to calculate all their heights when the table loads. Using estimation allows you to defer some of the cost of geometry calculation from load time to scrolling time.

大意是启用这个属性可以提升性能。
因为他把一些计算成本从加载时延迟到滚动时。

具体是什么计算？答案是contentSize属性、开启预估之后TableView会在滚动时获取cell实际的高度、并且修改contentSize值。

这个影响主要在两方面：视觉方面、代码方面。

视觉方面

滑动时右侧滑动条、会有一些长短变化以及些许抖动。
这个很容易理解。毕竟总rect发生了变化、滑动条自然需要发生变化。

代码方面

这才是我们关心的重点

1. 禁用预估功能

tableView会每次都读取所有indexPath的heightForRowAtIndexPath进行行高计算。

这就是文档中影响应能的主要原因所在(~~其他原因我并没发现。。~~）

2. 开启预估功能

TableView的contentSize值以及rectForSection方法返回的rect也为预估值。只有当你划过所有的cell、才会得到真实的值。

但是如果你的cell高度与预估的差太多、在contentoffset偏移很大的情况下直接reload会出现cell展示偏移的情况。(~~虽然我测试起来差二倍以内不会出现什么问题~~)

如果cell差别过大。你也可以使用tableView:estimatedHeightForRowAtIndexPath:来单独设置、或者insertRowsAtIndexPaths这种方式来添加新的cell。但是后者实在麻烦。

想说什么

iOS11之前是为0、在iOS11下、这个值默认为44。

代码里创建TableView的时候经常copy代码、由于某些SDK的原因、经常出现以下代码：

if (@available(iOS 11.0, *)) {
    tableView.estimatedRowHeight = 0;
    tableView.estimatedSectionFooterHeight = 0;
    tableView.estimatedSectionHeaderHeight = 0;
}

而这、恰恰会会影响到性能。

至于刚才所说的需要我们这样设置的SDK、按网上来看目前是以MJRefresh为主。但好在现在已经修复了这个bug。

结论、到底该不该禁用呢

1. 如果你可以很好的控制cell高度

启用吧、对性能有好处。起码会剩下几十次计算

2. 如果你没办法很好的控制cell高度(比如有展开啊什么乱七八糟的)

禁了吧、否则加载更多的时候直接reload有可能会出问题。
如果你非要启用、最好自己按照阀值测试效果再决定。

然后安利一下相关的东西《iOS-谈一谈自适应Cell的高度缓存》没准对你有帮助呢

最后

本文主要是自己的学习与总结。如果文内存在纰漏、万望留言斧正。如果愿意补充以及不吝赐教小弟会更加感激。