Arbeitsspeicherverwaltung

Die Arbeitsspeicheroptimierung ist entscheidend für stabile und leistungsstarke Spielerlebnisse auf Android. In diesem Leitfaden erfahren Sie, warum die Arbeitsspeichereffizienz wichtig ist, wie das Android-Betriebssystem Arbeitsspeicherlimits für Prozesse verwaltet und welche neuen Arbeitsspeichermesswerte in der Google Play Console verfügbar sind, mit denen Sie die technische Qualität Ihres Spiels überwachen und verbessern können.

Bedeutung der Arbeitsspeicheroptimierung

Die Optimierung des Arbeitsspeichers Ihres Spiels ist wichtig, um die Nutzerbindung aufrechtzuerhalten, die Gerätekompatibilität zu erweitern und die Qualitätsstandards der Plattform einzuhalten:

  • Verhinderung von Kaltstarts (Nutzererfahrung und ‑bindung): Wenn ein Spieler vorübergehend von Ihrem Spiel zu einer anderen App wechselt (z. B. um eine Benachrichtigung zu beantworten oder eine Nachricht zu lesen), wird der Spielprozess vom Betriebssystem in den Hintergrund verschoben. Wenn der Speicherbedarf des Spiels im Hintergrund zu hoch ist, beendet der Low Memory Killer (LMK) des Systems den Spielprozess vorrangig, um RAM für Vordergrundaufgaben freizugeben. Wenn der Nutzer das Spiel das nächste Mal fortsetzt, muss es einen langen Kaltstart durchlaufen, anstatt nahtlos und sofort wieder aufgenommen zu werden. Dabei werden umfangreiche Grafik-Assets, Audio und Binärdateien der Game Engine vollständig aus dem Speicher neu geladen. Wenn Sie die Arbeitsspeichernutzung im Hintergrund niedrig halten, werden diese stillen Beendigungen im Hintergrund verhindert. So bleibt der Nutzerstatus erhalten und Spieler können ihre Sitzung sofort fortsetzen. Weitere Informationen zum LMK-Verhalten des Systems finden Sie im Leitfaden Android Vitals – Low Memory Killer.
  • Ökosystem- und Gerätestabilität: Eine ineffiziente Arbeitsspeichernutzung und Arbeitsspeicher lecks beeinträchtigen die allgemeine Systemleistung. Wenn der Systemspeicher knapp ist, wird das System stark belastet, was zu niedrigeren Frameraten, UI-Rucklern und Audiofehlern führt. Wenn der Arbeitsspeicherdruck zu hoch ist, beendet der Low Memory Killer (LMK) des Systems aggressiv Hintergrundprozesse. Dadurch müssen andere Anwendungen langsame Kaltstarts durchlaufen und der Nutzerstatus geht verloren, wenn Spieler zwischen Aufgaben wechseln.
  • Beendigungen auf Plattformebene: Ab Android 17 (API-Level 37) beendet das System proaktiver Prozesse, die zu viel Arbeitsspeicher verwenden. Wenn die Arbeitsspeichernutzung Ihres Spiels zu hoch ist, kann das Betriebssystem den Prozess abrupt beenden, ohne einen Standard-Stacktrace zu generieren.
  • Gerätekompatibilität: Flaggschiffgeräte haben zwar 12 bis 16 GB RAM, aber ein Großteil der weltweiten Gaming-Zielgruppe verwendet Geräte mit 4 oder 6 GB RAM. Durch eine ordnungsgemäße Arbeitsspeicherverwaltung bleibt Ihr Spiel auf allen Hardwareebenen zugänglich und reaktionsschnell, ohne dass komplexe, separate Asset-Pakete erforderlich sind.

Arbeitsspeicher in Android

Um effektive Strategien für die Arbeitsspeicherbudgetierung zu entwickeln, müssen Entwickler wissen, wie die Android-Plattform den physischen Arbeitsspeicher verwaltet und wie sie die aktive Arbeitsspeichernutzung Ihres Spiels misst.

Grundlegende Android-Arbeitsspeicherkonzepte

Grundlegende Konzepte zur Arbeitsspeicherverwaltung auf Plattformebene finden Sie in der offiziellen Dokumentation Übersicht über die Arbeitsspeicherverwaltung. Diese Ressource umfasst vier Architekturbereiche:

  • Arbeitsspeicherübersicht: Android verwendet Paging und Memory-Mapping (mmap) zur Verwaltung von RAM. Eine herkömmliche Auslagerungsdatei auf der Festplatte wird nicht unterstützt. Stattdessen werden Seitenkomprimierung (mit zRAM) und Seitenrückforderung verwendet, um physischen Arbeitsspeicher freizugeben.
  • Arbeitsspeicherzuweisung an Prozesse: Android teilt RAM im gesamten System. Es weist bestimmte Heaps für die Ausführung von Dalvik- oder ART-VMs zu, während native Entwicklungsumgebungen (z. B. C++-Game Engines) Arbeitsspeicher aus dem nativen System-Heap anfordern können.
  • App-Arbeitsspeicherverwaltung: Android verwendet ein Mehrprozessmodell. Anwendungen müssen ihren Lebenszyklusstatus dynamisch überwachen und unnötige Ressourcen (z. B. nicht im Cache gespeicherte Grafiken und Bitmaps) freiwillig freigeben, um die Systemleistung zu unterstützen.
  • Übersicht über Prozesse und Threads: Das System kategorisiert Prozesse in einer Hierarchie basierend auf ihrer aktuellen, für den Nutzer sichtbaren Sichtbarkeit und Bedeutung. So wird festgelegt, welche Prozesse aktiv bleiben und welche bei wenig Arbeitsspeicher zuerst beendet werden.

Messwert für den gesamten Speicherbedarf

Der Android 17 Memory Limiter auf Plattformebene bewertet die Prozessnutzung anhand der gesamten Arbeitsspeichernutzung und nicht anhand der gesamten residenten Größe (RSS) oder der virtuellen Arbeitsspeichergröße.

Gesamte Arbeitsspeichernutzung = Anonymer RSS (RssAnon) + Unkomprimierter Swap (VmSwap)

Damit Spiele die Plattformlimits nicht überschreiten, müssen Sie genau wissen, was diese Messwerte auf Systemebene darstellen. Weitere Informationen zu diesen Messwerten, physischen RAM-Zuweisungen und zur Verarbeitung von dateibasierten Seiten finden Sie im Leitfaden Arbeitsspeichernutzung überwachen unter RSS- und Swap-Messwerte.

Arbeitsspeicherbeschränkungen

Um die Systemstabilität aufrechtzuerhalten und zu verhindern, dass Anwendungen zu viele Ressourcen verbrauchen, verwaltet die Android-Plattform Arbeitsspeicherlimits für laufende Prozesse.

Memory Limiter in Android 17 und höher

Android 17 (API-Level 37) und höher verwalten strenge, app-spezifische Arbeitsspeicherlimits mit Linux cgroup v2, um zu verhindern, dass einzelne Apps systemweite Instabilität verursachen. Weitere Informationen zur technischen Implementierung finden Sie im AOSP Memory Limiter Guide und im Blogpost Prioritizing Memory Efficiency: Essential Steps for Android 17.

  • Mechanismus: Der Memory Limiter überwacht alle Anwendungsprozesse und weist dynamisch Limits basierend auf dem Lebenszyklusstatus des Prozesses zu:
    • Sichtbare Prozesse (Vordergrund): Für App-Prozesse, die derzeit eine UI anzeigen, wird ein größeres Ressourcenset erwartet und es wird ein großzügigeres Limit gewährt.
    • Nicht sichtbare Prozesse (Hintergrund oder Dienste): App-Prozesse, die aktiv arbeiten, ohne eine UI anzuzeigen, sind auf ein engeres, restriktiveres Budget beschränkt.
  • Kernelattribute: Der Dienst basiert auf zwei Hauptattributen:
    • memory.high: Ein weiches Limit. Wenn es überschritten wird, drosselt der Kernel den Prozess und versucht, aggressiv Arbeitsspeicher zurückzufordern. Diese Rückforderung kann zu einer Leistungsminderung des Spiels führen.
    • memory.swap.max: Verwaltet eine harte Obergrenze für den Swap- oder zRAM-Speicher, den der Prozess verwenden kann.
  • Beendigungsverhalten: Wenn ein Prozess weiterhin anonymen Arbeitsspeicher über memory.high hinaus zuweist und seine Swap-Kapazität erschöpft, schlagen die Zuweisungen fehl und das Betriebssystem beendet den Prozess im Hintergrund. Diese Beendigung wird mit ApplicationExitInfo unter dem Beendigungsgrund „Memory Limiter“ protokolliert (verfügbar ab Android 17, 4. Quartal 2026).

Neue Arbeitsspeicherlimits in Play Console Vitals

Damit Entwickler Arbeitsspeicherprobleme proaktiv erkennen können, führt Google Play neue Messwerte in Play Console Android Vitals ein. In der Play Console wird das 90. Perzentil (P90) des anonymen RSS- und Swap-Speicherbedarfs Ihrer Spielsitzungen erfasst, um extreme Ausreißer zu identifizieren.

Die Warn- und Erzwingungsschwellen werden basierend auf der physischen RAM-Kapazität und den Prozessstatus des Geräts skaliert. Diese Limits gelten in zwei verschiedenen Phasen.

Detaillierte Richtlinien und Arbeitsspeicherlimits finden Sie unter Android Vitals – Was sind die Schwellenwerte für schlechtes Verhalten?.

Für Nutzer sichtbare Dienste

Wahrnehmbare Dienste sind wichtige Hintergrundprozesse, die das Android-System als für den Nutzer wahrnehmbar betrachtet. Dieser Status umfasst alle laufenden Prozesse:

  • Dienste im Vordergrund (Foreground Services, FGS)
  • Express-Jobs
  • Vom Nutzer initiierte Datenübertragungsvorgänge
  • Systemgebundene Dienste oder Dienste, die von anderen Anwendungen gebunden sind

Da wahrnehmbare Dienste für kritische, lang andauernde Aufgaben im Hintergrund konzipiert sind, sind sie sehr anfällig für kumulative Lebenszykluslecks. Bei den Arbeitsspeicherlimits der Android-Plattform wird dieser Status nicht als Vordergrund betrachtet. Wenn Ihr Spiel also im Hintergrund ausgeführt wird, aber weiterhin einen wahrnehmbaren Dienst ausführt, unterliegt es den strengeren Arbeitsspeicherlimits für Hintergrundprozesse oder Dienste, die auf der Google Play-Hilfeseite aufgeführt sind. Spiele müssen unnötige Assets aggressiv entfernen, wenn sie vom Vordergrund in einen wahrnehmbaren Dienststatus im Hintergrund wechseln.

R8-Anforderungen

Um die Bytecode-Größe zu minimieren und den Overhead grundlegender Java-Prozesse zu reduzieren, bewertet die Google Play Console die Codeoptimierung im Rahmen ihrer Qualitätsrichtlinien für Apps. Weitere Informationen zum Konfigurieren Ihrer Build-Pipeline finden Sie im Leitfaden App-Optimierung mit R8 aktivieren.

Folgen Sie der Anleitung App-Optimierung mit R8 aktivieren, um R8 in Ihrem Projekt zu konfigurieren. Informationen zum Aktivieren erweiterter Einstellungen für das Shrinking und die Optimierung finden Sie unter R8 im vollständigen Modus verwenden. Wenn Sie herausfinden möchten, welche Regeln verhindern, dass R8 Klassen verschleiert oder toten Code entfernt, verwenden Sie den R8-Konfigurationsanalysator.

Bitmap-Anforderungen

Bitmaps machen einen großen Teil der Arbeitsspeichernutzung in modernen Spielen mit hoher Wiedergabetreue aus. Da Bitmap-Pixeldaten in Android 8.0 (API-Level 26) und höher direkt im nicht verwalteten nativen Heap gespeichert werden, kann das Laden nicht optimierter Bilder dazu führen, dass Prozesse die Arbeitsspeichergrenzwerte der Plattform überschreiten. Best Practices für die Bild skalierung und das Caching finden Sie unter Bildnutzung optimieren.

Arbeitsspeichernutzung überwachen

Um den Arbeitsspeicher Ihres Spiels effektiv zu optimieren, müssen Sie zuerst wissen, wie die Android-Plattform die Arbeitsspeichernutzung misst. In Android 17 wird der Arbeitsspeichermesswert aktualisiert, um die Summe aus anonymem RSS (RssAnon) und unkomprimiertem Swap (VmSwap) zu erfassen, wobei dateibasierter oder GPU-privater Arbeitsspeicher ausgeschlossen wird. In diesem Leitfaden wird beschrieben, wie Sie Tools auf Systemebene wie Perfetto und meminfo nutzen, Diagnose-APIs wie ProfilingManager und onTrimMemory implementieren und genaue Arbeitsspeicherzuweisungen in Unity und Unreal Engine extrahieren. Sie erfahren, wie Sie Ihr Spiel genau profilieren und die Leistungsruckler vermeiden, die mit der herkömmlichen Arbeitsspeicherabfrage zur Laufzeit verbunden sind.

Weitere Informationen finden Sie unter Arbeitsspeichernutzung überwachen.

Strategien zur Arbeitsspeicherreduzierung

Game Engines vereinfachen zwar die plattformübergreifende Entwicklung, aber ihre Standard-Arbeitsspeicherverwaltung kann Arbeitsspeicherlimits auf Betriebssystemebene auslösen. Auf dieser Seite werden praktische Optimierungsschritte beschrieben, die speziell auf Unity und Unreal Engine zugeschnitten sind. Sie erfahren, warum die Verwendung von Java-basiertem onTrimMemory in Unity zu Deadlocks führen kann und wie Sie stattdessen native Lebenszyklus-Callbacks verwenden. Außerdem werden wichtige Optimierungen auf Asset-Ebene beschrieben, z. B. die Verwendung der ASTC 8x8-Texturkomprimierung und das Konfigurieren des Entladens von Assets, damit Ihr Spiel auf allen Hardwareebenen reibungslos ausgeführt wird.

Weitere Informationen finden Sie unter Arbeitsspeichernutzung reduzieren.