2012-04-13 6 views
1

Ich habe eine App in meinem iPod.Seltsames Ding in der Speicherverwaltung für iOS-Entwicklung

1.Open die App, und schauen Sie sich die Speicher Instruments (Activity Monitor), ist es 8.95M

2.click ein Knopf, eine UIImageView mit einem großen Bild auf dem Bildschirm hinzufügen wird, der Speicher 17.8M jetzt.

3. Entfernen Sie die UIImageView vom Bildschirm, und warten Sie eine Sekunde, der Speicher ist 9.09M jetzt.

Ich bin sicher, dass die UIImageView freigegeben wird, nachdem es vom Bildschirm entfernt wurde. Das ist ein sehr einfacher Code. Also, wenn es entfernt wurde, sollte der Status der App wie zuvor das Hinzufügen der UIImageView auf dem Bildschirm hinzufügen, habe ich recht? Aber warum ist das Gedächtnis 9.09M statt 8.95M? Wenn Sie dem Bildschirm eine komplexere Ansicht hinzufügen, ist der Unterschied deutlicher.

+1

Wenn Sie das gleiche Bild wieder öffnen und es dann wieder und wieder entfernen, wächst es jedes Mal um den gleichen Betrag? Wenn ja, ist es ein Speicherleck. Wenn nicht, ist das normal. –

+0

Nein, wird es nicht. Der Speicher bleibt 9.09M. Aber das ist das Problem. Ich habe eine Ansicht, wenn add dann entfernt, 300k Speicher wird hinzugefügt! – Ning

+3

Wenn der Speicher bei 9.09M bleibt und nicht größer wird, wenn Sie die Ansicht öffnen und schließen, haben Sie kein Speicherleck. Es ist normal. Sie können nicht alle Ressourcen vollständig an das System zurückgeben. Einige von ihnen bleiben bei der Bewerbung stecken. Solange die Anwendung sie wiederverwenden kann, ist das kein Problem. –

Antwort

3

Das ist normal. Es ist aufgrund eines Algorithmus "faul wachsen, Lazy Shrink". Das bedeutet, dass Sie eine Datenstruktur haben, die für eine kleine Anzahl von Elementen oder eine große Anzahl von Elementen dimensioniert werden kann. Die Größenanpassung für eine kleine Anzahl von Elementen benötigt nur sehr wenig Speicher, ist jedoch nicht effizient, wenn eine große Anzahl von Elementen gehandhabt wird. Die Größenanpassung für große Zahlen ist sehr effizient für die Verwaltung großer Sammlungen von Objekten, benötigt jedoch mehr Speicher zum Indizieren der Objekte.

Ein "fauler Grow, Lazy Shrink" -Algorithmus versucht, die Kosten für die Größenänderung eines Strukturindex zu vermeiden, indem der Index nur vergrößert wird, wenn er viel zu klein ist, und nur verkleinert wird, wenn er viel zu groß ist. Zum Beispiel kann ein typischer Algorithmus den Index nur vergrößern, wenn seine ideale Größe mindestens dreimal so groß ist wie er ist, und nur verkleinern, wenn er mehr als das Dreifache seiner idealen Größe beträgt. Dies ist auch erforderlich, um eine große Anzahl von Größenänderungsoperationen zu verhindern, wenn eine Anwendung Ressourcen schnell zuordnet und freigibt - die Indexgröße soll etwas "sticky" sein.

Wenn Sie das große Objekt öffnen und GUI-Objekte konsumieren, machen Sie den Index viel zu klein und er wächst. Aber wenn Sie das große Objekt schließen, machen Sie den Index nur ein bisschen zu groß, so dass er nicht schrumpft.

Wenn das Gerät unter Speicherdruck gerät, schrumpft der Index. Wenn die Anwendung weiterhin die Verwendung von UI-Ressourcen reduziert, wird der Index verkleinert. Wenn die Anwendung mehr UI-Ressourcen verwendet, muss der Index nicht so schnell wieder wachsen.

Eine gute Analogie könnte Stapel Papier auf Ihrem Schreibtisch sein. Wenn du 30 Papiere hast, die du vielleicht finden musst, kannst du sie in 4 Stapeln behalten. Aber wenn Sie 5.000 Papiere haben, werden 4 Stapel die Suche mühsam machen. Sie werden in diesem Fall mehr Stapel benötigen. Wenn also die Anzahl der Blätter für 4 Stapel zu groß wird, müssen Sie in eine größere Anzahl von Stapeln neu indizieren. Aber dann, wenn die Zahl klein wird, werden Sie sich nicht bemühen, ständig neu zu indizieren, bis Sie viel zu viele Stapel haben, weil die Suche immer noch ziemlich schnell ist.

Wenn Sie mit all diesen Papieren fertig sind, hat Ihr Schreibtisch ein paar zusätzliche Stapel. Das erspart das erneute Indizieren, wenn es das nächste Mal viel Papier verarbeiten muss.

+1

Danke für Ihre so detaillierte Antwort!Jetzt bin ich sehr klar ~~ :) – Ning