heightForRowAtIndexPath和UITableView scrollToBottom的初始负载性能较差

Question

我有一个UITableView，它通过适当的机制(使用FetchedResultsController等)从CoreData读取信息。此信息要么是文本信息，要么是要加载到表视图中的本地图像的URL。

数据需要以自下而上的方式填充到表中(类似于消息应用程序)。我的目标是iOS 8+，但是如果我使用estimatedHeightForRowAtIndexPath，我会在3+多行标签和图像上感到可怕的混乱。除非是一行UILabel，否则估计值似乎太远了。我的预感是，细胞高度是以自上而下的方式来估计的，因此细胞高度从细胞的顶端到细胞的底部都在增长。这意味着从上到下滚动是很好的，但是自下而上不是，因为当我向上滚动时，单元格正在被“向下”调整。

我目前正在使用heightForRowAtIndexPath计算单元格高度。这方面的问题是，视图最初加载需要很长时间，因为所有单元格高度都是一次性计算的。我使用单元格高度缓存来存储单元格高度，这样一旦视图加载，滚动就会非常平滑。

，所以我的问题是：如何使用heightForRowAtIndexPath而不受3-5秒的初始负载的影响？

接下来还有一个额外的问题:当你的细胞高度有很大不同时，是否有可靠地使用estimatedHeightForRowAtIndexPath的方法？我们说的是从44便士到300便士。根据我所读到的，在这种情况下，我根本不能使用estimatedHeight计算。

我已经用尽了所有关于估计heightForRowAtIndexPath的堆叠溢出帖子，现在我开始不止一次地查看相同的帖子。所以我卡住了。

Answer 1

为什么会在表中填充几行以填充可见区域，并且在viewDidAppear开始在表的顶部填充一到两个旧消息时，使用动画“无”、“自动”或其他任何内容。这样，随着uitableview人群的推迟，我认为你会得到一个不错的表现。

或者你也可以用skype的方式来做，用旧的信息来推迟表格的填充，直到表从最上面的边缘反弹出来。