Lorsque vous créez 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 qui utilisent 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 publié une nouvelle métrique dans Android Vitals : "Trop de wakelocks partiels". Cette métrique mesure le pourcentage de sessions utilisateur au cours desquelles l'utilisation cumulative 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 essentiel pour offrir une expérience utilisateur de qualité.

À partir du 1er mars 2026, les applications qui ne respectent pas le seuil de qualité pourront être exclues des surfaces de découverte de Google Play. Un avertissement pourra é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 permis à l'équipe de relever la barre en matière d'efficacité 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 indiquant que son travail en arrière-plan maintenait le processeur actif plus longtemps que nécessaire. En résolvant ce problème, elle pourrait continuer à offrir une expérience utilisateur de qualité tout en réduisant le temps perdu 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 pour obtenir plus d'informations sur les wakelocks qui affectaient la métrique. En consultant le tableau de bord Android Vitals "Trop de wakelocks partiels", elle a pu identifier le principal contributeur aux wakelocks partiels excessifs comme l'un de ses workers WorkManager (identifié dans le tableau de bord comme androidx.work.impl.background.systemjob.SystemJobService). Pour prendre en charge l'expérience "toujours activée" de WHOOP, l'application utilise WorkManager pour les tâches en arrière-plan telles que la synchronisation périodique et la diffusion de mises à jour récurrentes sur l'accessoire connecté. 

L'équipe savait que WorkManager acquérait un wakelock lors de l'exécution de tâches en arrière-plan, mais elle n'avait auparavant aucune visibilité sur la distribution de l'ensemble de son travail en arrière-plan (au-delà de WorkManager) jusqu'à l'introduction de la métrique "Trop de wakelocks partiels" dans Android Vitals.

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

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

WHOOP disposait déjà d'une infrastructure interne configurée pour surveiller les métriques WorkManager. Elle surveille périodiquement les éléments suivants :

1. Durée d'exécution moyenne : combien de temps le worker s'exécute-t-il ?
2. Délais : à quelle fréquence le worker expire-t-il au lieu de se terminer ?
3. Nouvelles tentatives : à quelle fréquence le worker effectue-t-il une nouvelle tentative si le travail a expiré ou échoué ?
4. Annulations : à quelle fréquence le travail a-t-il été annulé ?

Le suivi des succès et des échecs des workers permet à l'équipe de visualiser l'efficacité de son travail.

Les métriques internes ont signalé une durée d'exécution moyenne élevée pour quelques workers, ce qui leur a permis de limiter encore davantage l'enquête. 

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

Enquête : distinguer les variantes de worker

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

L'utilisation de ses métriques internes a permis de limiter la recherche à un worker spécifique, mais l'équipe n'a pas pu déterminer si le bug se produisait lorsque le worker était ponctuel, périodique ou les deux. Elle a 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.

Ce détail supplémentaire lui permettrait d'identifier définitivement la variante de worker (périodique ou ponctuelle) qui contribuait le plus aux sessions avec trop de wakelocks partiels. Toutefois, l'équipe a été surprise de constater que les données révélaient qu'aucune des deux variantes ne semblait contribuer plus que l'autre.

Manmeet Tuteja, ingénieur Android II chez WHOOP, a déclaré que "cette répartition nous a également permis de confirmer que le problème se produisait dans les deux variantes, ce qui nous a fait abandonner la configuration de la planification pour nous concentrer sur un problème de logique métier partagée dans l'implémentation du worker".

Examiner plus en détail le comportement des workers et corriger la cause première

Sachant qu'elle devait examiner la logique au sein du worker,  l'équipe a réexaminé le comportement des workers qui avaient été signalés lors de son enquête. Plus précisément, elle recherchait les cas où le travail pouvait être bloqué et ne pas se terminer.

Tout cela a abouti à la découverte de la cause première des wakelocks excessifs :

Un CoroutineWorker conçu pour attendre une connexion au capteur WHOOP avant de continuer. 

Si le travail commençait sans qu'aucun capteur ne soit connecté, whoopSensorFlow, qui indique si le capteur est connecté, était null. Le SensorWorker ne considérait pas cela comme une condition de sortie anticipée et continuait à s'exécuter, attendant indéfiniment une connexion. Par conséquent, WorkManager conservait un wakelock partiel jusqu'à l'expiration du travail, ce qui entraînait une utilisation élevée des wakelocks en arrière-plan et une replanification fréquente et indésirable du 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 de tenter d'exécuter la logique métier principale.

Si le capteur n'est pas disponible, le worker se ferme, évitant ainsi un scénario de délai d'expiration et libérant le wakelock. L'extrait de code suivant illustre 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 % les sessions avec trop de wakelocks partiels

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

En fin de compte, WHOOP a vu son pourcentage de wakelocks partiels excessifs passer de 15 % à moins de 1 % seulement 30 jours après avoir implémenté les modifications dans son worker. 

Grâce à ces modifications, l'équipe a constaté moins de cas d'expiration du travail sans qu'il ne soit terminé, ce qui a entraîné une baisse des durées d'exécution moyennes. 

Voici les conseils de l'équipe WHOOP aux autres développeurs qui souhaitent améliorer l'efficacité de leur travail 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, puis consultez la documentation sur les wakelocks pour obtenir plus de bonnes pratiques et de stratégies de débogage.