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

Question

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

我正在使用estimatedRowHeightiOS 7中UITableView 的方法,它非常适合快速加载具有5000行可变高度的UITableView.

我的UITableView由50个部分组成.每个部分有100行,高度可变.在开始时我estimatedRowHeight用于快速加载,但在我调用之后scrollToRowAtIndexPath,我的UITableView滚动到错误的偏移量.我可以理解为什么会这样,因为它有一个estimatedRowHeight直到我滚动整个表并且在heightForRowAtIndexPath委托方法中设置了正确的单元格高度.

有解决方案吗

Answer 1

top*_*ide 7

不幸的是,estimatedRowHeight在代码中使用如此低的值时会出现此问题.当你scrollToRowAtIndexPath没有主动计算正确的尺寸时.根本原因是,如果您从第1部分滚动到第2部分,它可以实时计算正确的位置和estimatedRowHeight单元格(如果它是一个相对较新的设备).任何较旧的设备都会被瘫痪,如果你必须处理5000个电池,那么即使是任何新的设备也会如此.

解决问题的可能方法可能是增加estimatedRowHeight常量,这样设备就不必做太多的工作.

我不同意这是'预期'行为 - 这是一个绝对可以并且应该由Apple修复的错误.我在iOS 7问世之后很快就提出了一个雷达(它也以其他方式出现,[点击这里](https://github.com/caoimghgin/TableViewCellWithAutoLayout/issues/13#issuecomment-31854501)关于bug和一些解决方法的讨论).请向Apple提交更多错误报告,以便他们优先解决此问题. (5认同)
不幸的是,这是不正确的.如果是这样的话,`estimatedRowHeight`将不会带来任何好处!要轻松证明这不会发生,请使用行高估计加载表格视图.然后告诉表视图滚动到表视图底部的单元格.你会看到`heightForRowAtIndexPath`不是**,因为它们之间的跳过单元格被调用,如果你检查表视图的`contentOffset`,你会发现它实际上等于`estimatedRowHeight*numberOfCellsSkipped`.很高兴上传一个示例项目,以便您自己轻松验证. (4认同)
是什么让你认为它必须知道从当前滚动位置到你滚动到的位置的实际行高？它可以应用与第一次加载表格视图时使用的完全相同的优化,其中滚动位置位于**任意**任意点 - 表格视图显示可见单元格,并且假设上方和下方的单元格具有估计高度,并基于此适当地定位/调整滚动指示符.然后,当单元格在屏幕上滚动并修改估计值时,滚动指示符位置/大小也会更新. (2认同)
让我把两分钱放进去.当我忘记更新估计的行常数而我的单元布局已经改变时,我也遇到了这个问题.我发现设置更高的值比更低的值更好,例如可能的最大单元格高度.以这种方式,滚动到顶部按预期发生. (2认同)

归档时间：	11 年，9 月前
查看次数：	6833 次
最近记录：	6 年，9 月前