Unsere App erstellt beim Laufen viele kleine Objekte. Es kommt meistens auf automatisch freigegebene NSString- und NSNumber-Objekte an. Da die App im Hintergrund "rund um die Uhr" läuft, wird die Fragmentierung des Heapspeichers zu einem großen Problem.
Was sind die Techniken, um dies ohne eine vollständige Umstrukturierung des Programms zu vermeiden.
Ich habe gedacht: - Objektpools, die nach der endgültigen Freigabe das Objekt in einen Pool zurückgeben würden, Objekte müssen dann jedoch änderbar sein. (Wird NSMuttableString die Heapfragmentierung selbst verursachen?)
Wie gehen andere mit diesen Problemen um?
EDIT: So habe ich die Speicherfragmentierung verdächtig gemacht. Sehen Sie sich rpages und [vm-pageshortage] an
%Vor%Eine Möglichkeit, mit diesem Problem umzugehen, besteht darin, den "90%" -Täter zu finden, der das Fragmentierungsproblem verursacht. Sie haben wahrscheinlich eine pathologische Bedingung in Ihrem Code, die den Swiss-Käse-Effekt verursacht.
Es ist selbstverständlich, dass Sie zuerst davon überzeugt sein sollten, dass Ihre hohe Seitennutzung auf Fragmentierung zurückzuführen ist und nicht aufgrund eines Speicherlecks. : -)
Wenn Sie dies noch nicht getan haben, ist die Verwendung der App "Instruments" in Xcode eine hervorragende Möglichkeit, Ihrem Programm zuzusehen, wie es im iOS-Simulator Speicher reserviert. Mit den Werkzeugen Zuordnungen und Leaks können Sie jede Objektzuordnung und malloc () Ihres Codes zusammen mit praktischen Zeitstempeln aufzeichnen. (Und kostenlos, das Tool Leaks zeigt Ihnen Zyklen in Ihrer Objektkarte, wenn ARC Speicher nicht wie gewünscht freigeben soll.)
Normalerweise behalten die Tools den Speicher im Auge, der noch verwendet wird. Sie können die Created & amp; Zerstörte -Option im Konfigurationsbereich Zuordnungen , um den Überblick zu behalten, der im Popup-Fenster direkt über den Zusammenfassungsinformationen angezeigt werden kann.
Es gibt auch ein VM-Seitenzuordnungswerkzeug, das Ihr Problem beleuchten könnte.
Sobald Sie den Schuldigen ermittelt haben, können Sie Ihren Code restrukturieren, um den pathologischen Zustand zu verhindern. Oder wenn die Restrukturierung zu teuer ist, können Sie die Auswirkungen der Bedingung mindern, indem Sie den Speicher erneut verwenden.
Normalerweise, wenn die Analyse zeigt, dass Objektzuordnung und Freigabezuweisungen Löcher verursachen oder ein bestimmtes Objekt mit einer alarmierenden Häufigkeit zugewiesen / freigegeben wird, nehme ich den schuldigen Übeltäter und mache ihn zu einem Objekt "pool".
Dies kann so einfach sein, wie Objekte in einem NSMutableArray zu speichern und sie nach Bedarf zu verschieben und zu löschen.
Natürlich möchten Sie vielleicht etwas anspruchsvolleres, das beim Holen Objekte initialisiert, den Pool mit fertigen Objekten auffüllt und automatisch mit Objekten füllt, wenn es leer ist oder leer läuft. In iOS sollten Sie auch den Pool löschen, wenn zu viele Objekte gesammelt werden oder wenn eine Warnung zu wenig Speicher empfangen wird.
Das Schöne ist, dass dies ein sehr generischer Code sein kann, den Sie für immer wiederverwenden können. : -)
Sie erwähnen das Problem, Objekte nicht veränderlich zu machen. In einigen Fällen (wie NSString) kann es mit Effizienz helfen, wenn Sie (im Voraus) die Speicherplatzanforderungen und Manipulationen kennen, die Sie für die Zeichenfolge ausführen müssen. Auf diese Weise können Sie im Voraus feststellen, wie viel Platz Sie benötigen und die Zeichenfolge "in-place" bearbeiten, wodurch der Overhead der Zuweisung reduziert wird. (Was NSString tut unter der Haube ist ein ganz anderer Artikel.: -)
Tags und Links objective-c ios heap-fragmentation objectpool