Arbeitsspeichereffizienz priorisieren: Wichtige Schritte für Android 17

Die App-Leistung wird oft mit einer flüssigen Benutzeroberfläche und schnellen Startzeiten gleichgesetzt. Der Arbeitsspeicher ist jedoch die stille Grundlage, auf der diese sichtbaren Messwerte basieren. Es ist kein Geheimnis, dass der Gerätespeicher wichtiger denn je ist. Mit Android 17 haben wir nicht nur Fortschritte bei der Optimierung des Android-Arbeitsspeichers gemacht, sondern bieten auch die Tools und API-Unterstützung, die Sie benötigen, um die strengeren Anforderungen an den Arbeitsspeicher, die später in diesem Jahr in Kraft treten, zu erfüllen.

Damit die Geräte möglichst stabil funktionieren, werden ab Android 17 App-Arbeitsspeicherlimits erzwungen, die auf dem gesamten RAM eines Geräts basieren. Wenn eine App diese Limits überschreitet, beendet Android den Prozess ohne zugehörigen Stacktrace.

Neben diesen erzwungenen Beendigungen führt eine nicht optimierte Arbeitsspeichernutzung unweigerlich zu einer Beeinträchtigung der Nutzerfreundlichkeit. Wenn die App sich den Heap-Speicherlimits nähert, wird die automatische Speicherbereinigung häufig ausgelöst, was zu spürbaren Rucklern der Benutzeroberfläche führt. Wenn ein Gerät nicht mehr genügend Arbeitsspeicher hat, versucht das System, Seiten zurückzugewinnen. Das führt zu einer hohen CPU-Auslastung, einer verzögerten Benutzeroberfläche und einer schnellen Akkuentladung. Wenn der Arbeitsspeichermangel zu schwerwiegend ist, kann dies zu LMK-Ereignissen (Low Memory Killer) führen, die Hintergrundprozesse abrupt beenden und dazu führen, dass Apps langsame Kaltstarts haben und der Nutzerstatus verloren geht.

Damit Sie leistungsstarke Apps entwickeln und diese erzwungenen Beendigungen vermeiden können, empfehlen wir Ihnen, die folgenden Strategien zur Speicheroptimierung zu nutzen:

1. Bytecode-Optimierung mit R8 maximieren
2. Laden von Bildern optimieren
3. Speicherlecks mit Android Studio erkennen und beheben
4. Speicherplatz freigeben, wenn die App nicht mehr sichtbar ist
5. Erweiterte Arbeitsspeicherbeobachtung mit ProfilingManager

Eine gekürzte Version dieses Blogposts ist auch als Video verfügbar.

Arbeitsspeicherlimits für Apps unter Android 17

Mit Android 17 werden App-Arbeitsspeicherlimits eingeführt, um zu verhindern, dass ein „böswilliger Akteur“ das Multitasking und die Stabilität des gesamten Geräts beeinträchtigt.

Hier finden Sie eine Aufschlüsselung der Gründe für diese Architekturänderung:

• Kaskadierende Beendigungen verhindern: Wenn eine App aufgebläht ist oder Speicher verliert, während sie einen privilegierten Status hat (z.B. wenn sie einen Dienst im Vordergrund ausführt), ist sie anfangs vor dem Low Memory Killer (LMK) des Systems geschützt. Wenn diese einzelne App ungehindert wächst und RAM hortet, muss der LMK dies ausgleichen, indem er Dutzende kleinerer, gut funktionierender Apps im Cache und Hintergrundjobs beendet, um Speicherplatz für die speicherintensive App freizugeben.
   
• Multitasking und Nutzerstatus beibehalten:Wenn das System gezwungen ist, im Cache gespeicherte Apps zu löschen, um einen einzelnen Prozess mit Speicherleck unterzubringen, wird das Multitasking erheblich beeinträchtigt. Nutzer, die zu zuvor im Cache gespeicherten Anwendungen zurückkehren, erleben langsame Kaltstarts anstelle von fast sofortigen Warmstarts. Diese Ineffizienz führt zu einer höheren CPU-Belastung und beschleunigt die Entladung des Akkus. Außerdem kann der Kontext des Nutzers in zuletzt verwendeten Apps verloren gehen, z. B. Scrollpositionen, Navigationsstapel und der Fortschritt im Spiel.

Wenn Sie feststellen möchten, ob Ihre App-Sitzung im Feld von diesen Einschränkungen betroffen war, können Sie getDescription() in ApplicationExitInfo aufrufen. Wenn das System ein Limit angewendet hat, wird der Beendigungs-Grund als REASON_OTHER gemeldet und der Beschreibungsstring enthält „MemoryLimiter:AnonSwap“. Sie können auch triggerbasiertes Profiling mit TRIGGER_TYPE_ANOMALY verwenden, um automatisch Heap-Dumps zu erfassen, wenn das Speicherlimit erreicht wird. Außerdem arbeitet Android aktiv daran, Entwicklern in der Google Play Console mehr Messwerte zum Arbeitsspeicher im Feld zur Verfügung zu stellen.

Wir haben auch unsere Dokumentation zu Speicherlimits um lokale Debugging-Befehle erweitert. So können Sie Speicherbeschränkungen in Ihrer lokalen Umgebung simulieren und das Verhalten Ihrer Anwendung bei der Durchsetzung von Speicherlimits validieren. 

Bytecode-Optimierung mit R8 maximieren

Eine sehr effektive Möglichkeit, den Speicherbedarf Ihrer App zu reduzieren, ist die Aktivierung des R8-Optimierers. Durch das Verkürzen von Klassen-, Methoden- und Feldnamen und das Entfernen von nicht verwendetem Code und nicht verwendeten Ressourcen reduziert R8 den Speicherbedarf Ihrer App erheblich, da die Menge an residentem Code, der während der Ausführung benötigt wird, minimiert wird. 

R8 minimiert den residenten Code, wodurch der Speicherbedarf verringert und das Risiko einer LMK-Beendigung gesenkt wird. Dies führt zu häufigeren Warmstarts im Vergleich zu langsamen Kaltstarts. Außerdem wird durch optimierten Bytecode der CPU-Overhead des Hauptthreads reduziert, was sich direkt auf die ANR-Raten auswirkt und für eine flüssigere Nutzererfahrung sorgt. Die digitale Bank Monzo hat beispielsweise die vollständige R8-Optimierung aktiviert und konnte so die ANR-Rate um 35 %, die Kaltstartrate um 30% und die Gesamtgröße der App um 9% reduzieren.

So konfigurieren Sie R8 in der Datei build.gradle richtig:

• Legen Sie isShrinkResources = true und isMinifyEnabled = true fest.
• Verwenden Sie proguard-android-optimize.txt anstelle des alten proguard-android.txt, das Optimierungen verhindert und im Android-Gradle-Plug-in 9 nicht mehr unterstützt wird.
• Entfernen Sie android.enableR8.fullMode = false von Ihrem gradle.properties.

Wenn Sie in Ihrer Codebasis Reflection verwenden, fügen Sie Keep-Regeln hinzu, um zu verhindern, dass R8 diese Teile des Codes optimiert. Beschränken Sie die Aufbewahrungsregeln so weit wie möglich, um die Optimierung zu maximieren. 

Wenn Sie die folgenden Best Practices in Ihrer Keep-Regeldatei beachten, können Sie die Optimierung maximieren.

• Entfernen Sie globale Optionen wie -dontoptimize, -dontshrink und -dontobfuscate, die verhindern, dass R8 den gesamten Code optimiert.
• Entfernen Sie Keep-Regeln, die die Optimierung von Android-Komponenten wie Activity, Services, Views oder Broadcast-Empfängern verhindern.
• Verfeinern Sie die allgemeinen Keep-Regeln für das Paket, sodass sie nur auf bestimmte Klassen oder Methoden angewendet werden. 

Weitere Best Practices finden Sie in unserer Dokumentation zu Aufbewahrungsregeln.

Best Practices für R8 für Bibliotheksentwickler

Wenn Sie Bibliotheken entwickeln, sollten Sie die Regeln, die Ihre Nutzer benötigen, unbedingt in Ihre consumer-rules file-Datei aufnehmen und die internen Schutzregeln Ihrer Bibliothek in der Datei proguard-rules.pro beibehalten. Weitere Informationen zum Optimieren von Bibliotheken finden Sie unter Optimierung für Bibliotheksautoren.

R8-Konfigurationsanalysetool

Verwenden Sie den Konfigurationsanalysator, um Ihre R8-Optimierung zu prüfen. Der Konfigurationsanalysator zeigt den aktuellen Optimierungsstatus mit Scores für Verschleierung, Optimierung und Verkleinerung an. Mit dem Konfigurationsanalysetool können Sie auch nachvollziehen, wie viele Klassen, Methoden oder Felder durch jede Keep-Regel von der Optimierung ausgeschlossen werden. Wenn Sie diese allgemeinen Regeln zum Beibehalten von Paketen verfeinern, können Sie die Optimierung maximieren. 

Mit dem Konfigurationsanalysetool können Sie auch Keep-Regeln identifizieren, die andere Keep-Regeln subsumieren, sowie redundante und ungenutzte Keep-Regeln.

R8-Agenten-Skill 

Sie können auch den R8 Agent Skill mit dem Android Studio-Agent oder anderen KI-Tools verwenden, um Fehlkonfigurationen zu beheben und Ihre Regeln zu optimieren. Dadurch wird die App-Leistung verbessert. (Für Statistiken zu KI-gestützten Skills ist eine technische Bestätigung erforderlich.)

Laden von Bildern optimieren

Bitmaps sind in der Regel die größten gängigen Objekte im Arbeitsspeicher Ihrer App. Sie stellen die letzte Phase des Bildladeverfahrens dar, in der komprimierte Dateien wie JPEGs oder PNGs in Rohpixeldaten für die Anzeige dekodiert werden. Das bedeutet, dass ein kleines komprimiertes Bild mit 100 KB mehrere Megabyte RAM belegen kann, da der Arbeitsspeicherverbrauch durch die Pixelabmessungen und die Farbtiefe des Bildes bestimmt wird. Da Bitmap-Vorgänge häufig auf dem kritischen Pfad zum Zeichnen von Frames liegen, führen nicht optimierte Bilder zu einem erheblichen Speicherverbrauch und Ruckeln der Benutzeroberfläche.

Google empfiehlt, für Kotlin-basierte Projekte Bildladebibliotheken wie Coil zu verwenden, insbesondere wenn Sie mit Jetpack Compose entwickeln, und für Java-basierte Anwendungen Glide.

Fünf Best Practices

1. Bilder mit niedrigerer Auflösung verwenden:Wenn Sie Bitmaps manuell laden, sollten Sie kein riesiges Bild in eine winzige Miniaturansicht laden. Verwenden Sie inSampleSize, um eine kleinere Version zu laden. Glide und Coil führen standardmäßig ein Downsampling von Bildern durch. Sie können diese Downsampling-Strategie mit DownsampleStrategy bzw. ImageLoader konfigurieren.
2. Zuschneiden : Betten Sie kein Padding direkt in eine Bilddatei ein, um Letterboxing zu erzielen (z.B. durch Erstellen eines transparenten Rahmens, um die Abmessungen eines Bildes zu erweitern). Anstatt diese Ränder fest zu codieren, sollten Sie InsetDrawable verwenden oder das Padding direkt in der View oder Composable anwenden, die die Bitmap enthält.
3. Konfiguration:Wählen Sie das richtige Pixelformat aus, um ein ausgewogenes Verhältnis zwischen Speicher und Qualität zu erzielen. Verwenden Sie RGB_565, wenn keine Transparenz erforderlich ist. Dieses Format benötigt nur halb so viel Speicherplatz wie das Standardformat ARGB_8888. In Glide können Sie dies mit DecodeFormat konfigurieren und in Coil mit dem Attribut bitmapConfig.
4. Vektordrawables priorisieren:Verwenden Sie für einfache geometrische Assets ShapeDrawable als schlanke Alternative zum Decodieren von gerasterten Bitmaps. Wenn Sie diese Assets einmal über XML definieren, lassen sie sich nahtlos auf alle Displaydichten skalieren. Außerdem wird so speicherintensiver Ressourcen-Bloat effektiv vermieden.
5. Wiederverwendung:Wenn Ihre Anwendung Bitmaps manuell verwaltet, sollte sie, um den Speicherverbrauch zu minimieren, bitmap.recycle() aufrufen und die Bitmap-Referenz sofort verwerfen, wenn ein Bitmap nicht mehr benötigt wird. Wenn Sie eine Bibliothek zum Laden von Bildern wie Glide oder Coil verwenden, geben Sie die Bitmap an den verwalteten Pool der Bibliothek zurück. Durch die Bereitstellung eines vorhandenen Puffers für zukünftige Arbeitsspeicheranforderungen wird der Overhead neuer Zuweisungen effektiv vermieden.

Weitere Informationen finden Sie in unserer Dokumentation zur Optimierung der Leistung für Bilder.

Android Studio-Tools

Mit Android Studio Narwhal 4 können Sie auch redundante Bitmaps entfernen. So finden Sie sie in fünf einfachen Schritten:

1. Öffnen Sie den Tab Profiler in Android Studio.
2. Klicken Sie auf Heap-Dump (oder „Arbeitsspeichernutzung analysieren“) und dann auf „Aufzeichnen“, um einen Snapshot des aktuellen Arbeitsspeicherstatus Ihrer App zu erstellen.
3. Achte in den Analyseergebnissen auf das gelbe Warndreieck ⚠️. Android Studio verwendet es, um doppelte Bitmaps zu kennzeichnen, die mehrmals gespeichert werden. Alternativ können Sie in der Profiler-Kopfzeile „Filtern nach:“ auswählen und die Einstellung „Doppelte Bitmaps“ auswählen.
4. Klicken Sie auf einen beliebigen Eintrag mit Markierung, um das Feld Bitmap-Vorschau zu öffnen. Dort sehen Sie genau, welches Bild die Wiederholung darstellt.
5. Mithilfe dieser visuellen Bestätigung können Sie die redundante Ladungslogik in Ihrem Code aufspüren und eine bessere Caching-Strategie implementieren.

Speicherlecks mit Android Studio erkennen und beheben

Speicherlecks in Android treten auf, wenn Ihr Code die Referenz eines Objekts lange nach dem Ende seines Lebenszyklus beibehält. Dadurch wird verhindert, dass der Garbage Collector (GC) diesen Arbeitsspeicher zurückfordert, was letztendlich zu einer trägen Leistung oder einem OutOfMemoryError (OOM) führt.

Android Studio Panda 3 bietet eine spezielle LeakCanary-Profiler-Aufgabe, mit der Entwickler Speicherlecks in Echtzeit analysieren und Traces direkt in der IDE zuordnen können.

Mit der Profiler-Aufgabe „LeakCanary“ in Android Studio wird die Speicherlecks-Analyse aktiv von Ihrem Gerät auf Ihren Entwicklungscomputer verlagert. Dies führt im Vergleich zur Analyse von Lecks auf dem Gerät zu einer erheblichen Leistungssteigerung während der Lecks-Analysephase.

Außerdem wird die Leckanalyse jetzt in der IDE kontextualisiert und vollständig in Ihren Quellcode integriert. Das bietet Funktionen wie „Zur Deklaration springen“ und andere hilfreiche Codeverbindungen, die den Aufwand und die Zeit, die für die Untersuchung und Behebung von Speicherlecks erforderlich sind, drastisch reduzieren.  

Beispiele für häufige Speicherlecks 

Speicherlecks treten auf, wenn ein Objekt über seine vorgesehene Lebensdauer hinaus im Arbeitsspeicher verbleibt. Das passiert in der Regel aus folgenden Gründen:

• Verweise auf Fragments, Activities oder Views, die nicht mehr verwendet werden, beibehalten.
• Falsche Verwaltung von Kontextreferenzen.
• Beobachter, Listener und Empfänger werden nicht ordnungsgemäß abgemeldet.
• Statische Referenzen auf Objekte erstellen, die an Komponenten mit kürzeren Lebenszyklen gebunden sind.

Hier einige Beispielszenarien:

Speicherplatz freigeben, wenn die App nicht mehr sichtbar ist

Android kann Speicherplatz von Ihrer App zurückfordern oder Ihre App vollständig beenden, wenn dies erforderlich ist, um Speicherplatz für kritische Aufgaben freizugeben. Weitere Informationen finden Sie unter Speicherverwaltung – Übersicht. Android gibt in der Regel Arbeitsspeicher von Ihrer App frei, wenn sie für den Nutzer nicht sichtbar ist. Dazu werden beispielsweise einige Code- und Datenseiten Ihrer App im Arbeitsspeicher verworfen oder Ihre Heap-Zuweisungen komprimiert. Wenn der Nutzer Ihre App fortsetzt und Ihre App versucht, auf einen Speicherbereich zuzugreifen, der freigegeben wurde, tauscht das Betriebssystem diesen Speicherbereich bei Bedarf wieder ein. Dieses Verhalten kann langsam sein und zu unerwarteten Rucklern oder Stottern in Ihrer App führen.

Wenn Sie dem Betriebssystem überlassen, welcher Arbeitsspeicher von Ihrer App freigegeben werden soll, kann es sein, dass das Betriebssystem Arbeitsspeicher freigibt, den Sie kurz nach dem Fortsetzen Ihrer App benötigen. Stattdessen kann Ihre App freiwillig Arbeitsspeicherzuweisungen verwerfen, die sie später bei Bedarf und zu geringen Kosten neu generieren kann. Dazu können Sie die ComponentCallbacks2-Schnittstelle implementieren. Sie können onTrimMemory in Ihrer Activity-, Fragment-, Service- oder sogar in Ihrer benutzerdefinierten Application-Klasse implementieren. Die Verwendung in der Klasse Application ist sehr effektiv für die globale Cacheverwaltung.

Die bereitgestellte Callback-Methode onTrimMemory() benachrichtigt Ihre App über Ereignisse im Zusammenhang mit dem Lebenszyklus oder dem Arbeitsspeicher, die eine gute Gelegenheit für Ihre App darstellen, die Arbeitsspeichernutzung freiwillig zu reduzieren.

Bei der Verwaltung des Speicherlebenszyklus sollte sich Ihre Implementierung ausschließlich auf TRIM_MEMORY_UI_HIDDEN und TRIM_MEMORY_BACKGROUND konzentrieren. Seit Android 14 werden keine Benachrichtigungen mehr für andere Legacy-Konstanten gesendet, die in Android 15 offiziell als veraltet eingestuft wurden.

TRIM_MEMORY_UI_HIDDEN: Dieses Signal gibt an, dass die Benutzeroberfläche Ihrer Anwendung nicht mehr im Blickfeld des Nutzers ist. So können Sie erhebliche Speicherzuweisungen freigeben, die ausschließlich an die Benutzeroberfläche gebunden sind, z. B. Bitmaps, Videowiedergabepuffer oder komplexe Animationsressourcen.

TRIM_MEMORY_BACKGROUND: Auf dieser Ebene befindet sich Ihr Prozess im Hintergrund und kann beendet werden, um den globalen Speicherbedarf des Systems zu decken. Wenn Sie die Dauer verlängern möchten, in der sich Ihr Prozess im Cache-Zustand befindet, und die Anzahl der Kaltstarts von Apps reduzieren möchten, sollten Sie alle Ressourcen freigeben, die leicht rekonstruiert werden können, sobald der Nutzer seine Sitzung fortsetzt.

import android.content.ComponentCallbacks2
// Other import statements.

class MainActivity : AppCompatActivity(), ComponentCallbacks2 {

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    override fun onTrimMemory(level: Int) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

Hinweis: Die onTrimMemory -Integration hängt möglicherweise von der SDK-Unterstützung ab. Bei einigen Spielen ist beispielsweise die Spiel-Engine dafür verantwortlich, dass diese Funktion verfügbar ist. Weitere Informationen finden Sie in der Dokumentation zur Optimierung des Arbeitsspeichers von Spielen.

Erweiterte Arbeitsspeicherbeobachtung mit ProfilingManager

Um Speicherprobleme zu erkennen und zu diagnostizieren, die sich nicht lokal reproduzieren lassen, sollten Sie die ProfilingManager API verwenden. Diese in Android 15 eingeführte API für erweiterte Observability ermöglicht es Ihnen, Perfetto-Profile von echten Nutzern programmatisch zu erfassen. 

Für Teams, die keine dedizierte Infrastruktur zum Verwalten und Hosten von Leistungsartefakten haben, wird bei Crashlytics eine spezielle Lösung zur Optimierung dieses Workflows in Betracht gezogen. Entwickler sind eingeladen, Feedback zu geben.

In Android 17 werden neue ereignisgesteuerte Trigger eingeführt, insbesondere TRIGGER_TYPE_OOM und TRIGGER_TYPE_ANOMALY:

• Der OOM-Trigger erfasst automatisch einen Java-Heap-Dump genau in dem Moment, in dem ein OutOfMemoryError-Absturz auftritt. So werden genaue Zuweisungsstatus bereitgestellt. Ein erfasstes OOM-Profil wird beim nächsten Start der App und bei der Registrierung des registerForAllProfilingResults-Callbacks bereitgestellt.
• Der Anomalie-Trigger erkennt schwerwiegende Leistungsprobleme wie übermäßigen Binder-Spam oder überschrittene Arbeitsspeichergrenzwerte. Bei einer Speicheranomalie wird ein Heap-Dump kurz vor dem Beenden der App durch das System erstellt.

    val profilingManager = 
applicationContext.getSystemService(ProfilingManager::class.java)
    val triggers = ArrayList<ProfilingTrigger>()  


    triggers.add(ProfilingTrigger.Builder(
                 ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
    val mainExecutor: Executor = Executors.newSingleThreadExecutor()
    val resultCallback = Consumer<ProfilingResult> { profilingResult ->
        if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
            // upload profile result to server for further analysis          
            setupProfileUploadWorker(profilingResult.resultFilePath)
        } 

    profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback)
    profilingManager.addProfilingTriggers(triggers)

Nachdem Sie den Heap-Dump erfasst haben, können Sie das Profil vom Server oder lokal über „adb pull“ herunterladen und die Datei per Drag-and-drop in die Perfetto-Benutzeroberfläche ziehen. Um den Workflow für das Debuggen des Arbeitsspeichers zu optimieren, verwenden Sie den Heap Dump Explorer. Das ist die neue Standardansicht für Heap-Dumps in der Perfetto-UI. Dieses Tool bietet eine intuitive Benutzeroberfläche zum Untersuchen von Java-Heap-Dumps. Damit können Sie Hierarchien für die Objektzuweisung visualisieren, die Größe des beibehaltenen Speichers berechnen und den kürzesten Pfad vom Root der automatischen Speicherbereinigung identifizieren. Mit dem Heap Dump Explorer können Sie schnell Speicherlecks, aufgeblähte beibehaltene Objekte wie übermäßige Bitmap-Zuweisungen erkennen und Heap-Objektzuweisungen an einem Ort analysieren.

Fazit

Das Optimieren von Bytecode mit R8, die Einhaltung von Best Practices für das Laden von Bildern und das Beheben von Speicherlecks sind wichtige Schritte, um eine hohe Nutzerfreundlichkeit zu gewährleisten und gleichzeitig Ressourcen unter Belastung effektiv zu verwalten. Durch diese proaktiven Maßnahmen können Sie die Stabilität und Leistung Ihrer App aufrechterhalten, unerwartete Beendigungen verhindern und den Nutzerkontext schützen. Weitere Informationen zur Leistung finden Sie in unserem überarbeiteten Leitfaden zum Arbeitsspeicher.