Comment WHOOP a réduit de plus de 90 % les sessions de wakelocks partiels excessifs

Lorsque l'on crée une application Android pour un accessoire connecté, le vrai travail commence lorsque l'écran s'éteint. WHOOP aide ses membres à comprendre comment leur corps réagit à l'entraînement, à la récupération, au sommeil et au stress. Pour les nombreux membres WHOOP sur Android, la synchronisation et la connectivité fiables en arrière-plan sont ce qui rend ces insights possibles.

Plus tôt cette année, Google Play a lancé une nouvelle métrique dans Android Vitals : les wakelocks partiels excessifs. Cette métrique mesure le pourcentage de sessions utilisateur au cours desquelles l'utilisation cumulée de wakelocks non exemptés dépasse deux heures sur une période de 24 heures. L'objectif de cette métrique est de vous aider à identifier et à résoudre les sources potentielles de décharge de la batterie, ce qui est crucial pour offrir une expérience utilisateur de qualité.

À partir du 1er mars 2026, les applications qui ne respectent toujours pas le seuil de qualité pourront être exclues des surfaces de découverte de Google Play. Un avertissement peut également être placé sur la fiche Google Play Store, indiquant que l'application peut consommer plus de batterie que prévu.

Selon Mayank Saini, ingénieur Android senior chez WHOOP, cela a "donné à l'équipe l'occasion d'améliorer l'efficacité sur Android", après qu'Android Vitals a signalé que le pourcentage de wakelocks partiels excessifs de l'application était de 15 %, ce qui dépassait le seuil recommandé de 5 %.

L'équipe a considéré la métrique Android Vitals comme un signal clair que son travail en arrière-plan maintenait le processeur actif plus longtemps que nécessaire. En résolvant ce problème, ils pourraient continuer à offrir une expérience utilisateur de qualité, tout en réduisant le temps d'exécution en arrière-plan et en maintenant une connectivité et une synchronisation Bluetooth fiables et rapides.

Identifier le problème

Pour savoir par où commencer, l'équipe s'est d'abord tournée vers Android Vitals afin de mieux comprendre quels wakelocks affectaient la métrique. En consultant le tableau de bord Android Vitals sur les wakelocks partiels excessifs, l'équipe a pu identifier le principal facteur de wakelocks partiels excessifs : l'un de ses workers WorkManager (identifié dans le tableau de bord comme androidx.work.impl.background.systemjob.SystemJobService). Pour proposer l'expérience "toujours active" de WHOOP, l'application utilise WorkManager pour les tâches en arrière-plan, comme la synchronisation périodique et l'envoi de mises à jour récurrentes à l'accessoire connecté. 

L'équipe savait que WorkManager acquiert un wakelock lors de l'exécution de tâches en arrière-plan, mais elle n'avait pas de visibilité sur la répartition de l'ensemble de ses tâches en arrière-plan (au-delà de WorkManager) avant l'introduction de la métrique "Wakelocks partiels excessifs" dans Android Vitals.

Le tableau de bord ayant identifié WorkManager comme principal contributeur, l'équipe a pu concentrer ses efforts sur l'identification de celui de ses workers qui contribuait le plus et s'efforcer de résoudre le problème.

Utiliser des métriques et des données internes pour mieux identifier la cause

WHOOP disposait déjà d'une infrastructure interne configurée pour surveiller les métriques WorkManager. Ils surveillent régulièrement :

1. Durée d'exécution moyenne : combien de temps le nœud de calcul s'exécute-t-il ?
2. Délais avant expiration : à quelle fréquence le worker expire-t-il au lieu de se terminer ?
3. Nouvelles tentatives : à quelle fréquence le nœud de calcul réessaie-t-il si le travail a expiré ou a échoué ?
4. Annulations : à quelle fréquence le travail a-t-il été annulé ?

Le suivi des réussites et des échecs des collaborateurs permet à l'équipe de mieux comprendre l'efficacité de son travail.

Les métriques internes ont signalé un temps d'exécution moyen élevé pour quelques nœuds de calcul, ce qui leur a permis d'affiner encore davantage l'investigation. 

En plus de ses métriques internes, l'équipe a également utilisé l'outil d'inspection des tâches en arrière-plan d'Android Studio pour inspecter et déboguer les workers concernés, en se concentrant spécifiquement sur les wakelocks associés, afin de s'aligner sur la métrique signalée dans Android Vitals.

Investigation : distinguer les variantes de nœuds de calcul

WHOOP utilise à la fois une planification ponctuelle et périodique pour certains workers. Cela permet à l'application de réutiliser la même logique Worker pour des tâches identiques avec les mêmes critères de réussite, qui ne diffèrent que par leur timing.

En utilisant leurs métriques internes, ils ont pu limiter leur recherche à un nœud de calcul spécifique, mais ils n'ont pas pu déterminer si le bug se produisait lorsque le nœud de calcul était ponctuel, périodique ou les deux. Ils ont donc déployé une mise à jour pour utiliser la méthode setTraceTag de WorkManager afin de distinguer les variantes ponctuelles et périodiques du même Worker.

Ces informations supplémentaires lui permettraient d'identifier de manière définitive quelle variante de Worker (périodique ou ponctuelle) contribue le plus aux sessions avec des wakelocks partiels excessifs. Cependant, l'équipe a été surprise de constater que les données ne montraient pas de différence significative entre les deux variantes.

Manmeet Tuteja, Android Engineer II chez WHOOP, a déclaré : "Cette répartition nous a également permis de confirmer que le problème se produisait dans les deux variantes, ce qui nous a permis d'écarter la configuration de la planification et de nous orienter vers un problème de logique métier partagé dans l'implémentation du worker."

Explorer en détail le comportement des nœuds de calcul et corriger la cause fondamentale

Sachant qu'elle devait examiner la logique au sein du nœud de calcul,  l'équipe a réexaminé le comportement des nœuds de calcul qui avaient été signalés lors de son investigation. Plus précisément, ils recherchaient des cas où le travail pouvait être bloqué et ne pas se terminer.

Tout cela a permis de trouver la cause des wakelocks excessifs :

Un CoroutineWorker conçu pour attendre qu'une connexion au capteur WHOOP soit établie avant de continuer. 

Si le travail a commencé sans capteur connecté, whoopSensorFlow (qui indique si le capteur est connecté) était défini sur null. SensorWorker n'a pas traité cela comme une condition de sortie anticipée et a continué à s'exécuter, attendant indéfiniment une connexion. Par conséquent, WorkManager conservait un wakelock partiel jusqu'à l'expiration du délai d'attente de la tâche, ce qui entraînait une utilisation élevée du wakelock en arrière-plan et une replanification fréquente et indésirable de SensorWorker.

Pour résoudre ce problème, l'équipe WHOOP a mis à jour la logique du worker afin de vérifier l'état de la connexion avant d'essayer d'exécuter la logique métier principale.

Si le capteur n'est pas disponible, le nœud de calcul se ferme, ce qui évite un scénario de délai avant expiration et libère le wakelock. L'extrait de code suivant montre la solution :

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()
            }
}

Réduire de 90% le nombre de sessions avec un nombre excessif de wakelocks partiels

Après avoir déployé le correctif, l'équipe a continué de surveiller le tableau de bord Android Vitals pour confirmer l'impact des modifications. 

WHOOP a ainsi vu son pourcentage de wakelocks partiels excessifs passer de 15% à moins de 1% seulement 30 jours après avoir implémenté les modifications apportées à son Worker. 

Grâce à ces changements, l'équipe a constaté une diminution du nombre de tâches qui expirent avant d'être terminées, ce qui a permis de réduire les temps d'exécution moyens. 

Voici les conseils de l'équipe WHOOP aux autres développeurs qui souhaitent améliorer l'efficacité de leurs tâches en arrière-plan :

Commencer

Si vous souhaitez réduire le nombre de wakelocks partiels excessifs de votre application ou améliorer l'efficacité des workers, consultez la métrique "Trop de wakelocks partiels" de votre application dans Android Vitals, ainsi que la documentation sur les wakelocks pour découvrir d'autres bonnes pratiques et stratégies de débogage.