Fallstudien

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

Lesezeit: 4 Minuten
Breana Tate
Developer Relations Engineer

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 einem Android-Gerät 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, bei denen die kumulative, nicht ausgenommene Wakelock-Nutzung in einem 24-Stunden-Zeitraum 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 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 übermäßigen Anteil an Teil-Wakelocks der App mit 15 % angegeben, was den empfohlenen Grenzwert von 5 % überschritt.

mayank.png

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 teilweiser Wakelocks identifizieren: einen ihrer 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 wusste zwar, dass WorkManager einen Wakelock erhält, wenn Aufgaben im Hintergrund ausgeführt werden. Vor der Einführung des Messwerts für übermäßige teilweise Wakelocks in Android Vitals hatte es jedoch keinen Einblick in die Verteilung aller Hintergrundaufgaben (nicht nur WorkManager).

Da im Dashboard WorkManager als Hauptursache angegeben wurde, konnte sich das Team darauf konzentrieren, welcher der 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 ü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 einen Einblick in die Effizienz seiner Arbeit.

Bei einigen wenigen Workern wurde bei den internen Messwerten eine hohe durchschnittliche Laufzeit festgestellt, 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 die in Android Vitals gemeldete Metrik zu optimieren.

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 ihrer internen Messwerte konnten sie die Suche auf einen bestimmten Worker eingrenzen, aber sie konnten nicht feststellen, ob der Fehler bei einmaligen oder periodischen 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 den 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 darauf hin, dass es sich nicht um ein Problem mit der Konfiguration der Zeitplanung, sondern um ein gemeinsames Problem mit der Geschäftslogik in der Worker-Implementierung handelte.“

manmeet.png

Grundursache für das Verhalten von Mitarbeitern 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 wartet, dass eine Verbindung zum WHOOP-Sensor hergestellt wird, 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 Wake Lock gehalten, bis für die Aufgabe ein Zeitlimit überschritten wurde. Dies führte zu einer hohen Nutzung von Wake Locks 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 die Aktivierungssperre 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 Wake Locks bei WHOOP innerhalb von nur 30 Tagen von 15% auf unter 1%, nachdem die Änderungen am Worker vorgenommen wurden. 

partialWake.png

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

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

sarthak.png

Jetzt starten

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

Verfasst von:

Weiterlesen