Wenn Sie eine Android-App für ein Wearable entwickeln, beginnt die eigentliche Arbeit erst, wenn sich der Bildschirm ausschaltet. WHOOP hilft Mitgliedern, zu verstehen, wie ihr Körper auf Training, Erholung, Schlaf und Stress reagiert. Für die vielen WHOOP-Mitglieder, die Android verwenden, sind eine zuverlässige Hintergrundsynchronisierung und Konnektivität entscheidend, um diese Erkenntnisse zu gewinnen.

Anfang dieses Jahres hat Google Play einen neuen Messwert in Android Vitals eingeführt: Übermäßige Teil-Wakelocks. Dieser Messwert gibt den Prozentsatz der Nutzersitzungen an, bei denen die kumulative, nicht ausgenommene Wakelock-Nutzung in einem Zeitraum von 24 Stunden 2 Stunden übersteigt. Mit diesem Messwert können Sie mögliche Ursachen für eine schnelle Akkuentladung ermitteln und beheben. Das ist entscheidend, um eine gute Nutzererfahrung zu bieten.

Ab dem 1. März 2026 werden Apps, die den Qualitätsschwellenwert weiterhin nicht erreichen, möglicherweise von den Google Play-Oberflächen für die Suche ausgeschlossen. Außerdem wird möglicherweise eine Warnung im Google Play Store-Eintrag platziert, die darauf hinweist, dass die App mehr Akku verbrauchen könnte als erwartet.

Laut Mayank Saini, Senior Android Engineer bei WHOOP,  bot dies dem Team die Möglichkeit, die Effizienz von Android zu verbessern. Android Vitals hatte den Prozentsatz der übermäßigen Teil-Wakelocks der App mit 15 % gekennzeichnet. Das überstieg den empfohlenen Schwellenwert von 5 %.

Das Team sah den Android Vitals-Messwert als klares Signal dafür, dass die Hintergrundarbeit die CPU länger als nötig aktiv hielt. Wenn dieses Problem behoben würde, könnten sie weiterhin eine gute Nutzererfahrung bieten und gleichzeitig die unnötige Hintergrundzeit reduzieren und eine zuverlässige und zeitnahe Bluetooth-Verbindung und -Synchronisierung aufrechterhalten.

Problem identifizieren

Um herauszufinden, wo sie anfangen sollten, wandte sich das Team zuerst an Android Vitals, um mehr Informationen darüber zu erhalten, welche Wakelocks den Messwert beeinflussten. Im Android Vitals-Dashboard für übermäßige Teil-Wakelocks konnten sie einen ihrer WorkManager-Worker als größten Verursacher für übermäßige Teil-Wakelocks identifizieren (im Dashboard als androidx.work.impl.background.systemjob.SystemJobService gekennzeichnet). Um die „Always-on-Funktion“ von WHOOP zu unterstützen, verwendet die App WorkManager für Hintergrundaufgaben wie die regelmäßige Synchronisierung und die Bereitstellung wiederkehrender Updates für das Wearable. 

Das Team wusste zwar , dass WorkManager ein Wakelock erwirbt , während Aufgaben im Hintergrund ausgeführt werden, hatte aber bisher keinen Einblick in die Verteilung der gesamten Hintergrundarbeit (nicht nur WorkManager), bis der Messwert für übermäßige Teil-Wakelocks in Android Vitals eingeführt wurde.

Da WorkManager im Dashboard als Hauptverursacher identifiziert wurde, konnte sich das Team darauf konzentrieren, herauszufinden, welcher Worker am meisten dazu beitrug, und das Problem beheben.

Interne Messwerte und Daten verwenden, um die Ursache besser einzugrenzen

WHOOP hatte bereits eine interne Infrastruktur eingerichtet, um WorkManager-Messwerte zu beobachten. Sie beobachten regelmäßig Folgendes:

1. Durchschnittliche Laufzeit: Wie lange wird der Worker ausgeführt?
2. Zeitüberschreitungen: Wie oft wird die Zeit für den Worker überschritten, anstatt dass er abgeschlossen wird?
3. Wiederholungen: Wie oft wird der Worker wiederholt, wenn die Zeit überschritten wurde oder ein Fehler aufgetreten ist?
4. Abbrüche: Wie oft wurde die Arbeit abgebrochen?

Wenn das Team nicht nur die Erfolge und Fehler der Worker verfolgt, sondern auch die Effizienz seiner Arbeit im Blick behält.

Die internen Messwerte wiesen eine hohe durchschnittliche Laufzeit für einige wenige Worker auf, sodass das Team die Untersuchung noch weiter eingrenzen konnte. 

Zusätzlich zu den internen Messwerten verwendete das Team auch den Background Task Inspector von Android Studio, um die relevanten Worker zu untersuchen und zu debuggen. Dabei lag der Schwerpunkt auf den zugehörigen Wakelocks, um die Übereinstimmung mit dem in Android Vitals gekennzeichneten Messwert zu prüfen.

Untersuchung: Unterscheidung zwischen Worker-Varianten

WHOOP verwendet sowohl einmalige als auch regelmäßige Zeitpläne für einige Worker. So kann die App dieselbe Worker-Logik für identische Aufgaben mit denselben Erfolgskriterien wiederverwenden, die sich nur im Zeitpunkt unterscheiden.

Mithilfe der internen Messwerte konnte die Suche auf einen bestimmten Worker eingegrenzt werden. Das Team konnte jedoch nicht feststellen, ob der Fehler auftrat, wenn der Worker einmalig oder regelmäßig ausgeführt wurde oder beides. Daher wurde ein Update eingeführt, um die Methode setTraceTag von WorkManager zu verwenden, um zwischen den einmaligen und regelmäßigen Varianten desselben Workers zu unterscheiden.

Mit diesen zusätzlichen Informationen konnte das Team genau ermitteln, welche Worker-Variante (regelmäßig oder einmalig) am meisten zu Sitzungen mit übermäßigen Teil-Wakelocks beitrug. Das Team war jedoch überrascht, als die Daten zeigten, dass keine der beiden Varianten mehr beitrug als die andere.

Manmeet Tuteja, Android Engineer II bei WHOOP, sagte: „Diese Aufteilung hat uns auch geholfen, zu bestätigen, dass das Problem in beiden Varianten auftrat. Das deutete nicht auf ein Problem mit der Zeitplankonfiguration hin, sondern auf ein gemeinsames Problem mit der Geschäftslogik in der Worker-Implementierung.“

Worker-Verhalten genauer untersuchen und Grundursache beheben

Da das Team wusste, dass es sich die Logik im Worker ansehen musste, untersuchte es das Worker-Verhalten für die Worker, die bei der Untersuchung gekennzeichnet worden waren, noch einmal. Konkret suchte es nach Fällen, in denen die Arbeit möglicherweise hängen geblieben war und nicht abgeschlossen wurde.

All das führte zur Ermittlung der Grundursache für die übermäßigen Wakelocks:

Ein CoroutineWorker, der darauf wartete, dass eine Verbindung zum WHOOP-Sensor hergestellt wurde, bevor er fortfuhr. 

Wenn die Arbeit ohne angeschlossenen Sensor gestartet wurde, war whoopSensorFlow – das angibt, ob der Sensor verbunden ist – null. Der SensorWorker behandelte dies nicht als Bedingung für einen frühen Ausstieg und wurde weiter ausgeführt. Er wartete effektiv unbegrenzt auf eine Verbindung. Infolgedessen hielt WorkManager ein Teil-Wakelock, bis die Zeit für die Arbeit überschritten wurde. Das führte zu einer hohen Nutzung von Hintergrund-Wakelocks und zu häufigen, unerwünschten Neuplanungen des SensorWorker.

Um dieses Problem zu beheben, aktualisierte das WHOOP-Team die Worker-Logik, um den Verbindungsstatus zu prüfen, bevor die Kern-Geschäftslogik ausgeführt wurde.

Wenn der Sensor nicht verfügbar ist, wird der Worker beendet, wodurch ein Timeout-Szenario vermieden und das Wakelock freigegeben wird. Das folgende Code-Snippet zeigt die Lösung:

class SensorWorker(appContext: Context, params: WorkerParameters): CoroutineWorker(appContext, params) {
   override suspend fun doWork(): Result {
      ...
      // Check the sensor state and perform work or return failure
       return whoopSensorFlow.replayCache
            .firstOrNull()
            ?.let { cachedData ->
                processSensorData(cachedData)
                Result.success()
            } ?: run {
                Result.failure()
            }
}

90% weniger Sitzungen mit übermäßigen Teil-Wakelocks

Nach der Einführung der Korrektur beobachtete das Team weiterhin das Android Vitals-Dashboard, um die Auswirkungen der Änderungen zu bestätigen. 

Letztendlich sank der Prozentsatz der übermäßigen Teil-Wakelocks bei WHOOP innerhalb von nur 30 Tagen nach der Implementierung der Änderungen am Worker von 15% auf weniger als 1 %.

Durch die Änderungen gab es weniger Fälle, in denen die Zeit für die Arbeit überschritten wurde, ohne dass sie abgeschlossen wurde. Das führte zu kürzeren durchschnittlichen Laufzeiten.

Der Rat des WHOOP-Teams an andere Entwickler, die die Effizienz ihrer Hintergrundarbeit verbessern möchten:

Jetzt starten

Wenn Sie die Anzahl der übermäßigen Teil-Wakelocks Ihrer App reduzieren oder die Effizienz der Worker verbessern möchten, sehen Sie sich den Messwert für übermäßige Teil-Wakelocks Ihrer App in Android Vitals an. In der Dokumentation zu Wakelocks finden Sie weitere Best Practices und Debugging-Strategien.