ios 奇怪的 UIView-Encapsulated-Layout-Height 错误

Strange UIView-Encapsulated-Layout-Height Error

提问by Zaporozhchenko Oleksandr

I'm making test application, so in my tableviewCell in storyboard I have imageView& webView(webview to show html-text).

我正在制作测试应用程序，因此在故事板的 tableviewCell 中，我有imageView和webView（显示 html 文本的 webview）。

I set constraints like top/left/right/height=200 for imageView, spacing=5 between them & left/right/bot for webView, so I want to calculate my webViewheight programmatically and then change cell's height to stretch my webView. But I got this :

我为imageView设置了像 top/left/right/height=200 这样的约束，它们之间的间距=5 和webView 的left/right/bot ，所以我想以编程方式计算我的webView高度，然后更改单元格的高度以拉伸我的webView。但我得到了这个：

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 & fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property

    translatesAutoresizingMaskIntoConstraints) 
    (
        "<NSLayoutConstraint:0x7fd6f3773f90 V:[UIImageView:0x7fd6f3773e90(200)]>",
        "<NSLayoutConstraint:0x7fd6f3774280 UIImageView:0x7fd6f3773e90.top == UITableViewCellContentView:0x7fd6f3462710.topMargin>",
        "<NSLayoutConstraint:0x7fd6f3774320 V:[UIImageView:0x7fd6f3773e90]-(5)-[UIWebView:0x7fd6f3462800]>",
        "<NSLayoutConstraint:0x7fd6f3774370 UITableViewCellContentView:0x7fd6f3462710.bottomMargin == UIWebView:0x7fd6f3462800.bottom>",
        "<NSLayoutConstraint:0x7fd6f375ee40 'UIView-Encapsulated-Layout-Height' V:[UITableViewCellContentView:0x7fd6f3462710(205)]>"
    )

Any suggestions?

有什么建议？

回答by Fran Sevillano

I usually remove this warning by lowering the priority of the constraint that AutoLayoutis trying to break. So if it says:

我通常通过降低AutoLayout试图打破的约束的优先级来消除这个警告。所以如果它说：

Will attempt to recover by breaking constraint 
<NSLayoutConstraint:0x7fd7c2ecb520 V:[UIView:0x7fd7c2ecd0e0(300)]>

Go ahead and lower that one's priority to 999.

继续并将其优先级降低到999。

That should work.

那应该工作。

Cheers.

干杯。

回答by Paul T.

if you use tableView.rowHeight = UITableViewAutomaticDimension, you should always set estimatedRowHeight. For example:

如果使用tableView.rowHeight = UITableViewAutomaticDimension，则应始终设置estimatedRowHeight。例如：

tableView.estimatedRowHeight = 44

or you should implement:

或者你应该实施：

func tableView(tableView: UITableView, estimatedHeightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat

otherwise you will always get the warning UIView-Encapsulated-Layout-Height' V:[UITableViewCellContentViewand the content will be collapsed in a wrong way

否则你总是会收到警告UIView-Encapsulated-Layout-Height' V:[UITableViewCellContentView并且内容会以错误的方式折叠

回答by superarts.org

For me I use estimated height for cells, and to solve this problem, I set the priority of the constraint from label bottom to it's neighbor to 999 and it worked.

对我来说，我使用单元格的估计高度，为了解决这个问题，我将约束的优先级设置为从标签底部到它的邻居到 999 并且它起作用了。

回答by u1389917

The following piece of code not worked for me

以下代码对我不起作用

func tableView(_ tableView: UITableView, estimatedHeightForRowAt indexPath: IndexPath) -> CGFloat {
        return 100
    }

func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
        return UITableViewAutomaticDimension
    }

Neither add translatesAutoresizingMaskIntoConstraints=false to a bunch of views.

既不添加 translatesAutoresizingMaskIntoConstraints=false 到一堆视图。

Finally, Removing cell.updateConstraintsIfNeeded()in datasource callback function tableView:cellForRowAtmakes Xcode content

最后，cell.updateConstraintsIfNeeded()在数据源回调函数中RemovingtableView:cellForRowAt使Xcode内容

回答by ngobw

Sorry that I'm late to the game. :)

对不起，我玩游戏迟到了。:)

Lowering the priority of the constraint that Autolayout is trying to break might not be the solution if the constraint is required in the first place.

如果首先需要约束，降低 Autolayout 试图打破的约束的优先级可能不是解决方案。

I had this issue the other day, here's what my layout looked like:

前几天我遇到了这个问题，这是我的布局：

• OuterView <-- C1: A width constraint equal to it's superview
  • StackView <-- C2: A width constraint equal to the OuterView
    • ChildView <-- C3: A fixed width constraint, constant = StackView.frame.size.width

• OuterView <-- C1：宽度约束等于它的超级视图
  • StackView <-- C2：宽度约束等于 OuterView
    • ChildView <-- C3：固定宽度约束，常量 = StackView.frame.size.width

The issue happened when I was reducing the width of C1, so obviously because C3 was on a fixed width that took the original frame size, reducing C1 caused conflicts and C1 was broken by iOS to fix the issue.

问题发生在我减小 C1 的宽度时，很明显，因为 C3 处于固定宽度，采用原始帧大小，减小 C1 导致冲突，C1 被 iOS 打破以解决问题。

Issue was quickly fixed by setting C3 to take StackView's widthAnchor instead of its frame size.

通过将 C3 设置为采用 StackView 的 widthAnchor 而不是其框架大小，问题很快得到解决。

Wrong Constraint

错误的约束

view.widthAnchor.constraint(equalToConstant: stackView.frame.size.width).isActive = true

view.widthAnchor.constraint(equalToConstant: stackView.frame.size.width).isActive = true

Right Constraint

右约束

view.widthAnchor.constraint(equalTo: stackView.widthAnchor, multiplier: 1.0).isActive = true

view.widthAnchor.constraint(equalTo: stackView.widthAnchor, multiplier: 1.0).isActive = true

This way, whenever C1 changes, all child constraints will react to it accordingly.

这样，每当 C1 更改时，所有子约束都会对其做出相应的反应。

Conclusion:

结论：

1. I do not think this error was a bug as stated by some.
2. Resolving by adjusting the priority works, but is that the intended result you wanted?
3. If you are determined to resolve it without priority, look at your constraints, especially those set programmatically, to check for conflicts. If you are dealing with dynamic width or height for your views such as cell views, make sure the parent view's height or width constraint do not conflict with these dynamic changes and just keep working upwards.

1. 我不认为这个错误是某些人所说的错误。
2. 通过调整优先级来解决问题，但这是您想要的预期结果吗？
3. 如果您决定不优先解决它，请查看您的约束，尤其是那些以编程方式设置的约束，以检查冲突。如果您正在处理视图（例如单元格视图）的动态宽度或高度，请确保父视图的高度或宽度约束与这些动态更改不冲突，并继续向上工作。

回答by John Stephen

I've seen two cases where this happens so far. One is documented in the accepted answer, which is that your tableView:heightForRow: implementation must return the same value your constraints will compute to.

到目前为止，我已经看到了两个发生这种情况的案例。一个记录在接受的答案中，即您的 tableView:heightForRow: 实现必须返回您的约束将计算到的相同值。

The other time this happens is if you forget to set translatesAutoresizingMaskIntoConstraints = NO (or false for Swift) on one or more autolayout views. Before adding constraints to a programmatically created view, turn off autoresizing like this:

另一种情况是，如果您忘记在一个或多个自动布局视图上设置 translatesAutoresizingMaskIntoConstraints = NO（或 Swift 为 false）。在向以编程方式创建的视图添加约束之前，请像这样关闭自动调整大小：

view.translatesAutoresizingMaskIntoConstraints = false

Otherwise, if your view has a fixed width or height specified by the autoresizing mask then a constraint will be created to enforce it.

否则，如果您的视图具有由自动调整大小掩码指定的固定宽度或高度，则将创建一个约束来强制执行它。

回答by DevAndArtist

I run today into this problem. I had one collection view on the screen but that was not the issue. I was using a custom container view controller and some views were layed-out before the container view itself was layed-out. The trick was to ensure that the container view was layed-out first by calling loadViewIfNeeded()on the container view controller.

我今天遇到了这个问题。我在屏幕上有一个集合视图，但这不是问题。我正在使用自定义容器视图控制器，并且在布局容器视图本身之前布局了一些视图。诀窍是通过调用loadViewIfNeeded()容器视图控制器来确保首先布局容器视图。

That means if 0x7fd6f375ee40from the original question is the view from a view controller you may need to check if you're loading that view hierarchy before some subviews are layed-out.

这意味着如果0x7fd6f375ee40原始问题是来自视图控制器的视图，您可能需要在布局某些子视图之前检查是否正在加载该视图层次结构。

回答by Rivera

This error happened to me with a UIButtontrying to auto-adjust its height by creating a UIView-Encapsulated-Layout-Heightthat conflicts with my top and bottom constraints.

这个错误发生在我UIButton试图通过创建UIView-Encapsulated-Layout-Height与我的顶部和底部约束冲突的自动调整其高度时。

I fixed it by explicitly adding a height constraint.

我通过显式添加高度约束来修复它。

回答by perec

I ran into this problem today: - Xcode 11 - using UITableViewAutomaticDimension - using estimatedRowHeight

我今天遇到了这个问题： - Xcode 11 - 使用 UITableViewAutomaticDimension - 使用estimatedRowHeight

One of the factors that fixed the issue was setting the tableView 'Separator' property to 'None' in the storyboard.

解决该问题的因素之一是在情节提要中将 tableView 的“分隔符”属性设置为“无”。

Also, if your constraints result in a fractional height (for example if you are using a multiplier based on an aspect ratio) then it will cause a conflict with UIView-Encapsulated-Layout-Height, which is always constrained to integral values. The solution is to lower the priority on your height constraint slightly.

此外，如果您的约束导致高度的分数（例如，如果您使用基于纵横比的乘数），那么它将导致与 UIView-Encapsulated-Layout-Height 的冲突，它总是被限制为整数值。解决方案是稍微降低高度限制的优先级。

回答by Mike

I was trying to implement a simple cell with a one line top label and an n line bottom label that would expand with longer text, with the hopes that the cell would automagically expand to fit the content based on my constraints.

我试图实现一个带有一行顶部标签和一个 n 行底部标签的简单单元格，该标签可以用更长的文本扩展，希望单元格能够根据我的约束自动扩展以适应内容。

Interestingly enough for me, the fix for this was to override - tableView:heightForRowAtIndexPath:and tableView:estimatedHeightForRowAtIndexPath:and return my estimated row height and UITableViewCellAutomaticDimensioninstead of setting the rowHeightand estimatedRowHeighton my tableView in viewDidLoad:.

对我来说有趣的是，这种修复是重写-tableView:heightForRowAtIndexPath:和tableView:estimatedHeightForRowAtIndexPath:并返回我的估计行高和UITableViewCellAutomaticDimension替代设置rowHeight和estimatedRowHeight我在的tableView viewDidLoad:。