Von anderen APIs erstellte Wakelocks identifizieren

Mehrere Bibliotheken und System-APIs können Wakelocks erwerben, die Ihrer App zugeordnet werden können. Das kann es schwierig machen, ein Wakelock in Ihrer App zu identifizieren, das ein Problem verursachen könnte. Wenn Sie eine API missbrauchen, kann das dazu führen, dass Ihre App eine Wakelock zu lange hält, auch wenn Sie die Wakelock-APIs nicht direkt aufrufen.

In diesem Dokument sind einige gängige Wakelock-Namen aufgeführt, die Sie möglicherweise sehen, wenn Sie die Tools zum Debuggen von Wakelocks verwenden. Möglicherweise sehen Sie diese Namen auch in einem Bericht von Android Vitals. In einigen Fällen wurde die Wakelock möglicherweise von einer Bibliothek oder System-API erstellt. In anderen Fällen gibt es einen Grund dafür, dass das Tool den Namen der Wakelock verschleiert, die Sie in der App verwenden. Mit den Debugging-Tools können Sie fehlerhafte Wakelocks ermitteln und dann den Namen der Wakelock in diesem Dokument nachschlagen, um herauszufinden, welche API das Problem verursacht und wie es behoben werden kann.

In diesem Dokument werden die folgenden Namen für Wakelocks behandelt. In jedem Fall kann die Sperre zwar von einer anderen Bibliothek oder API erstellt werden, sie wird jedoch der App zugeordnet, die diese API aufgerufen hat.

*alarm*

Diese Wecksperre wird von AlarmManager abgerufen und der anrufenden App zugeordnet. AlarmManager ruft die Wecksperre ab, wenn der Wecker klingelt, und gibt sie frei, wenn die Ausführung der Methode onReceive() des Weck-Broadcasts abgeschlossen ist.

Empfehlung

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

  • Verwenden Sie AlarmManager, um die Häufigkeit der Weckerplanung zu optimieren.
  • Verwenden Sie RTC_WAKEUP-Wecker (die das Gerät wecken) nur bei Bedarf.
  • Verwenden Sie Alarme möglichst selten und vermeiden Sie lange Arbeitsschritte mit der Methode onReceive().

AudioIn, AudioMix usw.

Verschiedene Wakelocks, deren Namen mit Audio beginnen, werden von Medien-APIs beim Aufzeichnen oder Abspielen von Audiodaten erworben. Die Aufwecksperren werden der anrufenden App zugeordnet.

AudioIn wird während der Aufnahme von AudioRecord im Camcordermodus erfasst, während das Mikrofon aktiv ist. AudioMix wird während der AudioTrack-Wiedergabe auf dem Gerät erfasst. Andere Medien-APIs können Wakelocks mit anderen Namen erwerben, die mit Audio beginnen.

Empfehlung

Wir empfehlen Folgendes:

  • Verwenden Sie keine Wakelock-Namen, die mit Audio beginnen.
  • Wenn Sie die Medien-APIs verwenden, müssen Sie Wakelocks nicht direkt erwerben. Sie können sich darauf verlassen, dass die APIs die erforderlichen Wakelocks für Sie erwerben.
  • Wenn Sie Medien-APIs verwenden, beenden Sie die Mediensitzung, wenn Sie sie nicht mehr benötigen.

GOOGLE_C2DM

Dieser Wakelock wird von GCM beim Senden eines Firebase Cloud Message (FCM)-Broadcasts an die App erworben. Der Wakelock wird freigegeben, sobald die Ausführung der FCM-Broadcast-Methode onMessageReceived() abgeschlossen ist.

Empfehlung

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

  • Optimieren Sie die Häufigkeit der FCM-Zustellung.
  • Verwenden Sie FCM-Nachrichten mit hoher Priorität nur, wenn die Nachricht tatsächlich sofort zugestellt werden muss.
  • Schließen Sie die onMessageReceived()-Methode so schnell wie möglich ab. Weitere Informationen finden Sie in der Firebase-Anleitung.

*job*/<package_name>/<package_and_job_name>

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

„<package_name>“ ist der Name des Pakets Ihrer App, nicht der Text <package name>. „<package_and_job_name>“ ist der Paketname gefolgt vom Jobnamen. *job* ist die Zeichenfolge *job* mit Sternchen. Die Sternchen werden nicht als Platzhalter verwendet. Hier ein Beispiel für einen solchen Namen:

*job*/com.example.app/com.example.app.example.path.ExampleJobService

Empfehlung

Prüfen Sie die Nutzung von JobScheduler-Aufgaben. Beachten Sie insbesondere unsere Hinweise zur Optimierung der Akkunutzung für APIs zur Aufgabenplanung.

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

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

„<package_name>“ ist der Name des Pakets Ihrer App, nicht der Text <package name>. *job* ist die Zeichenfolge *job* mit Sternchen. Die Sternchen werden nicht als Platzhalter verwendet.

Empfehlung

Prüfen Sie die Nutzung von WorkManager-Workern. Beachten Sie insbesondere unsere Hinweise zur Optimierung der Akkunutzung für APIs zur Aufgabenplanung.

NetworkLocationLocator, FusedLocation, *location*

Diese Wakelock-Namen werden von LocationManager und FusedLocationProviderClient verwendet, um den Gerätestandort abzurufen und zu senden. Die Wakelocks werden der App zugeordnet, die diese APIs aufgerufen hat.

Empfehlung

Standortnutzung optimieren Sie können beispielsweise Zeitüberschreitungen festlegen, Standortanfragen in Batches senden oder passive Standortupdates verwenden.

_UNKNOWN

Wenn die De-Bug-Tools der Meinung sind, dass ein Wakelock-Name personenidentifizierbare Informationen enthält, wird der tatsächliche Wakelock-Name nicht angezeigt. Stattdessen kennzeichnen sie die Wake-Lock als _UNKNOWN. Dies kann beispielsweise der Fall sein, wenn der Name der Sperre für die Aktivierung eine E-Mail-Adresse enthält.

Empfehlung

Befolgen Sie die Best Practices für die Benennung von Wakelocks und verwenden Sie keine personenidentifizierbaren Informationen im Namen des Wakelocks. Wenn Sie eine Wakelock mit dem Namen _UNKNOWN für Ihre App finden, versuchen Sie, die Wakelock zu identifizieren und einen anderen Namen dafür festzulegen.