Die Arbeitsspeichernutzung (anonyme RSS + Auslagerung) ist ein Messwert in Android Vitals, 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. 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. Bei anonymem Arbeitsspeicher kann das System Seiten in den Auslagerungsspeicher (oder zRAM unter Android) schreiben, wenn der Arbeitsspeicher ausgelastet ist.
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.
Hohe Speichernutzung ermitteln
Android Vitals
In Android Vitals wird die Arbeitsspeichernutzung Ihrer App nach den folgenden Prozessstatus aufgeschlüsselt:
- Vordergrund: Der Prozess der App ist sichtbar. Ein hoher P99 wirkt sich häufig auf die von Nutzern wahrgenommene Leistung aus (Verzögerung oder OOM-Abstürze) und wird stark durch das Beibehalten von UI-Komponenten oder Aktivitäten beeinflusst, die nicht mehr benötigt werden.
- Für Nutzer sichtbare Dienste: Der Prozess der App wird in einem wahrnehmbaren Zustand ausgeführt. Dazu gehören Vordergrunddienste, beschleunigte Jobs und vom Nutzer initiierte Datenübertragungsvorgänge. Das kann sich auch auf systemgebundene Dienste oder Dienste erstrecken, die an andere Apps gebunden sind. Da diese Dienste für lang andauernde Aufgaben konzipiert sind, kann es sein, dass der P99-Tail im Laufe der Zeit ansteigt, wenn Arbeitsspeicher aufgrund von Lecks belegt bleibt oder Ressourcen nicht freigegeben werden.
- Hintergrund: Die App führt einen Hintergrunddienst aus oder wurde vor Kurzem in den Hintergrund verschoben, ist aber noch nicht im Cache. Hier können Hintergrundverarbeitungslecks und nicht freigegebene Ressourcen auftreten. Da dieser Prozessstatus weniger wichtig ist als Vordergrund- oder wahrnehmbare Prozesse, sollten Sie versuchen, in diesem Status nicht zu viel Arbeitsspeicher zu belegen.
- Im Cache: Die App befindet sich im Cache. Dieser Status reagiert sehr empfindlich auf den Systemarbeitsspeicher, z. B. auf LMKs. Da das Betriebssystem diesen Prozessstatus nach Belieben entfernen kann, wird er nur zu Debugging-Zwecken bereitgestellt.
Informationen dazu, wie diese Prozessstatus mit onTrimMemory-Callbacks zusammenhängen, finden Sie im Leitfaden zum Freigeben von Arbeitsspeicher als Reaktion auf Ereignisse.
Android Vitals unterteilt die Arbeitsspeichernutzung Ihrer App auch nach RAM-Buckets. Der Messwert zur Arbeitsspeichernutzung wird als Zeitachse mit täglichen Perzentilwerten zusammen mit dem letzten Tageswert für das 50. und 90. Perzentil angezeigt.
Speicherlecks mithilfe von Tail-Skew identifizieren
Um Speicherlecks zu erkennen, sollten Sie in Android Vitals nach einer Abweichung zwischen Ihren typischen (P50) und den Nutzern am unteren Ende (P90) suchen. Während allgemeine Asset-Bloat den Arbeitsspeicher über alle Perzentile hinweg gleichmäßig erhöht, summieren sich Speicherlecks im Laufe der Zeit und verzerren die Daten am unteren Ende stark.
Vergleichen Sie Ihre P90- und P99-Messwerte mit Ihrer P50-Referenz nach Prozessname. Wenn das Verhältnis von P90 zu P50 mehr als 3,5-mal so hoch ist, deutet dies auf ein wahrscheinliches Speicherleck bei längeren Sitzungen hin. In bestimmten Anwendungsfällen deutet ein erhöhtes Verhältnis nicht immer auf ein Leck hin. Sie sollten den jeweiligen Workflow jedoch prüfen, um festzustellen, ob die erhöhte Arbeitsspeichernutzung erwartet wird.