Profilez et optimisez la consommation d’énergie de votre app

Bonjour tout le monde ! Je m’appelle Wiam et je suis ingénieure logiciel chez Apple. Je vais vous parler d’optimisation énergétique.

Offrir des expériences d’app de grande qualité est ce que vous faites le mieux. Les utilisateurs aiment les apps sur lesquelles ils peuvent compter et l’autonomie est un élément crucial de cette fiabilité. Une app économe en énergie signifie une utilisation plus longue et une satisfaction accrue. Tandis qu’une app trop gourmande en énergie peut rapidement gâcher cette expérience positive. Et si je vous disais qu’il existe un outil permettant de créer des apps à la fois puissantes et incroyablement économes en énergie ? Je vais vous expliquer comment exploiter les capacités de cet outil pour résoudre les problèmes d’énergie. Mais voyons d’abord les sujets que nous allons aborder aujourd’hui. Je vais commencer par les problèmes que vous pouvez facilement reproduire au bureau. J’expliquerai comment identifier et réduire une consommation excessive d’énergie dans un exemple.

Nous aborderons ensuite des scénarios réels plus complexes, qui sont plus difficiles à cerner. Nous verrons comment recueillir des données dans n’importe quel environnement.

Ensuite, je montrerai comment comparer la consommation d’énergie de différentes implémentations. Vous aurez ainsi un moyen clair de mesurer et d’améliorer l’efficacité de votre app.

Enfin, nous verrons comment détecter les problèmes d’énergie dès le début du développement et proposer une version hautement optimisée de votre app.

Vous avez peut-être détecté une consommation d’énergie élevée dans Xcode, qui suggère un problème, sans en trouver la cause. Vous avez alors besoin de reproduire le problème et d’enregistrer des mesures de consommation d’énergie.

Power Profiler d’Instruments est l’outil parfait pour cela. Il permet d’établir le profil de votre app et d’enregistrer un tracé de consommation, qui peut ensuite être affiché dans Instruments. C’est exactement le problème que j’essaie de résoudre dans mon app. Je travaille sur Destination Video, une app de streaming permettant de visionner du contenu sur iPhone et iPad. J’ai ajouté un volet Bibliothèque pour parcourir facilement toute la collection de vidéos. Le rapport énergétique de Xcode Organizer présente une augmentation significative de l’utilisation du CPU par rapport à avant. Résultat : les performances et l’autonomie de la batterie sont réduites. Utilisons Power Profiler dans Instruments pour étudier cette régression. D’abord, j’ouvre le projet Xcode et j’établis une connexion sans fil avec mon iPhone. Ensuite, je vais dans Product et je clique sur Profile. Cela crée et installe l’app sur mon appareil et ouvre Instruments. Je sélectionne le modèle vierge, puis Power Profiler et CPU Profiler pour recueillir aussi des informations sur l’utilisation du CPU. Vous pouvez choisir d’autres instruments selon vos besoins. Je conserve les paramètres par défaut et je commence l’enregistrement.

Je vais maintenant passer sur l’appareil et ouvrir ce volet Bibliothèque.

Je remarque un blocage à l’ouverture de ce volet, probablement lié au problème que j’étudie. Je vais arrêter d’enregistrer et examiner le tracé. Pour me concentrer sur l’enregistrement, j’appuie sur Commande + Contrôle + Z. Je développe la piste Power Profiler en cliquant sur le triangle d’expansion à sa gauche. Power Profiler indique les mesures de consommation d’énergie au niveau du système et par app. La première piste est la consommation d’énergie du système qui présente l’ensemble de la consommation d’énergie. Plus la valeur est élevée, plus la consommation de votre app risque d’être élevée. Vous pouvez sélectionner une région et inspecter la valeur moyenne dans le volet de synthèse. Après avoir sélectionné une zone du tracé, le volet de synthèse indique 10,5 %/heure. Passons aux mesures de l’impact sur la consommation de mon app. Je peux examiner différentes mesures liées à différents sous-systèmes : l’impact sur la consommation du CPU, du GPU, de l’écran et du réseau. La piste sur la consommation du CPU est essentielle, car une activité élevée est un facteur majeur de consommation d’énergie. Une utilisation soutenue ou intense du CPU augmente directement la consommation. Je vois un pic d’impact sur la consommation du CPU juste après que j’ai essayé d’ouvrir le volet Bibliothèque. Je souligne la région précédente pour déterminer la valeur moyenne de l’impact sur la consommation du CPU. La valeur moyenne est de 1. Maintenant, je vais mettre en évidence le pic. L’impact moyen de la consommation du CPU est de 21, ce qui est nettement supérieur à sa précédente valeur. Ce score vous permet d’identifier les pics de consommation inattendus et de déboguer en priorité le sous-système ayant le plus gros impact.

Time Profiler aide à identifier la source de cette surcharge du CPU en identifiant les fonctions qui consomment le plus de temps CPU. Je clique sur CPU Profiler. Pour concentrer l’analyse sur le code spécifique, je regarde la vue Call Tree et sélectionne "Hide System Libraries". Dans le volet Heaviest Stack Trace, Instruments indique qu’un temps important est consacré à VideoCardView. Le corps de cette vue étant relativement simple, le problème vient certainement de la fréquence à laquelle il est appelé. Cela signifie que je vais maintenant vérifier la LibraryThumbnailView. C’est elle qui crée toutes ces vignettes vidéo dans le volet Bibliothèque. Le problème vient très probablement de là. Je vais revenir à Xcode pour analyser le code dans cette vue.

Le code est utilisé par itération dans l’ensemble des vidéos. Pour chaque vidéo, il génère une VideoCardView qui crée sa vignette et crée une vue pour l’afficher. Toutes ces vues sont ensuite placées à l’intérieur d’une VStack. Imaginons maintenant qu’il y ait des centaines, voire des milliers de vidéos. Cette approche oblige l’app à charger chaque vignette et à créer chaque vue quand le volet Bibliothèque devient visible, qu’elles s’affichent à l’écran ou non. Cela est inefficace et explique l’utilisation élevée du CPU, découverte dans Instruments. L’app travaille trop pour charger un contenu qui n’est même pas encore nécessaire. Heureusement, SwiftUI nous offre une excellente API pour régler cela : LazyVStack. Elle crée et affiche uniquement les vues des éléments actuellement visibles ou sur le point de défiler. L’optimisation est donc simple. Je vais remplacer l’utilisation de VStack par LazyVStack. Je lui fournirai le même éventail de vidéos, mais la vue elle-même gère intelligemment la création et la destruction des vues d’éléments à mesure que je fais défiler. Je vais maintenant tester cette optimisation. Je clique à nouveau sur Profile et je commence à enregistrer. Ensuite, sur mon appareil, j’ouvre le volet Bibliothèque.

Mon app est désormais réactive, elle ne se bloque plus. J’arrête l’enregistrement et consulte la piste Impact sur la consommation du CPU.

Je vais mettre en évidence la même région pour pouvoir déterminer la valeur moyenne. Elle indique désormais une moyenne plus petite : 4,3 au lieu de 21 auparavant. Cela résout la régression du CPU. Le chargement de toutes les vignettes vidéo à l’avance dans le volet Bibliothèque a été identifié comme la cause d’une consommation d’énergie inutile. Instruments a aidé à identifier le code inefficace, et le passage au chargement à la demande rend la fonctionnalité beaucoup plus performante. Pour mieux comprendre les techniques de profilage et d’optimisation du CPU, je vous conseille vivement de regarder « Optimize CPU performance with Instruments ». Power Profiler fournit de précieuses informations sur la consommation d’énergie de votre app. Utilisez-le dès que vous suspectez un problème et ne savez pas sur quel sous-système vous concentrer ni quoi optimiser. Jusqu’à présent, j’ai établi le profil avec mon iPhone connecté à Xcode. C’est idéal pour les tests contrôlés, mais cela ne donne pas toujours une vue d’ensemble. Comment régler les problèmes qui ne se produisent qu’en conditions réelles ? Ceux qui sont impossibles à reproduire systématiquement dans votre bureau ? Peut-être êtes-vous confronté à des scénarios tels que : Comment votre app se comporte-t-elle réellement pendant la navigation avec CarPlay ? Ou quelle énergie consomme votre fonctionnalité de réalité augmentée en extérieur ? Comment déboguer l’utilisation de la batterie en arrière-plan qui met des heures à s’afficher ? Comment votre équipe qualité peut-elle fournir facilement des diagnostics énergétiques exploitables à partir de tests sur le terrain ? Pour résoudre ces problèmes, j’ai besoin d’un moyen de recueillir des données à partir d’une utilisation réelle, sans connexion directe à Xcode. Power Profiler est également disponible sur l’appareil, ce qui permet d’identifier les problèmes impossibles à reproduire en phase de développement. Prenons un exemple concret. Un collègue a signalé de gros problèmes d’autonomie de batterie : sur son appareil, mon app Destination Video est systématiquement en tête de la consommation de batterie. J’ai tout essayé, mais je n’ai pas pu reproduire cela avec ma configuration. Comme chacun utilise les apps différemment, c’est peut-être un cas limité encore inconnu. Grâce au profilage de la consommation sur l’appareil, plus besoin d’emprunter son appareil. Je lui ai demandé d’effectuer un suivi avec ce nouveau mode et de m’envoyer le fichier. Je vais vous montrer comme c’est facile de collecter ces données. Activez d’abord le mode développeur dans l’app Réglages, qui est disponible après avoir connecté votre appareil à Xcode. Accédez ensuite à Performance Trace dans les réglages du développeur. Une fois Performance Trace activé, vous pouvez activer Power Profiler. Assurez-vous que cette option est activée. Ensuite, vous devez spécifier l’app que vous souhaitez profiler. Seules les apps installées par Xcode, TestFlight ou via le programme d’entreprise peuvent être surveillées. Sélectionnez votre app dans la liste. Parfait ! Maintenant, commençons la collecte des données. Balayez vers le bas depuis l’angle supérieur droit de votre appareil pour accéder au Centre de contrôle. L’icône de Performance Trace permet de lancer la collecte de données. Touchez cette icône une fois que vous l’avez ajoutée pour commencer l’enregistrement. Laissez l’outil fonctionner quelques heures ou jusqu’à la reproduction de votre problème. Maintenant, arrêtez la collecte. Touchez à nouveau l’icône de Performance Trace dans le centre de contrôle. Cela génère un fichier de suivi avec toutes les mesures de consommation collectées, que vous pouvez partager avec votre Mac et ouvrir dans Instruments. C’est tout ! C’est ce qu’a fait mon collègue, et je vais maintenant vous montrer comment analyser le fichier pour identifier la cause source. J’ouvre le fichier avec Instruments. Grâce au relevé, vous avez accès aux mesures de la consommation au niveau du système, de la consommation par app et à Time Profiler. Dans ce mode, Time Profiler a une fréquence d’échantillonnage plus faible pour réduire l’effet d’observateur. La piste d’impact de la consommation du CPU révèle un schéma clair, avec des zones d’impact élevé du CPU suivies de périodes de faible impact, se répétant périodiquement. Ce n’est pas du tout ce que j’attendais de l’app Destination Video. Zoomons sur une zone à impact élevé pour comprendre ce qui provoque cette consommation d’énergie. Je vérifie Time Profiler pour avoir une idée des fonctions qui s’exécutent pendant cette période. En tête de liste, videoSuggestionsForLocation consomme beaucoup de temps CPU. Cette fonctionnalité recommande des vidéos selon la localisation, sur des points d’intérêt ou des évènements à proximité, et est appelée à chaque changement de localisation. Ça explique pourquoi je n’ai pas pu reproduire le problème ! Comme je reste au bureau, ma localisation ne change pas vraiment. La fonctionnalité peut s’exécuter une fois au démarrage de l’app, puis patiente. Mais mon collègue utilise l’app dans les transports : il se déplace tout le temps ! Les changements répétés de localisation déclenchaient sans arrêt le lourd processus de filtrage. Je vais rapidement passer à l’app Destination Video elle-même.

Cette fonctionnalité s’affiche dans la sous-fenêtre Nearby Suggestions. C’est là que s’affichent les recommandations basées sur la localisation, alimentées par cette fonction. Je sais maintenant quelle fonction pose problème. Je vais entrer dans le code et tâcher de l’optimiser. videoSuggestionsForLocation est appelée chaque fois que ma position change. Elle est chargée de générer une liste de vidéos pertinentes à afficher. Actuellement, chaque fois qu’elle est appelée, elle lit ce fichier RecommendationRules dans un objet Data, puis utilise JSONDecoder pour l’analyser dans la carte RecommendationRule. Et ce fichier JSON n’est pas petit : il contient des centaines de règles complexes. Le traitement des fichiers (E/S) et l’analyse JSON sont des opérations gourmandes en ressources ! L’app répète ce travail intensif, encore et encore, à chaque changement de localisation. C’est clairement la source du problème. Les règles elles-mêmes ne changent pas pendant que l’app est en cours d’exécution. L’optimisation consiste donc à charger et à analyser les règles une seule fois, et à les mettre en cache. Ce simple changement réduira le travail nécessaire à chaque changement de localisation. Je demanderai au même collègue de retester mon app une fois que je l’aurai optimisée. Quand vous effectuez une correction de ce type, demandez à quelqu’un de la tester dans les mêmes conditions et étudiez le nouveau tracé de consommation. C’est le moyen idéal pour vérifier que vous avez résolu le problème d’origine, sans générer accidentellement un nouveau problème de consommation d’énergie ! Cela vous aide vraiment à boucler la boucle et à valider vos optimisations.

Je vous ai expliqué comment identifier les problèmes existants. Mais comment être sûr de choisir la bonne stratégie d’optimisation ? Une optimisation implique parfois un compromis : moins d’utilisation du CPU, mais peut-être un peu plus d’activité réseau. Comment s’assurer des conséquences sur l’autonomie de la batterie ? Voici un scénario courant : vous développez une nouvelle fonctionnalité. Vous avez votre implémentation, je l’appellerai l’approche 1. Elle est simple, semble efficace quand vous la testez avec de petits volumes de données. Et puis, votre collègue propose l’approche 2. C’est une architecture différente, peut-être un peu plus complexe ou plus lente sur ces petits ensembles de données, mais conçue pour gérer de gros volumes de données de façon plus fluide. Vous faites face à un dilemme : quelle approche préserve le mieux l’autonomie de la batterie ? Difficile de trancher en vous basant uniquement sur des tests locaux ou l’examen du code. Vos tests locaux peuvent ne pas être représentatifs des tailles de données typiques rencontrées, de l’impact des conditions réseau et de l’activité en arrière-plan sur les performances. D’où l’intérêt de Power Profiler, en particulier pour comparer l’impact. Vous pouvez profiler votre app avec une approche et recommencer avec la seconde pour les comparer. Gardez à l’esprit que des conditions telles que la température, l’état de l’appareil ou la pression du système peuvent impacter la consommation réelle. Cela inclut également l’état de votre app, comme la quantité de données qu’elle gère ou les fonctionnalités activées. Pour tenir compte de ces variables, vous pouvez enregistrer plusieurs exécutions de chaque approche dans diverses conditions et faire la moyenne des résultats, puis utiliser ces données pour prendre des décisions éclairées sur les fonctionnalités et les implémentations, afin d’optimiser votre app. Power Profiler n’est qu’un des nombreux outils à votre disposition. Pendant que vous codez, obtenez un retour instantané avec les jauges d’énergie Xcode et approfondissez avec Instruments. Détectez rapidement les problèmes avec les XCTests automatisés. Après publication, surveillez l’impact sur le terrain avec Xcode Organizer, MetricKit et l’API App Store Connect. Ces outils sont vos alliés dans la lutte pour l’efficacité énergétique : ils fournissent un contexte et des informations précieux. En les utilisant efficacement, vous pouvez intégrer une stratégie d’efficacité énergétique solide dans votre processus de développement. Vous avez maintenant tous les outils nécessaires pour concevoir des apps économes en énergie. Utilisez Power Profiler tôt et souvent, laissez les données guider vos décisions et itérez en fonction de ce que vous apprenez. Voici un défi : lancez un tracé pour votre app dès maintenant et examinez les données qui en résultent ! C’est une façon amusante de mettre en pratique vos nouvelles compétences. Voilà, c’est tout pour mes astuces d’optimisation énergétique ! Merci de votre attention !