L'utilisation de la radio sans fil pour transférer des données est potentiellement l'une des sources les plus importantes de décharge de la batterie de votre application. Pour minimiser la décharge de la batterie associée à l'activité réseau, il est essentiel de comprendre l'impact de votre modèle de connectivité sur le matériel radio sous-jacent.
Cette section présente la machine d'état de la radio sans fil et explique comment le modèle de connectivité de votre application interagit avec elle. Il propose ensuite plusieurs techniques qui, lorsqu'elles sont suivies, permettent de minimiser l'effet de la consommation de données de votre application sur la batterie.
Machine d'état de la radio
La radio sans fil de l'appareil de l'utilisateur dispose de fonctionnalités d'économie d'énergie intégrées qui permettent de réduire la consommation de la batterie. Lorsqu'elle est entièrement active, la radio sans fil consomme beaucoup d'énergie, mais lorsqu'elle est inactive ou en veille, elle en consomme très peu.
N'oubliez pas que la radio ne peut pas passer instantanément du mode veille au mode actif. Il existe une période de latence associée à la "mise sous tension" de la radio. La batterie passe donc lentement d'un état d'énergie élevé à un état d'énergie faible afin d'économiser de l'énergie lorsqu'elle n'est pas utilisée, tout en essayant de minimiser la latence associée à la "mise sous tension" de la radio.
La machine d'état d'une radio réseau 3G classique se compose de trois états énergétiques :
- Pleine puissance : utilisé lorsqu'une connexion est active, ce qui permet à l'appareil de transférer des données au débit le plus élevé possible.
- Faible consommation : état intermédiaire qui réduit la consommation de la batterie d'environ 50%.
- Veille : état de consommation d'énergie minimale pendant lequel aucune connexion réseau n'est active.
Bien que les états faible et de veille consomment beaucoup moins de batterie, ils introduisent également une latence importante dans les requêtes réseau. Le retour à la pleine puissance à partir de l'état faible prend environ 1,5 seconde, et le passage de l'état de veille à la pleine puissance peut prendre plus de 2 secondes.
Pour minimiser la latence, la machine d'état utilise un délai pour retarder la transition vers des états d'énergie inférieurs. La figure 1 utilise les timings d'AT&T pour une radio 3G classique.
Figure 1 : Machine d'état radio sans fil 3G standard.
La machine d'état radio de chaque appareil, en particulier le délai de transition associé ("temps de latence") et la latence de démarrage, varie en fonction de la technologie radio sans fil utilisée (3G, LTE, 5G, etc.). Elle est définie et configurée par le réseau de l'opérateur sur lequel l'appareil fonctionne.
Cette page décrit une machine d'état représentative d'une radio sans fil 3G classique, d'après les données fournies par AT&T. Toutefois, les principes généraux et les bonnes pratiques qui en découlent s'appliquent à toutes les implémentations de radio sans fil.
Cette approche est particulièrement efficace pour la navigation Web mobile standard, car elle évite une latence indésirable lorsque les utilisateurs naviguent sur le Web. Le temps de queue relativement faible garantit également qu'une fois la session de navigation terminée, la radio peut passer à un état d'énergie inférieur.
Malheureusement, cette approche peut entraîner des applications inefficaces sur les systèmes d'exploitation des smartphones modernes comme Android, où les applications s'exécutent à la fois au premier plan (où la latence est importante) et en arrière-plan (où l'autonomie de la batterie doit être prioritaire).
Impact des applications sur la machine d'état radio
Chaque fois que vous créez une connexion réseau, la radio passe à l'état de pleine puissance. Dans le cas de la machine d'état radio 3G classique décrite précédemment, elle reste à pleine puissance pendant toute la durée du transfert, plus cinq secondes supplémentaires de temps de latence, suivies de 12 secondes à l'état de faible consommation d'énergie. Ainsi, pour un appareil 3G standard, chaque session de transfert de données entraîne une consommation d'énergie par la radio pendant au moins 18 secondes.
En pratique, cela signifie qu'une application qui effectue un transfert de données d'une seconde, trois fois par minute, maintient la radio sans fil perpétuellement active, la faisant repasser en mode haute puissance au moment même où elle passe en mode veille.
Figure 2 : Consommation d'énergie relative de la radio sans fil pour un transfert d'une seconde exécuté trois fois par minute. Ce chiffre exclut la latence de "mise sous tension" entre les exécutions.
En comparaison, si la même application regroupait ses transferts de données en exécutant un seul transfert de trois secondes toutes les minutes, la radio resterait en mode haute puissance pendant seulement 20 secondes par minute. Cela permettrait à la radio d'être en veille pendant 40 secondes par minute, ce qui réduirait considérablement la consommation de la batterie.
Figure 3 : Consommation d'énergie relative de la radio sans fil pour des transferts de trois secondes exécutés une fois par minute.
Techniques d'optimisation
Maintenant que vous comprenez l'impact de l'accès au réseau sur l'autonomie de la batterie, voyons ce que vous pouvez faire pour réduire la décharge de la batterie, tout en offrant une expérience utilisateur rapide et fluide.
Regrouper les transferts de données
Comme indiqué dans la section précédente, regrouper vos transferts de données afin de transférer plus de données moins souvent est l'un des meilleurs moyens d'améliorer l'efficacité de la batterie.
Bien sûr, cela n'est pas toujours possible si votre application doit recevoir ou envoyer des données immédiatement en réponse à une action de l'utilisateur. Vous pouvez atténuer ce problème en anticipant et en préchargeant les données. D'autres scénarios, tels que l'envoi de journaux ou d'analyses à un serveur et d'autres transferts de données non urgents initiés par l'application, se prêtent très bien au traitement par lot et au regroupement. Consultez Optimiser les tâches déclenchées par l'application pour obtenir des conseils sur la planification des transferts réseau en arrière-plan.
Prérécupération des données
La prérécupération des données est un autre moyen efficace de réduire le nombre de sessions de transfert de données indépendantes exécutées par votre application. Avec la prérécupération, lorsque l'utilisateur effectue une action dans votre application, celle-ci anticipe les données qui seront probablement nécessaires pour la série d'actions suivante de l'utilisateur et les récupère en une seule fois, via une seule connexion, à pleine capacité.
En préchargeant vos transferts, vous réduisez le nombre d'activations radio nécessaires pour télécharger les données. Vous économisez ainsi la batterie, mais vous améliorez également la latence, réduisez la bande passante requise et diminuez les temps de téléchargement.
La prérécupération améliore également l'expérience utilisateur en minimisant la latence dans l'application, qui est causée par l'attente de la fin des téléchargements avant d'effectuer une action ou d'afficher des données.
Voici un exemple concret.
Un lecteur de flux d'actualités
De nombreuses applications d'actualités tentent de réduire la bande passante en ne téléchargeant les titres qu'après la sélection d'une catégorie, les articles complets uniquement lorsque l'utilisateur souhaite les lire et les miniatures lorsqu'elles s'affichent.
Avec cette approche, la radio est forcée de rester active pendant la majeure partie de la session de lecture des actualités des utilisateurs, car ils font défiler les titres, changent de catégorie et lisent des articles. De plus, le passage constant d'un état d'énergie à un autre entraîne une latence importante lors du changement de catégorie ou de la lecture d'articles.
Une meilleure approche consiste à précharger une quantité raisonnable de données au démarrage, en commençant par le premier ensemble de titres et de vignettes d'actualités (ce qui garantit un temps de démarrage à faible latence), puis en continuant avec les titres et vignettes restants, ainsi que le texte de chaque article disponible dans au moins la liste principale des titres.
Une autre solution consiste à précharger chaque titre, miniature, texte d'article et éventuellement même des images d'articles complets, généralement en arrière-plan selon un calendrier prédéterminé. Cette approche risque de consommer une quantité importante de bande passante et de batterie pour télécharger du contenu qui n'est jamais utilisé. Elle doit donc être mise en œuvre avec prudence.
Informations complémentaires
Bien que la prérécupération des données présente de nombreux avantages, une utilisation trop agressive de cette technique risque d'augmenter la décharge de la batterie et l'utilisation de la bande passante, ainsi que le quota de téléchargement, en téléchargeant des données qui ne sont pas utilisées. Il est également important de s'assurer que la prérécupération ne retarde pas le démarrage de l'application pendant que l'application attend la fin de la prérécupération. En pratique, cela peut signifier traiter les données progressivement ou lancer des transferts consécutifs hiérarchisés de manière à ce que les données requises pour le démarrage de l'application soient téléchargées et traitées en premier.
L'agressivité de la prérécupération des données dépend de la taille des données téléchargées et de la probabilité qu'elles soient utilisées. À titre indicatif, sur la base de la machine d'état décrite précédemment, pour les données qui ont 50% de chances d'être utilisées au cours de la session utilisateur actuelle, vous pouvez généralement précharger environ 6 secondes (environ 1 à 2 Mo) avant que le coût potentiel du téléchargement des données inutilisées ne corresponde aux économies potentielles réalisées en ne téléchargeant pas ces données, pour commencer.
En règle générale, il est recommandé de précharger les données de manière à ne devoir lancer un autre téléchargement que toutes les deux à cinq minutes, et de l'ordre de 1 à 5 Mo.
En suivant ce principe, les téléchargements volumineux (comme les fichiers vidéo) doivent être téléchargés par fragments à intervalles réguliers (toutes les deux à cinq minutes), en ne préchargeant que les données vidéo susceptibles d'être visionnées dans les minutes qui suivent.
Une solution consiste à planifier le téléchargement complet uniquement lorsque l'appareil est connecté au Wi-Fi, et éventuellement uniquement lorsqu'il est en charge. L'API WorkManager est parfaitement adaptée à ce cas d'utilisation, car elle vous permet de limiter le travail en arrière-plan jusqu'à ce que l'appareil remplisse les critères spécifiés par le développeur, comme le chargement et la connexion au Wi-Fi.
Vérifier la connectivité avant d'effectuer des requêtes
La recherche d'un signal cellulaire est l'une des opérations les plus énergivores sur un appareil mobile. Pour les requêtes initiées par l'utilisateur, il est recommandé de vérifier d'abord la connexion à l'aide de ConnectivityManager, comme indiqué dans Surveiller l'état de la connectivité et la mesure des connexions.
S'il n'y a pas de réseau, l'application peut économiser la batterie en ne forçant pas la radio mobile à effectuer une recherche. La requête peut ensuite être planifiée et exécutée par lot avec d'autres requêtes lorsqu'une connexion est établie.
Connexions de pool
En plus du traitement par lot et de la prérécupération, vous pouvez également regrouper les connexions réseau de votre application.
Il est généralement plus efficace de réutiliser les connexions réseau existantes que d'en lancer de nouvelles. La réutilisation des connexions permet également au réseau de réagir plus intelligemment aux problèmes de congestion et de données réseau associés.
HttpURLConnection et la plupart des clients HTTP, tels que OkHttp, activent le regroupement de connexions par défaut et réutilisent la même connexion pour plusieurs requêtes.
Récapitulatif et perspectives
Dans cette section, vous avez découvert de nombreuses informations sur la radio sans fil et certaines stratégies que vous pouvez appliquer de manière générale pour offrir une expérience utilisateur rapide et réactive tout en réduisant l'épuisement de la batterie.
Dans la section suivante, nous examinerons en détail trois types d'interactions réseau distincts, courants dans la plupart des applications. Vous découvrirez les moteurs de chacun de ces types, ainsi que les techniques et les API modernes permettant de gérer efficacement ces interactions.