2016-05-25 5 views
0

Lange Geschichte hier, so mit mir tragen ...iOS CPU Aktivität plötzlich stirbt

ich einen View-Controller haben, die, wenn während der gesamten Lebensdauer einer Anwendungssitzung mehr als drei Mal präsentiert wird hängen und sperren und einfrieren meine gesamte Bewerbung. Sogar das Sprungbrett bleibt stehen, bis meine App vollständig im Hintergrund ist! Im Xcode-Inspektor fiel mir ziemlich beunruhigend auf, dass der Speicherbedarf jedes Mal, wenn ich diese Ansicht präsentierte, gut 5-8 MB betragen würde und nach der Entlassung nicht wieder sinken würde. Zu dem Zeitpunkt, zu dem der vierte Aufruf stattfindet, verwendet die App bereits 40 MB Arbeitsspeicher.

Mein erster Gedanke war, "OMG, Itz ein Memry Lauch!" Der zweite sagte mir, in Instrumente zu springen und es aufzuspüren.

Während das Leaks-Tool einigen geholfen hat, hat es mir nur gesagt, dass die App wie verrückt durchgesickert ist. Alles, was es mir sagen würde, war, dass ich irgendwo in diesen vier Sekunden Intervallen zwischen "4 neuen Lecks" und "17 neuen Lecks" gewonnen hatte. Sie entsprachen jedoch meiner Eröffnung, und nachdem ich angefangen hatte, zufällige Dinge zu kommentieren (und der manchmal hilfreichen Anleitung des Tools "Zuweisungen" zu folgen), verfolgte ich die meisten von ihnen auf drei zusätzliche Zeilen Code. "Oh, ich brauche diese Ansichten sowieso nicht!" Diese drei Linien existieren nicht mehr und Instrumente beschweren sich nicht mehr.

Meine einzige Beschwerde hier ist, dass meine Benutzeroberfläche immer noch das gleiche verhält! Bei der vierten Präsentation wird die gesamte App langsamer. Bei der weiteren Überprüfung der Xcode-Geräte sehe ich, dass der Speicher nicht nur immer noch steigt (diesmal nur auf 30 statt 40 MB), sondern dass die CPU-Aktivität abgenommen hat!


Ok bewilligte ich in erster Linie sah es haben sollte, aber ich bin nicht perfekt!

Ich habe die App erneut ausgeführt, und festgestellt, dass die gesamte CPU-Aktivität konsistent stieg, je mehr ich diese Ansicht Controller präsentierte. Beim dritten war es bis zu 40-60%. Der Haupt-Thread schien ziemlich klar zu sein, und die meiste Aktivität wurde zwischen acht anderen Hintergrund-Threads verteilt (wer weiß, was all diese tun).

Hey look, it's running hot!

Das vierte Mal, dass ich diese Ansicht geöffnet, hatte ich alles wie verrückt zu blockieren erwartet. Es tat es nicht. Die CPU hat gerade ... angehalten. Es lief bei ungefähr 50-ish%, als bis zu dem Zeitpunkt, als mein Finger den Bildschirm verlassen hatte, es bei 1% lag. Alle Fadengraphen schrumpften von stacheligen Stalagmiten zu winzigen Wellen in einer Pfütze. Laut dem Tortendiagramm konnte die überwiegende Mehrheit des Prozessors frei tun, was er wollte. Es mag mich nicht.

Where did it all go??

Ich habe buchstäblich keine Ahnung, warum es dies tut. Ich bin seit Tagen in einem Zimmer fest und versuche es herauszufinden. Jede Hilfe oder Beratung wäre sehr willkommen.

Hat jemand eine Idee, warum das passiert, wie das passiert, oder was ich tun kann, um dies nicht geschehen zu lassen? Ich zeichne ein Leerzeichen hier ...

Vielen Dank!


Es sollte beachtet werden, dass ich diese durch Ausführen der App auf meinem iPhone 5s bekam. Ja, ich habe es am Simulator versucht, aber mein kleines MacBook Air nahm es wie ein Champion und war keine Hilfe, um das herauszufinden, außer um mir zu sagen, dass das Problem auf iPhones passiert ist.

Antwort

1

Ich habe schon einmal darauf hingewiesen, und das folgende ist meine allgemeine Vorgehensweise, die es mir normalerweise erlaubt, diese Art von Speicherlecks zu beheben.

Zuerst würde ich eine print-Anweisung in Sie ViewController, um zu sehen, ob Ihre VC freigegeben wird, wenn sie Pop-up ist.

deinit { 
    print(self.description) 
} 

Der nächste Schritt in dem Fall, dass der Viewcontroller wird nicht aufgehoben wird, würde ich durch Entfernen Kernstücke, von unten nach oben, kommentieren sie aus Chunks einen Schritt zu einer Zeit, aber verlassen Sie die Rückseite Kontrolle, die versteckt starten der View-Controller sichtbar. Normalerweise können Sie das Speicherleck isolieren, sobald Sie sehen, dass deInit nach dem Entfernen von Code aufgerufen wird. Möglicherweise haben Sie den Teil getroffen, der eine starke Zyklusreferenz erstellt hat.

Noch eine Sache, stellen Sie sicher, dass alle Ihre Delegierten für schwach erklärt werden, und durchsuchen Sie Ihren Code für Schließungen, und überprüfen Sie, dass die Schließungen keine harten Referenzen innerhalb enthalten, insbesondere für sich selbst.

Überprüfen Sie auch diesen Artikel, um die Verwendung von unowned oder schwach, wenn in Instanzen in eine Schließung übergeben, könnte hilfreich sein.

http://krakendev.io/blog/weak-and-unowned-references-in-swift

+0

Danke für den Rat. Ich habe nicht einmal daran gedacht, aus 'Deinit' zu drucken! Nach einiger Zeit stellte ich fest, dass die Übergabe von "self" in einem userInfo-Wörterbuch in "NSNotificationCenter" schlecht war. Es gab ein paar andere zufällige Orte, an denen 'NSNotificationCenter' ebenfalls im Weg war, und ich habe diese zu KVO verschoben. Danke für die Hilfe! – SeizeTheDay

+0

@SeizeTheDay Großartig zu hören :) Ich habe lange von NSNotificationCenter entfernt, es ist absolut mein letzter Ausweg, seit ich dies gelesen habe, weiß ich nicht, ob es immer noch der Fall ist, aber es ist ein großes Lesen http : //sealedabstract.com/code/nsnotificationcenter-with-blocks-consided-harmful/ – AntonTheDev