Diese Seite wurde von der Cloud Translation API übersetzt.

Übersicht über die Speicherverwaltung

Die virtuelle Maschine Android Runtime (ART) und Dalvik nutzen Plaging und memory-mapping (mmapping) verwendet. Das bedeutet, dass sich jede App ändert – sei es durch Zuweisen neue Objekte oder das Berühren von zugeordneten Seiten – verbleiben im RAM und kann nicht ausgecheckt werden. Die einzige Möglichkeit, eine Erinnerung von einer App freizugeben, besteht darin, auf das die App verweist, wodurch der Speicher für für die automatische Speicherbereinigung. Mit einer Ausnahme: Alle Dateien, die ohne Änderung mmapped werden, z. B. Code, können aus dem RAM ausgelagert werden, wenn das System diesen Speicher an anderer Stelle verwenden möchte.

Auf dieser Seite wird erläutert, wie Android App-Prozesse und -Speicher verwaltet Zuordnung. Weitere Informationen zum effizienteren Verwalten des Arbeitsspeichers in Ihrer App finden Sie unter App-Speicher verwalten

Automatische Speicherbereinigung

In einer verwalteten Arbeitsspeicherumgebung wie der ART- oder Dalvik-VM wird jede Arbeitsspeicherzuweisung erfasst. Sobald festgestellt wird, dass ein Teil des Speichers nicht mehr vom Programm verwendet wird, und gibt sie wieder auf den Heap frei, ohne dass der Programmierer etwas tun muss. Der Mechanismus zur Rückgewinnung von ungenutztem Arbeitsspeicher in einer verwalteten Arbeitsspeicherumgebung wird als automatische Speicherbereinigung bezeichnet. Die automatische Speicherbereinigung hat zwei Ziele: Datenobjekte in einem Programm finden, auf die in Zukunft nicht mehr zugegriffen werden kann; und Ressourcen zurückfordern, die von diesen Objekten genutzt wurden.

Der Speicher-Heap von Android ist eine Generation. verschiedene Arten von Zuweisungen, die erfasst werden, basierend auf der erwarteten Lebensdauer und Größe eines zuzuweisenden Objekts. Beispielsweise gehören kürzlich zugewiesene Objekte zur Junge Generation. Wenn ein Objekt lange genug aktiv bleibt, kann es in eine ältere Generation und dann in eine dauerhafte Generation hochgestuft werden.

Für jede Heap-Generation gilt eine eigene Obergrenze für den Wert die Objekte darin einnehmen können. Jedes Mal, wenn eine Generierung beginnt ausgeführt wird, führt das System eine automatische Speicherbereinigung aus. um Arbeitsspeicher freizugeben. Dauer der automatischen Speicherbereinigung hängt davon ab, welche Generierung von Objekten erfasst wird und wie viele aktive Objekte es in jeder Generation gibt.

Auch wenn die automatische automatische Speicherbereinigung ziemlich schnell ist, die Leistung Ihrer App beeinflussen. Im Allgemeinen steuern Sie nicht, Wenn in Ihrem Code ein Ereignis für die automatische Speicherbereinigung auftritt. Das System hat eine Reihe von Kriterien, anhand derer bestimmt wird, wann die automatische Speicherbereinigung durchgeführt werden soll. Wenn die Kriterien erfüllt sind, beendet das System die Ausführung des Prozesses und beginnt mit der Garbage Collection. Wenn Die automatische Speicherbereinigung erfolgt mitten in einer intensiven Verarbeitungsschleife. z. B. bei Animationen oder während der Musikwiedergabe, kann sich die Verarbeitungszeit erhöhen. Diese Erhöhung kann dazu führen, dass die Codeausführung in Ihrer App über die empfohlenen Grenzwert von 16 ms für ein effizientes und flüssiges Frame-Rendering.

Außerdem führt Ihr Codefluss möglicherweise Aufgaben aus, die Erzwingen, dass Ereignisse für die automatische Speicherbereinigung auftreten häufiger oder länger andauern. Wenn Sie beispielsweise mehrere Objekte in der den innersten Teil einer For-Schleife während jedes Frames eines Alpha-Tracks können Sie Ihren Gedächtnis-Heap mit einer und viele Objekte. In diesem Fall führt der Garbage Collector mehrere Garbage Collection-Ereignisse aus und die Leistung Ihrer App kann beeinträchtigt werden.

Allgemeinere Informationen zur Garbage Collection finden Sie unter Garbage Collection.

Erinnerung teilen

Damit alles, was es im RAM benötigt, Android versucht, RAM-Seiten prozessübergreifend zu teilen. Es können Sie dies folgendermaßen tun:

Jeder Anwendungsprozess wird von einem vorhandenen Prozess namens Zygote abgespalten. Der Zygote-Prozess wird gestartet, wenn das System hochfährt, und lädt gängigen Framework-Code und Ressourcen (z. B. Aktivitätsthemen) Um einen neuen App-Prozess zu starten, erstellt das System einen Fork des Zygote-Prozesses und lädt dann den Code der App in den neuen Prozess. Bei diesem Ansatz können die meisten RAM-Seiten Framework-Code und Ressourcen, die in allen App-Prozessen gemeinsam genutzt werden können.
Die meisten statischen Daten werden in einen Prozess mmapped. Mit diesem Verfahren können Daten zwischen Prozessen und ermöglicht zudem, bei Bedarf anpassen. Beispiele für statische Daten: Dalvik-Code (durch Einfügen in ein vorab verknüpftes .odex-Objekt) für die direkte Zuordnung), App-Ressourcen (indem die Ressourcentabelle als Struktur das sich verkleiden lässt, und indem Sie den Reißverschluss des APK) und herkömmliches Projekt Elemente wie nativer Code in .so-Dateien.
Vielerorts verwendet Android die gleiche Dynamik, prozessübergreifender RAM mit explizit zugewiesenem gemeinsamen Speicherregionen (entweder mit Ashmem oder Gralloc). Beispielsweise verwenden Fensteroberflächen gemeinsam genutzten Arbeitsspeicher zwischen der App und dem Bildschirmkompositierer und Cursor-Buffer gemeinsam genutzten Arbeitsspeicher zwischen dem Inhaltsanbieter und dem Client.

Aufgrund der intensiven Nutzung von gemeinsam genutztem Arbeitsspeicher wie viel Speicher deine App benötigt . Techniken zur richtigen Bestimmung der werden in den Videos RAM-Nutzung prüfen

App-Arbeitsspeicher zuweisen und freigeben

Der Dalvik-Heap ist auf eine virtueller Speicherbereich für jeden Anwendungsprozess erstellen. Hiermit wird definiert, logische Heap-Größe, die je nach Bedarf aber nur bis zu einem vom System definierten Grenzwert für jede App.

Die logische Größe des Heaps ist nicht dasselbe wie die Menge an physischem Arbeitsspeicher, die vom Heap verwendet wird. Bei der Untersuchung des Heaps Ihrer App berechnet Android einen Wert namens Proportional Set Size (PSS), was sowohl für schmutzige als auch für saubere Seiten die mit anderen Prozessen geteilt werden – aber nur in einem Betrag, der proportional zur Anzahl der Apps ist, RAM. Diese Summe (PSS) entspricht dem, ist Ihr physischer Speicherbedarf. Weitere Informationen zu PSS finden Sie in der RAM-Nutzung prüfen .

Der Dalvik-Heap verdichtet nicht das logische die Größe des Heaps, was bedeutet, dass Android den Heap defragmentieren, um den Bereich zu defragmentieren. Android kann die Größe des logischen Heaps nur dann verkleinern, wenn am Ende des Heaps nicht genutzter Speicherplatz vorhanden ist. Sie können jedoch kann das System trotzdem den vom Heap verwendeten physischen Arbeitsspeicher reduzieren. Nach der automatischen Speicherbereinigung geht den Heap, findet nicht verwendete Seiten und gibt dann diese Seiten mit Madvise an den Kernel zu senden. Wenn also Zuweisungen und Deallocations von Blöcke sollten alles (oder fast alle) zurückfordern verwendet wird. Das Zurückfordern von Speicher aus kleinen Zuweisungen kann jedoch viel weniger effizient sein, da die Seite, die für eine kleine Zuweisung verwendet wird, möglicherweise noch mit etwas anderem geteilt wird, das noch nicht freigegeben wurde.

App-Speicher einschränken

Um eine funktionierende Multitasking-Umgebung aufrechtzuerhalten, Android legt ein festes Limit für die Heap-Größe fest für jede App. Das genaue Limit für die Heap-Größe variiert zwischen Geräten, je nachdem, wie viel RAM sie haben. insgesamt verfügbar ist. Wenn Ihre App die Heap-Kapazität und versucht, mehr Arbeitsspeicher erhalten, kann sie ein OutOfMemoryError empfangen.

In einigen Fällen kann es sinnvoll sein, um genau zu bestimmen, wie viel Heap-Speicherplatz die auf dem aktuellen Gerät verfügbar sind, wie viele Daten sicher in einem Cache gespeichert werden. Sie können das System nach dieser Zahl abfragen, indem Sie getMemoryClass() Diese Methode gibt eine Ganzzahl zurück, die die Anzahl der Megabyte für den Heap Ihrer App verfügbar.

Apps wechseln

Wenn Nutzer zwischen Apps wechseln, Android hält Apps, die nicht im Vordergrund, d. h. für den Nutzer nicht sichtbar sind, Dienste im Vordergrund wie die Musikwiedergabe, im Cache gespeichert. Wenn ein Nutzer beispielsweise zum ersten Mal eine App startet, wird ein Prozess dafür erstellt. Wenn der Nutzer die App jedoch verlässt, wird dieser Prozess nicht beendet. Das System hält den Prozess im Cache. Wenn der Nutzer später zur App zurückkehrt, verwendet das System den Prozess wieder, wodurch das App-Wechseln schneller wird.

Wenn Ihre Anwendung einen im Cache gespeicherten Prozess hat und Ressourcen beibehält die es derzeit nicht benötigt, wird Ihre App – auch wenn der Nutzer sie nicht verwendet – die Leistung des Systems die Gesamtleistung. Da das System nur noch wenig Arbeitsspeicher hat, kann es sein, werden Prozesse im Cache beendet. Das System stellt Prozesse mit dem meisten Arbeitsspeicher bereit und können sie beenden, um RAM freizugeben.

Hinweis:Je weniger Arbeitsspeicher Ihre Anwendung im Cache verbraucht, desto besser sind die Chancen, nicht getötet zu werden und schnell wieder aufgenommen zu werden. Abhängig von den aktuellen Systemanforderungen ist es jedoch möglich, Prozesse unabhängig von ihrer Ressourcennutzung jederzeit beendet werden können.

Weitere Informationen dazu, wie Prozesse im Cache gespeichert werden, wenn sie nicht im Vordergrund ausgeführt werden, und wie Android entscheidet, welche Prozesse beendet werden können, finden Sie im Leitfaden Prozesse und Threads.

Speicher-Stresstest

Auf High-End-Geräten treten seltener Speicherprobleme auf, sie können aber trotzdem zu Problemen führen. für Nutzer mit wenig RAM, z. B. Geräten mit Android (Go-Edition). Es ist wichtig, Diese speicherlastige Umgebung reproduzieren, damit Sie Instrumentierungstests zur App-Überprüfung schreiben können und die Nutzererfahrung auf Geräten mit wenig Arbeitsspeicher verbessern.

Stresstests

Stresser Anwendungstest (stressapptest) ist ein Speicherschnittstellentest, mit dem realistische Situationen mit hoher Belastung erstellt werden können, um verschiedene Speicher und Hardwareeinschränkungen für Ihre App. Dank der Fähigkeit, Zeit- und Speicherbeschränkungen zu definieren, ermöglicht Ihnen das Schreiben von Instrumentierungen, um reale Begegnungen in Situationen mit großem Speicher zu verifizieren. Verwenden Sie beispielsweise die folgenden Befehle, um die statische Bibliothek in Ihr Datendateisystem zu übertragen. machen sie ausführbar und führen Sie einen Belastungstest für 20 Sekunden (990 MB) durch:

    adb push stressapptest /data/local/tmp/
    adb shell chmod 777 /data/local/tmp/stressapptest
    adb shell /data/local/tmp/stressapptest -s 20 -M 990

Weitere Informationen zur Installation des Tools, zu gängigen Argumenten und zur Fehlerbehandlung finden Sie in der stressapptest-Dokumentation.

Beobachtungen zu Stressapptest

Mit Tools wie stressapptest können Speicherzuweisungen angefordert werden, die größer als frei verfügbar sind verfügbar. Diese Art von Anfrage kann verschiedene Benachrichtigungen auslösen, die Sie im auf der Entwicklungsseite. Die drei wichtigsten Warnungen, die aufgrund geringer Arbeitsspeicherverfügbarkeit ausgelöst werden können, sind:

SIGABRT: Dies ist ein schwerwiegender, nativer Absturz für Ihren Prozess aufgrund der Anforderung von größer als der kostenlose Arbeitsspeicher ist, während das System bereits unter Speicherauslastung steht.
SIGQUIT: Erzeugt einen Dump des Kernspeichers und beendet den Prozess, wenn dieser vom Instrumentierungstest erkannt wird.
TRIM_MEMORY_EVENTS: Diese Callbacks sind ab Android 4.1 (API-Level 16) verfügbar und enthalten detaillierte Speicherbenachrichtigungen für Ihren Prozess.