Anwendungsfälle für Wake Locks identifizieren und optimieren

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

In diesem Dokument sind einige häufige Wakelock-Namen aufgeführt, die Ihnen bei der Verwendung der Wakelock-Debugging-Tools oder in Berichten von Android Vitals begegnen können. Diese Namen können aus einer Bibliothek oder System-API stammen oder verschleiert sein. Wenn Sie mit den Debugging-Tools fehlerhaftes Verhalten von Wakelocks identifizieren und dann in diesem Dokument nach dem Wakelock-Namen suchen, können Sie feststellen, welche API das Problem verursacht, und Empfehlungen zur Optimierung der Nutzung finden.

In diesem Dokument werden häufige Anwendungsfälle für den Erwerb 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 erwirbt Wakelocks und ordnet sie der aufrufenden App zu. AlarmManager erwirbt das Wakelock, wenn der Alarm ausgelöst wird, und gibt es frei, wenn die Methode onReceive() der Alarmübertragung beendet ist.

Wakelock-Namen

AlarmManager erstellt Wakelocks mit dem Namen *alarm*. (Die Sternchen sind Teil des Wakelock-Namens und stellen keine Platzhalter dar.)

Empfehlung

Wir empfehlen die folgenden Best Practices zur Optimierung des Alarmverhaltens:

Audio und Medien

Media APIs können beim Aufzeichnen oder Abspielen von Audio Wakelocks erwerben. Die Wakelocks werden der aufrufenden App zugeordnet.

Wakelock-Namen

Media APIs erwerben Wakelocks mit verschiedenen Namen, 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 für Apps verwendet, die diesen Modus unterstützen.
  • AudioSpatial: Wird für die Wiedergabe von Mehrkanal-Audio von Filmen oder Musik auf Geräten verwendet, die räumliches 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 für professionelle Audioanwendungen.

Empfehlung

Wir empfehlen die folgenden Best Practices:

  • Deklarieren Sie keine Wakelock-Namen, die mit Audio beginnen.
  • Wenn Sie die Media APIs verwenden, müssen Sie keine Wakelocks direkt erwerben. Sie können sich darauf verlassen, dass die APIs die erforderlichen Wakelocks für Sie erwerben.
  • 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-Wakelocks, während Bluetooth-Aktionen ausgeführt werden. Diese sind nicht der Anwendung zuzuordnen.

Empfehlung

  • Verwenden Sie die Companion Device-Kopplung, um Bluetooth-Geräte zu koppeln, damit beim Koppeln von Bluetooth-Geräten kein manuelles Wakelock erworben wird.
  • In der Anleitung zur Kommunikation im Hintergrund erfahren Sie , wie Sie die Bluetooth-Kommunikation im Hintergrund durchführen.
  • Die Verwendung von WorkManager ist oft ausreichend, wenn eine verzögerte Kommunikation keine Auswirkungen auf den Nutzer hat. Wenn ein manuelles Wakelock erforderlich ist, halten Sie es nur für die Dauer der Bluetooth-Aktivität oder der Verarbeitung der Aktivitätsdaten.

Gerätesensoren

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

Verwenden Sie auf Wear OS die Wear Health Services, um Gerätedaten wie Höhe, Herzfrequenz und zurückgelegte Strecke zu erfassen.

Wenn die Daten von anderen Anwendungen erfasst 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 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 Schrittzahl oder die Schritte in den letzten 6 Stunden) unterstützt Health Connect auch die Schrittzählung auf dem Gerät für Geräte mit Android 14 oder höher.

In bestimmten Situationen ist möglicherweise eine benutzerdefinierte Erfassung von Gerätesensordaten mit SensorManager erforderlich. SensorManager erwirbt keine Wakelocks im Namen der App, es sei denn, der Sensor ist ein Wakeup-Sensor. Dieser kann mit der isWakeUpSensor API identifiziert werden.

Empfehlung

Wenn Sie Sensoren verwenden, um Daten mit hohen Abtastraten aufzuzeichnen, kann dies den Akku erheblich belasten. Hier sind Empfehlungen, um den Akkuverbrauch und die Wakelock-Nutzung zu reduzieren:

  • Wenn Sie Schrittzahlen oder zurückgelegte Strecken erfassen, verwenden Sie die Recording API, um Daten auf akkusparende Weise aufzuzeichnen. Auf Geräten mit Android 14 oder höher können Sie Health Connect verwenden, um auf historische Gerätedaten und aggregierte Schrittzahlen zuzugreifen.
  • Verwenden Sie für die passive Sensorerfassung auf Wear OS Wear Health Services, um den Akkuverbrauch zu optimieren.
  • Wenn Sie einen Sensor mit SensorManager registrieren, definieren Sie eine maxReportLatencyUs von mehr als 30 Sekunden, um die Batchverarbeitungslogik für Sensoren zu verwenden und die Anzahl der Unterbrechungen zu reduzieren, die die Anwendung erhält. Wenn das Gerät anschließend durch einen anderen Trigger wie eine Nutzerinteraktion, den Abruf des Standorts oder einen geplanten Job aktiviert wird, sendet das System sofort die im Cache gespeicherten Sensordaten.
  • Wenn Ihre App sowohl Standort- als auch Sensordaten benötigt, synchronisieren Sie den Abruf und die Verarbeitung der Ereignisse. Indem Sie Sensormessungen mit dem kurzen Wakelock zusammenführen, das das System für Standortaktualisierungen verwendet, vermeiden Sie, dass ein Wake lock erforderlich ist, um die CPU aktiv zu halten. Verwenden Sie einen Worker oder ein kurzzeitiges Wakelock, um das Hochladen und die Verarbeitung dieser kombinierten Daten zu verarbeiten.

Firebase Cloud Messaging (FCM)

Beim Senden einer Firebase Cloud Message (FCM)-Übertragung an die App wird ein Wakelock erworben. Das Wakelock wird freigegeben, sobald die Methode onMessageReceived() der FCM-Übertragung beendet ist.

Wakelock-Namen

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

Empfehlung

Wir empfehlen die folgenden Best Practices zur Optimierung des FCM-Verhaltens:

  • Optimieren Sie die Häufigkeit der FCM-Übermittlung.
  • Verwenden Sie FCM mit hoher Priorität nur, wenn die Nachricht tatsächlich sofort zugestellt werden muss.
  • Sorgen Sie dafür, dass die onMessageReceived() Methode so schnell wie möglich abgeschlossen wird, oder planen Sie einen Worker, um die Aufgabe fortzusetzen, wenn eine zusätzliche Verarbeitung erforderlich ist. Weitere Informationen finden Sie in der Firebase-Anleitung.

JobScheduler

JobScheduler-Jobs erwerben Wakelocks, während sie Aufgaben in Hintergrund ausführen. 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 und dem Zweck des Jobs ab.

Die Elemente in spitzen Klammern sind Variablen. Beispielsweise ist "<package_name>" der Name des Pakets Ihrer App, nicht der wörtliche Text <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 Wakelocks 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.1 und höher

Von Nutzern initiierte Jobs erstellen Wakelocks mit Namen, die diesem Muster folgen:

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

Beschleunigte Jobs verwenden dieses Muster:

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

Reguläre Jobs verwenden dieses Muster:

*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 lautet der Name des Wakelocks:

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

Auf Geräten mit Android 16.1 oder höher lautet der Name des Wakelocks:

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

Empfehlung

  • Erwerben Sie kein manuelles Wakelock für Anwendungsfälle zum Herunterladen/ Hochladen, die vom Nutzer initiiert werden. Verwenden Sie stattdessen die User-Initiated Data Transfer (UIDT) API. Dies ist der vorgesehene Pfad für lang andauernde Datenübertragungsaufgaben, die initiiert vom Nutzer werden.
  • Wenn Sie Wakelocks identifizieren, die von JobScheduler mit hoher Wakelock-Nutzung erstellt wurden, 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 des Jobs , insbesondere wenn STOP_REASON_TIMEOUT häufig auftritt.
  • Prüfen Sie Ihre Nutzung von JobScheduler-Aufgaben. Beachten Sie insbesondere unsere Anleitung zur Optimierung des Akkuverbrauchs für APIs zur Aufgabenplanung.

Standort

LocationManager und FusedLocationProviderClient verwenden Wakelocks, um den Gerätestandort zu erfassen und zu übermitteln. Die Wakelocks werden der App zugeordnet, die diese APIs aufgerufen hat.

Wakelock-Namen

Standortdienste verwenden die folgenden Namen:

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

Empfehlung

  • Beachten Sie unsere Anleitung zur Optimierung der Standortnutzung. Sie können Time-outs implementieren, die Batchverarbeitung von Standortanfragen nutzen oder passive Standortaktualisierungen verwenden.
  • Erwerben Sie kein separates, kontinuierliches Wakelock für das Caching von Standortdaten, da dies redundant ist und entfernt werden sollte. Wenn Sie Standortaktualisierungen anfordern mit den APIs FusedLocationProvider oder LocationManager, löst das System während des Standortereignis-Callbacks automatisch eine Aktivierung des Geräts aus. 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 beschrieben, in denen Apps möglicherweise Verbindungen aufrechterhalten oder auf Ereignisse von anderen Geräten reagieren müssen, was sich auf die Wakelock-Nutzung auswirken kann. Zu den häufigsten Anwendungsfällen gehören:

  • Begleitende Apps für die Video- oder Audioü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 Desktopversion aufrechterhalten.

Die meisten Aktivierungen in diesen Remote-Messaging-Szenarien 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 Mobilfunkgerät eintreffen, löst die Funk hardware eine Unterbrechung in Form eines Kernel-Wakelocks aus. Sie können dann einen Worker planen oder ein Wakelock erwerben, um die Daten zu verarbeiten.
  • Wenn Sie beispielsweise ktor-network verwenden, um auf Datenpakete auf einem Netzwerk-Socket zu warten, sollten Sie nur dann ein Wakelock erwerben, wenn Pakete an den Client gesendet wurden.

WorkManager

WorkManager-Worker erwerben Wakelocks, während sie Aufgaben in the background 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 Android-Version ab.

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.1 und höher

Beschleunigte Aufgaben erstellen Wakelocks mit Namen, die diesem Muster folgen:

*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 beschleunigten Worker mit dem Namen BackupFileWorker. Der Paketname ist com.example.app.

Auf Geräten mit Android 15 oder niedriger lautet der Name des Wakelocks:

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

Auf Geräten mit Android 16 oder höher und WorkManager 2.10.0+, lautet der Name des Wakelocks:

*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.1 oder höher ausführlicher zu gestalten.
  • Prüfen Sie Ihre Nutzung von WorkManager-Workern. Achten Sie insbesondere darauf, dass sie unserer Anleitung zur Optimierung des Akkuverbrauchs für APIs zur Aufgabenplanung folgen. Verwenden Sie unter Android 16.1 oder höher die setTraceTag Methode für den Worker, um weitere Debug Informationen hinzuzufügen, z. B. welche Klasse den Worker geplant hat.
  • Wenn Sie Wakelocks identifizieren, die von WorkManager mit hoher Wakelock-Nutzung erstellt wurden, 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 des Workers, insbesondere wenn Sie häufige Vorkommen von STOP_REASON_TIMEOUT sehen.
  • Zusätzlich zur Protokollierung der Gründe für das Beenden des Workers, finden Sie in unserer Dokumentation Informationen zum Debuggen von Workern. Sie können auch System-Traces erfassen und analysieren, um zu verstehen, wann Wakelocks erworben und freigegeben werden.

_UNKNOWN

Wenn die Debugging-Tools der Meinung sind, dass ein Wakelock-Name personenidentifizierbare Informationen (PII) enthält, wird der tatsächliche Wakelock-Name nicht angezeigt. Stattdessen wird das Wakelock als _UNKNOWN bezeichnet. Das kann beispielsweise der Fall sein, wenn der Wake lock-Name eine E-Mail-Adresse enthält.

Empfehlung

Beachten Sie die Best Practices für die Benennung von Wakelocks und verwenden Sie keine PII im Wake lock-Namen. Wenn Sie ein Wakelock mit dem Namen _UNKNOWN finden, das Ihrer App zugeordnet ist, versuchen Sie es zu identifizieren und ihm einen anderen Namen zu geben.