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) verwenden. 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. Es gibt jedoch eine Ausnahme: ohne Änderungen eingefügt werden, wie z. B. Code, Wenn das System diesen Speicher woanders verwenden möchte, kann das aus dem RAM gelöscht werden.

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

Eine verwaltete Speicherumgebung wie die virtuelle ART- oder Dalvik-Maschine 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. Zuweisungen, die es verfolgt, 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 hochgestuft werden. auf eine ältere Generation, gefolgt von einer dauerhaften Generation.

Jede Heap-Generation hat 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 verfügt über eine Reihe laufender Kriterien, anhand derer ermittelt wird, wann die Ausführung erfolgen soll. automatische Speicherbereinigung. Sind die Kriterien erfüllt, stoppt das System die Ausführung des Prozesses und startet die automatische Speicherbereinigung. Wenn Die automatische Speicherbereinigung erfolgt mitten in einer intensiven Verarbeitungsschleife. z. B. in einer Animation oder während der Musikwiedergabe, kann dies die Verarbeitungszeit verlängern. 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 die automatische Speicherbereinigung mehrere automatische Speichervorgänge aus. und die Leistung Ihrer App beeinträchtigen können.

Allgemeine Informationen zur automatischen Speicherbereinigung finden Sie unter Müllabfuhr.

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 startet und lädt Framework-Code und -Ressourcen (z. B. Aktivitätsthemen). Um einen neuen App-Prozess zu starten, verzweigt das System den Zygote-Prozess. lädt den Anwendungscode im neuen Prozess und führt ihn aus. 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 eingebunden. Mit diesem Verfahren können Daten zwischen Prozessen und ermöglicht zudem, bei Bedarf anpassen. Beispiele für statische Daten: Dalvik-Code (durch Platzierung in einem vorab verknüpften .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 werden für Fensteroberflächen freigegebene Arbeitsspeicher zwischen App und Bildschirm-Compositor und Cursor-Zwischenspeichern nutzen gemeinsamen Speicher zwischen den Contentanbieter und Kunden.

Aufgrund der umfangreichen Nutzung von gemeinsamem 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-Geräte die logische Heap-Größe nur verkleinern kann, ist ungenutzter Platz am Ende des Heaps. 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. Sie können jedoch die Rückgewinnung von Arbeitsspeicher aus kleinen Zuweisungen weniger effizient ist, weil die verwendete Seite können für eine kleine Zuweisung etwas anderes, 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 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 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, in einem Cache. Wenn z. B. ein Nutzer zum ersten Mal eine App startet, wird ein Prozess dafür erstellt; aber wenn Nutzende die App verlässt, wird der Prozess nicht beendet. Das System hält den Prozess im Cache. Wenn wenn der Nutzer später zur App zurückkehrt, verwendet das System den Prozess noch einmal, wodurch der App-Wechsel beschleunigt 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, nicht im Vordergrund ausgeführt werden, Android entscheidet, welche getötet werden kann, siehe Prozesse und Threads .

Gedächtnis-Belastungstest

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.

Stressiger Anwendungstest

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 finden Sie in der stressapptest. Dokumentation mit weiteren Informationen zur Installation des Tools, zu häufigen Argumenten und zur Fehlerbehandlung Informationen.

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. Diese sollten Sie im auf der Entwicklungsseite. Die drei wichtigsten Warnungen, die aufgrund geringer Arbeitsspeicherverfügbarkeit ausgelöst werden können, sind: <ph type="x-smartling-placeholder">

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.