Was ist NSLayoutConstraint "UIView-Encapsulated-Layout-Height" und wie sollte ich vorgehen, um eine saubere Neuberechnung zu erzwingen?

262

Ich habe eine UITableViewAusführung unter iOS 8 und verwende automatische Zellenhöhen aufgrund von Einschränkungen in einem Storyboard.

Eine meiner Zellen enthält eine einzelne UITextViewund ich muss sie basierend auf Benutzereingaben zusammenziehen und erweitern. Tippen Sie auf, um den Text zu verkleinern / erweitern.

Dazu füge ich der Textansicht eine Laufzeitbeschränkung hinzu und ändere die Konstante der Einschränkung als Reaktion auf Benutzerereignisse:

-(void)collapse:(BOOL)collapse; {

    _collapsed = collapse;

    if(collapse)
        [_collapsedtextHeightConstraint setConstant: kCollapsedHeight]; // 70.0
    else
        [_collapsedtextHeightConstraint setConstant: [self idealCellHeightToShowFullText]];

    [self setNeedsUpdateConstraints];

}

Wann immer ich dies tue, verpacke ich es in tableViewUpdates und rufe an [tableView setNeedsUpdateConstraints]:

[tableView beginUpdates];

[_briefCell collapse:!_showFullBriefText];

[tableView setNeedsUpdateConstraints];
// I have also tried 
// [self.tableView reloadRowsAtIndexPaths:@[indexPath] withRowAnimation:UITableViewRowAnimationTop];
// with exactly the same results.

[tableView endUpdates];

Wenn ich das mache, wird meine Zelle zwar erweitert (und dabei animiert), aber ich erhalte eine Warnung zu Einschränkungen:

2014-07-31 13:29:51.792 OneFlatEarth[5505:730175] 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:0x7f94dced2b60 V:[UITextView:0x7f94d9b2b200'Brief text: Lorem Ipsum i...'(388)]>",

    "<NSLayoutConstraint:0x7f94dced2260 V:[UITextView:0x7f94d9b2b200'Brief text: Lorem Ipsum i...']-(15)-|   (Names: '|':UITableViewCellContentView:0x7f94de5773a0 )>",

    "<NSLayoutConstraint:0x7f94dced2350 V:|-(6)-[UITextView:0x7f94d9b2b200'Brief text: Lorem Ipsum i...']   (Names: '|':UITableViewCellContentView:0x7f94de5773a0 )>",

    "<NSLayoutConstraint:0x7f94dced6480 'UIView-Encapsulated-Layout-Height' V:[UITableViewCellContentView:0x7f94de5773a0(91)]>"
 )

Will attempt to recover by breaking constraint 

<NSLayoutConstraint:0x7f94dced2b60 V:[UITextView:0x7f94d9b2b200'Brief text: Lorem Ipsum i...'(388)]>

388 ist meine berechnete Höhe, die anderen Einschränkungen für die UITextViewsind meine von Xcode / IB.

Das letzte stört mich - ich vermute, das UIView-Encapsulated-Layout-Heightist die berechnete Höhe der Zelle, wenn sie zum ersten Mal gerendert wird - (ich setze meine UITextViewHöhe auf> = 70,0), aber es scheint nicht richtig, dass diese abgeleitete Einschränkung dann eine überschreibt Benutzer cnstraint aktualisiert.

Schlimmer noch, obwohl der Layoutcode besagt, dass versucht wird, meine Höhenbeschränkung zu brechen, ist dies nicht der Fall. Anschließend wird die Zellenhöhe neu berechnet und alles wird so gezeichnet, wie ich es möchte.

Also, was ist NSLayoutConstraint UIView-Encapsulated-Layout-Height(ich vermute, es ist die berechnete Höhe für die automatische Zellengröße) und wie sollte ich vorgehen, um es zu zwingen, sauber neu zu berechnen?

Rog
quelle
3
Kreuz in Apple Dev Foren gepostet: devforums.apple.com/thread/238803
Rog
3
Ich habe ein ähnliches Problem folgendermaßen behoben und es funktioniert unter iOS 7/8. 1) Senken Sie eine der Einschränkungsprioritäten auf 750. Ich würde die 1. oder 2. versuchen. 2) In der Zellenunterklasse in awakeFromNib set self.contentView.autoresizingMask = UIViewAutoresizingFlexibleHeight;. Ich denke, dass das anfängliche Einstellen der Autoresize-Maske das Hinzufügen der letzten Einschränkung verhindert. Ich habe diese Lösung hier gefunden: github.com/wordpress-mobile/WordPress-iOS/commit/…
Jesse
3
@ RogerNolan, irgendwelche Neuigkeiten? Ich habe das gleiche Problem beim Spielen mit dem automatischen Layout in Interface Builder festgestellt. Einige Zellen verursachen dieses Problem, andere nicht.
Orkenstein
3
Ich denke nicht, dass das Hinzufügen einer Autoresizing-Marke eine gute Lösung ist.
Rog
1
@ RogerNolan Generieren Sie diese Zelle in IB, bevor Sie diese Layoutänderungen vornehmen? Ich habe das gleiche Problem behoben, aber keine zusätzlichen Einschränkungen hinzugefügt. Ich habe es geschafft, die Warnung zu unterdrücken, indem ich meine Ansicht von Grund auf neu erstellt habe. Als ich die beiden Storyboard-Dateien unterschied, bestand der einzige Unterschied darin, dass der Version mit den Warnungen die Zeile <rect key="frame" x="0.0" y="0.0" width="600" height="110"/>in ihrer Definition fehlte , was mich zu der Annahme führte, dass dies ein IB-Fehler ist . Zumindest meins war es sowieso.
Ell Neal

Antworten:

301

Versuchen Sie, die Priorität Ihres _collapsedtextHeightConstraintauf 999 zu senken. Auf diese Weise hat die vom System bereitgestellte UIView-Encapsulated-Layout-HeightEinschränkung immer Vorrang.

Es basiert auf dem, was Sie zurückgeben -tableView:heightForRowAtIndexPath:. Stellen Sie sicher, dass Sie den richtigen Wert und Ihre eigene Einschränkung zurückgeben, und die generierte sollte identisch sein. Die niedrigere Priorität für Ihre eigene Einschränkung wird nur vorübergehend benötigt, um Konflikte zu verhindern, während Animationen zum Reduzieren / Erweitern ausgeführt werden.

Ortwin Gentz
quelle
74
Das würde genau das Gegenteil von dem erreichen, was ich will. Die UIView-Encapsulated-Layout-Höhe ist falsch - sie gehört zum vorherigen Layout.
Rog
7
Die UIView-Encapsulated-Layout-HeightEinschränkung wird von UITableView hinzugefügt, sobald die Höhen bestimmt sind. Ich berechne die Höhe basierend auf der systemLayoutSizeFittingSizeder Inhaltsansicht. Hier spielt das UIView-Encapsulated-Layout-Heightkeine Rolle. Dann setzt die tableView die contentSize explizit auf den von zurückgegebenen Wert heightForRowAtIndexPath:. In diesem Fall ist es richtig, die Priorität unserer benutzerdefinierten Einschränkungen zu verringern, da die tableView-Einschränkung nach der Berechnung der rowHeights Vorrang haben muss.
Ortwin Gentz
8
@OrtwinGentz: Es ist immer noch nicht richtig, die Priorität unserer benutzerdefinierten Einschränkungen zu senken, da die tableView-Einschränkung nach der Berechnung der rowHeights Vorrang haben muss . Die Sache ist, dass UIView-Encapsulated-Layout-Heightes falsch ist, wenn ich die Priorität nicht absenke ...
Testen
38
Ich behaupte, dass dadurch Konflikte vermieden werden, die das eigentliche Problem nicht beheben - obwohl dies immer noch wie ein Apple-Fehler wirkt, denke ich, dass es wahrscheinlich das Richtige ist. Insbesondere angesichts der Tatsache, dass Apple diese Einschränkung neu berechnet und nach dem Drucken des Fehlers alles korrekt dargestellt wird.
Rog
9
-1 für diese Antwort, da davon ausgegangen wird, dass die hinzugefügte Einschränkung korrekt ist. Das UIView-Encapsulated-Layout-Widthin meinem Fall hinzugefügte ist einfach falsch, aber es scheint meinen expliziten Einschränkungen zur Laufzeit vorzuziehen.
Ray
68

Ich habe ein ähnliches Szenario: eine Tabellenansicht mit einer Zeilenzelle, in der sich einige Zeilen mit UILabel-Objekten befinden. Ich verwende iOS 8 und Autolayout.

Beim Drehen habe ich die falsche vom System berechnete Zeilenhöhe erhalten (43,5 ist viel geringer als die tatsächliche Höhe). Es sieht aus wie:

"<NSLayoutConstraint:0x7bc2b2c0 'UIView-Encapsulated-Layout-Height' V:[UITableViewCellContentView:0x7bc37f30(43.5)]>"

Es ist nicht nur eine Warnung. Das Layout meiner Tabellenansichtszelle ist schrecklich - der gesamte Text überlappt sich in einer Textzeile.

Es überrascht mich, dass die folgende Zeile mein Problem auf magische Weise "behebt" (Autolayout beschwert sich über nichts und ich bekomme, was ich auf dem Bildschirm erwarte):

myTableView.estimatedRowHeight = 2.0; // any number but 2.0 is the smallest one that works

mit oder ohne diese Zeile:

myTableView.rowHeight = UITableViewAutomaticDimension; // by itself this line only doesn't help fix my specific problem
Goldener Daumen
quelle
8
Schließlich! Dies ist eine richtige Antwort. In der WWDC-Sitzung wurde erwähnt, dass Sie, wenn Sie die automatische Zeilenhöhengröße verwenden möchten, eine geschätzte Zeilenhöhe festlegen müssen, da sonst schlechte Dinge passieren. (Ja, Apple wirklich böse Dinge passiert ist)
Abdalrahman Shatou
50
FWIW, das Hinzufügen der Schätzung hat für mich überhaupt keinen Unterschied gemacht.
Benjohn
3
Heh. Ich bin wieder bei dieser Antwort und habe sie mit Freude und Hoffnung umgesetzt. Wieder einmal hat es für mich keinen Unterschied gemacht :-)
Benjohn
3
Von tableView zurückgegebene Schätzungen: geschätzte HöheForRowAtIndexPath: MUSS mindestens so groß wie die Zelle sein. Andernfalls ist die berechnete Höhe der Tabelle geringer als die tatsächliche Höhe, und die Tabelle kann nach oben scrollen (z. B. nachdem der Abwicklungsabschnitt zur Tabelle zurückgekehrt ist). UITableViewAutomaticDimension sollte nicht verwendet werden.
Matt
1
Beachten Sie, dass anfänglich je niedriger estimatedRowHeightdesto häufiger cellForRowAtIndexPathaufgerufen wird. Tabellenansichtshöhe geteilt durch geschätzte Zeilenhöhenzeiten, um genau zu sein. Auf einem 12-Zoll-iPad Pro kann dies möglicherweise eine Zahl von Tausenden sein, die Datenquelle hämmern und zu einer erheblichen Verzögerung führen.
Mojo66
32

Ich konnte die Warnung zum Verschwinden bringen, indem ich eine Priorität für einen der Werte in der Einschränkung angab, die laut Warnmeldungen unterbrochen werden musste (siehe unten "Will attempt to recover by breaking constraint"). Es scheint, dass 49die Warnung verschwindet, solange ich die Priorität auf etwas Größeres als setze .

Für mich bedeutete dies, meine Einschränkung zu ändern. Die Warnung besagte, dass versucht wurde zu brechen:

@"V:|[contentLabel]-[quoteeLabel]|"

zu:

@"V:|-0@500-[contentLabel]-[quoteeLabel]|"

Tatsächlich kann ich jedem Element dieser Einschränkung eine Priorität hinzufügen, und es wird funktionieren. Es scheint egal zu sein, welches. Meine Zellen haben die richtige Höhe und die Warnung wird nicht angezeigt. Roger, zum Beispiel, versuchen Sie, @500direkt nach der 388Höhenwertbeschränkung (z 388@500. B. ) hinzuzufügen .

Ich bin mir nicht ganz sicher, warum das funktioniert, aber ich habe ein wenig nachgeforscht. In der NSLayoutPriority-Enumeration scheint die NSLayoutPriorityFittingSizeCompressionPrioritätsstufe zu sein 50. Die Dokumentation für diese Prioritätsstufe lautet:

Wenn Sie eine FittingSize-Nachricht an eine Ansicht senden, wird die kleinste Größe berechnet, die groß genug für den Inhalt der Ansicht ist. Dies ist die Prioritätsstufe, mit der die Ansicht bei dieser Berechnung so klein wie möglich sein soll. Es ist ziemlich niedrig. Es ist im Allgemeinen nicht angebracht, eine Einschränkung mit genau dieser Priorität vorzunehmen. Du willst höher oder niedriger sein.

Die Dokumentation für die referenzierte fittingSizeNachricht lautet:

Die Mindestgröße der Ansicht, die die darin enthaltenen Einschränkungen erfüllt. (schreibgeschützt)

AppKit setzt diese Eigenschaft auf die beste für die Ansicht verfügbare Größe, wobei alle Einschränkungen und Unteransichten berücksichtigt werden und die Präferenz erfüllt wird, die Ansicht so klein wie möglich zu gestalten. Die Größenwerte in dieser Eigenschaft sind niemals negativ.

Ich habe nicht darüber hinaus gegraben, aber es scheint sinnvoll zu sein, dass dies etwas damit zu tun hat, wo das Problem liegt.

Jeff Bowen
quelle
Das ist Jeff. Fühlt sich für mich immer noch wie ein Käfer an. Apple hat jedoch nicht auf den Rdar reagiert :-(
Rog
12

Ich war in der Lage , diesen Fehler zu beheben , indem ein falsches Entfernen , cell.layoutIfNeeded()dass ich in meinem hatte tableView‚s - cellForRowAtMethode.

Clifton Labrum
quelle
1
Ja, das hat das Problem auch für mich gelöst. Ich habe Code-Layout-Einschränkungen vorgenommen, sodass ich anfangs dachte, ich könnte etwas verpassen. Danke
John
1
Das gleiche! Vielen Dank!
Andrey Chernukha
12

In 99,9% der Fälle UITableViewstreten bei Verwendung benutzerdefinierter Zellen oder Header alle Konflikte auf, wenn die Tabelle beim ersten Mal geladen wird. Nach dem Laden wird der Konflikt normalerweise nicht mehr angezeigt.

Dies liegt daran, dass die meisten Entwickler normalerweise eine feste Höhe oder eine Ankerbeschränkung verwenden, um ein Element in der Zelle / Kopfzeile zu gestalten. Der Konflikt tritt auf, weil beim UITableViewersten Laden / Auslegen die Höhe der Zellen auf 0 gesetzt wird. Dies steht offensichtlich im Widerspruch zu Ihren eigenen Einschränkungen. Um dies zu lösen, setzen Sie einfach alle festen Höhenbeschränkungen auf eine niedrigere Priorität ( .defaultHigh). Lesen Sie die Konsolenmeldung sorgfältig durch und sehen Sie, welche Einschränkung das Layoutsystem aufgehoben hat. Normalerweise muss die Priorität geändert werden. Sie können die Priorität folgendermaßen ändern:

let companyNameTopConstraint = companyNameLabel.topAnchor.constraint(equalTo: companyImageView.bottomAnchor, constant: 15)
    companyNameTopConstraint.priority = .defaultHigh

NSLayoutConstraint.activate([
            companyNameTopConstraint,
           the rest of your constraints here
            ])
DU BIST VERRÜCKT
quelle
1
Schöne Erklärung.
Glenn
7

Versuchen Sie, die Zelle neu zu laden, anstatt die Tabellenansicht zu informieren, um ihre Einschränkungen zu aktualisieren:

[tableView beginUpdates];

[_briefCell collapse:!_showFullBriefText];

[tableView reloadRowsAtIndexPaths:@[[tableView indexPathForCell:_briefCell]] withRowAnimation:UITableViewRowAnimationNone];

[tableView endUpdates];

UIView-Encapsulated-Layout-Height ist wahrscheinlich die Höhe, die die Tabellenansicht für die Zelle während des anfänglichen Ladens berechnet hat, basierend auf den Einschränkungen der Zelle zu diesem Zeitpunkt.

Austin
quelle
Ich hätte in meiner Frage sagen sollen, ich habe es versucht und es funktioniert nicht. Ich stimme Ihrer Vermutung über UIView-Encapsulated-Layout-Height
Rog
6
Haben Sie trotzdem das Kopfgeld, um zumindest eine Antwort einzureichen. Scheint, als würde SO es sonst einfach verdunsten lassen.
Rog
6

Andere Möglichkeit:

Wenn Sie das automatische Layout verwenden, um die Zellenhöhe zu berechnen (die Höhe von contentView, meistens wie unten), und wenn Sie ein geeignetes Ansichtstrennzeichen haben, müssen Sie die Trennzeichenhöhe hinzufügen, um zur Zellenhöhe zurückzukehren. Sobald Sie die richtige Höhe erreicht haben, wird diese Autolayout-Warnung nicht mehr angezeigt.

- (CGFloat)calculateHeightForConfiguredSizingCell:(UITableViewCell *)sizingCell {
   [sizingCell setNeedsLayout];
   [sizingCell layoutIfNeeded];
   CGSize size = [sizingCell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
   return size.height; // should + 1 here if my uitableviewseparatorstyle is not none

}
Cullen SUN
quelle
Das hat mir in einem Fall geholfen, in dem ich nur in einigen Simulatoren (iPad 6 Plus) Mehrdeutigkeiten in der Layouthöhe in einem ziemlich komplexen Zellenlayout festgestellt habe. Es scheint mir, dass der Inhalt aufgrund einiger interner Rundungsfehler etwas zusammengedrückt ist und wenn die Einschränkungen nicht darauf vorbereitet sind, zusammengedrückt zu werden, habe ich Unklarheiten. Also statt der Rückkehr UITableViewAutomaticDimensionin heightForRowAtIndexPathkehre ich [sizingCell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize] + 0.1
Leo
Ich meine natürlich[sizingCell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize].height + 0.1
Leo
Umwerfend; Durch das Entfernen des Trennzeichens hat sich mein Tisch verhalten, also danke.
Royalmurder
5

Wie von Jesse in dem Kommentar der Frage erwähnt, funktioniert dies für mich:

self.contentView.autoresizingMask = UIViewAutoresizingFlexibleHeight;

Zu Ihrer Information, dieses Problem tritt in iOS 10 nicht auf.

Phu Nguyen
quelle
2
In Swift 4.2: self.contentView.autoresizingMask = [.flexibleHeight]
Airowe
4

Ich hatte diesen Fehler, als ich UITableViewAutomaticDimension verwendete und eine Höhenbeschränkung für eine Ansicht innerhalb der Zelle änderte.

Ich fand schließlich heraus, dass es daran lag, dass der Wert der Einschränkungskonstante nicht auf die nächste ganze Zahl aufgerundet wurde.

let neededHeight = width / ratio // This is a CGFloat like 133.2353
constraintPictureHeight.constant = neededHeight // Causes constraint error
constraintPictureHeight.constant = ceil(neededHeight) // All good!
Che
quelle
2
Dies war der Kommentar, der mich auf mein Problem aufmerksam machte. Ich habe eine Bildzelle, die dynamisch geladen wird (wächst und schrumpft) und eine Tabellenansicht mit geschätzter Zeilenhöhe = 50 und Zeilenhöhe = UITableViewAutomaticDimension. Ich habe immer noch gegen Einschränkungen verstoßen, obwohl die Tabellenansicht die richtige Höhe hatte. Es stellte sich heraus, dass die Trennzeichen eine Höhe von 0,3333 hatten, und genau das hat meine Bildgrößenbeschränkung in der zu brechenden Zelle ausgelöst. Nach dem Ausschalten der Separatoren war alles in Ordnung. Danke Che, dass du mir gegeben hast, wonach ich suchen soll.
migs647
1
In diesem Fall erstellen Sie eine zusätzliche Einschränkung, z. B. bottomMargin> = view.bottomMargin+1@900. AutoLayout versucht, den zusätzlichen Punkt 1 aufzunehmen, ändert die Größe der Zelle, wird aufgrund der Trennhöhe verwirrt, versucht, einige Einschränkungen zu lösen / zu lockern, findet den Punkt @ 900 und verwirft diesen. Sie erhalten das gewünschte Layout ohne Warnungen.
Anton
rette meinen Tag. sowieso ein paar Stunden
Anton Tropashko
1

Durch die Größenanpassung der Textansicht an den Inhalt und die Aktualisierung der Höhenbeschränkungskonstante auf die resultierende Höhe wurde der UIView-Encapsulated-Layout-HeightEinschränkungskonflikt für mich behoben , z.

[self.textView sizeToFit];
self.textViewHeightConstraint.constant = self.textView.frame.size.height;
Kim André Sand
quelle
Wo hast du das gemacht? In layoutSubviews?
Stuckj
1

Nachdem ich einige Stunden damit verbracht hatte, mir mit diesem Fehler den Kopf zu kratzen, fand ich endlich eine Lösung, die für mich funktionierte. Mein Hauptproblem war, dass ich mehrere Schreibfedern für verschiedene Zelltypen registriert hatte, aber ein Zelltyp speziell unterschiedliche Größen haben durfte (nicht alle Instanzen dieser Zelle werden dieselbe Größe haben). Das Problem trat also auf, als die Tabellenansicht versuchte, eine Zelle dieses Typs aus der Warteschlange zu entfernen, und sie zufällig eine andere Höhe hatte. Ich habe es durch Einstellen gelöst

self.contentView.autoresizingMask = UIViewAutoresizingFlexibleHeight; self.frame = CGRectMake(0, 0, self.frame.size.width, {correct height});

wann immer die Zelle ihre Daten hatte, um ihre Größe zu berechnen. Ich denke, es kann sein

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

etwas wie

cell.contentView.autoresizingMask = UIViewAutoresizingFlexibleHeight; cell.frame = CGRectMake(0, 0, self.frame.size.width, {correct height});

Hoffe das hilft!

Alcides Eduardo Zelaya
quelle
0

TableView ruft die Höhe für die Zelle bei indexPath vom Delegaten ab. Dann holen Sie sich die Zelle von cellForRowAtIndexPath:

top (10@1000)
    cell
bottom (0@1000)

wenn cell.contentView.height: 0 // <-> (UIView-Encapsulated-Layout-Höhe: 0 @ 1000) top (10 @ 1000) in Konflikt mit (UIView-Encapsulated-Layout-Höhe: 0 @ 1000),

weil sie Prioritäten gleich 1000 sind. Wir müssen die höchste Priorität unter UIView-Encapsulated-Layout-Heightder Priorität setzen.

user2962814
quelle
0

Ich bekam eine Nachricht wie diese:

Kann nicht gleichzeitig Einschränkungen erfüllen ...
...
...
...
NSLayoutConstraint: 0x7fe74bdf7e50 'UIView-Encapsulated-Layout Höhe' V: [UITableViewCellContentView: 0x7fe75330c5c0 (21,5)]
...
...
von zu erholen versuchen , Unterbrechen der Einschränkung NSLayoutConstraint: 0x7fe0f9b200c0 UITableViewCellContentView: 0x7fe0f9b1e090.bottomMargin == UILabel: 0x7fe0f9b1e970.bottom

Ich benutze einen Brauch UITableViewCellmit UITableViewAutomaticDimensionfür die Höhe. Und ich habe auch die estimatedHeightForRowAtIndex:Methode implementiert .

Die Einschränkung, die mir Probleme bereitete, sah ungefähr so ​​aus

[NSLayoutConstraint constraintsWithVisualFormat:@"V:|-[title]-|" options:0 metrics:nil views:views];

Wenn Sie die Einschränkung in diese ändern, wird das Problem behoben, aber wie bei einer anderen Antwort war ich der Meinung, dass dies nicht korrekt ist, da dies die Priorität einer Einschränkung senkt, die ich benötigen möchte:

[NSLayoutConstraint constraintsWithVisualFormat:@"V:|-6@999-[title]-6@999-|" options:0 metrics:nil views:views];

Was mir jedoch aufgefallen ist, ist, dass dies auch funktioniert, wenn ich nur die Priorität entferne, und ich nicht die Protokolle für brechende Einschränkungen erhalte:

[NSLayoutConstraint constraintsWithVisualFormat:@"V:|-6-[title]-6-|" options:0 metrics:nil views:views];

Dies ist ein bisschen rätselhaft, was der Unterschied zwischen |-6-[title]-6-|und ist |-[title-|. Die Angabe der Größe ist für mich jedoch kein Problem, und die Protokolle werden entfernt, und ich muss die Priorität meiner erforderlichen Einschränkungen nicht verringern.

user1687195
quelle
0

Ich hatte ein ähnliches Problem mit einer Sammlungsansichtszelle.

Ich habe es gelöst, indem ich die Priorität der letzten Einschränkung, die mit dem unteren Rand der Zelle verknüpft war (die letzte in der Kette von oben nach unten in der Ansicht - dies bestimmt letztendlich ihre Höhe), auf 999 gesenkt habe.

Die Höhe der Zelle war korrekt und die Warnungen gingen weg.

Reich
quelle
-1

Stellen Sie dies ein, view.translatesAutoresizingMaskIntoConstraints = NO;um dieses Problem zu beheben.

kathy zhou
quelle
Das hat bei mir perfekt funktioniert, auch wenn es nicht die perfekte Lösung war.
Enkha