Anwendungsfälle für Wake Locks identifizieren und optimieren

In diesem Dokument erfahren Sie, wie Sie Anwendungsfälle für Wake Locks in Ihrer App identifizieren und optimieren können. Außerdem wird erläutert, ob für diesen Anwendungsfall Wake Locks verwendet werden, die von anderen Bibliotheken oder System-APIs angefordert werden. Da diese Wake Locks Ihrer App zugeordnet sind, kann es schwierig sein, die Quelle eines problematischen Wake Locks zu ermitteln. Eine falsche API-Nutzung kann dazu führen, dass Ihre App wegen übermäßiger Nutzung von Wake Locks gekennzeichnet wird, auch wenn Sie Wake Locks nicht explizit abrufen.

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

In diesem Dokument werden gängige Anwendungsfälle für das Abrufen von Wake Locks beschrieben. Außerdem werden die Wake Lock-Namen aufgeführt, die von verschiedenen APIs und Bibliotheken verwendet werden. Darüber hinaus finden Sie Empfehlungen und Best Practices zur Optimierung und Reduzierung der Wake Lock-Nutzung.

AlarmManager

AlarmManager ruft Wake Locks ab und weist sie der aufrufenden App zu. AlarmManager ruft das Wake Lock ab, wenn der Wecker ausgelöst wird, und gibt es frei, wenn die Ausführung der Methode onReceive() des Wecker-Broadcasts abgeschlossen ist.

Wakelock-Namen

AlarmManager erstellt Wake Locks mit dem Namen *alarm*. Die Sternchen sind Teil des Namens des Wake Locks und stellen keine Platzhalter dar.

Empfehlung

Wir empfehlen die folgenden Vorgehensweisen, um das Verhalten von Benachrichtigungen zu optimieren:

  • Weitere Informationen zur Auswahl zwischen einem ungenauen und einem genauen Alarm finden Sie unter Alarmtyp auswählen. Wenn Ihr Alarm nicht präzise sein muss, verwenden Sie ungenaue Alarme, um dem System mehr Flexibilität bei der Planung zu geben. Dies kann die Akkulaufzeit verbessern.
  • Berücksichtigen Sie die vom System auferlegten Alarmkontingente und entwickeln Sie Ihre App so, dass sie diese einhält.
  • Vermeiden Sie es, in der Methode onReceive() lange Vorgänge auszuführen, und planen Sie Worker, wenn nach dem Wecker zusätzliche Verarbeitung erforderlich ist.

Audio und Medien

Media-APIs können Wake Locks beim Aufzeichnen oder Abspielen von Audioinhalten abrufen. Die Wake Locks werden der Anruf-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 gemeinsamen Gerät verwendet.
  • AudioOffload: Wird für die langfristige reine Musikwiedergabe in Apps verwendet, die diesen Modus unterstützen.
  • AudioSpatial: Wird für die Wiedergabe von Mehrkanal-Audio für Filme oder Musik auf Geräten verwendet, die Raumklang unterstützen.
  • AudioUnknown: Wird verwendet, wenn die anderen Situationen nicht zutreffen.
  • MmapCapture: Wird für die Audioaufnahme mit geringer Latenz verwendet.
  • MmapPlayback: Wird für die Wiedergabe mit geringer Latenz verwendet, z. B. für Spiele oder professionelle Audioanwendungen.

Empfehlung

Wir empfehlen Folgendes:

  • Deklarieren Sie keine Namen für Wake Locks, die mit Audio beginnen.
  • Wenn Sie die Media APIs verwenden, müssen Sie keine Wake Locks direkt abrufen. Die APIs rufen die erforderlichen Wake Locks für Sie ab.
  • Wenn Sie Media APIs verwenden, beenden Sie die Mediensitzung und den zugehörigen Vordergrunddienst, wenn Sie sie nicht mehr benötigen.

Bluetooth

Die Bluetooth-APIs der Plattform halten hauptsächlich Kernel-Wake Locks, während Bluetooth-Aktionen ausgeführt werden, die nicht der Anwendung zuzuschreiben sind.

Empfehlung

  • Verwenden Sie Companion Device Pairing (Kopplung mit Begleitgerät), um Bluetooth-Geräte zu koppeln und so zu vermeiden, dass während der Bluetooth-Kopplung ein manuelles Wake Lock angefordert wird.
  • In der Anleitung Im Hintergrund kommunizieren erfahren Sie, wie die Bluetooth-Kommunikation im Hintergrund funktioniert.
  • Die Verwendung von WorkManager ist oft ausreichend, wenn eine verzögerte Kommunikation keine Auswirkungen auf die Nutzer hat. Wenn ein manueller Wake Lock 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 verschiedene Methoden, um Gerätesensordaten wie Schrittzahl, Beschleunigungsmesser- oder Gyroskopdaten zu erfassen.

Verwende unter Wear OS Wear Health Services, um Gerätedaten wie Höhe, Herzfrequenz und zurückgelegte Distanz abzurufen.

Wenn die Daten von anderen Anwendungen erhoben werden, können Sie Health Connect in Kombination mit WorkManager verwenden, um die Daten regelmäßig abzurufen.

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

In bestimmten Situationen ist möglicherweise eine benutzerdefinierte Erfassung von Gerätesensoren mit SensorManager erforderlich. SensorManager ruft keine Wake Locks im Namen der App ab, es sei denn, der Sensor ist ein Wake-up-Sensor, der mit der isWakeUpSensor API identifiziert werden kann.

Empfehlung

Die Verwendung von Sensoren zur Aufzeichnung mit hohen Samplingraten kann den Akku erheblich entladen. Hier sind Empfehlungen zur Reduzierung des Akkuverbrauchs und der Wake Locks:

  • Wenn du Schritte oder zurückgelegte Distanzen erfassen möchtest, verwende die Recording API, um Daten akkusparend aufzuzeichnen. Bei Geräten mit Android 14 oder höher können Sie Health Connect verwenden, um auf den bisherigen Geräte- und aggregierten Schrittzähler zuzugreifen.
  • Verwenden Sie für die passive Sensornachverfolgung unter Wear OS die Wear Health Services, um den Akkuverbrauch zu optimieren.
  • Wenn Sie einen Sensor bei SensorManager registrieren, definieren Sie ein maxReportLatencyUs von mehr als 30 Sekunden, um die Logik für die Verarbeitung von Sensor-Batches 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 Ihre App sowohl Standort- als auch Sensordaten benötigt, synchronisieren Sie das Abrufen und die Verarbeitung der entsprechenden Ereignisse. Wenn Sie Sensormesswerte in den kurzen Wake Lock einfügen, den das System für Standortaktualisierungen verwendet, ist kein Wake Lock erforderlich, um die CPU aktiv zu halten. Verwenden Sie einen Worker oder einen Wake Lock mit kurzer Dauer, um das Hochladen und Verarbeiten dieser kombinierten Daten zu verarbeiten.

Firebase Cloud Messaging (FCM)

Ein Wake Lock wird abgerufen, während eine Firebase Cloud Message (FCM) an die App gesendet wird. Das Wake Lock wird freigegeben, sobald die Ausführung der FCM-Methode onMessageReceived() abgeschlossen ist.

Wakelock-Namen

Wenn auf dem Gerät eine FCM-Nachricht empfangen wird, wird eine kurze Aktivierungssperre mit dem Namen GOOGLE_C2DM gehalten. Unter Android 16 und höher lautet der Name der Aktivierungssperre GCM_MESSAGE.

Empfehlung

Wir empfehlen die folgenden Vorgehensweisen, um das Verhalten von FCM zu optimieren:

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

JobScheduler

JobScheduler-Jobs erhalten Wakelocks, während sie Aufgaben im Hintergrund ausführen. Die Wake Locks werden der App zugeordnet, die die Worker erstellt hat.

Wakelock-Namen

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

Die Elemente in spitzen Klammern sind Variablen. Beispiel: „<package_name>“ ist der Name des App-Pakets und 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>

Dieses Muster wird auch in anderen Jobs verwendet:

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

Bei vom Nutzer initiierten Jobs werden Wake Locks mit Namen erstellt, 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>

Bei regulären Jobs wird dieses Muster verwendet:

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

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

Auf Geräten mit Android 15 oder niedriger hat das Wake Lock folgenden Namen:

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

Auf Geräten mit Android 16 QPR2 oder höher würde das Wake Lock so benannt:

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

Empfehlung

  • Kein manuelles Wake Lock für vom Nutzer initiierte Download-/Upload-Anwendungsfälle abrufen. Verwenden Sie stattdessen die User-Initiated Data Transfer (UIDT) API. Dies ist der vorgesehene Pfad für vom Nutzer initiierte Datenübertragungsaufgaben, die lange dauern.
  • Wenn Sie von JobScheduler erstellte Wake Locks mit hoher Wake Lock-Nutzung feststellen, liegt das möglicherweise daran, dass Sie Ihren Job so konfiguriert haben, dass er in bestimmten Szenarien nicht abgeschlossen wird. Analysieren Sie die Gründe für das Beenden von Jobs, insbesondere wenn STOP_REASON_TIMEOUT häufig auftritt.
  • Prüfen Sie die Verwendung von JobScheduler-Aufgaben. Beachten Sie insbesondere unsere Richtlinien zur Optimierung der Akkunutzung für APIs zur Aufgabenplanung.

Standort

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

Wakelock-Namen

Standortdienste verwenden die folgenden Namen:

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

Empfehlung

  • Hier finden Sie Informationen zur Optimierung der Standortnutzung. Erwägen Sie, Zeitüberschreitungen zu implementieren, die Batch-Verarbeitung von Standortanfragen zu nutzen oder passive Standortaktualisierungen zu verwenden.
  • Vermeiden Sie es, ein separates, kontinuierliches Wake Lock für das Zwischenspeichern von Standortdaten zu erwerben, da dies redundant ist und entfernt werden sollte. Wenn Sie Standortupdates anfordern, indem Sie die APIs FusedLocationProvider oder LocationManager verwenden, wird das Gerät während des Standortereignis-Callbacks automatisch aktiviert. Speichern Sie die Standortereignisse stattdessen im Arbeitsspeicher oder 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 möglicherweise auf die Verwendung von Wake Locks auswirkt. Zu den häufigsten Anwendungsfällen gehören:

  • Begleit-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.

Bei den meisten Aktivierungen in diesen Szenarien für die Remote-Nachrichtenübermittlung handelt es sich um Kernel-Wake Locks. Da Kernel-Wakelocks nicht der App zugeordnet werden, gibt es hier keine zugehörigen Wakelock-Namen.

Empfehlung

  • Wenn die Netzwerkereignisse serverseitig 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 clientseitig über eine Socketverbindung verarbeitet werden müssen, ist kein Wake Lock erforderlich, um auf Ereignisunterbrechungen zu warten. Wenn Datenpakete am WLAN- oder Mobilfunkmodul eintreffen, löst die Funkhardware eine Unterbrechung in Form eines Kernel-Wake-Locks aus. Anschließend können Sie einen Worker planen oder ein Wake Lock abrufen, um die Daten zu verarbeiten.
  • Wenn Sie beispielsweise ktor-network verwenden, um auf einem Netzwerk-Socket auf Datenpakete zu warten, sollten Sie nur dann einen Wake Lock abrufen, wenn Pakete an den Client gesendet wurden.

WorkManager

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

Wakelock-Namen

Die von WorkManager abgerufenen Wake-Lock-Namen hängen davon ab, auf welcher Version des Android-Systems sie ausgeführt werden.

Android 15 und niedriger

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

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

Für beschleunigte Aufgaben werden Wake Locks mit Namen erstellt, die diesem Muster folgen:

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

Regelmäßige Aufgaben folgen diesem Muster:

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

Standardmäßig ist <trace_tag> der Name des Workers.

Beispiel

Angenommen, es gibt einen beschleunigten Worker namens BackupFileWorker. Der Paketname lautet com.example.app.

Auf Geräten mit Android 15 oder niedriger hat das Wake Lock folgenden Namen:

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

Auf Geräten mit Android 16 QPR2 oder höher, auf denen WorkManager 2.10.0+ verwendet wird, würde das Wake Lock so benannt:

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

Empfehlung

  • Aktualisieren Sie Ihre WorkManager-Version auf die aktuelle stabile Version, damit die Wake Lock-Tags unter Android 16 QPR2 oder höher ausführlicher sind.
  • Prüfen Sie die Verwendung von WorkManager-Workern. Prüfen Sie insbesondere, ob die App unseren Richtlinien zur Optimierung der Akkunutzung für APIs zur Aufgabenplanung entspricht. 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 identifizieren, liegt das möglicherweise daran, dass Sie Ihren Worker so konfiguriert haben, dass er in bestimmten Szenarien nicht abgeschlossen wird. Analysieren Sie die Gründe für das Beenden von Worker-Prozessen, insbesondere wenn STOP_REASON_TIMEOUT häufig auftritt.
  • Zusätzlich zum Protokollieren der Gründe für das Beenden von Workern finden Sie weitere Informationen in unserer Dokumentation zum Debuggen von Workern. Sie können auch System-Traces erfassen und analysieren, um zu sehen, wann Wake Locks aktiviert und deaktiviert werden.

_UNKNOWN

Wenn die Debugging-Tools der Meinung sind, dass ein Wake Lock-Name personenidentifizierbare Informationen enthält, wird der tatsächliche Wake Lock-Name nicht angezeigt. Stattdessen wird das Wake Lock als _UNKNOWN gekennzeichnet. Das kann beispielsweise passieren, wenn der Wake Lock-Name eine E-Mail-Adresse enthält.

Empfehlung

Halten Sie sich an die Best Practices für die Benennung von Wakelocks und vermeiden Sie die Verwendung personenidentifizierbarer Informationen im Wakelock-Namen. Wenn Sie einen Wake Lock mit dem Namen _UNKNOWN finden, der Ihrer App zugeordnet ist, versuchen Sie, ihn zu identifizieren und ihm einen anderen Namen zu geben.