Fallstudien
Wie WHOOP die Anzahl übermäßiger Teil-Wakelock-Sitzungen um über 90 % reduziert hat
Lesezeit: 4 Minuten
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.
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:
- Durchschnittliche Laufzeit: Wie lange wird der Worker ausgeführt?
- Zeitüberschreitungen: Wie oft überschreitet der Worker das Zeitlimit, anstatt die Aufgabe abzuschließen?
- Wiederholungsversuche: Wie oft wird der Worker wiederholt, wenn die Arbeit abgelaufen ist oder fehlgeschlagen ist?
- 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.“
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.
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:
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.
Weiterlesen
-
Fallstudien
Monzo ist eine britische Digitalbank mit 15 Millionen Kunden, Tendenz steigend. Als die App skaliert wurde, stellte das Entwicklerteam fest, dass die Startzeit der App ein kritischer Bereich war, der verbessert werden musste. Sie befürchteten jedoch, dass dies erhebliche Änderungen an ihrem Code erfordern würde.
Ben Weiss • Lesezeit: 2 Minuten
-
Fallstudien
TikTok ist eine globale Plattform für Kurzvideos, die für ihre große Nutzerbasis und innovativen Funktionen bekannt ist.
Ben Trengrove, Ajesh Pai • Lesezeit: 2 Minuten
-
Fallstudien
In der dynamischen Welt der sozialen Medien lässt sich die Aufmerksamkeit der Nutzer schnell gewinnen oder verlieren. Meta-Apps (Facebook und Instagram) gehören zu den weltweit größten sozialen Plattformen und werden von Milliarden Nutzern auf der ganzen Welt verwendet.
Mayuri Khinvasara Khabya • Lesezeit: 4 Minuten
Auf dem Laufenden bleiben
Lassen Sie sich Woche für Woche die neuesten Informationen zur Android-Entwicklung zusenden.