Wie WHOOP die Anzahl der Sitzungen mit übermäßigen Teil-Wakelocks um über 90 % reduzierte

Wenn Sie eine Android-App für ein Wearable entwickeln, beginnt die eigentliche Arbeit, 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 zuverlässige Hintergrundsynchronisierung und -verbindung die Voraussetzungen für diese Erkenntnisse.

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 die Akkuentladung ermitteln und beheben. Das ist entscheidend für eine gute Nutzererfahrung.

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 Android-Effizienz 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 wird, kann das Team weiterhin eine gute Nutzererfahrung bieten und gleichzeitig die verschwendete 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 der 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 , dass WorkManager ein Wakelock erwirbt , während Aufgaben im Hintergrund ausgeführt werden. Bis zur Einführung des Messwerts für übermäßige Teil-Wakelocks in Android Vitals hatten sie jedoch keinen Einblick in die Verteilung ihrer gesamten Hintergrundarbeit (nicht nur WorkManager).

Da WorkManager im Dashboard als Hauptverursacher identifiziert wurde, konnte sich das Team darauf konzentrieren, herauszufinden, welcher Worker am meisten dazu beitrug, und das Problem zu 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 Erfolge und Fehler von Workern verfolgt, sondern auch die Effizienz seiner Arbeit im Blick behält.

Die internen Messwerte wiesen für einige wenige Worker eine hohe durchschnittliche Laufzeit 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 für einige Worker sowohl einmalige als auch regelmäßige Zeitpläne. So kann die App dieselbe Worker-Logik für identische Aufgaben mit denselben Erfolgskriterien wiederverwenden, die sich nur im Timing unterscheiden.

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

Mit diesen zusätzlichen Informationen konnte das Team eindeutig 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 als die andere beitrug.

Manmeet Tuteja, Android Engineer II bei WHOOP, sagte: „Diese Aufteilung hat uns auch bestätigt, 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. Insbesondere 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 begann, war whoopSensorFlow – das angibt, ob der Sensor verbunden ist – null. Der SensorWorker behandelte dies nicht als Bedingung für den 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 Worker-Effizienz 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.