在执行问题之前,是否为所有行调用了heightForRowAtIndexPath以及UITableView中的行数?

Gre*_*reg 11 iphone uitableview ios heightforrowatindexpath

我以为我已经读到了UITableView那个heightForRowAtIndexPath不会被调用的所有行,但只对那些将是可见的.然而,这不是我所看到的.我正在看到数以百计的调用heightForRowAtIndexPath,例如iPhone的方向改变的简单情况.

所以我在此假设,因此,对于UITableViewheightForRowAtIndexPath实施,它(即heightForRowAtIndexPath)被调用的所有行(不只是那些可见的)...让我知道这是不太正确的.

问题:鉴于上述情况,在性能问题发生之前,您可以拥有多少行UITableView(在哪里heightForRowAtIndexPath实现)?

有没有解决性能问题的方法?即设置每行的标称/标准高度而不实现heightForRowAtIndexPath,但是只有在显示时才正确设置每一行高度并在此处正确设置...但是哪种方法可以做到这一点?

Mat*_*uch 8

请查看文档中的讨论部分tableView:heightForRowAtIndexPath:

该方法允许委托指定具有不同高度的行.如果实现此方法,则它返回的值将覆盖为给定行为UITableView的rowHeight属性指定的值.

使用tableView:heightForRowAtIndexPath:而不是rowHeight属性有性能影响.每次显示表视图时,它会在其每个行的委托上调用tableView:heightForRowAtIndexPath:这会导致具有大量行(大约1000或更多)的表视图出现严重的性能问题.

所以你应该使用rowHeightUITableView 的属性.如果你需要不同的高度,那你就不得不用了tableView:heightForRowAtIndexPath:.

AFAIK无法在显示时更改行高.
tableview必须知道之前的正确大小,否则会一直存在丑陋的位置变化.

  • 实际上,我并不完全确定他们能解决它.出于完全不同的原因,我开始开发自己的自定义tableView,旨在重新创建Apple的功能并添加我自己的功能.我很快意识到我必须知道所有细胞的高度才能使其发挥作用.因为你无法预测表的位置(它可以以编程方式跳转),所以你必须准备好在任何位置布局视图,这意味着你必须知道所有的高度.唯一的选择是计算每个布局的所有先前高度,这将是非常昂贵的. (2认同)