Arbeitsspeichernutzung (anonymer RSS + Auslagerung)

Die Arbeitsspeichernutzung (anonyme RSS + Auslagerung) ist ein Messwert, der die Arbeitsspeichernutzung Ihrer App widerspiegelt.

Anonymer Arbeitsspeicher ist Arbeitsspeicher, der nicht durch eine Datei im Speicher gesichert wird, z. B. Heap-Zuweisungen und mit „mmap“ zugewiesener Arbeitsspeicher. Dabei werden die dynamischen Speicherzuweisungen Ihrer App erfasst, einschließlich des Java- oder Kotlin-Heaps, nicht verwalteter nativer Heap-Zuweisungen (wo Bitmap-Pixeldaten unter Android 8.0 (API-Level 26) und höher gespeichert werden) und Thread-Ausführungsstacks. Das Betriebssystem kann zwar dateigestützten Arbeitsspeicher bei Bedarf freigeben, aber keinen anonymen Arbeitsspeicher.

Die Resident Set Size (RSS) ist die Gesamtzahl der von einem Prozess verwendeten Speicherseiten (sowohl gemeinsam genutzte als auch nicht gemeinsam genutzte), die im physischen RAM gespeichert sind. Eine Seite gilt als „freigegeben“, wenn auf sie von mehr als einem Prozess zugegriffen wird, z. B. von Apps, die auf dieselbe Bibliothek zugreifen.

Bei anonymem Arbeitsspeicher kann das System Seiten in den Auslagerungsspeicher (oder zRAM unter Android) schreiben, wenn der Arbeitsspeicher ausgelastet ist. Das System kann diese Seiten bei Bedarf aus dem Swap-Speicher lesen.

Insgesamt ist die Arbeitsspeichernutzung (anonymer RSS + Auslagerung) ein Maß für die Gesamtzahl der Arbeitsspeicherseiten Ihrer App, die nicht durch eine Datei im Speicher gesichert werden, einschließlich des Arbeitsspeichers, der auch vom System im Auslagerungsspeicher gesichert wird. Durch die Erfassung von anonymem RSS und Swap wird der tatsächliche, nicht auslagerbare Speicherbedarf Ihrer App ermittelt.

Wenn die Arbeitsspeichernutzung Ihrer App hoch ist, sollten Sie das Problem mithilfe der Anleitung auf dieser Seite genauer untersuchen und beheben.

Ressourcen

Übermäßige Arbeitsspeichernutzung lokal diagnostizieren

Um mit der Diagnose der Ursache für die übermäßige Arbeitsspeichernutzung zu beginnen, können Sie einen Heap-Dump mit Heap-Dump aufzeichnen in den Entwicklereinstellungen, Android Studio oder Perfetto erfassen. Wir empfehlen, zuerst einen Heap-Dump lokal zu erfassen, nachdem Sie die wichtigsten Aspekte des Nutzerverhaltens Ihrer App getestet haben.

Wir empfehlen insbesondere, die folgenden Nutzeraktionen zu testen:

  • Webviews und In-App-Browsersitzungen
  • Unendliches Scrollen mit vielen Medien
  • Workflows zum Erstellen und Bearbeiten von Assets

Um potenzielle Speicherlecks zu untersuchen, führen Sie die entsprechenden Nutzeraktionen lokal aus und erfassen Sie Heap-Dumps für verschiedene Prozesszustände (sichtbar, Dienst im Vordergrund und im Cache), um zu prüfen, ob die App Speicher freigibt, nachdem sie in den Hintergrund verschoben wurde. Informationen dazu, wie diese Prozessstatus mit onTrimMemory-Callbacks zusammenhängen, finden Sie im Leitfaden zum Freigeben von Arbeitsspeicher als Reaktion auf Ereignisse.

Wenn Sie Speicherprobleme mit dem Android Studio Profiler beheben, können Sie auch die LeakCanary-Integration verwenden, um die Erkennung von Speicherlecks und doppelten Bitmaps zu optimieren und so die Bildnutzung zu optimieren.

Nachdem Sie den Heap-Dump erfasst haben, empfehlen wir, ihn mit dem Android Profiler-Skill zu analysieren und potenzielle Quellen für eine hohe Arbeitsspeichernutzung zu ermitteln.

Hier ein Beispiel für eine Antwort der KI-Skills:

I have completed the analysis of memory leaks and bitmap issues for [app] using the provided Perfetto trace.
  Summary of Findings
  The investigation identified a critical memory pressure issue caused by massive bitmap retention within the app process.
...
Recommendations for [app]
   1. [Library] Image Cache Optimization:
       * Review the [Library] caching strategy. Ensure that bitmaps
         loaded for animations are released or downsampled when the animation is
         not in the foreground.
   2. Asset Resolution Audit:
       * The 14.7 MB average size suggests full-screen or extremely high-density assets. Audit the [library] files in the native_home component to ensure they are not using unnecessarily large source images.
   3. View Lifecycle Management:
       * Investigate why 21 [LibraryImage] instances are alive simultaneously. Ensure that views in the bottom
      tab are properly detached or their animations are cleared when switching between tabs.
   4. Fix Surface Leaks:
       * Address the Surface.release failures observed in the logs, as these can lead to both memory leaks and
         native resource exhaustion.

Zusätzliche Ressourcen zum Interpretieren von Heap-Dumps

In den folgenden Ressourcen finden Sie weitere Informationen zum Interpretieren von Heap-Dumps und zur Fehlerbehebung bei der Arbeitsspeichernutzung:

  • Manuelle Analyse:Verwenden Sie die Anleitung zum Perfetto Heap Dump Explorer, um zu erfahren, wie Sie Heap-Dump-Visualisierungen in der Perfetto-Benutzeroberfläche navigieren und interpretieren.
  • Java-/Kotlin-Zuweisungen:Eine detaillierte Anleitung zur Analyse von ART-Heap-Dumps (Android Runtime) finden Sie unter Ersten ART-Heap-Dump visualisieren.
  • Native Zuweisungen:In der Dokumentation zu Perfetto Native Profiling erfahren Sie, wie Sie native (C/C++) Speicherprofile erfassen und analysieren.
  • CLI-Prüfung:Mit adb dumpsys meminfo erhalten Sie eine schnelle Aufschlüsselung der Arbeitsspeichernutzung Ihrer App auf einem Gerät.

Arbeitsspeichernutzung verbessern

In den folgenden Abschnitten finden Sie weitere Informationen zur Verbesserung der Arbeitsspeichernutzung Ihrer App:

Eine ausführliche Anleitung zur Behebung von Speicherproblemen finden Sie im Leitfaden Verwaltung Ihres App-Speichers.

Zurück
Low-Memory-Kills (LMKs)
Weiter
Arbeitsspeichernutzung für Bitmaps