estimatedHeightForRowAtIndexPath实际上可以改变一行的最终“正确”高度吗?

时间:2013-11-27 09:31:55

标签: ios uitableview ios7 heightforrowatindexpath

使用estimatedHeightForRowAtIndexPath

时,我刚刚发现了一个惊人的问题或反直觉行为

(1)我的桌子行高度差异很大。最终结果可以在111到约400之间。

(2)我绝对完美地计算每一行的高度。我手头有一个数组,也就是缓存。

{请注意,这正是Apple工程师现在推荐的......例如,第5点...... Using Auto Layout in UITableView for dynamic cell layouts & variable row heights}

(3)当heightForRowAtIndexPath要求高度时,我确实给它绝对正确的高度。

(4)当我构建单元格时,实际上,我将其构建到正确的高度(如(2)和(3)中所示)。

{注意 - 当然iOS最终会调​​整单元格的高度,而不是“我”。}

这一切都完美无缺。

即,每个单元格都是由iOS构建的,其高度恰好是heightForRowAtIndexPath中给出的高度。

现在,我添加代码......

-(CGFloat)tableView:(UITableView *)tableView
    estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return 120;
}

事实上,桌子没有工作..................行高成为随从!!!

有没有人看到这种令人难以置信的行为?

我做了各种各样的测试,试图确定地狱估计的HeightForRowAtIndexPath的作用。起初,我认为它可能提供高度的下限。所以,150 ..甚至我的小细胞都会错误地达到150高度。但事实并非如此。

我认为它可能会做这样的事情:说你的estimatedHeightForRowAtIndexPath值是150.它有时使用150行(事实上()实际证明是那个大小或更小,但有时它是从实际大小到heightForRowAtIndexPath。

另一方面,如果你为estimatedHeightForRowAtIndexPath设置了一个比实际存在的更小的值(在我的例子中说是100),它几乎“完全不起作用”你只是得到了似乎只是细胞上的随机高度。

非常高的细胞似乎正常工作,也许类似“如果从heightForRowAtIndexPath的高度是估计的两倍,那么它确实使用真实高度”

要明确的是,它似乎永远不会使细胞太小,但它往往使它们太大。

要明确的是,我使用autolayout,它是您必须构建的单元格类型。 (我担心我不知道自动布局如何。)这只是Xcode5 / iOS7 +。

2 个答案:

答案 0 :(得分:18)

更新了答案

经过进一步调查后,结果显示“它只需要自动布局”不正确。这是我的示例代码,需要自动布局。我在DynamicHeightCell进行了一些修改,现在可以使用或不使用自动布局。

原始答案

它只需要自动布局。这并不奇怪,但是应该完全记录下来。

这是一个展示tableView:estimatedHeightForRowAtIndexPath:正常使用自动布局的工作项目。如果在故事板中关闭“自动布局”,则其行为与您所描述的相同。

Estimated Row Height Demo

答案 1 :(得分:1)

- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath { }

当您拥有大量动态单元格时,通常会使用此委托方法,这样可以粗略估计单元格。

例如:如果您有100个单元格,每个单元格的高度范围为200到300(例如201,207,250,299,300 ......),您可以估计单元格高度约为250.即

- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
return 250;
}
  • 提供估计行的高度可以改善加载表视图时的用户体验。
  • 如果此代表未实施,计算所有高度可能会很昂贵,从而导致更长的加载时间。
相关问题