Optimiser l'accès au réseau

L'utilisation du signal 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 que vous compreniez comment votre modèle de connectivité affecte 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, permettent de minimiser l'effet de la consommation de données de votre application sur la batterie.

La machine à états radio

La radio sans fil de l'appareil de votre utilisateur dispose de fonctionnalités d'économie d'énergie intégrées qui contribuent à réduire la consommation de la batterie. Lorsqu'elle est complètement active, la radio sans fil consomme une énergie importante, mais lorsqu'elle est inactive ou en veille, elle consomme très peu d'énergie.

Un facteur important à garder à l'esprit est que le signal radio ne peut pas passer de l'état de veille à l'état complètement actif instantanément. Une période de latence est associée à la mise sous tension de la radio. Ainsi, la batterie passe lentement d'un état énergétique supérieur à un état d'énergie inférieur afin de préserver l'énergie lorsqu'elle n'est pas utilisée, tout en essayant de minimiser la latence associée à l'allumage de la radio.

La machine d'état d'un réseau radio 3G classique comporte trois états énergétiques:

  • Pleine puissance: utilisée lorsqu'une connexion est active, ce qui permet à l'appareil de transférer des données à son 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%.
  • Standby (Veille) : état minimal de consommation d'énergie au cours duquel aucune connexion réseau n'est active.

Bien que les états faible et de veille déchargent considérablement moins la batterie, ils engendrent également une latence importante pour les requêtes réseau. Le retour à la pleine puissance depuis l'état faible prend environ 1,5 seconde, et le passage de la mise en veille à la pleine puissance peut prendre plus de deux secondes.

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


Figure 1 : Machine sans fil 3G standard.

L'appareil à états radio de chaque appareil, en particulier le délai de transition ("temps de latence") et la latence de démarrage, varient en fonction de la technologie radio sans fil utilisée (3G, LTE, 5G, etc.). Il est défini et configuré par le réseau de l'opérateur sur lequel fonctionne l'appareil.

Cette page décrit une machine d'état représentative d'une radio sans fil 3G classique, 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 mises en œuvre de radio sans fil.

Cette approche est particulièrement efficace pour la navigation Web mobile classique, car elle évite les latences indésirables lorsque les utilisateurs parcourent le Web. Le temps de latence relativement faible garantit également qu'une fois la session de navigation terminée, le signal 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 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).

L'impact des applications sur la machine à états radio

Chaque fois que vous créez une connexion réseau, le signal radio passe à l'état de pleine puissance. Dans le cas de la machine à états 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 traîne, puis 12 secondes à l'état à faible consommation d'énergie. Ainsi, pour un appareil 3G classique, chaque session de transfert de données entraîne la transmission d'énergie à 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 active de façon permanente, la remettant sur la puissance élevée lorsqu'elle passe en mode veille.


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

En comparaison, si la même application regroupe ses transferts de données en effectuant un seul transfert de trois secondes toutes les minutes, la radio reste à l'état haute puissance pendant un total de 20 secondes toutes les minutes. Cela permettrait à la radio de rester en veille pendant 40 secondes par minute, ce qui se traduisait par une réduction significative de l'utilisation de la batterie.


Figure 3 : Consommation d'énergie radio sans fil relative 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 la durée de vie 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.

Transferts de données groupés

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

Bien entendu, 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 lancés par une 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 section 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 extrait ces données en une seule rafale, sur une seule connexion, à pleine capacité.

En procédant au chargement anticipé de vos transferts, 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, 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, qui est due à 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'une fois qu'une catégorie a été sélectionnée, des articles complets uniquement lorsque l'utilisateur souhaite les lire et des vignettes lorsqu'elles font défiler l'écran pour les afficher.

Avec cette approche, la radio est forcée de rester active pendant la majorité des sessions de lecture d'actualités des utilisateurs, lorsqu'ils font défiler les titres, changent de catégorie et lisent des articles. En outre, le basculement 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écharger une quantité raisonnable de données au démarrage, en commençant par le premier ensemble de titres et de miniatures (ce qui garantit un temps de démarrage à faible latence), puis avec les titres et miniatures restants, ainsi que le texte de chaque article disponible au moins dans la liste des titres principaux.

Une autre alternative consiste à précharger chaque titre, miniature, texte d'article et éventuellement même images d'articles complets, généralement en arrière-plan selon un calendrier prédéterminé. Cette approche risque de gaspiller une bande passante et une autonomie importantes pour le téléchargement de contenus qui n'ont jamais été utilisés. Vous devez donc l'implémenter avec prudence.

Facteurs supplémentaires

Bien que le préchargement des données présente de nombreux avantages, son utilisation trop agressive présente également un risque d'augmentation de la décharge de la batterie, de l'utilisation de la bande passante, ainsi que du quota de téléchargement, en téléchargeant des données inutilisées. Il est également important de s'assurer que le préchargement ne retarde pas le démarrage de l'application tant qu'il attend la fin du préchargement. En pratique, cela peut signifier traiter les données progressivement ou lancer des transferts consécutifs priorisés 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é 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 d'état 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 précharger pendant environ 6 secondes (environ 1 à 2 mégaoctets) avant que le coût potentiel du téléchargement des données inutilisées ne corresponde aux économies potentielles si vous ne les téléchargez pas.

En règle générale, il est recommandé de précharger les données de sorte que vous n'ayez besoin de lancer un nouveau téléchargement que toutes les 2 à 5 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 à intervalles réguliers (toutes les 2 à 5 minutes), en préchargeant ainsi uniquement les données vidéo susceptibles d'être visualisées au cours des prochaines minutes.

Une solution consiste à programmer le téléchargement complet uniquement lorsque vous êtes connecté au Wi-Fi, et éventuellement uniquement lorsque l'appareil est en charge. L'API WorkManager prend en charge exactement 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 charge et la connexion au Wi-Fi.

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

La recherche d'un signal de réseau mobile est l'une des opérations les plus gourmandes en é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 de la connexion. En l'absence de réseau, l'application peut économiser la batterie en ne forçant pas la radio mobile à effectuer la recherche. La requête peut ensuite être planifiée et exécutée en lot avec d'autres requêtes lorsqu'une connexion est établie.

Connexions de pool

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 créer de nouvelles. La réutilisation des connexions permet également au réseau de réagir plus intelligemment à l'encombrement 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 perspectives

Dans cette section, vous avez beaucoup appris sur la radio sans fil et sur 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 pilotes de chacun de ces types, ainsi que les techniques et API modernes permettant de gérer efficacement ces interactions.