Objective-C und Speicherlecks, nachdem ein Programm beendet wurde?

Question

Ich bin ein neuer Objective-C Programmierer, der von einem C#, VB.NET, usw. kommt. Das sind alles Garbage Collection Sprachen und zum größten Teil ist das Schlimmste, was Sie tun können, die Speicherauslastung zu mißbrauchen, denn wenn Ihr Programm herunterfährt Speicher wird von der Laufzeit zurückgewonnen.

Allerdings bin ich nicht klar über Objective-C. Ich bekomme das zum größten Teil an uns als Entwickler, um die Zuweisung, Initialisierung, Aufbewahrung und Freigabe von Objekten zu verwalten. Ich versuche mein Bestes, um das zu tun und denke langsam, ich bekomme den Dreh raus.

Meine Sorge ist dies: Ich bin mir nicht sicher, ob ich den Begriff Speicherverlust richtig verstehe. Bezieht sich dies darauf, Speicher nicht ordnungsgemäß freizugeben, und wenn dann meine Anwendung heruntergefahren wird, gibt es ungenutzten Dangling-Speicher? Mit anderen Worten, wenn mein Programm heruntergefahren wird, stellt das Mac OS nicht sicher, dass alles, was das Programm benutzte, aufgeräumt ist?

Ich hoffe, das macht Sinn, es macht wirklich Sinn der Unterschiede, nachdem ein Programm heruntergefahren wird, nicht so sehr über Speicher, während das Programm läuft.

Answer 1

der Suche Ich bin nicht sicher, ob ich den Begriff Gedächtnis verstehen richtig lecken. Bezieht sich dies darauf, Speicher nicht ordnungsgemäß freizugeben, und wenn dann meine Anwendung heruntergefahren wird, gibt es ungenutzten Dangling-Speicher?

Nein; ein Speicherverlust ist ein Speicherleck während die Anwendung noch ausgeführt wird, da OS X den gesamten Speicher zurückgewinnt, wenn die Anwendung beendet wird. Wenn dies nicht der Fall ist, kann dies aufgrund schlechter Codierung und Speicherverwaltung zu großen Problemen führen und das gesamte System beeinträchtigen.

Es geht im Grunde darum, ein Objekt zu viel zu behalten oder nicht genug Speicher freizugeben. Wenn zum Beispiel Objekte zu einem Array hinzugefügt, dies ist ein üblicher Weg, um es zu tun:

NSMutableArray *array; //Pointer to some already allocated array 

[array addObject:someObject]; 
[someObject release]; 

Unter der Annahme, someObject korrekt zugeordnet wurde, wird es mit einem Beibehaltungszähler von 1 beginnen.Wenn Sie einem Array Objekte hinzufügen, ruft das Array retain für das fragliche Objekt auf und stößt es an, in diesem Fall 2.

Wenn ein Array freigegeben wird, sendet es release an alle seine Objekte; In diesem Szenario wird die Retain-Anzahl auf 1 zurückgesetzt (unter der Annahme, dass niemand das Objekt beibehalten hat). Dies ist nicht 0, also würde someObject noch existieren. Wenn someObject ein lokaler Zeiger wäre, der in einer Methode erstellt wurde und Sie keinen Zeiger mehr auf dieses Objekt hätten, würde der Speicher dort hängen bleiben. Dies ist ein Beispiel für einen Speicherverlust und verursacht, dass Ihre Anwendung mehr Arbeitsspeicher als benötigt, und wird leiden, bis es beendet wird.

Answer 2

Nein, das Betriebssystem sollte den gesamten Speicher freigeben, wenn Sie die Anwendung beenden. Speicherlecks werden Ihre App zum Absturz bringen, wenn sie nicht behandelt werden. Um es einfach zu halten, sagen die Geräte 10 MB RAM und Sie verlieren immer Speicher, wenn Sie eine Funktion aufrufen. Früher oder später wirst du keinen Widder mehr haben und deine App wird abstürzen.

Apple bietet ein großartiges Tool "Instruments", mit dem Sie Speicherlecks verfolgen und beheben können. Ich schlage vor, dass du deine App ab und zu durchführst, nur um nach Lecks zu suchen. Ich bin an den Punkt gekommen, dass ich immer den Ort finde, an dem ich das Objekt freigeben werde, wenn ich alloc anrufe. Wenn ich Alloc anrufe und es sich nicht um eine Autorelease handelt, muss ich den Ort finden, an den ich die Freigabe setzen kann.

Answer 3

Das Betriebssystem gibt zwar den Speicher frei, aber Sie können bis dahin leckt. Wenn Sie also beim Herunterfahren einen Bericht über Lecks erhalten, sind das nur die Objekte, die noch nicht veröffentlicht wurden (aber der Speicher wird jetzt zurückgewonnen).

Ich schrieb den Blog-Eintrag zum Verständnis der Ziel-C-Speicherverwaltung für das iPhone.

http://loufranco.com/blog/files/managing-memory-iphone.html

und dieses auf dem Clang statischen Analyse-Tool, das ich von unschätzbarem Wert gefunden habe, auf Lecks durch die Untersuchung der Quelle

http://loufranco.com/blog/files/scan-build-iphone.html