Optimiser l'accès au réseau

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 que vous compreniez l'impact de votre modèle de connectivité sur le matériel radio sous-jacent.

Cette section présente la machine à états 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, aideront à minimiser l'effet de la consommation de données de votre application sur la batterie.

La machine à états radio

Le signal 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 quantité d'énergie consommée par la batterie. Lorsqu'elle est entièrement active, le signal radio sans fil consomme beaucoup d'énergie, mais lorsqu'il est inactif ou en veille, il consomme très peu d'énergie.

Un facteur important à retenir est que la radio ne peut pas passer instantanément de l'état de veille à l'activation complète. Il existe une période de latence associée à la « mise sous tension » du signal radio. Ainsi, la batterie passe lentement d'un état à énergie supérieure à un état d'énergie plus 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 à états d'une radio de réseau 3G classique comporte trois états d'énergie:

  • 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 d'énergie: état intermédiaire qui réduit la consommation d'énergie de la batterie d'environ 50%.
  • Veille: état minimal de consommation d'énergie pendant lequel aucune connexion réseau n'est active.

Bien que les états faible et de veille déchargent considérablement la batterie, ils entraînent également une latence importante pour les requêtes réseau. Le rétablissement de la pleine puissance après l'état faible prend environ 1, 5 seconde.Le passage de la veille à la pleine puissance peut prendre plus de deux secondes.

Pour minimiser la latence, la machine à états utilise un délai pour reporter la transition vers des états d'énergie inférieurs. La figure 1 utilise les codes temporels d'AT&T pour une radio 3G classique.


Figure 1 : Machine à états radio sans fil 3G standard.

La machine à états radio de chaque appareil, en particulier le délai de transition ("tail time") et la latence de démarrage associés, 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 pour une radio sans fil 3G standard, d'après les données fournies par AT&T. Cependant, les principes généraux et les bonnes pratiques qui en résultent sont applicables à toutes les implémentations de radio sans fil.

Cette approche est particulièrement efficace pour la navigation Web mobile classique, car elle évite une latence indésirable lorsque les utilisateurs naviguent sur le Web. Ce délai relativement faible garantit également qu'une fois la session de navigation terminée, la radio peut passer à un état d'énergie plus faible.

Malheureusement, cette approche peut entraîner des applications inefficaces sur les systèmes d'exploitation de smartphone modernes tels qu'Android, où les applications s'exécutent 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 à états radio

Chaque fois que vous créez une nouvelle connexion réseau, le signal radio passe à l'état de pleine puissance. Dans le cas d'une machine à état radio 3G standard décrit précédemment, elle restera à pleine puissance pendant toute la durée du transfert, plus un temps de queue supplémentaire de cinq secondes, suivi de 12 secondes en mode basse consommation. Ainsi, pour un appareil 3G standard, chaque session de transfert de données entraîne la consommation d'énergie par le 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 le signal radio sans fil actif de manière permanente, en la ramenant à une puissance élevée lorsqu'elle passe en mode veille.


Figure 2 : Consommation relative de la puissance radio sans fil pour un transfert d'une seconde exécuté trois fois par minute. La figure n'exclut pas la latence de recharge entre les exécutions.

En comparaison, si la même application regroupe ses transferts de données, en exécutant un seul transfert de trois secondes toutes les minutes, le signal radio reste à l'état consommant beaucoup d'énergie pendant un total de seulement 20 secondes par minute. La radio serait ainsi en veille pendant 40 secondes par minute, ce qui réduirait considérablement l'utilisation de la batterie.


Figure 3 : Consommation relative de la puissance radio sans fil pour les transferts de trois secondes exécutés toutes les minutes.

Techniques d'optimisation

Maintenant que vous comprenez comment l'accès au réseau affecte l'autonomie de la batterie, abordons quelques mesures que vous pouvez prendre pour contribuer à réduire la décharge de la batterie, tout en offrant une expérience utilisateur rapide et fluide.

Transferts de données groupées

Comme indiqué dans la section précédente, l'un des meilleurs moyens d'améliorer l'efficacité de la batterie est de regrouper vos transferts de données afin de transférer moins de données.

Bien sûr, ce 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. Pour y remédier, vous pouvez anticiper et précharger 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 et initiés par l'application, se prêtent très bien au traitement par lot et au regroupement. Pour obtenir des conseils sur la planification des transferts réseau en arrière-plan, consultez la page Optimiser les tâches déclenchées par l'application.

Précharger les données

Le préchargement 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 le préchargement, lorsque l'utilisateur effectue une action dans votre application, celle-ci anticipe les données les plus susceptibles d'être nécessaires pour la prochaine série d'actions utilisateur et les récupère en une seule rafale, via une seule connexion, à pleine capacité.

En chargeant vos transferts de manière anticipée, vous réduisez le nombre d'activations radio nécessaires pour télécharger les données. Ainsi, non seulement vous préservez l'autonomie de la batterie, mais vous améliorez également la latence, réduisez la bande passante requise et les temps de téléchargement.

Le préchargement améliore également l'expérience utilisateur en minimisant la latence dans l'application 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 pratique.

Un lecteur 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 avoir sélectionné une catégorie, des articles complets uniquement lorsque l'utilisateur souhaite les lire et des miniatures à mesure qu'elles font défiler la page.

Avec cette approche, la radio doit rester active pendant la session de lecture d'actualités de la majorité des utilisateurs lorsqu'ils font défiler les titres, changent de catégorie et lisent des articles. De plus, le basculement constant entre les états de l'énergie 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 d'actualités et de vignettes (afin d'assurer un temps de démarrage à faible latence), puis en continuant avec les titres et miniatures restants, ainsi que le texte de chaque article disponible au moins dans la liste principale des titres.

Une autre solution consiste à précharger tous les titres, toutes les vignettes, le texte des articles et éventuellement des images d'articles complets, généralement en arrière-plan selon un calendrier prédéfini. Cette approche risque de dépenser une quantité importante de bande passante et d'autonomie de la batterie pour télécharger du contenu qui n'est jamais utilisé. Elle doit donc être mise en œuvre avec prudence.

Facteurs supplémentaires

Bien que le préchargement des données présente de nombreux avantages, une utilisation trop agressive du préchargement présente également un risque d'augmentation de la décharge de la batterie et de l'utilisation de la bande passante (ainsi que du 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 le préchargement ne retarde pas le démarrage de l'application pendant que celle-ci attend la fin du préchargement. En pratique, cela peut signifier traiter les données progressivement ou lancer des transferts consécutifs, de sorte que les données requises pour le démarrage de l'application soient d'abord téléchargées et traitées.

Le niveau d'agressivité du préchargement 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, d'après la machine à états décrite précédemment, pour les données qui ont 50% de chances d'être utilisées dans la session utilisateur en cours, vous pouvez généralement effectuer un préchargement pendant environ 6 secondes (environ 1 à 2 mégaoctets) avant que le coût potentiel du téléchargement de données inutilisées corresponde aux économies que vous pourriez réaliser si vous ne téléchargez pas ces données.

En règle générale, il est recommandé de précharger les données de sorte que vous n'ayez à lancer un autre téléchargement que toutes les deux à cinq minutes, de l'ordre de 1 à 5 mégaoctets.

Conformément à ce principe, les téléchargements volumineux, tels que les fichiers vidéo, doivent être téléchargés en fragments et à intervalles réguliers (toutes les deux à cinq minutes), en préchargeant uniquement les données vidéo susceptibles d'être vues dans les minutes suivantes.

Une solution consiste à planifier le téléchargement complet uniquement lorsque l'appareil est connecté au Wi-Fi, et éventuellement lorsque l'appareil est en charge. L'API WorkManager prend exactement en charge ce cas d'utilisation, ce qui vous permet de limiter les tâches en arrière-plan jusqu'à ce que l'appareil réponde aux critères spécifiés par le développeur, tels que la recharge et la connexion au Wi-Fi.

Vérifier la connectivité avant d'envoyer des requêtes

La recherche d'un signal cellulaire est l'une des opérations qui consomment le plus d'énergie sur un appareil mobile. Une bonne pratique pour les requêtes déclenchées par l'utilisateur consiste à vérifier d'abord une connexion à l'aide de ConnectivityManager, comme indiqué dans la section Surveiller l'état de la connectivité et la mesure des connexions. En l'absence 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 programmée et exécutée de manière groupée avec d'autres requêtes lorsqu'une connexion est établie.

Connexions de pools

Une stratégie supplémentaire qui peut être utile en plus du traitement par lot et du préchargement consiste à regrouper les connexions réseau de votre application.

Il est généralement plus efficace de réutiliser des connexions réseau existantes que d'en établir de nouvelles. La réutilisation des connexions permet également au réseau de réagir plus intelligemment aux encombrements et aux problèmes de données réseau associés.

HttpURLConnection et la plupart des clients HTTP, tels que OkHttp, activent le pooling de connexions par défaut et réutilisent la même connexion pour plusieurs requêtes.

Récapitulatif et prévisions

Dans cette section, vous avez beaucoup appris sur la radio sans fil et certaines stratégies que vous pouvez appliquer à grande échelle pour offrir une expérience utilisateur rapide et réactive tout en réduisant la décharge de la batterie.

Dans la section suivante, nous examinerons en détail trois types distincts d'interactions réseau communes à la plupart des applications. Vous découvrirez les moteurs de chacun de ces types, ainsi que des techniques et des API modernes permettant de gérer efficacement ces interactions.