Anwendungsfälle für Wake Locks identifizieren und optimieren

In diesem Dokument erfahren Sie, wie Sie Wake-Lock-Anwendungsfälle in Ihrer App identifizieren und optimieren. Außerdem wird hervorgehoben, ob es Wake-Locks gibt, die von anderen Bibliotheken oder System-APIs erworben wurden, die mit diesem Anwendungsfall verknüpft sind. Da diese Wake-Locks Ihrer App zugeordnet werden, kann es schwierig sein, die Quelle eines problematischen Wake-Locks zu ermitteln. Eine falsche API-Nutzung kann dazu führen, dass deine App wegen übermäßiger Nutzung von Wakelocks gekennzeichnet wird, auch wenn du Wakelocks nicht explizit erwirbst.

In diesem Dokument sind einige gängige Wake-Lock-Namen aufgeführt, die bei der Verwendung der Debugging-Tools für Wake-Locks oder in Berichten von Android Vitals auftreten können. Diese Namen können aus einer Bibliothek oder System-API stammen oder verschleiert sein. Wenn Sie die Debugging-Tools verwenden, um fehlerhafte Wakelocks zu identifizieren, und dann in diesem Dokument nach dem Namen des Wakelocks suchen, können Sie feststellen, welche API das Problem verursacht, und Empfehlungen zur Optimierung der Nutzung finden.

In diesem Dokument werden gängige Anwendungsfälle für die Verwendung von Wakelocks beschrieben. Außerdem werden die Wakelock-Namen aufgeführt, die von verschiedenen APIs und Bibliotheken verwendet werden, und es werden Empfehlungen und Best Practices zur Optimierung und Reduzierung der Wakelock-Nutzung gegeben.

AlarmManager

AlarmManager ruft Wakelocks ab und ordnet sie der aufrufenden App zu. AlarmManager ruft den Wakelock ab, wenn der Wecker ausgelöst wird, und gibt ihn frei, wenn die Methode onReceive() des Wecker-Broadcasts ausgeführt wurde.

Wakelock-Namen

AlarmManager erstellt Wakelocks mit dem Namen *alarm*. Die Sternchen sind Teil des Namens der Wakelock und keine Platzhalter.

Empfehlung

Wir empfehlen die folgenden Best Practices, um das Verhalten von Alarmen zu optimieren:

  • Unter Weckertyp auswählen kannst du dich zwischen einem ungenauen und einem genauen Wecker entscheiden. Wenn der Wecker nicht genau sein muss, können Sie ungenaue Wecker verwenden, um dem System mehr Flexibilität bei der Planung zu geben. Das kann die Akkulaufzeit verbessern.
  • Beachten Sie die vom System vorgegebenen Kontingente für Alarme und berücksichtigen Sie diese beim Design Ihrer App.
  • Vermeide langwierige Aufgaben in der Methode onReceive() und plane Worker, wenn nach dem Wecker zusätzliche Verarbeitung erforderlich ist.

Audio und Medien

Media APIs können Wakelocks abrufen, wenn Audio aufgenommen oder wiedergegeben wird. Die Wakelocks werden der aufrufenden App zugeordnet.

Wakelock-Namen

Media APIs rufen Wakelocks mit verschiedenen Namen ab, die mit Audio beginnen:

  • AudioBitPerfect: Wird für die verlustfreie USB-Audiowiedergabe verwendet.
  • AudioDirectOut: Wird für die verlustfreie Audiowiedergabe auf einem Fernseher oder einem speziellen Gerät verwendet.
  • AudioDup: Wird für die Wiedergabe von Benachrichtigungen verwendet, wenn eine Verbindung über Bluetooth oder USB besteht.
  • AudioIn: Wird für die Audioaufnahme im Camcorder-Modus verwendet, wenn das Mikrofon aktiv ist.
  • AudioMix: Wird für die Audiowiedergabe auf einem gängigen Gerät verwendet.
  • AudioOffload: Wird für die langfristige Wiedergabe von Musik in Apps verwendet, die diesen Modus unterstützen.
  • AudioSpatial: Wird für die Wiedergabe von mehrkanaligen Film- oder Musik-Audiodaten auf Geräten verwendet, die Spatial Audio unterstützen.
  • AudioUnknown: Wird verwendet, wenn die anderen Situationen nicht zutreffen.
  • MmapCapture: Wird für die Audioaufnahme mit niedriger Latenz verwendet.
  • MmapPlayback: Wird für die Wiedergabe mit niedriger Latenz verwendet, z. B. für Spiele oder professionelle Audioanwendungen.

Empfehlung

Wir empfehlen Folgendes:

  • Deklariere keine Wakelock-Namen, die mit Audio beginnen.
  • Wenn du die Media APIs verwendest, musst du keine Wakelocks direkt anfordern. Du kannst dich darauf verlassen, dass die APIs die erforderlichen Wakelocks für dich anfordern.
  • Wenn Sie Medien-APIs verwenden, beenden Sie die Mediensitzung und den zugehörigen Dienst im Vordergrund, wenn Sie sie nicht mehr benötigen.

Bluetooth

Die Bluetooth-APIs der Plattform halten hauptsächlich Kernel-Wakelocks, während Bluetooth-Aktionen ausgeführt werden, die nicht der Anwendung zugeordnet werden können.

Empfehlung

  • Verwende die Kopplung von Companion-Geräten, um Bluetooth-Geräte zu koppeln, damit du beim Bluetooth-Koppeln keine manuelle Wakelock-Sperre erwerben musst.
  • In der Anleitung zur Kommunikation im Hintergrund erfährst du, wie du die Bluetooth-Kommunikation im Hintergrund einrichtest.
  • Die Verwendung von WorkManager ist oft ausreichend, wenn eine verzögerte Kommunikation keine Auswirkungen auf die Nutzer hat. Wenn ein manueller Wakelock als notwendig erachtet wird, sollte er nur für die Dauer der Bluetooth-Aktivität oder der Verarbeitung der Aktivitätsdaten gehalten werden.

Gerätesensoren

Es gibt mehrere Methoden, um Gerätesensordaten wie Schrittzahl, Beschleunigungsmesser- oder Gyroskopdaten zu erfassen.

Unter Wear OS kannst du die Wear-Gesundheitsdienste verwenden, um Gerätedaten wie Höhe, Herzfrequenz und zurückgelegte Strecke abzurufen.

Wenn die Daten von anderen Anwendungen erhoben werden, kannst du Health Connect in Kombination mit WorkManager verwenden, um die Daten regelmäßig abzurufen.

Für Szenarien wie das Erfassen der Differenz bei Schritten oder zurückgelegter Strecke können Sie die Recording API auf Mobilgeräten in Kombination mit WorkManager verwenden, um die Daten regelmäßig abzurufen. Für den Zugriff auf historische Schrittdaten (z. B. die tägliche Gesamtzahl der Schritte oder die Schritte in den letzten 6 Stunden) unterstützt Health Connect auch das Schritt-Tracking auf dem Gerät für Geräte mit Android 14 oder höher.

In bestimmten Situationen kann es erforderlich sein, benutzerdefinierte Gerätesensoren mit SensorManager zu tracken. SensorManager fordert keine Wakelocks im Namen der App an, es sei denn, der Sensor ist ein Aktivierungssensor, der mit der isWakeUpSensor API identifiziert werden kann.

Empfehlung

Die Verwendung von Sensoren zur Aufzeichnung mit hohen Abtastraten kann den Akku erheblich belasten. Hier sind Empfehlungen, wie du die schnelle Akkuentladung und die Verwendung von Wakelocks reduzieren kannst:

  • Wenn du die Schrittzahl oder die zurückgelegte Strecke erfassen möchtest, verwende die Recording API, um Daten akkuschonend aufzuzeichnen. Für Geräte mit Android 14 oder höher kannst du Health Connect verwenden, um auf den Verlauf der Gerätedaten und die aggregierte Schrittzahl zuzugreifen.
  • Verwenden Sie für das passive Sensortracking unter Wear OS die Wear-Gesundheitsdienste, um die Akkunutzung zu optimieren.
  • Wenn du einen Sensor mit SensorManager registrierst, definiere eine maxReportLatencyUs von mehr als 30 Sekunden, um die Sensor-Batching-Logik zu verwenden und die Anzahl der Unterbrechungen zu reduzieren, die die Anwendung empfängt. Wenn das Gerät anschließend durch einen anderen Trigger wie eine Nutzerinteraktion, einen Standortabruf oder einen geplanten Job aktiviert wird, sendet das System die im Cache gespeicherten Sensordaten sofort.
  • Wenn deine App sowohl Standort- als auch Sensordaten benötigt, synchronisiere den Abruf und die Verarbeitung der Ereignisse. Wenn du die Sensormesswerte mit dem kurzen Wakelock zusammenführst, den das System für Standort-Updates verwendet, benötigst du keinen Wakelock, um die CPU aktiv zu halten. Verwende einen Worker oder eine kurzzeitige Wakelock, um das Hochladen und Verarbeiten dieser kombinierten Daten zu verwalten.

Firebase Cloud Message (FCM)

Während der Übermittlung einer Firebase Cloud Message (FCM)-Übertragung an die App wird eine Wakelock-Sperre abgerufen. Die Wakelock-Sperre wird aufgehoben, sobald die Ausführung der FCM-Übertragungsmethode onMessageReceived() abgeschlossen ist.

Wakelock-Namen

Wenn eine FCM-Nachricht auf dem Gerät empfangen wird, wird ein kurzer Wakelock mit dem Namen GOOGLE_C2DM gehalten. Unter Android 16 oder höher lautet der Name des Wakelocks GCM_MESSAGE.

Empfehlung

Wir empfehlen die folgenden Best Practices, um das FCM-Verhalten zu optimieren:

  • Optimieren Sie die Häufigkeit der FCM-Zustellung.
  • Verwende FCM mit hoher Priorität nur, wenn die Nachricht tatsächlich sofort zugestellt werden muss.
  • Lassen Sie die Methode onMessageReceived() so schnell wie möglich abschließen oder planen Sie einen Worker, um die Aufgabe fortzusetzen, wenn eine zusätzliche Verarbeitung erforderlich ist. Weitere Informationen finden Sie im Firebase-Leitfaden.

JobScheduler

JobScheduler-Jobs rufen Wakelocks ab, während Aufgaben im Hintergrund ausgeführt werden. Die Wakelocks werden der App zugeordnet, die die Worker erstellt hat.

Wakelock-Namen

Die von JobScheduler erworbenen Wakelock-Namen hängen von der Version des Android-Systems, auf dem sie ausgeführt werden, und vom Zweck des Jobs ab.

Die Elemente in spitzen Klammern sind Variablen. Beispiel: „<package_name>“ ist der Name des Pakets Ihrer App, nicht der Literaltext <package name>. *job* ist jedoch die Zeichenfolge *job* mit Sternchen. Die Sternchen werden nicht als Platzhalter verwendet.

Android 15 und niedriger

Von Nutzern initiierte Jobs erstellen Wake-Locks mit Namen, die diesem Muster folgen:

*job*u/@<name_space>@/<package_name>/<classname>

Andere Jobs verwenden dieses Muster:

*job*/@<name_space>@/<package_name>/<classname>
Android 16 QPR2 und höher

Von Nutzern initiierte Jobs erstellen Wake-Locks mit Namen, die diesem Muster folgen:

*job*u/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

Für Express-Jobs wird dieses Muster verwendet:

*job*e/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

Für reguläre Jobs wird dieses Muster verwendet:

*job*r/@<name_space>@/#<trace_tag>#/<package_name>/<classname>
Beispiel

Angenommen, es gibt einen Express-Job mit dem Namespace backup und dem Trace-Tag started. Der Paketname lautet com.example.app und die Klasse, die den Job erstellt hat, ist com.backup.BackupFileService.

Auf Geräten mit Android 15 oder niedriger würde die Wakelock so heißen:

*job*/@backup@/com.example.app/com.backup.BackupFileService

Auf Geräten mit Android 16 QPR2 oder höher würde der Wakelock so heißen:

*job*e/@backup@/#started#/com.example.app/com.backup.BackupFileService

Empfehlung

  • Erwerben Sie keine manuelle Wakelock für vom Nutzer initiierte Download-/Upload-Anwendungsfälle. Verwenden Sie stattdessen die UIDT API (User-Initiated Data Transfer). Dies ist der vorgesehene Pfad für lang andauernde Datenübertragungsaufgaben, die vom Nutzer initiiert werden.
  • Wenn Sie von JobScheduler erstellte Wakelocks mit hoher Wakelock-Nutzung finden, kann das daran liegen, dass Sie Ihren Job so konfiguriert haben, dass er in bestimmten Szenarien nicht abgeschlossen wird. Analysieren Sie die Gründe für den Abbruch von Jobs, insbesondere wenn STOP_REASON_TIMEOUT häufig auftritt.
  • Prüfen Sie die Verwendung von JobScheduler-Aufgaben. Beachte insbesondere unsere Anleitung zur Optimierung der Akkunutzung für APIs zur Aufgabenplanung.

Standort

LocationManager und FusedLocationProviderClient verwenden Wake-Locks, um den Gerätestandort abzurufen und zu liefern. Die Wakelocks werden der App zugeordnet, die diese APIs aufgerufen hat.

Wakelock-Namen

Standortbezogene Dienste verwenden die folgenden Namen:

  • CollectionLib-SigCollector
  • NetworkLocationLocator
  • NetworkLocationScanner
  • NlpCollectorWakeLock
  • NlpWakeLock
  • *location*

Empfehlung

  • In unserem Leitfaden finden Sie Informationen zur Optimierung der Standortnutzung. Sie können Zeitlimits implementieren, Standortanfragen bündeln oder passive Standortaktualisierungen verwenden.
  • Vermeide es, einen separaten, kontinuierlichen Wake-Lock für das Caching von Standortdaten zu erwerben, da dies redundant ist und entfernt werden sollte. Wenn Sie mit der FusedLocationProvider- oder LocationManager-API Standortaktualisierungen anfordern, wird das Gerät während des Standort-Callbacks automatisch aktiviert. Speichern Sie die Standortereignisse stattdessen im Arbeitsspeicher oder im Speicher und verarbeiten Sie sie regelmäßig mit WorkManager.

Remote-Messaging

In diesem Abschnitt werden Szenarien mit Remote-Messaging behandelt, in denen Apps möglicherweise Verbindungen aufrechterhalten oder auf Ereignisse von anderen Geräten reagieren müssen, was sich auf die Verwendung von Wake-Locks auswirken kann. Zu den häufigsten Anwendungsfällen gehören:

  • Companion-Apps für die Video- oder Tonüberwachung, die Ereignisse auf einem externen Gerät überwachen müssen, das über ein lokales Netzwerk verbunden ist.
  • Messaging-Apps, die eine Netzwerk-Socket-Verbindung mit einer Desktop-Variante aufrechterhalten.

Die meisten Wakeups in diesen Remote-Messaging-Szenarien sind Kernel-Wakelocks. Da Kernel-Wakelocks nicht der App zugeordnet werden, gibt es hier keine zugehörigen Wakelock-Namen, die aufgeführt werden könnten.

Empfehlung

  • Wenn die Netzwerkereignisse auf der Serverseite verarbeitet werden können, verwenden Sie FCM, um Informationen auf dem Client zu empfangen. Sie können einen beschleunigten Worker planen, wenn eine zusätzliche Verarbeitung von FCM-Daten erforderlich ist.
  • Wenn Ereignisse auf der Clientseite über eine Socket-Verbindung verarbeitet werden müssen, ist kein Wakelock erforderlich, um auf Ereignisunterbrechungen zu warten. Wenn Datenpakete über die WLAN- oder Mobilfunkschnittstelle eingehen, löst die Schnittstellenhardware einen Interrupt in Form eines Kernel-Wakelocks aus. Anschließend können Sie einen Worker planen oder eine Wakelock-Sperre erwerben, um die Daten zu verarbeiten.
  • Wenn Sie beispielsweise ktor-network verwenden, um auf Datenpakete in einem Netzwerk-Socket zu warten, sollten Sie nur dann eine Wakelock-Sperre erwerben, wenn Pakete an den Client übermittelt wurden.

WorkManager

WorkManager-Worker rufen Wakelocks ab, während sie Aufgaben im Hintergrund ausführen. Die Wakelocks werden der App zugeordnet, die die Worker erstellt hat.

Wakelock-Namen

Die von WorkManager erworbenen Wakelock-Namen hängen von der Version des Android-Systems ab, auf dem sie ausgeführt werden.

Android 15 und niedriger

WorkManager-Aufgaben erstellen Wakelocks mit Namen, die diesem Muster folgen:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
Android 16 QPR2 und höher

Bei beschleunigten Aufgaben werden Wakelocks mit Namen nach folgendem Muster erstellt:

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

Reguläre Aufgaben folgen diesem Muster:

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

Standardmäßig ist <trace_tag> der Worker-Name.

Beispiel

Angenommen, es gibt einen Worker mit beschleunigter Ausführung namens BackupFileWorker. Der Paketname lautet com.example.app.

Auf Geräten mit Android 15 oder niedriger würde die Wakelock so heißen:

*job*/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Auf Geräten mit Android 16 QPR2 oder höher, die WorkManager 2.10.0+ verwenden, würde der Wakelock so heißen:

*job*e/#BackupFileWorker#/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Empfehlung

  • Aktualisieren Sie Ihre WorkManager-Version auf die neueste stabile Version, um die Wakelock-Tags unter Android 16 QPR2 oder höher ausführlicher zu gestalten.
  • Prüfen Sie die Verwendung von WorkManager-Workern. Prüfe insbesondere, ob sie unseren Leitfaden zur Optimierung der Akkunutzung für APIs zur Aufgabenplanung befolgt. Wenn Sie Wake-Lock-Tags unter Android 16 QPR2 oder höher ausführlicher gestalten möchten, verwenden Sie die Methode setTraceTag für den Worker, um weitere Debugging-Informationen hinzuzufügen, z. B. welche Klasse den Worker geplant hat.
  • Wenn Sie von WorkManager erstellte Wake-Locks mit hoher Wake-Lock-Nutzung feststellen, kann das daran liegen, dass Sie Ihren Worker falsch konfiguriert haben, sodass er in bestimmten Szenarien nicht abgeschlossen wird. Analysieren Sie die Gründe für das Beenden von Workern, insbesondere wenn Sie häufig STOP_REASON_TIMEOUT sehen.
  • Zusätzlich zum Logging der Gründe für das Beenden von Workern finden Sie weitere Informationen in unserer Dokumentation zum Debugging von Workern. Außerdem solltest du System-Traces erfassen und analysieren, um zu verstehen, wann Wakelocks erworben und freigegeben werden.

_UNKNOWN

Wenn die Debugging-Tools davon ausgehen, dass der Name eines Wake-Locks personenidentifizierbare Informationen enthält, wird der tatsächliche Name des Wake-Locks nicht angezeigt. Stattdessen wird der Wake-Lock als _UNKNOWN gekennzeichnet. Das kann beispielsweise der Fall sein, wenn der Name der Wakelock eine E-Mail-Adresse enthält.

Empfehlung

Folgen Sie den Best Practices für die Benennung von Wakelocks und vermeiden Sie die Verwendung von personenidentifizierbaren Informationen im Wakelock-Namen. Wenn du einen Wake-Lock mit dem Namen _UNKNOWN findest, der deiner App zugeordnet ist, versuche herauszufinden, um welchen Wake-Lock es sich handelt, und gib ihm einen anderen Namen.