estimatedHeightForRowAtIndexPath实际上可以更改行的最终"correct"高度吗？

在使用estimatedHeightForRowAtIndexPath 时，我刚刚发现了一个惊人的问题或反直觉行为

（1） 我的桌子排高千差万别。最终结果可以在111到大约400的范围内。

（2） 我绝对完美地计算了每一排的高度。我手头有一个数组，也就是说缓存。

｛请注意，这正是苹果工程师现在建议的……例如，第5点。在UITableView中使用自动布局进行动态单元格布局和可变行高｝

（3） 当heightForRowAtIndexPath要求一个高度时，我会给它绝对正确的高度。

（4） 当我构建细胞时，实际上，我将其构建到正确的高度（如（2）和（3）所示）。

{注意-当然是iOS最终决定了单元格的高度，而不是"我"。}

这一切都很完美

即，每个单元格都是由iOS按照heightForRowAtIndexPath中给定的高度构建的。

现在，我添加代码。。。

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

事实上，该表不再有效。。。。。。。。。。。。。。。。。。行高度变得随机

有人见过这种令人难以置信的行为吗

我做了各种测试，试图确定地狱估计的HeightForRowAtIndexPath的作用之间的关系。起初，我认为它可能会提供一个关于高度的下限。所以，150。。即使我的小细胞也会错误地达到150的高度。但事实并非如此。

我认为它可能会这样做：假设您的估计HeightForRowAtIndexPath值为150。它有时会使用150来表示（事实上）大小等于或小于150的行，但有时会使用heightForRowAtIndexPath的实际大小。

另一方面，如果你为estimatedHeightForRowAtIndexPath输入一个比实际存在的值小的值（在我的例子中是100），它几乎"完全不起作用"，你只会得到细胞上看起来只能是随机高度的值。

非常高的单元格似乎工作正常，可能类似于"如果从heightForRowAtIndexPath开始的高度是估计高度的两倍，那么它确实使用了实际高度"

需要明确的是，它似乎从不让细胞太小，但它经常让细胞太大。

需要明确的是，我不是使用自动布局，这是你只需要构建的单元格类型。（恐怕我不知道自动布局是怎么回事。）这只是Xcode5/iOS7+。

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

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