Produktneuheiten

Akkulaufzeit Ihrer App mit dem Android Vitals-Messwert für Wakelocks optimieren

7 Minuten Lesezeit
Profil von Alice Yuan ansehen
Alice Yuan Developer Relations Engineer, Android

Die Akkulaufzeit ist ein entscheidender Aspekt der Nutzererfahrung und Wakelocks spielen dabei eine wichtige Rolle. Verwenden Sie sie übermäßig? In diesem Blogpost erfahren Sie, was Wakelocks sind, welche Best Practices für ihre Verwendung gelten und wie Sie das Verhalten Ihrer eigenen App mit dem Messwert in der Play Console besser nachvollziehen können.

Übermäßige Verwendung von Teil-Wakelocks in Android Vitals

In der Play Console wird jetzt der Akkuverbrauch überwacht, wobei der Fokus auf der übermäßigen Verwendung von Teil-Wakelocks als wichtiger Leistungsmesswert liegt.

Diese Funktion unterstreicht die Bedeutung der Akkueffizienz neben den bestehenden Stabilitätsindikatoren für wichtige Messwerte: übermäßige Abstürze und ANRs aus Nutzersicht. Wir haben einen Grenzwert zu unerwünschtem Verhalten bei übermäßigen Wakelocksdefiniert. Wenn Ihr Titel diesen Qualitätsgrenzwert ab dem 1. März 2026 nicht erfüllt, schließen wir ihn möglicherweise von prominenten Oberflächen zur Auffindbarkeit wie Empfehlungen aus. In einigen Fällen zeigen wir im Store-Eintrag Ihrer App eine Warnung an, um Nutzer darauf hinzuweisen, dass Ihre App möglicherweise eine schnelle Akkuentladung verursacht.

warning.png

Die Warnung zu übermäßigen Wakelocks in der Übersicht von Android Vitals.

Bei Mobilgeräten gilt der Android Vitals-Messwert für nicht ausgenommene Wakelocks, die erfasst werden, während das Display ausgeschaltet ist und die App im Hintergrund ausgeführt wird oder ein Dienst im Vordergrund ausgeführt wird. Android Vitals betrachtet die Verwendung von Teil-Wakelocks als übermäßig, wenn:

  • Wakelocks innerhalb von 24 Stunden mindestens zwei Stunden lang gehalten werden.
  • Dies durchschnittlich über 28 Tage mehr als 5% der Sitzungen Ihrer App betrifft.

Wakelocks, die von Audio, Standort und JobScheduler-APIs erstellt wurden, die vom Nutzer initiiert wurden, sind von der Berechnung der Wakelocks ausgenommen.

Wakelocks

Ein Wakelock ist ein Mechanismus, mit dem eine App die CPU eines Geräts auch dann ausführen kann, wenn der Nutzer nicht aktiv mit dem Gerät interagiert. 

Ein Teil-Wakelock sorgt dafür, dass die CPU auch dann ausgeführt wird, wenn das Display ausgeschaltet ist, und verhindert, dass die CPU in einen energiesparenden „Suspend“-Zustand wechselt. Ein vollständiger Wakelock sorgt dafür, dass sowohl das Display als auch die CPU ausgeführt werden.

Es gibt zwei Methoden, mit denen Teil-Wakelocks erfasst werden können:

  • Die App erfasst und gibt den Wakelock manuell mit PowerManager-APIs für einen bestimmten Anwendungsfall frei. Oft wird er in Verbindung mit einem Dienst im Vordergrund erfasst. Dabei handelt es sich um eine API für den Lebenszyklus der Plattform, die für einen für den Nutzer wahrnehmbaren Vorgang vorgesehen ist.
  • Alternativ wird der Wakelock von einer anderen API erfasst und der App aufgrund der Verwendung der API zugewiesen. Weitere Informationen finden Sie im Abschnitt zu Best Practices.

Wakelocks sind zwar für Aufgaben wie das Abschließen eines vom Nutzer initiierten Downloads einer großen Datei erforderlich, aber ihre übermäßige oder unsachgemäße Verwendung kann zu einer schnellen Akkuentladung führen. Wir haben Fälle beobachtet, in denen Apps Wakelocks stundenlang gehalten oder nicht ordnungsgemäß freigegeben haben, was zu Nutzerbeschwerden über eine schnelle Akkuentladung geführt hat, auch wenn sie nicht mit der App interagiert haben.

Best Practices für die Verwendung von Wakelocks

Bevor wir uns ansehen, wie Sie die übermäßige Verwendung von Wakelocks beheben können, sollten Sie die Best Practices für Wakelocks beachten. 

Beantworten Sie diese vier wichtigen Fragen.


1. Haben Sie alternative Wakelock-Optionen in Betracht gezogen?

Bevor Sie einen manuellen Teil-Wakelock erfassen, folgen Sie diesem Entscheidungsflussdiagramm:

wakelock.png

Flussdiagramm zur Entscheidung, wann ein Wakelock manuell erfasst werden soll

  1. Muss das Display eingeschaltet bleiben?
  2. Wird in der Anwendung ein Dienst im Vordergrund ausgeführt?
    • Nein: Sie müssen keinen Wakelock manuell erfassen.
  3. Ist es nachteilig für die Nutzererfahrung, wenn das Gerät in den Suspend-Modus wechselt?
    • Nein: Für das Aktualisieren einer Benachrichtigung, nachdem das Gerät aufgeweckt wurde, ist beispielsweise kein Wakelock erforderlich.
    • Ja: Wenn es wichtig ist, zu verhindern, dass das Gerät in den Suspend-Modus wechselt, z. B. bei der laufenden Kommunikation mit einem externen Gerät, fahren Sie fort.
  4. Gibt es bereits eine API, die das Gerät in Ihrem Namen aktiv hält?
  5. Wenn Sie alle diese Fragen beantwortet haben und keine Alternative gefunden haben, sollten Sie einen Wakelock manuell erfassen.

2. Benennen Sie den Wakelock richtig?

Beim manuellen Erfassen von Wakelocks ist die richtige Benennung für die Fehlerbehebung wichtig:

  • Lassen Sie alle personenbezogenen Daten (personenidentifizierbare Informationen) im Namen weg, z. B. E‑Mail-Adressen. Wenn personenbezogene Daten erkannt werden, wird der Wakelock als _UNKNOWN protokolliert, was die Fehlerbehebung erschwert.
  • Benennen Sie Ihren Wakelock nicht programmatisch mit Klassen- oder Methodennamen, da diese von Tools wie Proguard verschleiert werden können. Verwenden Sie stattdessen einen fest codierten String.
  • Fügen Sie den Wakelock-Tags keine Zähler oder eindeutigen IDs hinzu. Dasselbe Tag sollte jedes Mal verwendet werden, wenn der Wakelock ausgeführt wird, damit das System die Nutzung nach Namen zusammenfassen kann. So lassen sich ungewöhnliche Verhaltensweisen leichter erkennen.

3. Wird der erfasste Wakelock immer freigegeben?

Wenn Sie einen Wakelock manuell erfassen, muss die Freigabe des Wakelocks immer ausgeführt werden. Wenn ein Wakelock nicht freigegeben wird, kann dies zu einer schnellen Akkuentladung führen. 

Wenn beispielsweise während der Ausführung von „processingWork()“ eine nicht abgefangene Ausnahme ausgelöst wird, wird der Aufruf „release()“ möglicherweise nie ausgeführt. Stattdessen können Sie einen Try/Finally-Block verwenden, um sicherzustellen, dass der Wakelock freigegeben wird, auch wenn eine Ausnahme auftritt.

Außerdem können Sie dem Wakelock ein Zeitlimit hinzufügen, damit er nach einem bestimmten Zeitraum freigegeben wird und nicht unbegrenzt gehalten wird.

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. Können Sie die Aufwachfrequenz reduzieren?

Bei regelmäßigen Datenanfragen ist es wichtig, die Häufigkeit zu reduzieren, mit der Ihre App das Gerät aufweckt, um die Akku-Optimierung zu unterstützen. Beispiele für die Reduzierung der Aufwachfrequenz:

  • WorkManager: Erhöhen Sie das periodische Intervall in PeriodicWorkRequests.
  • SensorManager: Nutzen Sie Batching, indem Sie beim Registrieren des Listeners maxReportLatencyMs angeben.
  • Anbieter für kombinierte Standortbestimmung:
    • Reduzieren Sie die Häufigkeit des Abrufs von Standortdaten, indem Sie „getLastLocation“ für den zuletzt im Cache gespeicherten Standort verwenden.
    • Verwenden Sie „setPriority(PRIORITY_PASSIVE)“ für eine weniger akkuintensive Aktualisierungsmethode.
    • Außerdem können Sie den Mechanismus für das Batching von Standortdaten nutzen, indem Sie mit „setMinUpdateIntervalMillis“ ein Mindestaktualisierungsintervall festlegen.

Weitere Informationen finden Sie in der Dokumentation zu Best Practices für Wakelocks.

Fehlerbehebung bei übermäßiger Verwendung von Wakelocks

Auch mit den besten Absichten kann es zu einer übermäßigen Verwendung von Wakelocks kommen. Wenn Ihre App in der Play Console gekennzeichnet ist, gehen Sie so vor, um Fehler zu beheben:

Erste Identifizierung mit der Play Console

Das Android Vitals-Dashboard für übermäßige Teil-Wakelocks enthält Aufschlüsselungen der nicht ausgenommenen Wakelock-Namen, die mit Ihrer App verknüpft sind, sowie die betroffenen Sitzungen und Zeiträume. Denken Sie daran, in der Dokumentation nachzusehen, ob der Wakelock-Name von der App oder von einer anderen API gehalten wird.

breakdowns2.png

Das Android Vitals-Dashboard für übermäßige Teil-Wakelocks wurde nach unten zum Abschnitt „Aufschlüsselungen“ gescrollt, um Tags für übermäßige Wakelocks anzuzeigen.

Fehlerbehebung bei übermäßigen Wakelocks, die von Workern/Jobs gehalten werden

Wakelocks, die von Workern gehalten werden, können Sie mit diesem Wakelock-Namen identifizieren:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

Die vollständige Liste der Varianten von Wakelock-Namen, die von Workern gehalten werden, finden Sie in der Dokumentation. Zur Fehlerbehebung bei diesen Wakelocks können Sie den Background Task Inspector für die lokale Fehlerbehebung verwenden oder „getStopReason“ nutzen, um Probleme im Feld zu beheben. 

Background Task Inspector von Android Studio

taskinspector.png


Screenshot des Background Task Inspector, auf dem ein Worker „WeatherSyncWorker“ identifiziert wurde, der häufig wiederholt wurde und fehlgeschlagen ist.

Verwenden Sie dieses Tool auf einem Emulator oder verbundenen Gerät (API-Level 26 oder höher), um Fehler bei WorkManager lokal zu beheben. Es zeigt eine Liste der Worker und ihrer Status (abgeschlossen, wird ausgeführt, in die Warteschlange gestellt) an, sodass Sie Details prüfen und Worker-Ketten nachvollziehen können. 

So können Sie beispielsweise feststellen, ob ein Worker häufig fehlschlägt oder wiederholt wird, weil Systemlimits erreicht wurden. 

Weitere Informationen finden Sie in der Dokumentation zum Background Task Inspector.

WorkManager getStopReason

Verwenden Sie für die Fehlerbehebung bei Workern mit übermäßigen Wakelocks im Feld WorkInfo.getStopReason() in WorkManager 2.9.0 oder höher oder für JobScheduler JobParameters.getStopReason() in SDK 31 oder höher. 

Mit dieser API können Sie den Grund dafür protokollieren, warum ein Worker beendet wurde (z. B. STOP_REASON_TIMEOUT, STOP_REASON_QUOTA). So lassen sich Probleme wie häufige Zeitüberschreitungen aufgrund der Erschöpfung der Laufzeit ermitteln.

backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

Weitere Informationen finden Sie unter Akkunutzung für APIs zur Aufgabenplanung optimieren.

Fehlerbehebung bei anderen Arten von übermäßigen Wakelocks

Bei komplexeren Szenarien mit manuell gehaltenen Wakelocks oder APIs, die den Wakelock halten, empfehlen wir, die System-Trace-Erfassung zur Fehlerbehebung zu verwenden.

System-Trace-Erfassung

Ein System-Trace  ist ein leistungsstarkes Tool zur Fehlerbehebung, mit dem eine detaillierte Aufzeichnung der Systemaktivität über einen bestimmten Zeitraum erfasst wird. Es bietet Einblicke in den CPU-Status, die Thread-Aktivität, die Netzwerkaktivität und akkubezogene Messwerte wie die Jobdauer und die Verwendung von Wakelocks.

Sie können einen System-Trace mit verschiedenen Methoden erfassen: 

powermgmt.png

Aktivieren Sie die Atrace-Kategorie „power:PowerManagement“ in der Perfetto-UI auf dem Tab „Android apps & svcs“. 

Unabhängig von der gewählten Methode müssen Sie die Atrace-Kategorie „power:PowerManagement“ erfassen, damit Sie die Tracks zum Gerätestatus ansehen können. 

Prüfung der Perfetto-UI und SQL-Analyse

System-Traces können in der Perfetto-UI geöffnet und geprüft werden. Wenn Sie den Trace öffnen, sehen Sie eine Visualisierung verschiedener Prozesse auf einer Zeitachse. Die Tracks, auf die wir uns in diesem Leitfaden konzentrieren, befinden sich unter „Device State“.

perfetto.png


Pinnen Sie die Tracks unter „Device State“ an, z. B. „Top app“, „Screen state“, „Long Wake locks“ und „Jobs“, um lange Wakelock-Abschnitte visuell zu identifizieren.

In jedem Block sind der Name des Ereignisses, der Startzeitpunkt und der Endzeitpunkt aufgeführt. In Perfetto wird dies als Abschnitt bezeichnet.

Für die skalierbare Analyse mehrerer Traces können Sie die SQL-Analyse von Perfetto verwenden. Mit einer SQL-Abfrage lassen sich alle Wakelocks nach Dauer sortiert finden. So können Sie die Hauptursachen für die übermäßige Verwendung ermitteln.

Hier ist eine Beispielabfrage, mit der alle Wakelock-Tags summiert werden, die im System-Trace aufgetreten sind, sortiert nach Gesamtdauer:

SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

ProfilingManager für die Trace-Erfassung im Feld verwenden

Bei schwer zu reproduzierenden Problemen ist ProfilingManager (in SDK 35 hinzugefügt) eine programmatische API, mit der Entwickler System-Traces im Feld mit Start- und End-Triggern erfassen können. Sie bietet mehr Kontrolle über die Start- und End-Triggerpunkte für die Profilerfassung und erzwingt eine Ratenbegrenzung auf Systemebene, um Auswirkungen auf die Geräteleistung zu vermeiden. 

In der Dokumentation zu ProfilingManager finden Sie weitere Schritte zur Implementierung der System-Trace-Erfassung im Feld, einschließlich Informationen zum programmatischen Erfassen eines Traces, zum Analysieren von Profiling-Daten und zur Verwendung lokaler Debug-Befehle.

Die mit ProfilingManager erfassten System-Traces ähneln den manuell erfassten, aber Systemprozesse und andere App-Prozesse werden aus dem Trace entfernt.

Fazit

Der Messwert für übermäßige Teil-Wakelocks in Android Vitals ist nur ein kleiner Teil unseres kontinuierlichen Engagements, Entwickler dabei zu unterstützen, den Akkuverbrauch zu reduzieren und die App-Qualität zu verbessern. 

Wenn Sie Wakelocks verstehen und richtig implementieren, können Sie die Akkuleistung Ihrer App erheblich optimieren. Die Verwendung alternativer APIs, die Einhaltung der Best Practices für Wakelocks und die Nutzung leistungsstarker Tools zur Fehlerbehebung wie Background Task Inspector, System-Traces und ProfilingManager sind entscheidend für den Erfolg Ihrer App bei Google Play.

Geschrieben von:
Weiterlesen