Leistungsproblem bei der automatischen iOS-Anzeige im Hochformat. [NSISEngine optimieren]

Question

Ich habe ein sehr seltsames Problem erlebt und ich habe mich gefragt, ob mir jemand hier helfen könnte, da ich total verloren bin.

Kontext: Ich entwickle eine App mit einer relativ einfachen Hierarchie. Nur ein paar Blick Controller, aber eine ganze Reihe von hochauflösenden Bildern. Sie werden in einem UIScrollView mit etwas Text usw. dargestellt. Während des Tests im Hochformat scrollte die Scrollview überhaupt nicht reibungslos. Es schien, als wäre die Framerate auf etwa 4-5 fps gefallen. Zuerst dachte ich, es sei wegen der hochauflösenden Bilder.

Aber dann habe ich das iPad in Querformat und alles lief reibungslos. Da ich eine separate XIB-Datei für Hoch- und Querformat habe, dachte ich, dass es im Portrait-Xib ein Problem geben muss. Es stellte sich heraus, dass es nicht war. Beide hatten die gleiche VC-Klasse und verwendeten daher denselben Code, und beide XIBs sind bis auf die Größe und Position der Ansichten fast identisch.

Um das Problem einzugrenzen, habe ich TimeProfiler von Instrument verwendet, um zu sehen, was das Problem verursacht. Wie sich herausstellte, zeigte TimeProfiler einige Aufrufe an [NSISEngine optimize] (ausgelöst durch NSLayoutConstraint). Im Hochformat-Modus waren mehr Anrufe und diese Anrufe dauerte viel länger. Weiter unten im Baum sah ich, dass im Hochformat [NSISEngine optimize][NSISEngine fixupIntegralizationViolations] genannt und in der Landschaft nicht.

Ich entfernte sogar alle Viewcontroller aus der App mit Ausnahme der rootVC und einer anderen, die von der RootVC präsentiert wird. Das präsentierte vc enthält nur einige Bilder, Buttons und einige Animationen. Es hat nur eine Xib für beide Ausrichtungen und ist (wie alle anderen auch) mit Auto-Layout ausgelegt.

Das Layout funktioniert so, wie es in beiden Orientierungen sollte und es gibt keine Mehrdeutigkeiten (soweit ich das beurteilen kann. Mindestens po [[UIWindow keyWindow] _autolayoutTrace] zeigt keine).

Ich habe einen Screenshot des TimeProfile des Präsentationsprozesses der VC angehängt. Eins für Porträt und eins für Landschaft. Wie Sie sehen können, dauern die Aufrufe von [NSISEngine optimize] im Querformat nur eine Millisekunde, während sie im Hochformat über 3000 ms dauern.

Gibt es jemanden, der mir sagen kann, warum das ist? Oder vielleicht eine Idee, was ich tun kann, um herauszufinden, was das Problem ist?

Jede Hilfe würde sehr geschätzt werden!

Thx

Link zu einer größeren Version des Bildes: link

Answer 1

Ich reichte eine Tech-Support-Anfrage bezüglich dieses Problems und bekam endlich die Antwort, dass es wahrscheinlich ein Fehler. Fehlerbericht ist abgelegt. Hoffentlich werden sie es bald reparieren. Wenn es Neuigkeiten gibt, werde ich diese Antwort aktualisieren.

Answer 2

Ich stieß auf das gleiche Problem mit einer mäßig komplexen Ansicht, wo es auf Nicht-Retina-iPads oder einem Retina-iPad im Hochformat gut lief. Im Querformat auf einem Retina-Gerät dauerte es 10x länger, um ein Popover anzuzeigen oder eine andere Ansicht auf den Ansichtsstapel zu schieben. Am Ende ersetzte ich die XIB-Datei durch eine handcodierte loadView im View-Controller. Das scheint das Problem beseitigt zu haben. Der Builder für Schnittstellen neigt dazu, übermäßige Einschränkungen zu erzeugen. Dies zu kontrollieren, ist der Schlüssel für eine gute automatische Layout-Leistung.

Ich habe auch ein Support-Ticket für dieses Problem geöffnet.

Update:

fand ich die Ursache in meiner Situation. Es wurde die folgende von Einschränkungen eingestellt:

NSArray *constraints = [NSLayoutConstraint 
         constraintsWithVisualFormat : @"|[sunLabel][monLabel(==sunLabel)][tueLabel(==sunLabel)][wedLabel(==sunLabel)][thuLabel(==sunLabel)][friLabel(==sunLabel)][satLabel(==sunLabel)]|" 
         options : 0 
         metrics : nil 
         views : labelViewsDictionary]; 

Es gibt an, dass 7-Etiketten innerhalb einer übergeordneten Ansicht alle die gleiche Größe und die ganzen Breite der übergeordneten Ansicht erstrecken. Ich glaube, dass die übermäßige relationale Natur des Layouts automatische Layoutanpassungen ergab, insbesondere weil die übergeordnete Ansichtsbreite nicht durch 7 teilbar war.

Um es zu lösen, habe ich ein Array von Einschränkungen erstellt, die die Breite jedes Labels angeben und diese Einschränkungen angewendet. Wenn sich das Gerät dreht, ändert sich die Breite des übergeordneten Elements, sodass ich zurück gehe und die Konstante für die Abhängigkeiten auf 1/7 der Breite der übergeordneten Ansicht einstelle. Dies funktioniert nun gut, der Prozess des Ladens eines Popover dauert jetzt weniger als 300 ms statt 2000 ms.

Answer 3

Ich hatte gestern das gleiche Problem in einem Ipad iOS6.1 Gerät. Instrumentierung der App ergab, dass die Methode fixupIntegralisationViolations jedes Mal, wenn sie aufgerufen wurde, etwa 300 ms benötigte (etwa 20 mal, was sehr viel ist), was die App absolut nutzlos macht.

Mein Problem war sehr ähnlich zu dem, was Jack Cox kommentiert, aber ich habe es anders gelöst. Meine Einschränkung war:

@ "H: | [AlleButton] [InStoreButton (== AllButton)]] [OnlineButton (== AllButton)]] [SortButton (50)] |"

Das Problem ist, dass die parentView hier ist die volle iPad Landschaft Breite, so dass die Mathematik dieser Contraint gab jeder Taste diese Breite: (1024-50)/3 = 324.6666667.

Dies ist in der Regel kein Problem im Autolayout, da es sich um große Float-Zahlen kümmert und sie richtig rund, aber es scheint, dass in iPad iOS6 Landschaft Runden diese Zahlen einen Fehler, der die Benutzeroberfläche blockiert. Um alles zu ändern, musste ich den sortButton ändern, um 52 zu haben, also ist jede Tastenbreite jetzt: (1024-52)/3 = 324. Das ist alles. Jetzt dauert die Methode fixupIntegralisationViolations bei jedem Aufruf ca. 1ms.

Das Interessante ist, dass die Verwendung von 52 gibt es eine nicht Dezimalbreite in Querformat, aber es gibt eine Dezimalzahl im Hochformat: (768-52)/3 = 238.666667. Portrait scheint jedoch keinen Bug zu haben, und das automatische Layout rundet die Zahlen korrekt ab.