在使用estimatedHeightForRowAtIndexPath 时，我刚刚发现了一个令人震惊的问题或违反直觉的行为
(1) 我的桌子的行高变化很大。最终结果的范围可以从 111 到大约 400。
(2) 我绝对完美地计算了每一行的高度。我手头有这些数组，也就是说缓存。
{请注意，这正是 Apple 工程师现在推荐的……例如，第 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 来表示行（实际上（）证明是该大小或更小，但有时它适用于 heightForRowAtIndexPath 的实际大小。
另一方面，如果你输入一个比实际存在的值更小的estimatedHeightForRowAtIndexPath 值（在我的例子中说100），它几乎“完全不起作用”，你只会得到看起来只能是随机高度的值细胞。
非常高的单元格似乎可以正常工作，可能类似于“如果 heightForRowAtIndexPath 的高度是估计值的两倍，那么它确实使用实际高度”
需要明确的是，它似乎永远不会使细胞变得太小，但它经常使它们变得太大。
需要明确的是，我没有使用自动布局，它是您必须构建的单元格类型。（恐怕我不知道这与自动布局有什么关系。）这只是 Xcode5/iOS7+。