问UITableView scrollToRowAtIndexPath在iOS 7上使用estimatedRowHeight滚动到错误的偏移量

EN

不幸的是，当您的代码中使用estimatedRowHeight的值如此之低时，这个问题是意料之中的。当你计算时，它不会主动计算的正确大小。潜在的原因是，如果你从第一部分滚动到第二部分，如果它是一个相对较新的设备，它可以很容易地计算出单元的正确位置和estimatedRowHeight。任何较旧的设备都会瘫痪，例如，如果您必须处理5000个单元，那么即使是任何新的设备也是如此。

你的问题的一个可能的解决方案可能是增加estimatedRowHeight常量，这样设备就不需要做太多的工作。

当调用scrollToRowAtIndexPath时，不计算所有单元格的高度b/w当前位置和目标偏移量。只有他们中的一些人是。

相反，UITableView使用estimatedRowHeight计算目标偏移量，这会导致错误的偏移量。

我正面临着同样的问题，我发现了一个小技巧(我真的不喜欢)，在初始relaodData之后只计算一次确切的单元格高度。我在下面插入了两行：

tableView.reloadData()

// only for the initial reloadData

let numSections = tableView.numberOfSections
let numRowsInLastSection = tableView.numberOfRowsInSection(numSections-1)

// scrolls to the last row in the tableView
tableView.scrollToRowAtIndexPath(NSIndexPath(forRow: numRows-1, inSection: numSections-1), atScrollPosition: .Bottom, animated: false)

// back again to the original position(which is 0 for this is only called right after the initial reloadData)
tableView.scrollToRowAtIndexPath(NSIndexPath(forRow: 0, inSection: 0), atScrollPosition: .Top, animated: false)

这会导致tableView延迟出现在屏幕上，但我认为这是可以接受的，而不是在tableView出现后冻结UI。在开始调用API时甚至更好，因为它感觉像是网络上的一个小延迟，而不是UI延迟。

在此之后，tableView跳转到单元格的确切位置。

是的，我也不太喜欢这个解决方案:|

编辑：

我这样做的唯一原因是通过调用cellForRowAtIndexPath:来计算实际的行高度，但我发现，当通过委托方法estimatedHeightForRowAtIndexPath:为每一行提供适当的estimatedHeight而不是将静态值提供给UITableView.estimatedRowHeight时，就解决了这个问题。

我最后做的是将行的高度从willDisplayCell:forRowAtIndexPath:缓存到磁盘，并在estimatedHeightForRowAtIndexPath:上使用该值。

通过这样做，所有行的estimatedHeightForRowAtIndexPath:都会在开始时被调用，并且scrollToRowAtIndexPath可以很好地工作。

这不是最好的解决方案，但我使用了一个变通方法来解决这个问题。始终将estimatedRowHeight更新为最高的计算单元格，然后使用类似以下内容：

1. 将tableView的内容滚动到偏移量为零。
2. 通过调用scrollToRowAtIndexPath来索引路径零来完成。

CGPointZero:CGPointZero零动画:是；dispatch_after(dispatch_time(DISPATCH_TIME_NOW，(int64_t)(0.2 * NSEC_PER_SEC))，dispatch_get_main_queue()，^{ [self.tableView scrollToRowAtIndexPath:NSIndexPath indexPathForRow:0 inSection:0 atScrollPosition:UITableViewScrollPositionTop animated:YES]；});

因此，tableView应该会非常平滑地滚动到顶部。