Wie WHOOP die Anzahl übermäßiger Teil-Wakelock-Sitzungen um über 90 % reduziert hat

Wenn Sie eine Android-App für ein Wearable entwickeln, 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 mit Android sind zuverlässige Hintergrundsynchronisierung und Konnektivität die Grundlage für diese Erkenntnisse.

Anfang des Jahres hat Google Play einen neuen Messwert in Android Vitals eingeführt: „Übermäßige Teil-Wakelocks“. Dieser Messwert gibt den Prozentsatz der Nutzersitzungen an, in denen die kumulative, nicht ausgenommene Wakelock-Nutzung in einem 24-Stunden-Zeitraum 2 Stunden überschreitet. Dieser Messwert soll Ihnen helfen, mögliche Ursachen für eine schnelle Akkuentladung zu ermitteln und zu 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 Google Play-Oberflächen für die App-Suche ausgeschlossen. Außerdem wird im Google Play Store-Eintrag möglicherweise eine Warnung angezeigt, dass die App mehr Akku als erwartet verbrauchen könnte.

Laut Mayank Saini, Senior Android Engineer bei WHOOP, „bot sich dem Team damit die Möglichkeit, die Messlatte für die Android-Effizienz höher zu legen“. Android Vitals hatte den Prozentsatz der übermäßigen Teil-Wakelocks der App mit 15 % angegeben, was den empfohlenen Grenzwert von 5 % überschritt.

Das Team sah den Android Vitals-Messwert als deutliches 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 und gleichzeitig die verschwendete Hintergrundzeit verringern sowie eine zuverlässige und zeitnahe Bluetooth-Verbindung und Synchronisierung aufrechterhalten.

Problem identifizieren

Um herauszufinden, wo sie ansetzen sollten, wandte sich das Team zuerst an Android Vitals, um mehr darüber zu erfahren, welche Wake Locks sich auf den Messwert auswirkten. Mithilfe des Android Vitals-Dashboards für übermäßige teilweise Wakelocks konnte das Team den größten Verursacher übermäßiger teilweise Wakelocks ermitteln: einen der WorkManager-Worker (im Dashboard als androidx.work.impl.background.systemjob.SystemJobService angegeben). 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 war sich zwar bewusst, dass WorkManager beim Ausführen von Aufgaben im Hintergrund einen Wakelock erhält, hatte aber vor der Einführung des Messwerts „Übermäßige teilweise Wakelocks“ in Android Vitals keinen Einblick in die Verteilung aller Hintergrundaufgaben (nicht nur WorkManager).

Da WorkManager im Dashboard als Hauptursache identifiziert wurde, konnte sich das Team darauf konzentrieren, herauszufinden, welche Worker am meisten dazu beigetragen haben, 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 überwachen. Sie überwachen regelmäßig:

1. Durchschnittliche Laufzeit: Wie lange wird der Worker ausgeführt?
2. Zeitüberschreitungen: Wie oft überschreitet der Worker das Zeitlimit, anstatt die Aufgabe abzuschließen?
3. Wiederholungsversuche: Wie oft wird der Worker wiederholt, wenn die Arbeit abgelaufen ist oder fehlgeschlagen ist?
4. Stornierungen: Wie oft wurde die Arbeit storniert?

Wenn Sie nicht nur die Erfolge und Fehler von Mitarbeitern erfassen, erhält das Team Einblick in die Effizienz seiner Arbeit.

Bei den internen Messwerten wurde für einige wenige Worker eine hohe durchschnittliche Laufzeit gemeldet, sodass die Untersuchung noch weiter eingegrenzt werden 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 Fehler zu beheben. Dabei lag der Fokus insbesondere auf den zugehörigen Wake Locks, um den in Android Vitals gemeldeten Messwert zu optimieren.

Untersuchung: Unterscheidung zwischen Worker-Varianten

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

Mithilfe ihrer internen Messwerte konnten sie die Suche auf einen bestimmten Worker eingrenzen, aber sie konnten nicht feststellen, ob der Fehler bei einmaligen oder regelmäßigen Worker-Ausführungen oder bei beiden auftrat. Daher haben sie ein Update eingeführt, in dem die setTraceTag-Methode von WorkManager verwendet wird, um zwischen den einmaligen und regelmäßigen Varianten desselben Worker zu unterscheiden.

Anhand dieser zusätzlichen Informationen können sie genau ermitteln, welche Worker-Variante (regelmäßig oder einmalig) am meisten zu Sitzungen mit übermäßig vielen partiellen Wake Locks beigetragen hat. Das Team war jedoch überrascht, als die Daten zeigten, dass keine der beiden Varianten mehr als die andere zu den Ergebnissen beitrug.

Manmeet Tuteja, Android Engineer II bei WHOOP, sagte: „Durch diese Aufteilung konnten wir bestätigen, dass das Problem in beiden Varianten auftrat. Das deutete nicht auf eine Konfigurationsproblematik bei der Planung hin, sondern auf ein gemeinsames Problem mit der Geschäftslogik in der Worker-Implementierung.“

Arbeiterverhalten 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 aufgefallen waren, noch einmal. Konkret wurde nach Fällen gesucht, in denen die Arbeit möglicherweise hängen geblieben und nicht abgeschlossen worden ist.

All dies führte zur Ermittlung der Ursache für die übermäßigen Wakelocks:

Ein CoroutineWorker, der darauf ausgelegt ist, auf eine Verbindung zum WHOOP-Sensor zu warten, bevor er fortfährt. 

Wenn die Arbeit ohne angeschlossenen Sensor begonnen wurde, war whoopSensorFlow – das angibt, ob der Sensor angeschlossen ist – null. Die SensorWorker hat dies nicht als Bedingung für den vorzeitigen Beenden des Vorgangs behandelt und wurde weiter ausgeführt. Sie hat also unbegrenzt auf eine Verbindung gewartet. Daher hat WorkManager eine partielle Wakelock gehalten, bis für die Aufgabe ein Zeitlimit überschritten wurde. Dies führte zu einer hohen Nutzung von Wakelocks im Hintergrund und zu häufigen, unerwünschten Neuplanungen von SensorWorker.

Um dieses Problem zu beheben, hat das WHOOP-Team die Worker-Logik aktualisiert, sodass der Verbindungsstatus geprüft wird, bevor versucht wird, die zentrale Geschäftslogik auszuführen.

Wenn der Sensor nicht verfügbar ist, wird der Worker beendet, um ein Zeitüberschreitungsereignis zu vermeiden und den Wakelock freizugeben. 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

Nachdem das Team den Fehler behoben hatte, beobachtete es weiterhin das Android Vitals-Dashboard, um die Auswirkungen der Änderungen zu bestätigen. 

Letztendlich sank der Anteil der übermäßigen partiellen Wakelocks bei WHOOP innerhalb von nur 30 Tagen von 15% auf unter 1%, nachdem die Änderungen am Worker vorgenommen wurden. 

Durch die Änderungen sind weniger Fälle aufgetreten, in denen die Zeit für die Ausführung von Aufgaben abgelaufen ist, bevor sie abgeschlossen wurden. Das hat zu kürzeren durchschnittlichen Laufzeiten geführt. 

Das WHOOP-Team hat folgende Tipps für andere Entwickler, die die Effizienz ihrer Hintergrundarbeit verbessern möchten:

Jetzt starten

Wenn Sie die übermäßigen partiellen Wakelocks Ihrer App reduzieren oder die Effizienz von Workern verbessern möchten, sehen Sie sich den entsprechenden Messwert in Android Vitals an und lesen Sie die Dokumentation zu Wakelocks, um weitere Best Practices und Strategien zur Fehlerbehebung zu erhalten.