Anwendungsfälle für Wake Locks identifizieren und optimieren

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

In diesem Dokument werden einige häufige Namen für Wakelocks aufgeführt, die bei der Verwendung der Wakelock-Debugging-Tools oder in Berichten zu 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 fehlerhaftes Verhalten von Wakelocks zu erkennen, und dann in diesem Dokument nach dem Namen des Wakelocks 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 Wakelocks beschrieben. Außerdem werden die Wakelock-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 Wakelock-Nutzung.

AlarmManager

AlarmManager ruft Wakelocks ab und weist sie der aufrufenden App zu. AlarmManager ruft den Wakelock ab, wenn der Alarm ausgelöst wird, und gibt den Lock 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 Wakelocks 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 Kontingente 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 Wiedergeben von Audioinhalten abrufen. Die Wake Locks werden der Anruf-App zugeordnet.

Wakelock-Namen

Media APIs rufen Wake Locks 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 Spatial Audio 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 Wakelocks, 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 Wakelock aktiviert wird.
  • In der Anleitung zur Kommunikation im Hintergrund 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 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 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. 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 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 Abtastraten kann zu schneller Akkuentladung führen. Hier sind Empfehlungen zur Reduzierung der schnellen Akkuentladung und der Nutzung von Wakelocks:

  • Wenn du die Anzahl der Schritte oder die zurückgelegte Distanz erfassen möchtest, verwende die Recording API, um Daten akkusparend aufzuzeichnen. Für Geräte 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 Wear Health Services, um die Akkunutzung zu optimieren.
  • Wenn Sie einen Sensor bei SensorManager registrieren, definieren Sie ein 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 Ihre App sowohl Standort- als auch Sensordaten benötigt, sollten Sie den Abruf und die Verarbeitung der entsprechenden Ereignisse synchronisieren. Wenn Sie Sensormesswerte in den kurzen Wakelock einfügen, den das System für Standortaktualisierungen verwendet, ist kein Wakelock erforderlich, um die CPU aktiv zu halten. Verwenden Sie einen Worker oder einen Wakelock mit kurzer Dauer, um das Hochladen und Verarbeiten dieser kombinierten Daten zu verarbeiten.

Firebase Cloud Messaging (FCM)

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

Wakelock-Namen

Wenn auf dem Gerät eine FCM-Nachricht empfangen wird, wird ein kurzer Wakelock mit dem Namen GOOGLE_C2DM gehalten. Unter Android 16 und höher lautet der Name des Wakelock 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.
  • Die onMessageReceived()-Methode sollte so schnell wie möglich abgeschlossen werden. Wenn eine zusätzliche Verarbeitung erforderlich ist, können Sie einen Worker dafür einplanen. 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 erworbenen Wakelock-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

Bei vom Nutzer initiierten Jobs werden Wake Locks mit Namen erstellt, die diesem Muster entsprechen:

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

Dieses Muster wird auch für andere 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 der Wakelock folgenden Namen:

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

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

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

Empfehlung

  • Kein manuelles Wakelock 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 Wakelocks mit hoher Wakelock-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 Wakelock 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 während des Standortereignis-Callbacks automatisch ein Geräte-Wake-up ausgelöst. 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 Wakelocks 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.

Die meisten Wakeups in diesen Szenarien für die Remote-Nachrichtenübermittlung sind Kernel-Wakelocks. 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 Socket-Verbindung verarbeitet werden müssen, ist kein Wakelock erforderlich, um auf Ereignisunterbrechungen zu warten. Wenn Datenpakete am WLAN- oder Mobilfunkmodul eintreffen, löst die Funkhardware eine Unterbrechung in Form eines Kernel-Wakelocks aus. Anschließend können Sie einen Worker planen oder ein Wakelock abrufen, um die Daten zu verarbeiten.
  • Wenn Sie beispielsweise ktor-network verwenden, um Datenpakete an einem Netzwerk-Socket zu empfangen, sollten Sie nur dann einen Wakelock 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 Wakelock-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 der Wakelock 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 Wakelock 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 Wakelock-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 Wakelocks mit hoher Wakelock-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 sollten 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 Wakelock-Name personenidentifizierbare Informationen enthält, wird der tatsächliche Wakelock-Name nicht angezeigt. Stattdessen wird das Wakelock als _UNKNOWN gekennzeichnet. Das kann beispielsweise passieren, wenn der Wake Lock-Name eine E-Mail-Adresse enthält.

Empfehlung

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