ios8 单元格约束在添加披露指示器时中断

Question

我在 IOS8 上的自动布局有问题，我可以重新创建的最简单的情况是一个简单的 tableView。我设置了一个静态单元格，然后简单地添加一个标签。

我的目标是让标签在很大程度上填满空间，所以我对标签有三个约束......

1. 在超级视图中垂直居中（我认为这很好）
2. 将标签尾边距设置为 30（相对于 superview）
3. 将标签前导边距设置为 30（相对于 superview）

这一切都很好，完美运行，没有重大问题或警告（它确实警告零高度，但我认为这不是什么大问题）

现在......如果我添加一个披露指标，它就会崩溃。它看起来仍然不错，但我得到以下信息：

2014-10-30 15:51:46.358 ContraintIssue[25572:1586028] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. 
Try this: 
(1) look at each constraint and try to figure out which you don't expect; 
(2) find the code that added the unwanted constraint or constraints and fix it. 
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, 
refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) 
(
    "<NSLayoutConstraint:0x7fd3f3d23390 UITableViewCellContentView:0x7fd3f3d226f0.trailingMargin == UILabel:0x7fd3f3d227e0'Label'.trailing + 30>",
    "<NSLayoutConstraint:0x7fd3f3d235f0 UILabel:0x7fd3f3d227e0'Label'.leading == UITableViewCellContentView:0x7fd3f3d226f0.leadingMargin + 30>",
    "<NSLayoutConstraint:0x7fd3f53b73b0 'fittingSizeHTarget' H:[UITableViewCellContentView:0x7fd3f3d226f0(38)]>"
)

Will attempt to recover by breaking constraint 
<NSLayoutConstraint:0x7fd3f3d23390 UITableViewCellContentView:0x7fd3f3d226f0.trailingMargin == UILabel:0x7fd3f3d227e0'Label'.trailing + 30>

我不明白为什么添加指标会导致这样的问题，这与数字的规模无关，我已经尝试了很多。

有什么想法吗？

现实世界的例子是一个单元格，它有一个标签（标签），然后是另一个标签或一个包含可以通过遵循公开设置的值的文本视图。所以第一个标签的大小是固定的，理想情况下，第二个标签应该是最大的，但如果需要，可以截断文本。

（请参阅添加联系人中的“铃声”或“振动设置”，了解我想要实现的目标）

非常感谢，

李。

Answer 1

我也遇到了同样的问题。我想在左侧布局一个图像视图，其右侧有一个标签，该标签填充图像视图和超级视图的右（或尾随）边界之间的空间（这是单元格的内容视图）。附件视图也设置为披露指示器。 与您的情况一样，所有基于 H 的约束和我在 fittingSizeHTarget 的日志中发现的一个冲突约束。我不知道这是什么意思，也不知道这是从哪里来的，但我在这里找到了你的帖子。

以下内容对我有用：

降低标签尾随到超级视图约束的优先级。 （我选择了 990）。

我假设，由于某种原因，布局系统（显示指示符可见）不能再满足所有约束，所以它打破了一个。但是，如果您降低优先级，它仍然会尝试满足约束，但不会破坏它，因为冲突的约束具有更高的优先级。

希望这也能解决您的问题。

Answer 2

请注意斯蒂芬在赞成的答案的评论部分所说的话。赞成的答案是有些正确，但重要的是要理解为什么它应该只在某些情况下使用。

优先级通常用在元素 A 有一个约束说高度等于或小于/大于 300，元素 B 有一个说高度等于或小于/大于 500 的上下文中。然后自动布局可以满足这两个条件基于他们的优先事项。

在这个特定示例中，两个约束都设置为特定值，并且降低优先级本质上是在无法满足时忽略该约束（没有“部分忽略它”）。 然而 UILabel 有一个例外 - 默认 UILabel 行为是调整自身大小以适应内容，除非它受到额外边距的约束（自动大小约束隐藏在fittingSizeHTarget 名称下），并且此行为有时会显示错误警告。实际上，此约束将在运行时被忽略，但在内部禁用之前，它会发出警告。因此，即使我们通过降低其优先级（我们将优先级设置为 900 的那个）来告知忽略其中一个约束，由于 autosize 约束将在运行时被忽略，我们的 900 优先级将被应用并满足。

Answer 3

Raimunda 的上述回答解释了标签、按钮等上发生的内在尺寸，即该 FittingSizeHTarget 日志的来源。虽然您可以离开它并让系统处理它，但这是一种冒险的黑客行为，因为您依靠系统来打破不需要的约束……这在未来的版本中可能不会这样做。在某些情况下，就像我最近处理的一个视图示例一样，将尾随约束的优先级降低到外部安全区域并不能防止标签溢出（但是，它确实修复了日志警告哈哈）。

对于此类内容问题，请使用 Content Hugging Priority 和 Content Compression Resistance Priority 值。例如，如果您知道您的标签将要增加垂直高度但限制为水平值，则使垂直内容拥抱优先级（内容拥抱 = 抵抗变大的视图）低于水平。

抗压性与此相反。

然后将您的外部尾随约束设置为大于或等于，您就可以开始了。

在下面的堆栈视图中，标题为 Fake 4 的标签实际上超出了，想变成两行。这导致了涉及fittingSizeHTarget 的冲突（内在内容大小希望保持在一行并超出视图宽度）。这里的关键是将水平抗压优先级降低到低于所有其他内容优先级。这使我可以降低 >= 约束对尾随值的优先级，并且一切都按预期运行。

无论如何，调整这些东西是很烦人的，但是那些 Hugging/Compression 值，结合某种形式的 >= /

希望这会有所帮助。