Wie WHOOP die Anzahl der Sitzungen mit übermäßigen Teil-Wakelocks um mehr als 90 % reduziert hat

Bei der Entwicklung einer Android-App für ein Wearable beginnt die eigentliche Arbeit, wenn sich das Display 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 nutzen, sind eine zuverlässige Hintergrundsynchronisierung und Konnektivität entscheidend, um diese Einblicke zu erhalten.

Anfang des Jahres wurde bei Google Play ein neuer Messwert in Android Vitals veröffentlicht: „Übermäßige Teil-Wakelocks“. Dieser Messwert gibt den Prozentsatz der Nutzersitzungen an, in denen die kumulative, nicht ausgenommene Nutzung von Wakelocks innerhalb von 24 Stunden 2 Stunden überschreitet. Mit diesem Messwert können Sie mögliche Ursachen für einen hohen Akkuverbrauch ermitteln und beheben. Das ist entscheidend für eine gute Nutzererfahrung.

Ab dem 1. März 2026 können Apps, die den Qualitätsgrenzwert weiterhin nicht erfüllen, von den Google Play-Oberflächen für die Auffindbarkeit ausgeschlossen werden. Im Google Play Store-Eintrag wird möglicherweise auch eine Warnung angezeigt, dass die App mehr Akku als erwartet verbraucht.

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

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, können sie weiterhin eine hervorragende Nutzererfahrung bieten, gleichzeitig die im Hintergrund verschwendete Zeit reduzieren und eine zuverlässige und zeitnahe Bluetooth-Verbindung und ‑Synchronisierung aufrechterhalten.

Problem ermitteln

Um herauszufinden, wo sie anfangen sollten, nutzte das Team zuerst Android Vitals, um mehr darüber zu erfahren, welche Wakelocks den Messwert beeinflussten. Im Android Vitals-Dashboard für übermäßige partielle Wakelocks konnten sie den größten Verursacher übermäßiger partieller Wakelocks als einen ihrer WorkManager-Worker 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 beim Ausführen von Aufgaben im Hintergrund eine Wakelock-Sperre erwirbt, hatte aber bis zur Einführung des Messwerts für übermäßige partielle Wakelocks in Android Vitals keinen Einblick in die Verteilung aller Hintergrundaufgaben (über WorkManager hinaus).

Nachdem das Dashboard WorkManager als Hauptursache identifiziert hatte, konnte sich das Team darauf konzentrieren, herauszufinden, welcher ihrer 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 zur Überwachung von WorkManager-Messwerten eingerichtet. Sie überwachen regelmäßig:

1. Durchschnittliche Laufzeit: Wie lange läuft der Worker?
2. Zeitüberschreitungen: Wie oft kommt es zu einer Zeitüberschreitung, anstatt dass der Worker die Aufgabe abschließt?
3. Wiederholungen: Wie oft versucht der Worker es noch einmal, wenn die Arbeit ein Zeitlimit überschritten hat oder fehlgeschlagen ist?
4. Stornierungen: Wie oft wurde die Arbeit storniert?

Wenn Sie mehr als nur die Erfolge und Misserfolge der Worker im Blick behalten, erhält das Team Einblick in die Effizienz seiner Arbeit.

Die internen Messwerte zeigten für einige wenige Worker eine hohe durchschnittliche Laufzeit an, sodass die Untersuchung weiter eingegrenzt werden konnte. 

Zusätzlich zu den internen Messwerten nutzte das Team den Background Task Inspector von Android Studio, um die relevanten Worker zu prüfen und Fehler zu beheben. Dabei lag der Fokus auf den zugehörigen Wakelocks, um die in Android Vitals gekennzeichneten Messwerte zu berücksichtigen.

Untersuchung: Zwischen Worker-Varianten unterscheiden

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.

Anhand der internen Messwerte konnte die Suche auf einen bestimmten Worker eingegrenzt werden. Es war jedoch nicht möglich, festzustellen, ob der Fehler bei einem einmaligen oder periodischen Worker oder bei beiden auftrat. Sie haben daher ein Update veröffentlicht, um die setTraceTag-Methode von WorkManager zu verwenden und so zwischen den einmaligen und regelmäßigen Varianten desselben Workers zu unterscheiden.

Anhand dieser zusätzlichen Details lässt sich eindeutig feststellen, welche Worker-Variante (periodisch oder einmalig) am meisten zu Sitzungen mit übermäßigen partiellen Wakelocks beiträgt. Das Team war jedoch überrascht, als die Daten zeigten, dass keine der beiden Varianten mehr als die andere beizutragen schien.

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 darauf hin, dass es sich nicht um ein Problem mit der Planung der Konfiguration, sondern um ein Problem mit der gemeinsamen Geschäftslogik in der Worker-Implementierung handelte.“

Worker-Verhalten genauer untersuchen und die Ursache beheben

Da das Team wusste, dass es sich die Logik innerhalb des Workers ansehen musste, untersuchte es das Verhalten der Worker, die während der Untersuchung markiert worden waren, noch einmal. Insbesondere suchten sie nach Fällen, in denen die Arbeit möglicherweise ins Stocken geraten war und nicht abgeschlossen wurde.

All dies führte schließlich dazu, dass die Ursache für die übermäßigen Wakelocks gefunden wurde:

Ein CoroutineWorker, der so konzipiert ist, dass er auf eine Verbindung zum WHOOP-Sensor wartet, bevor er fortfährt. 

Wenn die Arbeit ohne verbundenen Sensor begonnen wurde, war whoopSensorFlow (gibt an, ob der Sensor verbunden ist) null. Die SensorWorker hat dies nicht als Bedingung für einen vorzeitigen Abbruch behandelt und weiter ausgeführt, sodass sie unbegrenzt auf eine Verbindung gewartet hat. Infolgedessen hielt WorkManager eine partielle Wakelock, bis die Zeit für die Arbeit abgelaufen war. Dies führte zu einer hohen Wakelock-Nutzung im Hintergrund und zu häufigen, unerwünschten Neuplanungen des SensorWorker.

Um dieses Problem zu beheben, hat das WHOOP-Team die Worker-Logik so aktualisiert, dass der Verbindungsstatus geprüft wird, bevor die zentrale Geschäftslogik ausgeführt wird.

Wenn der Sensor nicht verfügbar ist, wird der Worker beendet, um eine Zeitüberschreitung zu vermeiden, und die Wakelock wird aufgehoben. 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 des Fixes hat das Team das Android Vitals-Dashboard weiter im Blick behalten, um die Auswirkungen der Änderungen zu bestätigen. 

Letztendlich konnte WHOOP den Prozentsatz der übermäßigen partiellen Wakelocks von 15% auf weniger als 1%senken – und das nur 30 Tage nach der Implementierung der Änderungen am Worker. 

Infolge der Änderungen gab es weniger Fälle, in denen die Arbeit ohne Abschluss abgebrochen wurde, was zu kürzeren durchschnittlichen Laufzeiten führte. 

Das WHOOP-Team hat folgenden Rat für 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 von Workern verbessern möchten, rufen Sie den Messwert „Übermäßige Teil-Wakelocks“ Ihrer App in Android Vitals auf und lesen Sie die Dokumentation zu Wakelocks, um weitere Best Practices und Strategien zur Fehlerbehebung zu erhalten.