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 de décharge de la batterie les plus importantes de votre application. Pour minimiser la décharge de la batterie associée à l'activité réseau, il est essentiel de comprendre comment votre modèle de connectivité affecte le matériel radio sous-jacent.

Cette section présente la machine à états de la radio sans fil et explique comment le modèle de connectivité de votre application interagit avec elle. Elle propose ensuite plusieurs techniques qui, si elles sont suivies, vous aideront à minimiser l'effet de la consommation de données de votre application sur la batterie.

Machine à états de la radio

La radio sans fil de l'appareil de votre utilisateur est dotée de fonctionnalités d'économie d'énergie intégrées qui permettent de minimiser la quantité d'énergie qu'elle consomme. Lorsqu'elle est entièrement active, la radio sans fil consomme beaucoup d'énergie, mais lorsqu'elle est inactive ou en veille, elle consomme très peu d'énergie.

N'oubliez pas que la radio ne peut pas passer instantanément de l'état de veille à l'état entièrement actif. Une période de latence est associée à l'activation de la radio. La batterie passe donc lentement des états d'énergie plus élevés aux états d'énergie plus faibles afin d'économiser de l'énergie lorsqu'elle n'est pas utilisée, tout en essayant de minimiser la latence associée à l'activation de la radio.

La machine à états d'une radio réseau 3G typique comporte trois états d'énergie :

  • Pleine puissance : utilisée lorsqu'une connexion est active, ce qui permet à l'appareil de transférer des données à son débit maximal.
  • Faible puissance : état intermédiaire qui réduit la consommation d'énergie de la batterie d' environ 50 %.
  • Veille : état de consommation d'énergie minimal pendant lequel aucune connexion réseau n'est active.

Bien que les états de faible puissance et de veille consomment beaucoup moins de batterie, ils introduisent également une latence importante dans les requêtes réseau. Le passage de l'état de faible puissance à la pleine puissance 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 à états utilise un délai pour reporter la transition vers des états d'énergie plus faibles. La figure 1 utilise les délais d'AT&T pour une radio 3G typique.


Figure 1. : Machine à états de la radio sans fil 3G typique.

La machine à états de la radio sur chaque appareil, en particulier le délai de transition associé ("temps de queue") et la latence de démarrage, varient en fonction de la technologie de radio sans fil utilisée (3G, LTE, 5G, etc.). Ils sont définis et configurés par le réseau de l'opérateur sur lequel l'appareil fonctionne.

Cette page décrit une machine à états représentative pour une radio sans fil 3G typique, basée sur les données fournies par AT&T. Toutefois, les principes généraux et les bonnes pratiques qui en résultent s'appliquent à toutes les implémentations de radio sans fil.

Cette approche est particulièrement efficace pour la navigation Web mobile typique, car elle évite toute latence indésirable pendant que les utilisateurs naviguent sur le Web. Le temps de queue relativement faible garantit également qu'une fois une 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 smartphones modernes tels qu'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 privilégiée).

Impact des applications sur la machine à états de la 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 à états de la radio 3G typique décrite précédemment, elle restera à pleine puissance pendant toute la durée de votre transfert, plus 5 secondes supplémentaires de temps de queue, suivies de 12 secondes à l'état de faible énergie. Ainsi, pour un appareil 3G typique, chaque session de transfert de données entraînera une consommation d'énergie de 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, maintiendra la radio sans fil active en permanence, en la ramenant à pleine puissance juste au moment où elle passe en mode veille.


Figure 2. Utilisation relative de la puissance de la radio sans fil pour un transfert d'une seconde exécuté trois fois par minute. La figure exclut la latence d'activation 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 par minute, la radio resterait à pleine puissance pendant seulement 20 secondes par minute. Cela permettrait à la radio d'être en veille pendant 40 secondes par minute, ce qui entraînerait une réduction significative de la consommation de la batterie.


Figure 3. Utilisation relative de la puissance 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 comment l'accès au réseau affecte l'autonomie de la batterie, parlons de quelques mesures que vous pouvez prendre 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 lots et au regroupement. Consultez la section Optimiser les tâches initié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érecupé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érecupération, lorsque l'utilisateur effectue une action dans votre application, elle anticipe les données qui seront probablement nécessaires pour la prochaine série d'actions de l'utilisateur et les récupère en une seule fois, via une seule connexion, à pleine capacité.

En chargeant vos transferts en amont, vous réduisez le nombre d'activations radio nécessaires pour télécharger les données. Par conséquent, vous préservez non seulement l'autonomie de 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érecupération 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 concret.

Lecteur d'actualités

De nombreuses applications d'actualités tentent de réduire la bande passante en téléchargeant les titres uniquement après la sélection d'une catégorie, les articles complets uniquement lorsque l'utilisateur souhaite les lire et les miniatures uniquement lorsqu'elles apparaissent à l'écran.

Avec cette approche, la radio est obligée de rester active pendant la majeure partie de la session de lecture d'actualités des utilisateurs, car ils font défiler les titres, changent de catégorie et lisent des articles. De plus, le passage constant entre les états d'énergie entraîne une latence importante lors du changement de catégorie ou de la lecture d'articles.

Une meilleure approche consiste à prérecupérer une quantité raisonnable de données au démarrage, en commençant par le premier ensemble de titres et de miniatures d'actualités (ce qui garantit un temps de démarrage à faible latence), puis en continuant avec les titres et miniatures restants, ainsi que le texte de l'article pour chaque article disponible à partir d'au moins la liste des titres principaux.

Une autre solution consiste à prérecupérer tous les titres, miniatures, textes d'articles 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 bande passante et une autonomie de la batterie importantes 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érecupération des données présente de nombreux avantages, une prérecupération trop agressive augmente également le risque de décharge de la batterie et d'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érecupération ne retarde pas le démarrage de l'application pendant qu'elle attend la fin de la prérecupération. En termes pratiques, cela peut signifier le traitement progressif des données ou le lancement de transferts consécutifs prioritaires de sorte que les données requises pour le démarrage de l'application soient téléchargées et traitées en premier.

L'agressivité avec laquelle vous prérecupérez les données dépend de la taille des données téléchargées et de la probabilité qu'elles soient utilisées. En règle générale, en fonction de la machine à états 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érecupérer pendant environ 6 secondes (environ 1 à 2 mégaoctets) avant que le coût potentiel du téléchargement de données inutilisées ne corresponde aux économies potentielles de ne pas télécharger ces données au départ.

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

En suivant ce principe, les téléchargements volumineux, tels que les fichiers vidéo, doivent être téléchargés par blocs à intervalles réguliers (toutes les 2 à 5 minutes), en prérecupérant efficacement uniquement les données vidéo susceptibles d'être visionnées dans les prochaines minutes.

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 prend en charge exactement ce cas d'utilisation, ce qui vous permet de limiter le travail en arrière-plan jusqu'à ce que l'appareil réponde aux critères spécifiés par le développeur, tels que la charge 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 les plus gourmandes en énergie sur un appareil mobile. Une bonne pratique pour les requêtes initiées par l'utilisateur consiste à d'abord vérifier la présence d'une connexion à l'aide de ConnectivityManager, comme indiqué dans Surveiller l'état de la connectivité et la mesure de la connexion. En l'absence de réseau, l'application peut économiser la batterie en n'obligeant 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.

Regrouper les connexions

Une stratégie supplémentaire qui peut vous aider, en plus du traitement par lots et de la prérecupération, consiste à 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 créer de nouvelles. La réutilisation des connexions permet également au réseau de réagir plus intelligemment à la congestion et aux problèmes de données réseau associés.

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

Récapitulatif et perspectives

Dans cette section, vous avez appris beaucoup de choses sur la radio sans fil et sur 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 la décharge de la batterie.

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