Catégorie : Zone technique

La « digitalisation » des entreprises et particulièrement l’offre de plus en plus importante d’applications numériques, rendent le critère de qualité des applications mobiles de plus en plus nécessaire. La performance est dans ce cadre un critère de contrôle obligatoire. Sans cela, les risques sont nombreux pour les concepteurs d’applications : désinstallations, taux d’attrition en hausse, échec de projet, chiffre d’affaires en baisse…

Mais le fait de tester la performance des applications mobiles n’est pas aussi simple que de tester une application classique comme en avait l’habitude les équipes des DSI. En effet de plus en plus, les applications mobiles sont d’une part exécutées dans un environnement contraint (en termes de batterie, ressources…) et d’autre part, elles intègrent des services tiers qui sont complexes à maîtriser. Au final, avec des serveurs répondant en moins de 200ms, on arrive très souvent à des temps de réponses des applications malheureusement supérieurs à 3s.

Pour répondre à ce problème, il est important de bien comprendre les méthodes utilisées par les outils de ce marché en constante évolution.

Outils de monitoring vs outils de développement

Tester la performance de son application reste possible et accessible, surtout avec les SDK et les IDE de développement (Xcode, Android Studio…). Pour aller plus loin, de nombreuses solutions sont disponibles en open source. Cependant, cette approche nécessite de lancer des tests manuels sur son téléphone.

Avantages :

• Mesure de la performance pendant le développement
• Analyse détaillée possible dès détection d’un problème

Inconvénients :

• Mesure assez aléatoire et pas forcément reproductible
• Nécessite un smartphone de test à disposition

Les outils de monitoring permettent d’industrialiser la démarche de mesure de la performance en se basant sur des agents qui prennent la place du développeur.

Outils de monitoring synthétique vs outil de monitoring en usage réel (Real User Monitoring)

Les outils de monitoring synthétique sont des outils qui testent la performance des solutions dans des cas d’usages proches de ceux d’un utilisateur. Pour cela, des agents extérieurs stimulent l’application dans un environnement soit simulé soit réel (Emulateurs ou fermes de devices). L’avantage de cette solution est de surveiller la performance en continu. Cette approche s’applique même avant la mise en production de la solution ou avant que les utilisateurs finaux soient présents.

Avantages :

• Remontée de la performance avant la mise en production

• Mesure en continue pour l’identification des problèmes

Inconvénients :

• Simulation pas nécessairement représentative de l’usage réel de l’application par les utilisateurs finaux

• Nécessité d’utiliser des devices en continu pour faire tourner le monitoring

Les outils RUM remontent la performance réelle des utilisateurs. Cela nécessite l’intégration d’un agent dans l’application. Cette intégration permet la remontée d’autres métriques : parcours utilisateur, usages de l’application…

Avantage :

• Vision réelle de la performance des applications

Inconvénients :

• Impact de l’agent sur la performance de l’application

• Détection trop tardive des problèmes

• Trop d’informations lors de l’analyse des problèmes

Tests techniques vs tests fonctionnels pour les outils de monitoring

La simulation de l’application dans les outils de monitoring nécessite des tests automatiques. La solution la plus simple à mettre en œuvre repose sur les tests techniques : Lancement de l’application, ouverture de pages…

Avantages :

• Mise en œuvre immédiate

• Tests standards permettent d’identifier facilement des problèmes ou de se comparer avec des applications concurrentes

Inconvénient :

• Tests pas forcément adaptés aux spécificités et au fonctionnel de l’application

• Certains outils proposent d’effectuer des tests fonctionnels pour suivre la consommation. Le parcours utilisateur est alors simulé ou réellement effectué. Cela nécessite de scripter les actions de l’utilisateur. Généralement les outils se basent sur des technologies de script standardisés.

Avantages :

• Simulation proche du parcours réel de l’utilisateur

• Mutualisation des tests développés pour d’autres usages (tests fonctionnels par exemple)

Inconvénient :

• Nécessité de développer les tests automatiques au préalable

NB : Des outils permettent de simuler une suite de requête vers les serveurs. Cette pratique issue des technologies serveurs (par exemple Jmeter) permet de tester plus la partie serveur mais est peu adaptée à la mobilité. En effet, elle ne permet pas de prendre en compte la complexité des plateformes mobiles.

Environnement émulé ou physique

Les environnements émulés (ou virtuels) sont identiques aux émulateurs de développement.

Avantage :

• Mise en place assez rapide

Inconvénient :

• Performance ne correspondant pas à des devices réels

Les environnements réels sont des téléphones mis à disposition par les outils de monitoring.

Avantage :

• Performance identique aux devices réels

Inconvénients :

• Coûts plus importants
• Difficulté d’être représentatif de l’ensemble des devices des utilisateurs.

Les conseils des experts GREENSPECTOR

La clé est de détecter au plus tôt les problèmes de performance avant qu’ils n’affectent vos utilisateurs finaux. Il est donc nécessaire d’utiliser des outils de monitoring synthétique. Les outils de développement permettront de compléter l’analyse des problèmes de performance. Afin d’être représentatif de l’usage final de l’application, il sera nécessaire de mettre en place la bonne stratégie : tests fonctionnels à minima, exécution sur un échantillon représentatif de devices réels d’utilisateurs, simulation de différentes conditions de communication… Les outils RUM permettront de confirmer et compléter les hypothèses.

Les utilisateurs de GREENSPECTOR ont la possibilité d’appliquer cette stratégie via différents modules :

• Monitoring synthétique via le benchmark runner sur les devices réels du Power Test Cloud
• Intégration de la mesure de performance dans les tests fonctionnels existants
• Débuggage des problèmes via les tests exploratoires avec le Free Runner Test
• Monitoring en continu lors du build ou du run

Olivier PHILIPPOT

Expert Sobriété Numérique
Auteur des livres «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels

L’automatisation des tests est bien souvent considérée comme un surcoût au sein des équipes de développement, et cela pour différentes raisons :

Nécéssite une montée en compétence des équipes sur un outil en particulier

Les temps de rédaction sont plus importants que les temps d’éxécution manuels

Nécéssite un maintien des tests sur la durée

…

Le développement mobile comprenant des coûts projets plus faibles et des temps de développement raccourcis n’aide pas au passage à l’automatisation des tests. Les bénéfices ne sont en effet pas forcément bien évalués vis-à-vis du coût de l’automatisation. Au final, les projets d’automatisation des applications mobiles passent souvent à la trappe ou sont décalés trop tard dans le projet. C’est une erreur car les bénéfices de l’automatisation des tests pour les applications mobiles sont nombreux.

Les applications mobiles sont des applications comme les autres : complexes, techniques…

Les applications mobiles sont considérées comme des applications nécessitant peu de développement, des coûts faibles… Or ce n’est pas toujours le cas. Nous ne sommes plus dans la même situation des dernières années où les projets d’applications mobiles étaient des Proofs Of Concept et autres balbutiements. Les applications mobiles ont maintenant subi l’entropie naturelle de tout projet logiciel : contraintes de sécurité renforcées, librairies et SDK intégrées, architectures modulaires, intéractions multiples avec des serveurs backend…

Cette maturité (mélée à l’entropie des logiciels) ne permet plus de laisser de côté les tests. Une industrialisation des tests, et en particulier l’automatisation, permet d’assurer une qualité nécessaire aux projets mobiles. Sans cela, c’est un échec assuré.

L’échec n’est plus envisageable

Associées à cette complexification des projets mobiles, les applications sont devenues des projets critiques pour les entreprises. En effet, elles sont les nouvelles vitrines des marques et des organisations. Et compte-tenu des cycles de développement rapides, un échec du projet (retards, détection trop tardive de bugs utilisateurs…) peut être fatal à l’image de l’entreprise. D’autant plus qu’une mauvaise expérience vécue par l’utilisateur peut amener tout simplement à la désinstallation, la non-utilisation de l’application ou encore la rédaction d’un avis négatif sur les stores.

Le niveau de qualité doit donc être au rendez-vous et les tests automatisés sont un passage obligé pour contrôler la performance de son application.

Tester c’est douter, le doute est bon

Une équipe de développement de qualité, un processus « carré » et des tests manuels pourraient permettre d’assurer cette qualité. Tester serait mettre en doute les compétences de l’équipe ? Non, car comme le stress du funambule qui lui permet de traverser le ravin, le doute est bon pour la qualité. Un SDK avec un comportement inattendu, une regression non-désirée… Autant assurer avec des tests.

L’automatisation permet de faire du Test Driven Development (TDD)

Anticiper l’automatisation va permettre de plus d’aller vers des pratiques de Test Driven Development. Rédiger les tests avant le développement est tout à fait possible dans les projets mobiles. Avec ou sans outillage, il est intéressant d’automatiser un scénario spécifié et de le lancer en cours de développement.

Et sans parler de Test Driven Development, le fait d’avoir des tests qui suivent de près le développement permettra de détecter au plus tôt des problèmes et autres bugs.

La fragmentation des plateformes ne peut être géré avec des tests manuels

Tester manuellement sur un device uniquement ne permet plus de s’assurer du bon fonctionnement d’une application. La diversité des matériels avec des configurations matérielles et logicielles variées est source de bug. Tailles d’écran différentes, surcouches constructeurs… une automatisation va permettre de lancer des tests en parallèle sur différents devices et de détecter des potentiels bugs. On évitera comme cela de confondre utilisateurs finaux et bêta-testeurs de l’application !

Maîtriser les régressions en maintenance

La sortie de la première release de l’application n’est que le début du cycle de vie de l’application. 80% de la charge de développement correspond à de la maintenance et à l’évolution de l’application. Il est donc nécessaire de se projeter sur la durée. En automatisant, on va ainsi éviter d’ajouter des régressions dans l’application. Le lancement des tests sera systématique à chaque évolution de l’application.

L’automatisation permet d’avoir des métriques de performance

Au final, l’automatisation va permettre de suivre d’autres exigences que les exigences fonctionnelles : les exigences non-fonctionnelles. En effet, associés à des outils des mesures, les tests automatisés vont permettre de remonter de nouvelles métriques : performance, consommation de ressources…

C’est la stratégie que GREENSPECTOR préconise à ses utilisateurs. En intégrant l’API GREENSPECTOR dans les tests automatisés, ils peuvent suivre à chaque campagne de test : l’efficience et la performance de leur développement. Le coût de l’automatisation est alors largement couvert par les bénéfices. CQFD

Olivier PHILIPPOT

Expert Sobriété Numérique
Auteur des livres «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels

Android 9 Pie (API level 28) introduit une nouvelle fonctionnalité de gestion de la batterie : l’Adaptive Battery. En fonction de l’usage des applications par l’utilisateur, le système va restreindre certains mécanismes pour ces applications.

Nouveauté Android 9 : Adaptive Battery

Le système priorise l’usage des ressources d’après la fréquence d’usage des applications ainsi que le temps écoulé depuis leur dernière utilisation. 5 classes d’applications (buckets) ont été mises en place :

• Active : L’utilisateur utilise fréquemment l’application. Certains critères d’architecture sont également pris en compte : lancement d’une activité, service foreground [premier-plan], utilisateur qui clique sur une notification…
• Working set : L’application est utilisée fréquemment mais n’est pas tout le temps active. Une application de type réseau social sera par exemple assignée en Working set. Une application utilisée indirectement sera aussi dans cette classe.
• Frequent : L’application est utilisé fréquemment mais pas forcément quotidiennement.
• Rare : Une application utilisée de façon irrégulière. Par exemple une application de réservation de vol d’avion pour un particulier.
• Never : L’application a été installée mais jamais utilisée.

L’algorithme se base sur l’intelligence artificielle (IA), il est probable que l’apprentissage de l’usage prenne plusieurs jours. Il est probable que beaucoup d’applications seront attribuées à la classe Frequent voire Rare. Les applications system ou Google (Maps, Appareil photo…) seront probablement en Working Set et les applications usuelles (banque, voyage…) risquent d’être classées comme Frequent. L’implémentation pourra aussi dépendre du constructeur du smartphone.

Restrictions liées à l’Adaptive Battery

En fonction des buckets, plusieurs restrictions seront mise en place :

• Job
• Alarm
• Network
• Firebase Cloud Messaging

Cela signifie plusieurs fonctionnalités de vos applications pourraient être impactées :

• Requête réseau pour mettre à jour des ressources
• Téléchargement d’information
• Tâche de fond
• Appel périodique d’API système

Les restrictions seront les suivantes :

Comment améliorer le classement de son application ?

L’une des manières d’éviter d’être déclassé est l’attribution est que l’utilisateur place votre application dans la whitelist Doze. En effet, les applications figurant sur cette liste blanche sont exemptées des restrictions.

• Si votre application n’a pas de launcher activity, il faut penser à en implémenter une si possible.
• Il est important que vos utilisateurs puissent interagir avec les notifications.
• N’encombrez pas votre utilisateur de trop de notifications, sinon ce dernier pourrait les bloquer et votre application serait déclassée.

La difficulté de tester

Il va être difficile de prévoir dans quelle classe votre application sera affectée. Il est probable que l’usage des utilisateurs sera fragmenté et votre application pourra se retrouver dans chacune des 5 classes. Si vous souhaitez connaître la classe de votre application (mais dans le cas de votre usage), vous pouvez utiliser l’API :

Il est cependant nécessaire de tester votre application dans les différents cas. Pour cela vous pouvez placer l’application dans la classe voulue avec ADB :

adb shell am set-standby-bucket packagename active|working_set|frequent|rare

Il est évident que la durée des tests va être plus longue.

À noter que si vous avez une application multi-apk, il est possible que tous les APK n’aient pas la même classe. Il est alors important de réfléchir à une stratégie de test adaptée.

L’Adaptive battery réduit-elle réellement la consommation de batterie ?

Avec l’annonce de cette nouvelle feature (associée au buzzword d’Intelligence Artificielle) de nombreuses spéculations sur le fonctionnement ont été entendues : Android mettrait en mémoire les applications les plus utilisées, permettrait des gains importants en énergie… Google annonçait 30% de gain CPU sur le lancement de l’application. Or ce chiffre correspondait en fait plus à des mesures réalisées dans le contexte Google. On est plus probablement autour de 5% de réduction. L’implémentation de l’Adaptive battery est en effet plus restreint : en fonction de l’usage, certains traitements, surtout en tâche de fond, sont décalés. Cela permet par exemple dans certains cas où l’utilisateur n’aurait plus de batterie de les reporter à une période où l’appareil sera branché. On décale donc le traitement, mais il n’est en aucun cas supprimé. (Source). L’Adaptive battery permettra probablement plus de gain au fur est à mesure que les développeurs utiliseront les alarms et les jobs. L’Intelligence Artificielle qui réduirait drastiquement la consommation d’énergie est une cible pour Android mais nous n’assistons qu’à ces débuts.

On le voit, les différentes versions Android amènent de plus en plus des fonctionnalités de gestion d’énergie (Doze, Adaptive battery…). Les gains pour les utilisateurs sont en revanche difficilement chiffrables. En tout cas, nous n’assistons pas à une explosion de la durée d’autonomie des smartphones. Cependant, cela amène une visibilité supplémentaire pour les applications qui sont détectées en tant que trop consommatrices par le système. Et l’impact est alors fort pour l’application, car l’utilisateur, une fois prévenu, risque tout simplement de la désinstaller.

Au final, que faire ?

Il est difficile de prévoir comment le système va percevoir une application donnée (Fréquemment utilisée, rarement…). Cependant trois axes sont importants :

• Une application efficiente, fluide et bien conçue sera probablement plus souvent utilisée. Au-delà des bonnes pratiques que l’on donne dans cet article, il est important d’avoir un niveau de qualité élevée pour son application. Cela implique plus de test, un contrôle élevé de la qualité, la mesure des métriques de consommation de ressources et d’énergie…
• Les traitements en tâches de fond via Alarmes et Jobs ainsi que les traitements réseaux sont ciblés par Android. Il est important de concevoir une architecture d’application efficace et de tester le comportement de ces tâches. Et cela dans diverses conditions : connexions réseau différentes, plateformes fragmentées….
• Les OS et constructeurs continuent de rechercher des mécanismes pour éviter que les applications n’utilisent trop de batterie. En tant que développeur d’application il est critique d’anticiper cette problématique. En effet, la clé du problème est la conception des applications. Sans un meilleur comportement des applications, les systèmes risquent de continuer à mettre des mécanismes peu efficaces mais contraignants.

Olivier PHILIPPOT

Expert Sobriété Numérique
Auteur des livres «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels

Compte-tenu de la fragmentation des smartphones Android, il est nécessaire d’optimiser le choix. En effet, il est impossible de mesurer la consommation de ressource et d’énergie sur tous les devices du marché.

Olivier PHILIPPOT

Expert Sobriété Numérique
Auteur des livres «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels

Reading Time: 2 minutes

Il est parfois nécessaire d’exécuter des tests en parallèle sur plusieurs devices. Dans tous les cas, cela permet d’accélérer sa campagne de test :

Continue reading « Lancer des tests Appium en parallèle sur plusieurs devices »

Olivier PHILIPPOT

Expert Sobriété Numérique
Auteur des livres «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels

À l’heure de la digitalisation et de la forte croissance de la mobilité, le développement des applications mobiles est devenu stratégique pour toutes les entreprises.

Olivier PHILIPPOT

Expert Sobriété Numérique
Auteur des livres «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels

En ce qui concerne l’utilisation du réseau en mobilité, le monde des applications se divise en deux catégories : celles qui gardent la batterie chargée, et celles qui creusent.
Dans quelle catégorie se trouve votre application ?

Olivier PHILIPPOT

Expert Sobriété Numérique
Auteur des livres «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels

Dans cet article, nous vous expliquons les enjeux et les problématiques d’énergie et de performance de vos applications mobiles, et comment les détecter avant vos utilisateurs.

Performance et énergie, critères primordiaux pour les applications mobiles

La performance d’une solution numérique est un critère important pour les utilisateurs.
Sans performance, les utilisateurs seront critiques et dans le pire des cas n’utiliseront plus le service. Ce facteur s’est renforcé avec la mobilité, compte-tenu des plateformes moins puissantes et des réseaux avec des caractéristiques inégales. À cela s’est ajoutée la problématique de l’énergie. En effet, il est rare que les plateformes mobiles soient alimentées en continu !

Détection trop tardive des problèmes d’énergie et de performance

Avant l’arrivée des smartphones, le respect d’exigence de performance s’était principalement focalisé via des tests de charge côté serveur. Les équipes ont continué cette démarche en ajoutant quelques tests de performance sur des émulateurs ou sur leurs propres téléphones.

Cette démarche permet de détecter quelques problèmes de performance mais est cependant limitée. D’une part, les connexions réseau et les appareils des équipes de développement sont généralement d’un bon niveau et pas assez représentatifs de ceux des utilisateurs finaux ; d’autre part, la problématique d’énergie n’est jamais prise en compte. En effet, les tests s’effectuent sur des connexions Wi-fi avec fibre optique et un émulateur tournant sur un poste de développeur puissant. Très loin d’une connexion 2G sur un téléphone reconditionné.

Au final, la solution passe le cap des recettes pour la mise en production mais les retours du terrain sont nombreux. On peut anticiper cela avec les outils de Real User Monitoring, cependant le coût d’analyse des problèmes et de correction est élevé (et ne prend pas en compte les problématiques d’énergie).

Détecter les problèmes avant la mise en production

Afin d’améliorer son service numérique mobile, il est donc nécessaire de détecter le maximum de problèmes avant la mise en production. Et c’est possible en appliquant une stratégie de test structurée et ciblée qui sera exécutée sur des téléphones de test.

Il est tout d’abord nécessaire d’identifier les types d’usage principaux de l’application. Il ne faut pas écarter la possibilité de faire des tests sous excuses de la fragmentation de l’usage. Il faut pour cela simplement identifier 2 ou 3 types d’utilisateur : utilisateur avec téléphone dernier cri et connexion 4G, utilisateur en mobilité avec téléphone moyenne gamme, utilisateur en zone blanche avec téléphone reconditionné. Cela permet de mettre en place les plateformes sur lesquelles vous allez tester (ici 3 types de téléphones) ainsi que les connexions (Wi-fi, 3G, 2G).

Ensuite il n’est pas nécessaire de mettre en place des tests qui couvrent 100% de vos fonctionnalités. L’idée est plutôt de contrôler que l’usage principal de l’application répond bien à des critères acceptables de performance et de consommation d’énergie, et cela dans tous les paramètres d’exécutions que vous avez définis (Plateforme et connexion).

La détection avant la mise en production dans GREENSPECTOR

Les utilisateurs de GREENSPECTOR appliquent cette stratégie via l’usage de certaines fonctionnalités :

• Tests sur des téléphones réels de différentes générations
• Intégration des tests automatisés ou lancement de tests manuels
• Modification des moyens de connexion des devices (Wifi, 2G…)
• Mesure de la performance et de l’énergie de chaque fonctionnalité de l’application

Au final, avant chaque mise en production (voire plus régulièrement), l’exécution des campagnes de tests ciblés sur des mobiles réels permet de détecter les principales problématiques d’énergie et de performance.

Olivier PHILIPPOT

Expert Sobriété Numérique
Auteur des livres «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels

Lors de sa présentation Upscale 2018 en mars dernier, [Brendan Gregg]( http://www.brendangregg.com/), ingénieur senior performance chez Netflix, explique pourquoi le CPU n’est pas une bonne métrique pour mesurer la performance.

Brendan Gregg, Ingénieur performance chez Netflix : « Everyone uses %CPU to measure performance, but everyone is wrong »

C’est l’occasion pour nous de revenir sur ce que nous poussons depuis longtemps : comment mesurer la performance et la consommation de ressource de façon fiable ?

Brendan Gregg explique que le taux CPU peut indiquer des fausses informations. Par exemple, un CPU busy n’indique pas forcément que le CPU est occupé à faire des calculs mais qu’il est en attente d’informations. Il est donc nécessaire d’utiliser des outils plus poussés pour analyser ce qui se passe dans les couches basses du code. Brendan Gregg conclut même que cette problématique va empirer avec l’accélération de la vitesse de processeur.

Nous avons observé ce phénomène par le biais de notre R&D. En effet, un taux CPU élevé ne veut pas nécessairement dire que le CPU est sollicité et inversement un CPU bas pourrait cacher une surconsommation provenant d’une autre cachette.

Le problème est encore plus présent dans la mobilité. En effet, les plateformes actuelles sont hétérogènes : CPU, GPU, Radio, interfaces multiples … Il est donc complexe de suivre la réelle performance de ses plateformes et il est nécessaire d’utiliser des outils de profiling divers et complexes.

Notre approche chez Greenspector est différente, nous proposons d’utiliser l’énergie comme une métrique plus fiable. Tout composant sollicité consomme de l’énergie, suivre la consommation d’énergie va permettre de détecter des sur-consommations de ressources.

Pour plus d’informations, nous vous invitons à lire notre article « Pourquoi devriez-vous mesurer la consommation énergétique de votre logiciel ?« 

Olivier PHILIPPOT

Expert Sobriété Numérique
Auteur des livres «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels

Chez GREENSPECTOR, nos équipes R&D travaillent depuis plusieurs années sur la mesure d’énergie des smartphones. Plusieurs années de recherche et innovation qui nous permettent aujourd’hui de proposer un produit unique permettant de mesurer simplement les données d’énergie des smartphones. Il existe néanmoins des outils qui permettent de compléter l’analyse du comportement de la batterie et du téléphone. Battery Historian en fait partie.

Battery Historian est un outil développé par Google, lancé en 2016, qui permet d’analyser le comportement d’un téléphone et plus exactement d’examiner les informations et évènements liés à la batterie. Il s’agit, nous le verrons, d’un outil d’analyse pour expert. Plusieurs métriques et insights sont disponibles : cellules radio, communication… tout cela corrélé au niveau de batterie.

Tutoriel d’usage de Battery Historian

1) Dans un premier temps, installez Docker. Docker est un logiciel libre qui automatise le déploiement d’applications dans des conteneurs logiciels. Pour ma part, je suis sur Ubuntu donc j’utilise les scripts d’installation rapide :

curl -fsSL get.docker.com -o get-docker.sh
sudo sh get-docker.sh

2) Depuis votre interface de ligne de commande, lancez l’image Docker :

docker run -d -p 9999:9999 bhaavan/battery-historian

3) Vous pouvez désormais accéder à Battery Historian depuis l’adresse localhost:9999

Vous devez maintenant récupérer les informations détaillées du système de votre téléphone. Pour cela, vous devez avoir préalablement installé le SDK Android et être passé en mode développeur sur votre téléphone.

4) Branchez votre téléphone en USB à votre PC.

5) Depuis votre interface de ligne de commande, récupérez le fichier d’information système du téléphone avec la commande suivante :

adb bugreport bugreport.zip

6) Vous pouvez désormais uploader le fichier bugreport.txt dans Battery Historian

Vous obtiendrez alors votre analyse :

Vous pouvez observer le niveau de batterie sur l’axe de droite (de 0 à 100%), ce niveau est représenté par la courbe noire. Sur l’axe de gauche et les autres lignes, vous trouverez toutes les autres informations sur les métriques et insights remontés par le système.

En dessous de ce graph, vous retrouverez des statistiques de toutes les informations sur des applications spécifiques ou informations système de votre téléphone. Vous permettant une vision d’ensemble de ce qui se passe avec votre device. Vous pourrez par exemple analyser l’impact d’une application particulière sur la batterie au cours de l’usage :

Notre avis sur Battery historian

Battery Historian est un outil puissant qui vous permet d’analyser le comportement de la batterie et surtout comprendre ce qui se passe dans le système. Mais c’est aussi un outil complexe. Il y a énormément d’informations et il devient vite casse-tête de trouver les causes de la décharge. De plus, l’outil étant basé sur le niveau de batterie, il est nécessaire de laisser tourner un certain temps l’application que vous souhaitez analyser. Il s’agit donc d’un outil utile pour une analyse détaillée du système mais à mettre dans des mains expertes.

Olivier PHILIPPOT

Expert Sobriété Numérique
Auteur des livres «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels