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, die von Nutzern wahrgenommen werden. 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 App-Suche wie Empfehlungen aus. In einigen Fällen wird im Store-Eintrag Ihrer App auch eine Warnung angezeigt, um Nutzer darauf hinzuweisen, dass Ihre App möglicherweise zu einer schnellen Akkuentladung führt.

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 abgerufen 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 hinweg mehr als 5% der Sitzungen Ihrer App betrifft.

Wakelocks, die von nutzerinitiierten APIs für Audio, Standort und JobScheduler erstellt 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 aktiv halten kann, wenn der Nutzer nicht aktiv mit dem Gerät interagiert. 

Ein Teil-Wakelock hält die CPU aktiv, auch wenn das Display ausgeschaltet ist, und verhindert, dass die CPU in einen energiesparenden „Suspend“-Zustand wechselt. Ein vollständiger Wakelock hält sowohl das Display als auch die CPU aktiv.

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

  • Die App ruft den Wakelock manuell ab und gibt ihn wieder frei. Dazu werden PowerManager APIs für einen bestimmten Anwendungsfall verwendet. Oft wird er in Verbindung mit einem Dienst im Vordergrund abgerufen. Dabei handelt es sich um eine API für den Lebenszyklus der Plattform, die für nutzerwahrnehmbare Vorgänge vorgesehen ist.
  • Alternativ wird der Wakelock von einer anderen API abgerufen und der App aufgrund der Verwendung der API zugewiesen. Weitere Informationen dazu finden Sie im Abschnitt zu Best Practices.

Wakelocks sind zwar für Aufgaben wie das Abschließen eines nutzerinitiierten 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 halten oder sie nicht ordnungsgemäß freigeben. Dies führt zu Beschwerden von Nutzern über eine erhebliche schnelle Akkuentladung, auch wenn sie nicht mit der App interagieren.

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 die folgenden vier wichtigen Fragen.


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

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

wakelock.png

Flussdiagramm zur Entscheidung, wann ein Wakelock manuell abgerufen 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 abrufen.
  3. Ist es nachteilig für die Nutzererfahrung, wenn das Gerät in den Suspend-Modus wechselt?
    • Nein: Wenn Sie beispielsweise eine Benachrichtigung aktualisieren, nachdem das Gerät aufgewacht ist, ist 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 für Sie aktiv hält?
  5. Wenn Sie alle diese Fragen beantwortet haben und keine Alternative gefunden haben, sollten Sie einen Wakelock manuell abrufen.

2. Benennen Sie den Wakelock richtig?

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

  • Geben Sie im Namen keine personenbezogenen Informationen (personenidentifizierbare Informationen) wie E‑Mail-Adressen an. Wenn personenbezogene Informationen 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 anormale Verhaltensweisen leichter erkennen.

3. Wird der abgerufene Wakelock immer freigegeben?

Wenn Sie einen Wakelock manuell abrufen, 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 Verarbeitung von „processingWork()“ eine nicht abgefangene Ausnahme ausgelöst wird, wird der Aufruf von „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 für die Akku-Optimierung entscheidend, wie oft Ihre App das Gerät aufweckt. Hier einige Beispiele, wie Sie die Aufwachfrequenz reduzieren können:

  • 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 Standort-Batching 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 das Problem zu beheben:

Erste Identifizierung mit der Play Console

Im Android Vitals-Dashboard für übermäßige Teil-Wakelocks finden Sie 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.

Für die lokale Fehlerbehebung bei WorkManager-Problemen verwenden Sie dieses Tool auf einem Emulator oder einem verbundenen Gerät (API-Level 26 oder höher). 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

Für die Fehlerbehebung im Feld bei Workern mit übermäßigen Wakelocks verwenden Sie 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 Verwendung der System-Trace-Erfassung zur Fehlerbehebung.

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 auf verschiedene Arten 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, um die Tracks für den Gerätestatus ansehen zu 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 Beginn und das Ende des Ereignisses 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, die alle Wakelock-Tags summiert, 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 Profilerstellung und erzwingt eine Ratenbegrenzung auf Systemebene, um Auswirkungen auf die Geräteleistung zu vermeiden. 

In der Dokumentation zu ProfilingManager finden Sie weitere Informationen zur Implementierung der System-Trace-Erfassung im Feld, einschließlich der programmatischen Erfassung eines Traces, der Analyse von Profiling-Daten und der 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 bei der Reduzierung des Akkuverbrauchs und der Verbesserung der App-Qualität zu unterstützen. 

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