13

我有一个 TableView，我使用委托方法为每个单元格指定高度tableView:heightForRowAtIndexPath:。

当我旋转视图时，我得到了这个我不太明白的错误。

它不能满足下面的约束并打破它继续。

"<_UIScrollViewAutomaticContentSizeConstraint:0x8e8d040 UITableView:0x9423400.contentHeight{id: 213} == -1568.000000>"

有谁知道发生了什么以及我为什么要打破这个限制？

4

3 回答 3

22

更新：这个问题在 iOS 8 中不再相关，它增加了对自调整单元格的支持。然而，它仍然适用于 iOS 7。

原始答案（iOS 7）：

Greg 的回答肯定对我有用——我需要调试我的 tableView:estimatedHeightForRowAtIndexPath: 方法。我做了一些调试和一些快速实验，以下是我学到的一些东西：

  1. 不要在估计的行方法中使用 UITableViewAutomaticDimension。此常量用于页眉和页脚方法。我想我在阅读文档时没有给予足够的关注 :)更新：UITableViewAutomaticDimension 现在可用于 iOS 8 中的行高，这是自调整单元格功能的一部分。

  2. 估计 1.0 的行高会导致异常：“NSInternalInconsistencyException”，原因：“表视图行高不能为负...””估计小于 1.0 也会产生奇怪的结果。

  3. 估计 2.0 和实际工作正常，没有任何例外（尽管出于优化原因，2.0 可能是一个糟糕的选择 - 你希望尽可能接近实际）。

  4. 仅当估计的行高大于实际行高时，才会发生约束异常。越接近实际，异常发生的可能性就越小。在获得异常之前您的估计可能有多远似乎与几个不同的因素有关：实际行高、行的位置等。

于 2014-05-07T18:31:22.310 回答
12

tl;博士：寻找与您估计的完全不同的实际高度值。或实际值为负或。0

我只花了几分钟调试这个约束异常。我有一个UITableView带有单元格、节页眉和节页脚的单元格。其中每一个都estimatedHeightFor定义了 iOS 7 消息，并返回一个static const值。我删除了单元格、页眉和页脚，一次一个，直到我确定问题来自页脚（如果没有页脚，这并不重要，请继续阅读）。

如果我消除estimatedHeightForFooterInSection:了，异常就消失了。在我heightForFooterInSection:的 中，页脚的高度是一条路径0。当我恢复estimatedHeight消息并消除实际高度为 的代码路径时0，异常也消失了。在异常再次出现之前，我将这个值替换0并22降低到 12。

无论如何，我需要页脚的高度0（我nil从viewForFooterInSection:那种情况下返回）并且我希望能够估计高度（我支持动态文本）。我的解决方案是考虑给我一个0高度的代码路径estimatedHeightForFooterInSection:。一旦我添加了它，异常就消失了。

于 2014-01-02T02:20:38.717 回答
1

尝试调试您的

(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath

执行。在我的情况下，它在极少数情况下返回一个负整数，导致消息显示在我的日志中，并弄乱了我的表格视图的滚动行为。

于 2013-11-10T23:40:47.757 回答