Neue Statistiken zu Problemen mit der App-Qualität und Empfehlungen
Derzeit werden Probleme mit der App-Kompatibilität, unerwünschtes Verhalten und einige Empfehlungen für mehr Nutzerfreundlichkeit angezeigt. Im Laufe des nächsten Jahres werden wir weitere Qualitätsprobleme offenlegen und mehr Empfehlungen hinzufügen.
Mit Android Vitals können Sie die Stabilität, Leistung und Akkunutzung Ihrer App sowie andere Aspekte besser verstehen und optimieren.
App-Daten ansehen
Es gibt zwei Möglichkeiten, Android Vitals zu verwenden: über die Play Console und die Play Developer Reporting API.
Entwickler, die Android Vitals-Daten in andere Datensätze oder in ihre Workflows einbinden möchten, erhalten über die API programmatischen Zugriff auf Android Vitals. Weitere Informationen zur Verwendung einer API für den Zugriff auf Android Vitals finden Sie auf der Seite Google Play Developer Reporting API.
So finden Sie die Android Vitals-Daten Ihrer App in der Play Console:
- Öffnen Sie die Play Console und rufen Sie die Seite Übersicht über Android Vitals (Qualität > Android Vitals > Übersicht) auf.
- Mithilfe der Zeitraumauswahl oben rechts können Sie den Zeitraum festlegen, den Ihre Daten abdecken sollen.
Wichtig: Wenn keine Daten verfügbar sind, gibt es für Ihre App nicht genügend Datenpunkte in den festgelegten Filtern, um mögliche Probleme zu erkennen.
Vitalparameter der App beobachten
Oben auf der Seite Übersicht über Android Vitals sehen Sie Daten zu den Vitalparametern Ihrer App. Dies sind die wichtigsten technischen Messwerte, die auch die Sichtbarkeit Ihrer App bei Google Play beeinflussen. Zu den Vitalparametern gehören:
In Google Play sind für diese Messwerte Grenzwerte zu unerwünschtem Verhalten definiert. Überschreitet Ihre App diese Grenzwerte, ist sie bei Google Play wahrscheinlich weniger gut sichtbar. In einigen Fällen wird im Store-Eintrag der App auch eine Warnung angezeigt, um die Nutzer zu informieren.
Unter „Kritische Probleme“ können Sie schnell erkennen, in welchen Bereichen Ihre App Verbesserungspotenzial hat. Es gibt zwei Arten von kritischen Problemen:
- Unerwünschtes Verhalten: Messwerte, die die Grenzwerte zu unerwünschtem Verhalten überschreiten
- Anomalien: Drastische Änderungen der Daten, z. B. ein deutlicher Anstieg der Rate der vom Nutzer wahrgenommenen ANR-Fehler
Wenn Sie E-Mail-Benachrichtigungen erhalten möchten, rufen Sie Einrichtung > Benachrichtigungen auf oder klicken Sie in der Ecke des Bereichs „Vitalparameter“ auf Benachrichtigungen verwalten (Qualität > Android Vitals > Übersicht). Benachrichtigungen sind derzeit nur für Anomalien verfügbar.
Alle Vitals-Daten ansehenEtwa in der Mitte der Seite Übersicht über Android Vitals finden Sie Details zu allen Vitals-Daten nach Qualitätspunkten sortiert.
In der Tabelle sehen Sie die Messwerte für den aktuellen Zeitraum und vorherige Zeiträume. Außerdem können Sie erkennen, wie Ihre App im Vergleich zu anderen Apps bei Google Play abschneidet.
Wenn Sie weitere Informationen zu einem bestimmten Messwert aufrufen möchten, klicken Sie daneben auf Details ansehen (). Auf dem nächsten Bildschirm wird Folgendes angezeigt:
- Grenzwerte zu unerwünschtem Verhalten
- Benchmark-Kategorien
- Detaillierte Benchmark-Vergleiche
- Um eine benutzerdefinierte Gruppe ähnlicher Apps zu bearbeiten, wählen Sie oben auf der Seite auf der Karte zum App-Vergleich die Option Gruppe ähnlicher Apps bearbeiten aus. Nachdem Sie eine solche Gruppe erstellt haben, können Sie sehen, wie Ihre App bei Google Play im Vergleich zu anderen, von Ihnen ausgewählten Apps abschneidet.
- Trend der Messwerte im Zeitverlauf
Damit Sie die Daten Ihrer App besser ordnen, segmentieren und analysieren können, werden die Messwerte in verschiedene Dimensionen unterteilt. Die Aufschlüsselung sieht so aus:
- Artefakt: Die Version Ihrer App, bei der das Problem aufgetreten ist.
- Android-Version (SDK): Die Version des Android-Betriebssystems, die vom Gerät des Nutzers gemeldet wird.
- Formfaktor: Der Gerätetyp, auf dem die App ausgeführt wird, z. B. Smartphone, Tablet, Fernseher oder Wearable.
- Gerätemodell: Eine allgemeine Beschreibung des Geräts mit einer eindeutigen Marken- und Geräte‑ID, z. B. Google Oriole. Ein einzelnes Gerätemodell kann Varianten mit unterschiedlichen Android-, RAM-, Speicher- oder SoC-Versionen (System-on-a-Chip) haben.
- Land/Region: Der Standort, der vom Gerät des Nutzers zum Zeitpunkt des Problems gemeldet wurde.
Tipp: Für eine Aufschlüsselung nach bestimmten Hardware‑ oder Softwaredetails, wie Gerätemodell oder Android-Version, klicken Sie neben dem jeweiligen Eintrag in der Tabelle auf das Symbol .
Für einige Messwerte gibt es zusätzliche Details:
- Wakelock-Name: Tags, die programmatisch gesetzt werden, wenn die PowerManager API in Ihrer App verwendet wird
- Wakeup-Name: Tags, die programmatisch gesetzt werden, wenn die AlarmManager API in Ihrer App verwendet wird
- ANR-Aktivitätsname: Der voll qualifizierte Name der Aktivitätsklasse, in der der ANR-Fehler aufgetreten ist (falls verfügbar)
- ANR-Typ: Gibt an, wann ein ANR-Fehler aufgetreten ist, z. B. beim Ausführen eines Diensts (falls verfügbar)
Sie können sich auch weitere Details ansehen, sofern verfügbar, z. B. die mit dieser Aufschlüsselung verknüpften Absturz- oder ANR-Cluster. Wählen Sie dazu neben dem jeweiligen Eintrag Details ansehen () aus.
Tipp: Über die Ein/Aus-Schaltfläche oben auf dem Bildschirm können Sie zwischen den Messwerten einer Kategorie wechseln. Außerdem können Sie die Seite filtern.
Datentypen und Messwerte
Android Vitals-Daten sind in der Play Console für die letzten 90 Tage und in der Play Developer Reporting API für die letzten drei Jahre verfügbar.
Die Daten von ausgewählten Android-Geräten und -Betriebssystemversionen stammen von Nutzern, die zugestimmt haben, Nutzungs- und Diagnosedaten automatisch zu teilen. Weitere Informationen zum automatischen Teilen finden Sie in der Google-Konto-Hilfe.
Die Android Vitals-Daten werden täglich aktualisiert. Es kann vorkommen, dass Daten für Geräte mit Android 10 und höher früher angezeigt werden als Daten für Geräte mit niedrigeren Versionen. Wenn dies der Fall ist, sehen Sie die Daten für Android 10 oder höher an den Tagen, an denen nur diese Daten verfügbar sind.
Hinweis: Die Android Vitals-Messwerte umfassen keine technischen Probleme, die auf nicht zertifizierten Gerätemodellen oder in Versionen Ihrer App auftreten, die nicht über Google Play installiert wurden.
Alles minimieren Alles maximieren
Stabilität
Messwerte zur ANR-RateDie Messwerte zur ANR-Rate geben einen Überblick über die Qualität Ihrer App. Zur Berechnung dieser Messwerte wird die Zahl der Nutzer ermittelt, bei denen ANR-Fehler aufgetreten sind, und diese dann anhand der App-Nutzung normalisiert. Die Messwerte werden als Prozentsatz der aktiven Nutzer pro Tag angezeigt. Zu „Aktiver Nutzer pro Tag“ zählt jeder Nutzer, der die App an einem Tag auf einem Gerät verwendet. Wenn ein Nutzer Ihre App an einem Tag auf mehreren Geräten verwendet, wird jedes Gerät zur Zahl der aktiven Nutzer an diesem Tag addiert. Verwenden mehrere Nutzer an einem Tag dasselbe Gerät, zählt dies als ein aktiver Nutzer.
Es gibt drei Messwerte zu ANR-Raten:
- Rate der vom Nutzer wahrgenommenen ANR-Fehler: Prozentsatz der aktiven Nutzer pro Tag, bei denen mindestens ein vom Nutzer wahrgenommener ANR-Fehler aufgetreten ist. Ein vom Nutzer wahrgenommener ANR-Fehler ist ein ANR, den der Nutzer wahrscheinlich bemerkt hat. Derzeit werden nur ANR-Fehler mit einer Zeitüberschreitung bei der Eingabe gezählt. Dieser Messwert ist immer niedriger als die ANR-Rate insgesamt, weil er durch die tägliche Nutzung normalisiert wird, aber nicht alle ANR-Fehler berücksichtigt werden.
Die Rate der vom Nutzer wahrgenommenen ANR-Fehler ist ein Vitalparameter, d. h., er beeinflusst die Sichtbarkeit Ihrer App bei Google Play. Er ist wichtig, weil die gezählten ANR-Fehler immer auftreten, während der Nutzer mit der App interagiert, und daher die größte Störung verursachen.
- ANR-Rate: Prozentsatz der Nutzer pro Tag, bei denen mindestens ein ANR-Fehler aufgetreten ist. Dieser Messwert umfasst ANRs, die nicht als „vom Nutzer wahrgenommen“ eingestuft werden. Wir können jedoch nicht mit Sicherheit sagen, dass die Nutzung durch diese ANR-Fehler nicht beeinträchtigt wurde.
- Mehrfach-ANR-Rate: Prozentsatz der Nutzer pro Tag, bei denen mindestens zwei ANR-Fehler aufgetreten sind. Mit diesem Messwert lassen sich Fehlerschleifen erkennen.
Problem beheben
Die ANR-Fehler, die für die Messwerte zur ANR-Rate berücksichtigt wurden, werden auf der Seite Abstürze und ANRs aufgeführt. Auf dieser Seite können Sie nach vom Nutzer wahrgenommenen ANR-Fehlern filtern.
Auf der Website für Android-Entwickler finden Sie Informationen zur Diagnose und Behebung von ANR-Fehlern.
Die Messwerte zur Absturzrate geben einen Überblick über die Qualität Ihrer App. Zur Berechnung dieser Messwerte wird die Zahl der Nutzer ermittelt, bei denen Abstürze aufgetreten sind, und diese dann anhand der App-Nutzung normalisiert. Die Messwerte werden als Prozentsatz der Nutzer pro Tag angezeigt. Zu „Nutzer pro Tag“ zählt jeder Nutzer, der die App an einem Tag auf einem Gerät verwendet. Wenn ein Nutzer mehr als ein Gerät hat, wird er mehrmals gezählt. Verwenden beispielsweise zwei Nutzer die App zwei Tage lang auf jeweils einem Gerät, werden vier tägliche Sitzungen gezählt.
Es gibt drei Messwerte zur Absturzrate:
- Rate der vom Nutzer wahrgenommenen Abstürze: Prozentsatz der Nutzer pro Tag, bei denen mindestens ein vom Nutzer wahrgenommener Absturz aufgetreten ist. Ein vom Nutzer wahrgenommener Absturz ist ein Absturz, den der Nutzer wahrscheinlich bemerkt hat. Dazu gehören zum Beispiel Abstürze, die auftreten, solange in Ihrer App eine Aktivität angezeigt oder sie als Dienst im Vordergrund ausgeführt wird. Dieser Messwert ist immer niedriger als die Absturzrate insgesamt, weil er durch die tägliche Nutzung normalisiert wird, aber nicht alle Abstürze berücksichtigt werden.
Die Rate der vom Nutzer wahrgenommenen Abstürze ist ein Vitalparameter, d. h., er beeinflusst die Sichtbarkeit Ihrer App bei Google Play. Das ist wichtig, weil die gezählten Abstürze immer auftreten, während der Nutzer mit der App interagiert, und daher die größte Störung verursachen. Aus diesem Grund sollten Sie dafür sorgen, dass Ihre App den Grenzwert zu unerwünschtem Verhalten für diesen Messwert nicht überschreitet.
-
Absturzrate: Prozentsatz der Nutzer pro Tag, bei denen mindestens ein Absturz aufgetreten ist. Dieser Messwert umfasst Abstürze, die nicht als „vom Nutzer wahrgenommen“ eingestuft werden. Wir können jedoch nicht mit Sicherheit sagen, dass die Nutzung durch diese Abstürze nicht beeinträchtigt wurde.
-
Mehrfachabsturzrate: Prozentsatz der Nutzer pro Tag, bei denen mindestens zwei Abstürze aufgetreten sind. Mit diesem Messwert lassen sich Fehlerschleifen erkennen.
Problem beheben
Auf der Website für Android-Entwickler finden Sie Informationen zur Diagnose und Behebung von Abstürzen.
Start- und Ladezeiten
Startzeit (Zeit bis zur ersten Anzeige)Auf der Seite Startzeit finden Sie die Details zu langsamen Kaltstartzeiten, Warmstartzeiten und Heißstartzeiten der App. Die Startzeit entspricht der Zeitspanne zwischen dem Starten Ihrer App durch den Nutzer und der Anzeige der ersten Frames auf dem Bildschirm. Das wird auch als „Zeit bis zur ersten Anzeige“ bezeichnet.
Ihre App ist nach dieser Zeit möglicherweise noch nicht für eine Nutzerinteraktion bereit, z. B. wenn sie zusätzliche Bildschirme hat, die geladen werden.
Details zur Datenerhebung
- Startzeiten werden nur aufgezeichnet, wenn ein Nutzer eine Aktivität auslöst.
- Beispiel: Bei Tastatur-Apps entspricht die Startzeit der Startzeit der Companion App.
- Wird eine App an einem Tag mehrmals aus demselben Systemzustand gestartet, wird die längste Startzeit des Tages aufgezeichnet.
- Startzeiten werden erfasst, sobald der erste Frame der App vollständig geladen wurde, auch wenn der Nutzer nicht mit diesem Bildschirm interagiert.
- Beispiel: Wenn eine App mit einem Ladebildschirm startet, entspricht die Startzeit der Zeit, die zum Aufrufen des Ladebildschirms erforderlich war.
Details zu Android Vitals
- Betroffene Sitzungen: Prozentsatz der Sitzungen, bei denen Nutzer für den jeweiligen Systemzustand eine lange Startzeit hatten:
- Lange Kaltstartzeit: 5 Sekunden oder länger
- Lange Warmstartzeit: 2 Sekunden oder länger
- Lange Heißstartzeit: 1 Sekunde oder länger
- Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
- 90./99. Perzentil: 10 % bzw. 1 % der täglichen Sitzungen, bei denen Nutzer lange App-Startzeiten hatten.
Problem beheben
Werden für Ihre App viele lange App-Startzeiten aufgezeichnet, finden Sie auf der Website für Android-Entwickler Lösungsansätze.
Rendering
Gesamtes Rendering
Anteil langsamer Sitzungen (30 oder 20 fps) [nur Spiele]Warum ist das wichtig?
Durch die Analyse langsamer Sitzungen können Sie die Framerateleistung Ihres Spiels nachvollziehen, die sich darauf auswirkt, wie flüssig und ruckelfrei sich Ihr Spiel für Nutzer anfühlt.
Daten Ihrer App analysieren
Auf der Seite „Langsame Sitzungen“ finden Sie den Prozentsatz der täglichen Sitzungen, bei denen mehr als 25 % der Frames langsamer als 30 oder 20 fps dargestellt wurden, je nachdem, welche Benchmark Sie ausgewählt haben. Sie können sich auch die Verteilung der Sitzungen nach Framerate für Ihr Spiel ansehen. Die Framerate auf Sitzungsebene wird im 75. Perzentil gemessen. Das bedeutet, dass 75 % der Frames mindestens diese Framerate erreichen.
Die meisten Spiele bei Google Play sollten mindestens 30 fps erreichen. Unabhängig von der Art des Spiels ist das der Wert, ab dem ein Spiel für Nutzer geeignet ist. Insbesondere auf hochwertigeren Geräten bevorzugen manche Nutzer aber mindestens 60 fps. Behalten Sie den Messwert für den Anteil langsamer Sitzungen (30 fps) im Blick, damit Sie diesen Grenzwert auch sicher erreichen. Beachten Sie, dass dieser Messwert nur Sitzungen umfasst, bei denen mehr als 25 % der Frames keine 30 fps erreichen, es besteht also etwas Toleranz im Hinblick auf die Frameratevariabilität.
30 fps bieten zwar eine angemessene Qualität, es kann aber Situationen oder Arten von Spielen geben, bei denen es sinnvoll ist, die Framerate darunter anzusetzen. Es kann außerdem auch vorkommen, dass Nutzer Ihr Spiel auf Smartphones spielen möchten, die keine 30 fps unterstützen. In diesen Szenarien sollten mindestens 75 % der Frames in einer Sitzung weiterhin 20 fps erreichen. Behalten Sie den Messwert für den Anteil langsamer Sitzungen (20 fps) im Blick, damit Sie diesen Grenzwert auch sicher erreichen.
Android Vitals meldet langsame Sitzungen (30 fps sowie 20 fps) für jedes Gerät sowie für alle Geräte und Sitzungen. Anhand des Gesamtmesswerts können Sie sich ein Bild von der Qualität insgesamt machen, achten Sie aber auch auf die Leistung bei einzelnen Geräten. Google Play wird früher oder später dazu übergehen, Nutzern Spiele nicht mehr zu empfehlen, die keine 20 fps auf ihren Smartphones erreichen.
Vitals beginnt erst eine Minute nach dem Start Ihres Spiels, seine Framerate zu erfassen.
Details zur Datenerhebung
Der Messwert für langsame Sitzungen wird mit Daten von SurfaceFlinger berechnet. Genauer gesagt wird die Framerate einer Sitzung basierend auf der Zeit zwischen den Frames berechnet, die auf Oberflächen der App gezeichnet wurden. Dazu gehören Frames, die von OpenGL, Vulkan und dem Android-UI-Toolkit gerendert werden. Dieser Messwert ist derzeit nur für Spiele verfügbar.
Für Geräte mit Android 9 und höher werden Daten zur Framerate bei langsamen Sitzungen erhoben.
Dashboardanzeige
- Repräsentative Framerate: Die Framerate für Ihr Spiel auf Geräten mit Android 9 und höher, die im 75. Perzentil berechnet wird. Das bedeutet, dass diese Framerate in 75 % der Sitzungen erreicht wurde oder höher war.
- Anteil langsamer Sitzungen im Zeitverlauf: Eine Zeitreihe mit dem Prozentsatz der Sitzungen, die als „Langsame Sitzungen“ eingestuft werden.
- Framerate-Verteilung: Histogramm, das das 75. Perzentil der Framerate für mehrere Sitzungen zeigt. Das bedeutet, dass 75 % der Frames in einer Sitzung schneller waren als die Framerate, mit der die Sitzung gruppiert wurde.
Problem beheben
Wenn bei Ihrer App viele Sitzungen langsam ausgeführt werden, finden Sie auf der Website für Android-Entwickler Lösungsansätze.
Android-UI-Toolkit-Rendering
Übermäßig langsame Frames [nur Apps]Daten Ihrer App analysieren
Auf der Seite „Übermäßig langsame Frames“ finden Sie den Prozentsatz der täglichen Sitzungen, bei denen mehr als 50 % der Frames die Rendering-Frist des Geräts nicht einhalten. Nutzerinteraktionen mit Ihrer App werden üblicherweise mit 60 Frames pro Sekunde ausgeführt, ohne dass Frames ausgelassen oder verzögert werden.
Details zur Datenerhebung
Google erfasst nur die Renderingzeit der Frames, die von Ihrer App mit dem UI Toolkit gerendert werden. Mithilfe von OpenGL oder Vulkan direkt gerenderte Frames gehören nicht dazu.
Dashboardanzeige
Wenn Sie eine Zeile auswählen, sehen Sie die Daten in Perzentile unterteilt.
- Betroffene Sitzungen: Prozentsatz der täglichen Sitzungen, bei denen mehr als 50 % der Frames länger als 16 ms gerendert wurden. Die Kennzahl „tägliche Sitzung“ bezeichnet einen Tag, an dem Ihre App genutzt wurde. Wenn beispielsweise zwei Nutzer die App zwei Tage lang verwenden, werden vier tägliche Sitzungen erstellt.
- Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
- 90./99. Perzentil: 90 % bzw. 99 % der Frames insgesamt hatten eine Renderingzeit, die kürzer war als der angegebene Wert. Diese Werte beruhen auf allen erfassten Frames.
Wenn Sie auf einen Tabelleneintrag klicken, wird das Diagramm „Verteilung der UI-Renderingzeit“ angezeigt. Hier sollten Sie prüfen, ob die meisten Frames Ihrer App bei oder unter 16 ms liegen.
Anhand der Daten unterhalb des Diagramms können Sie die Rendering-Leistung der App analysieren und so möglicherweise die Ursache potenzieller Rendering-Probleme erkennen. Wenn beispielsweise der Prozentsatz unter „Hohe Eingabelatenz“ hoch ausfällt, sollten Sie eventuell den App-Code prüfen, der Nutzereingaben verarbeitet. Weitere Informationen zu diesen Messwerten finden Sie im Artikel UI-Leistung testen.
- Verpasste VSync-Ereignisse: Für alle in mehr als 16 ms gerenderten Frames die Anzahl verpasster VSync-Ereignisse geteilt durch die Anzahl der Frames.
- Hohe Eingabelatenz: Für alle in mehr als 16 ms gerenderten Frames die Anzahl der Eingabeereignisse, für die mehr als 24 ms benötigt wurden, geteilt durch die Anzahl der Frames.
- Langsamer UI‑Thread: Für alle in mehr als 16 ms gerenderten Frames die Häufigkeit, mit der für den Abschluss des UI-Threads mehr als 8 ms benötigt wurden, geteilt durch die Anzahl der Frames.
- Langsame Zeichenbefehle: Für alle in mehr als 16 ms gerenderten Frames die Häufigkeit, mit der zum Senden von Zeichenbefehlen an die GPU mehr als 12 ms benötigt wurden, geteilt durch die Anzahl der Frames.
- Langsame Bitmap-Uploads: Für alle in mehr als 16 ms gerenderten Frames die Häufigkeit, mit der zum Hochladen der Bitmap-Datei in die GPU mehr als 3,2 ms benötigt wurden, geteilt durch die Anzahl der Frames.
Problem beheben
Wenn in Ihrer App viele Frames in mehr als 16 ms gerendert werden, finden Sie auf der Website für Android-Entwickler Lösungsansätze.
Daten Ihrer App analysieren
Auf der Seite „Übermäßig langsame Frames“ finden Sie den Prozentsatz der täglichen Sitzungen, bei denen mehr als 50 % der Frames die Rendering-Frist des Geräts nicht einhalten. Nutzerinteraktionen mit Ihrer App werden üblicherweise mit 60 Frames pro Sekunde ausgeführt, ohne dass Frames ausgelassen oder verzögert werden.
Details zur Datenerhebung
Google erfasst nur die Renderingzeit der Frames, die von Ihrer App mit dem UI Toolkit gerendert werden. Mithilfe von OpenGL oder Vulkan direkt gerenderte Frames gehören nicht dazu.
Dashboardanzeige
Wenn Sie eine Zeile auswählen, sehen Sie die Daten in Perzentile unterteilt.
- Betroffene Sitzungen: Prozentsatz der täglichen Sitzungen, bei denen mehr als 50 % der Frames länger als 16 ms gerendert wurden. Die Kennzahl „tägliche Sitzung“ bezeichnet einen Tag, an dem Ihre App genutzt wurde. Wenn beispielsweise zwei Nutzer die App zwei Tage lang verwenden, werden vier tägliche Sitzungen erstellt.
- Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
- 90./99. Perzentil: 90 % bzw. 99 % der Frames insgesamt hatten eine Renderingzeit, die kürzer war als der angegebene Wert. Diese Werte beruhen auf allen erfassten Frames.
Wenn Sie auf einen Tabelleneintrag klicken, wird das Diagramm „Verteilung der UI-Renderingzeit“ angezeigt. Hier sollten Sie prüfen, ob die meisten Frames Ihrer App bei oder unter 16 ms liegen.
Anhand der Daten unterhalb des Diagramms können Sie die Rendering-Leistung der App analysieren und so möglicherweise die Ursache potenzieller Rendering-Probleme erkennen. Wenn beispielsweise der Prozentsatz unter „Hohe Eingabelatenz“ hoch ausfällt, sollten Sie eventuell den App-Code prüfen, der Nutzereingaben verarbeitet. Weitere Informationen zu diesen Messwerten finden Sie im Artikel UI-Leistung testen.
- Verpasste VSync-Ereignisse: Für alle in mehr als 16 ms gerenderten Frames die Anzahl verpasster VSync-Ereignisse geteilt durch die Anzahl der Frames.
- Hohe Eingabelatenz: Für alle in mehr als 16 ms gerenderten Frames die Anzahl der Eingabeereignisse, für die mehr als 24 ms benötigt wurden, geteilt durch die Anzahl der Frames.
- Langsamer UI‑Thread: Für alle in mehr als 16 ms gerenderten Frames die Häufigkeit, mit der für den Abschluss des UI-Threads mehr als 8 ms benötigt wurden, geteilt durch die Anzahl der Frames.
- Langsame Zeichenbefehle: Für alle in mehr als 16 ms gerenderten Frames die Häufigkeit, mit der zum Senden von Zeichenbefehlen an die GPU mehr als 12 ms benötigt wurden, geteilt durch die Anzahl der Frames.
- Langsame Bitmap-Uploads: Für alle in mehr als 16 ms gerenderten Frames die Häufigkeit, mit der zum Hochladen der Bitmap-Datei in die GPU mehr als 3,2 ms benötigt wurden, geteilt durch die Anzahl der Frames.
Problem beheben
Wenn in Ihrer App viele Frames in mehr als 16 ms gerendert werden, finden Sie auf der Website für Android-Entwickler Lösungsansätze.
Akkunutzung
Hängende Wakelocks und hängende Teil-Wakelocks im HintergrundAuf den Seiten Hängende Teil-Wakelocks und Hängende Teil-Wakelocks im Hintergrund werden Teil-Wakelocks angezeigt, die Ihre App aus der Klasse „PowerManager“ übernommen hat. Bei einem Teil-Wakelock können das Display und die Tastaturbeleuchtung bei aktiver CPU ausgeschaltet werden.
Details zur Datenerhebung
- Zum Schutz der Privatsphäre werden die Tags zur Identifizierung von Teil-Wakelocks anonymisiert.
- Daten zu Teil-Wakelocks werden erfasst, während das Gerät gerade nicht geladen wird und der Bildschirm ausgeschaltet ist.
- Daten zu hängenden Teil-Wakelocks im Hintergrund werden nur erhoben, wenn die App im Hintergrund ausgeführt wird.
- Google berechnet die Höchstdauer der Teil-Wakelocks pro Akkusitzung, um zu analysieren, wie viele Sitzungen von einem langen Wakelock betroffen sind. Wenn ein Nutzer beispielsweise zwei Wakelocks von je einer Stunde auslöst, legt Google den Wert der Höchstdauer auf eine Stunde fest.
- Für Apps, bei denen in der Manifestdatei eine
sharedUserIdfestgelegt wurde: Es werden nur Daten angezeigt, wenn höchstens eine App mit derselbensharedUserIdinstalliert wurde.
Details zu Android Vitals
- Betroffene Sitzungen: Prozentsatz der Sitzungen, bei denen mindestens ein Wakelock von mehr als einer Stunde genutzt wurde.
- Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
- 90./99. Perzentil: 10 % bzw. 1 % der täglichen Sitzungen, bei denen Teil-Wakelocks von einer längeren Dauer als dem angezeigten Wert stattgefunden haben.
- Grenzwert zu unerwünschtem Verhalten: Wenn Ihre App über dem angezeigten Grenzwert liegt oder ihm entspricht, gehört sie zu den unteren 25 % der 1.000 meist installierten Apps bei Google Play.
Problem beheben
Wenn Ihre App eine hohe Anzahl von hängenden Teil-Wakelocks hat, finden Sie auf der Website für Android-Entwickler Lösungsansätze.
Auf der Seite Übermäßige Wakeups werden AlarmManager-Wakeups angezeigt, die von Ihrer App ausgelöst wurden. Hier sehen Sie Wakeup-Daten der Klassen ELAPSED_REALTIME_WAKEUP oder RTC_WAKEUP.
Details zur Datenerhebung
- Aus Datenschutzgründen werden die Tags zur Identifizierung von Wakeups anonymisiert.
- Wakeups werden erfasst, während das Gerät gerade nicht geladen wird.
- Um einen normalisierten Messwert zu liefern, wird die Anzahl der Wakeups mit der Akkulaufzeit verglichen. Google berechnet die Anzahl der Wakeups pro Nutzer pro Stunde, um zu analysieren, wie viele Nutzer von einer hohen Wakeup-Rate betroffen sind.
- Für Apps, bei denen in der Manifestdatei eine
sharedUserIdfestgelegt wurde: Es werden nur Daten angezeigt, wenn höchstens eine App mit derselbensharedUserIdinstalliert wurde.
Details zu Android Vitals
- Betroffene Sitzungen: Prozentsatz der Akkusitzungen, bei denen Nutzer mehr als zehn Wakeups pro Stunde hatten. Eine Akkusitzung ist die Zusammenfassung aller Akkuberichte, die innerhalb eines festgelegten Zeitraums von 24 Stunden empfangen wurden. In Android 10 bezieht sich ein Akkubericht auf das Intervall zwischen zwei Akkuladungen: entweder von unter 20 % bis über 80 % oder von einem beliebigen Wert bis 100 %. Ab Android 11 bezieht sich ein Akkubericht auf einen festen Zeitraum von 24 Stunden. Google erfasst die Daten nur, während das Gerät nicht geladen wird.
- Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
- 90./99. Perzentil: 10 % bzw. 1 % der täglichen Sitzungen, bei denen Nutzer mehr Wakeups pro Stunde hatten als den angegebenen Wert.
- Grenzwert zu unerwünschtem Verhalten: Wenn Ihre App über dem angezeigten Grenzwert liegt oder ihm entspricht, gehört sie zu den unteren 25 % der 1.000 meist installierten Apps bei Google Play.
Problem beheben
Wenn in Ihrer App häufig Wakeups vorkommen, finden Sie auf der Website für Android-Entwickler Lösungsansätze.
Auf der Seite Übermäßig viele WLAN-Scans im Hintergrund wird angezeigt, wenn WLAN-Scans den Akku stark beanspruchen.
Details zur Datenerhebung
Daten zu WLAN-Scans werden erfasst, während das Gerät gerade nicht geladen und die App im Hintergrund ausgeführt wird.
Details zu Android Vitals
- Betroffene Sitzungen: Prozentsatz der Akkusitzungen, bei denen mehr als vier WLAN‑Scans pro Stunde durchgeführt wurden.
- Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
- 90./99. Perzentil: 10 % bzw. 1 % der täglichen Sitzungen, bei denen im Hintergrund mehr WLAN‑Scans pro Stunde durchgeführt wurden als der angezeigte Wert.
Problem beheben
Wenn auf Ihrem Gerät viele WLAN-Scans im Hintergrund auftreten, finden Sie auf der Website für Android-Entwickler Lösungsansätze.
Auf der Seite Übermäßige Mobilfunknutzung im Hintergrund wird angezeigt, wenn einem Hintergrunddienst große Mengen Netzwerkdaten zugeordnet sind. Wenn die Mobilfunknutzung im Hintergrund erfolgt, ist es Nutzern aufgrund fehlender Steuerelemente nicht ohne Weiteres möglich, die Datenübertragung zu stoppen.
Details zur Datenerhebung
Daten zur Mobilfunknutzung werden erfasst, während das Gerät gerade nicht geladen und die App im Hintergrund ausgeführt wird.
Details zu Android Vitals
- Betroffene Sitzungen: Prozentsatz der Akkusitzungen, bei denen pro Tag mehr als 50 MB Mobilfunkdaten im Hintergrund genutzt wurden.
- Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
- 90./99. Perzentil: 10 % bzw. 1 % der täglichen Sitzungen, bei denen im Hintergrund eine höhere tägliche Mobilfunknutzung stattfand als der angezeigte Wert.
Problem beheben
Wenn Ihre App eine starke Mobilfunknutzung im Hintergrund verursacht, finden Sie auf der Website für Android-Entwickler Lösungsansätze.
Berechtigungen
Abgelehnte BerechtigungenAuf der Seite Abgelehnte Berechtigungen sehen Sie Details zum Prozentsatz der täglichen Berechtigungssitzungen, bei denen Nutzer Berechtigungen verweigert haben. Eine tägliche Berechtigungssitzung bezieht sich auf einen Tag, an dem Ihre App mindestens eine Berechtigungsanfrage an einen Nutzer stellt.
Details zur Datenerhebung
Daten zu abgelehnten Berechtigungen werden erfasst, wenn Nutzer auf Berechtigungsanfragen in Ihrer App reagieren.
Details zu Android Vitals
- Ablehnungen: Prozentsatz der täglichen Berechtigungssitzungen, bei denen Nutzer Berechtigungen verweigert haben
- Nicht mehr fragen: Prozentsatz der täglichen Berechtigungssitzungen, bei denen Nutzer die Option „Nicht mehr fragen“ ausgewählt und damit Berechtigungen verweigert haben.
- Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
Problem beheben
Wenn in Ihrer App viele Berechtigungen abgelehnt wurden, finden Sie auf der Website für Android-Entwickler Lösungsansätze.
Grenzwert zu unerwünschtem Verhalten bei Vitalparametern
Google Play hat Grenzwerte zu unerwünschtem Verhalten für die Vitalparameter Ihrer App definiert.
Überschreitet Ihre App einen Grenzwert zu unerwünschtem Verhalten, ist sie bei Google Play wahrscheinlich weniger gut sichtbar. Wenn Ihre App auf bestimmten Gerätemodellen ein unerwünschtes Verhalten aufweist, werden Nutzern dieser Geräte bei Google Play besser geeignete Apps angezeigt. In einigen Fällen wird im Store-Eintrag der App auch eine Warnung angezeigt, um die Nutzer zu informieren und ihnen die Möglichkeit zu bieten, nach Alternativen mit einer besseren technischen Qualität zu suchen.
Google Play berücksichtigt bei der Bewertung der App-Qualität in der Regel die Daten der letzten 28 Tage, kann jedoch im Falle einer starken Zunahme der Probleme auch schneller handeln.
Alles minimieren Alles maximieren
Stabilität
Grenzwerte für die Rate der vom Nutzer wahrgenommenen ANR-FehlerGoogle Play hat Grenzwerte zu unerwünschtem Verhalten für die Rate der vom Nutzer wahrgenommenen ANR-Fehler definiert:
-
Unerwünschtes Verhalten auf allen Geräten: Bei mindestens 0,47 % der aktiven Nutzer pro Tag tritt auf allen Gerätemodellen ein vom Nutzer wahrgenommener ANR-Fehler auf.
-
Unerwünschtes Verhalten auf einzelnen Geräten: Bei mindestens 8 % der aktiven Nutzer pro Tag tritt bei einem einzelnen Gerätemodell ein vom Nutzer wahrgenommener ANR-Fehler auf.
Um die ANR-Rate zu verbessern, korrigieren Sie die zugrunde liegenden ANR-Cluster, die auf der Seite Abstürze und ANRs aufgeführt werden. Je größer die Anzahl der betroffenen Nutzer ist, desto stärker fällt dieser Cluster bei der ANR-Rate ins Gewicht.
Falls bestimmte Aspekte der Gerätehardware oder ‑software zur ANR-Rate beitragen, werden Sie von Android Vitals benachrichtigt. Sie können sich die Zusammenhänge auch auf der Seite Übersicht zu Reichweite und Geräten ansehen (Release > Reichweite und Geräte > Übersicht).
Google Play hat Grenzwerte zu unerwünschtem Verhalten für die Rate der vom Nutzer wahrgenommenen Abstürze definiert:
-
Unerwünschtes Verhalten auf allen Geräten: Auf allen Gerätemodellen tritt bei mindestens 1,09 % der Nutzer pro Tag ein vom Nutzer wahrgenommener Absturz auf.
-
Unerwünschtes Verhalten auf einzelnen Geräten: Bei einem einzelnen Gerätemodell tritt bei mindestens 8 % der Nutzer pro Tag ein vom Nutzer wahrgenommener Absturz auf.
Um die Absturzrate zu verbessern, korrigieren Sie die zugrunde liegenden Absturzcluster, die auf der Seite Abstürze und ANRs aufgeführt werden. Je größer die Anzahl der betroffenen Nutzer ist, desto stärker fällt dieser Cluster bei der Absturzrate ins Gewicht.
Falls bestimmte Aspekte der Gerätehardware oder ‑software zur Absturzrate beitragen, werden Sie von Android Vitals benachrichtigt. Sie können sich die Zusammenhänge auch auf der Seite Übersicht zu Reichweite und Geräten ansehen (Release > Reichweite und Geräte > Übersicht).