多次调用估计的HeightForRowAtIndexPath 导致不稳定的uitableview

Posted 2023-02-27

【中文标题】多次调用估计的HeightForRowAtIndexPath 导致不稳定的uitableview

【英文标题】：estimatedHeightForRowAtIndexPath called many times resulting in jerky uitableview

【发布时间】：2016-01-22 18:26:56

【问题描述】：

我在一个应用程序中有一个要求，其中几乎每个 uitableviewcell 都具有不同的高度。此外，许多单元格都有带文本的图像（1,2 或 3）。

之前我使用的是 heightForRowAtIndexpath，但和往常一样，性能非常可悲，感觉很生涩，

我做了以下来解决这个问题，

已实现 estimatedHeightForRowAtIndexPath 使用缓存来计算高度，以便后续调用estimatedHeightForRowAtIndexPath 在所有单元格中使用自动布局。

与以前的方法相比，性能要好得多， 但是，estimatedHeightForRowAtIndexPath 随后被调用了很多次，因此列表很不稳定。

如果单元格编号 N 被加载，estimatedHeightForRowAtIndexPath 被调用 N-1 次，如果我们在列表中更进一步就会发生这种情况，如果我们往回走，它就会知道估计的高度。

请帮助我了解为什么会发生这种情况，以及我可以做些什么来提高性能并让滚动更流畅。

【参考方案1】：

为了让桌子光滑，我使用了这个策略..

每当我填充我的 tableView 数据源时，我都会计算每个单元格的高度。我将每个单元格的高度存储在一个数组中cellHeights 在heightforRowAtIndexPath，我返回cellHeights[indexPath.row]

由此产生的过渡一直非常平滑:)

【讨论】：

同意，但我想，最好完全依赖自动布局来实现可重用性和灵活布局。

【参考方案2】：

与其责怪框架“过于频繁地”向你发送消息，你应该责怪自己的代码响应速度不够快。你说：

之前我使用 heightForRowAtIndexpath，但像往常一样，性能非常可悲，感觉很生涩

但是你的“像往常一样”是错误的。如果你不能从heightForRowAtIndexPath:立即返回结果，那么你这个方法的实现是错误的。您应该“记忆”您的高度计算，以便在计算一次行的高度之后，您知道它的高度永远不会。

【讨论】：

好吧，我根本不使用'heightforrow...' 如果我们想完全依赖自动布局，我们不应该这样做。估计高度专门用于摆脱明确计算高度。正如我所说，我的单元格高度不断变化，并且有许多带有图像和文本的子视图。此外，我的问题与“为什么它调用这么多次”有关，因为这是罪魁祸首，它会产生生涩的行为。一旦所有的高度都已知，桌面视图就会像黄油一样光滑。