Ich bin im Rahmen meines Entwicklungsprozesses für Krachen und Speicherlecks aufzuspüren. Als Strategie, setzen Sie NSLog Nachrichten oder Benachrichtigungen von einigen so in didReceiveMemoryWarning:? Die Dokumentation für diese Methode ist eher spärlich. Ist es richtig zu sagen , dass vor einem Absturz passieren wird, die UIViewController diese Methode auslösen? Ist das ein Ausgangspunkt , bevor auch vorwärts mit Instrumenten geht?
iOS: Hilfs von didReceiveMemoryWarning:
quelle vom benutzer Coocoo4Cocoa
In anderen Sprachen...
OK, einige Dinge zu beachten:
- didReceiveMemoryWarning wird vor einem Out-of-Memory-Crash genannt werden. Nicht andere Abstürze. Wenn Sie die Warnung richtig und Speicherplatz freizugeben handhaben, dann können Sie die Out-of-Memory-Zustand vermeiden und nicht abstürzen.
- Sie können manuell eine Speicherwarnung im Simulator unter dem Hardware-Menü auslösen. Sehr zu empfehlen das Ihren Umgang mit didReceiveMemoryWarning zu testen, zu tun.
- Instruments hilft debuggen Sie Lecks (wenn auch nicht alle) - es ist für Abstürze, dass nützliche nicht wirklich ist.
- Nein, ich persönlich nicht NSLog verwenden - ich nur die Speicher Warnungen Breakpoint, wenn ich das Debuggen.
Wenn der Benutzer nach links öffnen einige Anwendungen werden Sie sehr wenig Speicher zur Verfügung haben. Also manchmal didReceiveMemoryWarningkann erst nach 1 MB Nutzung durch das System aufgerufen werden.
Das System ruft diese Methode auf alle Ihre Ansicht-Controller, wenn Sie ein NSLog in jedem Ihrer Ansicht-Controller setzen, werden Sie feststellen, dass.
Dann automatisch das Verfahren viewDidUnloadwird durch das System auf alle Ihre Ansicht - Controller aufgerufen werden (nichtdealloc ). Also muss man dort alle Deallokation Anweisungen setzen.
Sie haben eine Menge Experimente zu machen, weil wenn Ihre Anwendung komplex ist, werden Sie viele Abstürze Gesicht, bevor es gut zu verwalten.
UPDATE
Wie von IOS 6 UIViewControllerAnsichten sind nicht mehr entladen als Reaktion auf Speichern Warnungen. Stattdessen tun nur Ihre besten alle Ressourcen freizugeben , können Sie einigermaßen neu erstellen (zB Cache - Daten) , wenn didReceiveMemoryWarningaufgerufen wird.
UPDATE
schrieb ich meine ursprüngliche Antwort , wenn ich ein zorniger junger Mann war; Zeiten haben sich geändert und im Grunde, dass es falsch ist .
Wenn Sie eine App mit einem einzigen View - Controller haben und Sie erhalten eine Erinnerung Warnung, gibt es nicht viel Sie tun können. Aber die Dinge dramatisch ändern , wenn Sie mehr View - Controller haben, weil Sie entladen können alle den Zustand im Zusammenhang mit dem nicht vordersten Controller. In der Tat [UIViewController didReceiveMemoryWarning]werden Sie in der richtigen Richtung prod durch Ihre nicht sichtbaren Ansichten für Sie Entladen (Überraschung!). Wenn der vorderste View - Controller abgewiesen wird, wird die zugrunde liegende Ansicht neu geladen und höchstens soll der Benutzer nur noch von einer Verzögerung bewusst sein , obwohl intern Ihre App einen kompletten Neustart getan haben.
Das ist nicht irgendein Detail , das Sie leicht nachrüsten können, müssen Sie die Speichernutzung im Auge von Anfang an halten und gestalten Sie Ihren Multi - View - App in sauber unloadable UIViewControllerStücke. In der Tat ist es den Code kompatibel mit dem Simulator im Wert hält nur seine Speicherwarnfunktion zu verwenden.
Wenn der Speicher reichlich vorhanden ist, ist nichts entladen und alles ist seidig glatt, und wenn nicht genügend Arbeitsspeicher ist, die Dinge weiter arbeiten, wenn auch langsamer. Ich würde jetzt sagen, dass diese Lösung für das Finite-Speicherproblem ideal ist.
Um die Vorteile dieser Speichersalon Trick zu nehmen, die überlasten UIViewControllerMethoden
viewDidLoad, viewDidUnloadund
viewWillUnload(iOS5, nützlich , wenn Staat Entladen erfordert Ihrer Ansicht nach noch vorhanden sind , zum Beispiel , wenn Sie nicht Ihre OpenGL - Texturen wollen Leck & machen Puffer, auf iOS4 können Sie simulieren diese durch Überlastung didReceiveMemoryWarningund Ihre Ansicht Sichtbarkeit Tracking).
Originelle, gallig ANTWORT
didReceiveMemoryWarning ist absolut nutzlos.
Es gibt keine Garantie, dass, wenn Sie Speicher (auch alles) frei zu machen, dass Sie nicht getötet.
In meiner bitteren Erfahrung funktioniert es in der Regel, wie dies auf 2.x / 3.0:
mediaserverd leckt ein Bündel von Speicher
meine app wird getötet
Leider denkt der Reaper nie mediaserverd zu töten.
Also, wenn die Speicherauslastung nicht Ihre Schuld ist, haben Sie eigentlich immer nur zwei Möglichkeiten:
den Benutzer auffordern, neu zu starten (Benutzer übernimmt es ist deine Schuld, schreibt eine vernichtende Kritik)
hoffen, dass der Täter abstürzt (mediaserverd verpflichtet oft!)
Der Zweck didReceiveMemoryWarning ist es, Ihnen eine Chance zu geben, um Speicher frei oder Pop Ansichten, die einen Absturz zu vermeiden. Sie werden es nicht zu jedem vorhersehbaren Punkt erhalten, weil es hängt davon ab, was der Benutzer tut. Zum Beispiel, wenn der Benutzer auf den iPod hört, gibt es weniger verfügbare Speicher und Sie werden es früher erhalten.
Die Faustregel ist, dass Sie über 8 MB RAM haben, mit zu arbeiten. Wenn Sie zu, dass nahe kommen können Sie das Ereignis erwarten angehoben werden. Wenn Sie so viel RAM Aufnahme absichtlich sollten Sie einen Plan haben, um etwas dagegen zu tun.