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,异常也消失了。在异常再次出现之前,我将这个值替换022降低到 12。

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

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

尝试调试您的

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

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

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