Économiser l'énergie et la batterie

L'efficacité énergétique est particulièrement importante sur Wear OS. Les principes de conception de Wear OS sont axés sur l'utilisation de l'énergie de l'appareil, car la montre est un appareil de petit format conçu pour des interactions courtes.

Par rapport aux appareils mobiles plus grands, les appareils Wear OS sont équipés de batteries plus petites. Toute décharge de la batterie est donc plus visible. De plus, l'utilisateur doit faire plus d'efforts pour charger un appareil Wear OS que pour charger un appareil mobile. Les utilisateurs peuvent charger leurs appareils mobiles à différents intervalles tout au long de la journée, mais ils doivent retirer un appareil Wear OS de leur corps avant de le charger.

Pour améliorer l'efficacité énergétique de votre application, suivez ces bonnes pratiques de conception :

• La conception de votre application doit tirer parti du facteur de forme de Wear OS. Elle ne doit pas copier directement votre application mobile.
• Utilisez votre application mobile existante pour certains cas d'utilisation. Par exemple, Internet et la synchronisation sur la montre sont coûteux. Déterminez si l'appareil mobile peut effectuer les tâches les plus lourdes et si l'appareil Wear OS reçoit les modifications apportées aux données.
• Concevez vos cas d'utilisation pour des interactions plus courtes.
• Déterminez les événements Wear OS que vous utilisez et leur fréquence.

• Dans la mesure du possible, reportez le travail de votre application jusqu'à ce que la montre soit en charge. Cela s'applique particulièrement aux tâches gourmandes en données, telles que la synchronisation des données et l'organisation des bases de données.

  Si l'appareil est en charge et dispose d'une connexion Wi-Fi, planifiez des tâches pour précharger les données, les images et les mises à jour que l'utilisateur souhaite probablement voir dans votre application.

Ce guide sur l'alimentation vous aide à comprendre quand et comment le système exécute votre application, et comment vous pouvez limiter la durée d'exécution et la décharge de la batterie de votre application. Pour en savoir plus sur la manière dont certaines actions sont effectuées, par exemple le chargement d'une application ou le défilement d'une liste, consultez les conseils liés aux performances, tels que le guide sur les performances de Compose sur Wear OS.

Surveiller l'utilisation de la batterie dans le temps

Pour analyser les statistiques de la batterie d'un appareil Wear OS qui exécute votre application, saisissez la commande suivante dans une fenêtre de terminal sur votre ordinateur de développement :

adb shell dumpsys batterystats

Une bibliothèque sur GitHub propose un analyseur de statistiques de la batterie, qui peut être utile pour exécuter cette commande.

Événements qui affectent l'autonomie de la batterie

Avant de penser spécifiquement à votre application, il est utile de réfléchir plus généralement aux événements qui consomment de l'énergie sur un appareil Wear OS.

Le tableau suivant présente l'effet relatif sur l'autonomie de la batterie de plusieurs événements courants dans les applications Wear OS. La décharge exacte de la batterie varie d'un appareil à l'autre.

Minimiser le temps d'écran allumé

Dans votre application Wear OS, suivez ces principes d'utilisation de l'écran :

• Verrouillages de l'écran allumé : évitez-les autant que possible. Pour tester, désactivez Affichage permanent dans les paramètres système et vérifiez si l'écran s'éteint dans le délai d'inactivité.
• Animations : minimisez les animations élaborées et concentrez-vous plutôt sur des transitions brèves pour un aspect plus professionnel. En particulier, évitez les animations et les boucles de longue durée. Si une boucle est nécessaire, ajoutez une pause entre les boucles qui soit au moins aussi longue que l'animation elle-même.
• Temps d'éveil en mode ambiant : si nécessaire, prenez en charge le mode toujours activé, par exemple pour les cas d'utilisation liés au fitness. Si votre application nécessite le mode toujours activé, suivez ces recommandations pour le mode ambiant.

Minimiser l'utilisation du processeur

Dans votre application Wear OS, suivez ces principes d'utilisation du processeur :

• Limitez la durée d'utilisation.
• Regroupez toutes les opérations associées pour maximiser le temps d'inactivité du processus de votre application.

Minimiser les wakelocks

Dans la plupart des cas, évitez toute opération qui empêche votre application de se mettre en veille, comme les wakelocks. Par exemple, dans les applications de santé et de fitness, les entraînements de longue durée n'ont pas besoin de wakelock. Utilisez le temps d'éveil du processeur lorsque vous recevez des rappels de l'API du capteur, par exemple lorsque vous utilisez les Services Santé sur Wear OS.

Dans certains cas, il est acceptable d'acquérir un wakelock, par exemple lorsque votre application effectue l'une des opérations suivantes :

• Lit des contenus multimédias en arrière-plan.
• Utilise WorkManager ou JobScheduler. (Le système maintient un wakelock en votre nom lors de l'exécution du job en arrière-plan.)

Pour déboguer les wakelocks localement, utilisez l'outil Background Task Inspector d'Android Studio, le traçage système ou adb shell dumpsys batterystats pour inspecter les occurrences individuelles de wakelocks longs, ainsi que les récapitulatifs du nombre total et de la durée des wakelocks maintenus. Comparez le nombre et la durée des wakelocks que votre application maintient aux modèles d'utilisation interactive de votre application :

• Recherchez les wakelocks inattendus.
• Si la durée est plus longue que prévu, déterminez si le travail est bloqué par une dépendance, telle que la disponibilité du réseau.

Inspecter la manière dont votre application devient inactive

Déterminez ce que fait l'application active lorsque des événements clés de l'appareil se produisent, tels que les suivants :

• L'écran s'éteint et l'appareil passe en mode ambiant.

• L'application est ignorée par balayage.

Pour analyser l'activité de l'application, utilisez les outils présentés dans les sections suivantes.

Profileur d'alimentation

Le profileur d'alimentation est accessible dans le menu Android Studio en sélectionnant View > Tool Windows > Profiler (Affichage > Fenêtres d'outils > Profileur) :

1. Inspectez la trace système lorsque l'écran s'éteint et que l'appareil passe en mode ambiant.
2. Recherchez tout travail qui se poursuit et le niveau d'utilisation du processeur de l'appareil.

Perfetto

Perfetto vous permet d'enregistrer une trace, puis d'inspecter votre application pour voir si des threads effectuent un travail lorsque l'écran s'éteint, que l'appareil passe en mode ambiant ou que l'utilisateur ignore l'activité de votre application.

Définissez des événements personnalisés pour marquer les événements importants de votre application, y compris les événements spécifiques au domaine. Pour une application multimédia, cela inclut des tâches telles que la récupération de playlists, le téléchargement d'un élément multimédia spécifique, le démarrage de la lecture et l'arrêt de la lecture. En définissant ces événements, vous pouvez les afficher dans Perfetto et comparer leur timing avec l'utilisation du processeur et de l'alimentation de votre application.

Vous pouvez également utiliser la CLI Android pour installer la android-profiler compétence (android skills add android-profiler), qui permet aux agents d'IA d'enregistrer des traces système Perfetto à partir de la ligne de commande et d'analyser les rails d'alimentation, les wakelocks et les états de suspension de l'appareil.

Analyser les jobs planifiés de votre application

Les jobs planifiés, à l'aide de WorkManager, vous permettent d'effectuer des tâches en arrière-plan dans votre application. Bien que certaines tâches en arrière-plan doivent être périodiques, n'exécutez pas les jobs trop fréquemment ou pendant une longue durée, car cela peut décharger la batterie de l'appareil.

Utilisez l'outil Background Task Inspector d'Android Studio (View > Tool Windows > App Inspection (Affichage > Fenêtres d'outils > Inspection des applications)) ou exécutez adb shell dumpsys jobscheduler et adb shell dumpsys batterystats pour inspecter l'exécution des jobs et des workers planifiés. Vérifiez la fréquence d'exécution et la durée totale :

• Si un job s'exécute très fréquemment, envisagez de réduire cette fréquence.
• Vérifiez que la durée totale d'exécution correspond à ce que vous attendez et qu'elle n'est pas beaucoup plus longue.

Vous pouvez également enregistrer une trace système pour corréler l'exécution du job avec l' activité de votre application sur une chronologie. Tenez compte des points suivants :

• Pour votre application, la durée d'exécution doit être logique.
• Déterminez si les jobs se produisent pendant l'exécution de votre application ou s'ils représentent un travail périodique en arrière-plan.

Capteurs

Les appareils Wear OS sont équipés de nombreux capteurs différents, tels que le GPS. Dans la plupart des cas, utilisez les Services Santé sur Wear OS au lieu d'interagir directement avec SensorManager. Dans de nombreux cas, les Services Santé regroupent intelligemment les données pour améliorer les performances de la batterie.

Pour analyser l'utilisation des capteurs dans votre application, exécutez la commande suivante dans une fenêtre de terminal sur votre ordinateur de développement :

adb shell dumpsys sensorservice

Les résultats de cette commande affichent les éléments suivants :

• Enregistrements de capteurs actuels et précédents.
• Configuration du capteur, y compris le regroupement s'il est défini.
• Données récemment échantillonnées.

Tester la désinscription des capteurs

Pour vérifier si votre application cesse d'extraire les données des capteurs comme prévu, testez les scénarios suivants :

1. Ignorez votre application par balayage.
2. Appuyez sur l'écran avec la paume de votre main. L'écran s'éteint ou passe en mode ambiant.

Utilisez la commande ADB de la section précédente pour vérifier si le capteur s'affiche correctement comme non enregistré.

Couche de données

Lorsque vous utilisez l'API Data Layer, chaque transmission consomme de l'énergie. En particulier, si vous utilisez cette API pour envoyer des données, votre application doit se réactiver pour les recevoir. Pour ces raisons, utilisez cette API avec modération.

Voici quelques bonnes pratiques supplémentaires pour utiliser l'API Data Layer :

• Attendez que votre application soit active avant de configurer un écouteur à l'aide de WearableListenerService.
• N'utilisez pas l'API Data Layer pour envoyer régulièrement un ping à la montre afin de vérifier si un appareil ou une application associée est disponible. En envoyant des messages de manière répétée, votre application réactive la radio et le processus de l'application à distance, ce qui décharge la batterie de l'appareil plus que nécessaire. Utilisez plutôt CapabilityClient pour détecter la disponibilité et les fonctionnalités de l'appareil, ou n'envoyez des messages que lorsque l'état change.

• Transmettez les changements d'état au lieu de configurer des mises à jour rapides. Ces changements d'état permettent à l'appareil Wear OS d'effectuer des calculs de données locaux, par exemple lorsqu'une séance d'entraînement a commencé.

  Ne transmettez que les changements d'état qui mettent à jour votre interface utilisateur. Par exemple, si votre écran d'activité n'affiche que les "kilomètres parcourus" avec une décimale, n'envoyez pas de changement d'état à Wear OS chaque fois que l'utilisateur avance d'un mètre.

Pour analyser l'utilisation de l'API Data Layer dans votre application, exécutez la commande suivante dans une fenêtre de terminal sur votre ordinateur de développement :

adb shell dumpsys activity service WearableService

Les résultats de cette commande incluent les éléments suivants :

• RpcService : vous permet de voir la fréquence et les chemins qui sont appelés à l'aide de MessageClient.
• DataService : vous permet de voir la fréquence à laquelle les éléments de données sont définis à l'aide de DataClient.

Applications de santé et de fitness

Si vous gérez une application de santé et de fitness, utilisez les Services Santé pour optimiser l'utilisation des capteurs par votre application.

• Pour ExerciseClient, utilisez une trace système, Perfetto ou adb shell dumpsys batterystats pour vérifier le bon comportement en mode ambiant. Vérifiez que votre application ne se réactive pas plus fréquemment que toutes les minutes ou deux minutes pour recevoir les données ExerciseUpdate.
• Pour la surveillance générale de la santé tout au long de la journée, utilisez le PassiveMonitoringClient, comme décrit dans le guide sur la façon de surveiller les données de santé et de fitness en arrière-plan.

Cartes et complications

Si votre application est compatible avec une carte ou une complication, suivez ces bonnes pratiques :

• Désactivez l'actualisation automatique ou augmentez la fréquence d'actualisation à deux heures ou plus.
• Utilisez Firebase Cloud Messaging (FCM) ou des jobs planifiés de manièreappropriée pour envoyer des mises à jour de données. Veillez à éviter une fréquence de mises à jour rapide, car cela peut entraîner la planification répétée du travail par le système à une fréquence plus rapide que celle à laquelle l'utilisateur ou la plate-forme peuvent accéder aux données nécessaires pour effectuer ce travail.
• Ne planifiez pas de travail pour votre carte ou votre complication lorsque l'utilisateur n'interagit pas avec elle.
• Utilisez des approches "hors connexion d'abord".
• Partagez une seule base de données entre votre application principale, vos cartes et vos complications. Cela permet également de garantir la cohérence des données sur les surfaces de l'interface utilisateur.