Catégorie : Zone technique

Comment est calculé l’écoscore dans le cas d’un benchmark web ou mobile ?

Reading Time: 4 minutes

Dans cet article, nous allons voir plus en détail comment est calculé l’écoscore dans le cas d’un benchmark web réalisé par Greenspector.  

Et dans les autres cas ? 

Comme vous le savez peut-être déjà, Greenspector réalise également des mesures sur applications mobiles. Dans le cas des applications Android, il est possible de réaliser facilement un benchmark. On reste sur une méthodologie standard : mesures sur les étapes de chargement, pauses et référence. L’écoscore est là aussi calculé à partir des écoscores Réseau et Ressources Client. La seule différence notable est que la mise en œuvre des bonnes pratiques n’est pas contrôlée automatiquement et n’entre donc pas dans le calcul.  

Aussi, dans certains cas, il est plus judicieux de mesurer directement un parcours utilisateur afin d’être au plus près du comportement du site dans ses conditions réelles d’utilisation. Que ce soit dans le cas du web ou d’une application mobile, Greenspector réalise les mesures (toujours sur terminaux utilisateurs réels) après automatisation du parcours (via le langage GDSL). L’écoscore est ensuite établi à partir des métriques représentées via 3 écoscores : Données mobiles, Performance et Energie.

Qu’est-ce qu’un benchmark web ? 

Afin d’évaluer les impacts environnementaux des sites web, Greenspector dispose de plusieurs modes opératoires et outils. Le plus simple à mettre en place est le benchmark web. Cette méthodologie standard permet de mesurer n’importe quelle page web et de la comparer avec d’autres pages.

Notre Test Bench

Les mesures sont effectuées sur un smartphone réel disponible sur notre banc de test, le plus souvent en WIFI (même si d’autres modes de connexion, type 3G ou 4G par exemple, sont possibles) et avec le navigateur Chrome.  

Une telle mesure dure 70 secondes et inclut :  

  • Le chargement de la page 
  • Une étape de pause avec la page affichée au premier plan 
  • Une étape de pause avec la page affichée à l’arrière-plan 
  • Le scrolling sur la page 

A ceci s’ajoute une mesure de référence sur un onglet vide de Chrome.  

Plusieurs itérations de mesure sont réalisées afin de s’assurer de leur stabilité. 

On récupère ainsi des métriques sur les données transférées mais aussi l’impact sur le terminal de l’utilisateur et en particulier sur la décharge de la batterie. En plus de cela, la bonne mise en œuvre d’une trentaine de bonnes pratiques est vérifiée automatiquement.  

Ensuite, les indicateurs environnementaux sont calculés en tenant compte quand c’est possible des statistiques réelles d’utilisation de la page. Vous trouverez davantage d’informations à ce sujet dans la page dédiée sur le blog Greenspector

Une fois toutes ces informations disponibles, il devient facile de comparer différentes pages web, qu’elles soient ou non sur le même site. C’est ce mode opératoire qui est utilisé notamment dans le cadre des classements de sites proposés sur ce blog mais aussi à la demande d’un client afin d’établir un état des lieux sur un ou plusieurs de ses sites web et de proposer un plan d’action. Ce peut aussi être un moyen de construire un benchmark concurrentiel permettant de se positionner par rapport à un échantillon de sites similaires.  

Vous pouvez d’ores et déjà avoir un aperçu de tout ceci via le Mobile Efficiency Index (MEI) mis à disposition par Greenspector afin d’évaluer gratuitement l’impact d’une page web.  

Il ne nous reste pour l’heure qu’à voir comment est calculé l’écoscore dans le cadre d’un benchmark web.  

Calcul de l’écoscore pour un benchmark web 

Tout d’abord, l’écoscore établi pour une page web est la moyenne de deux valeurs :  

  • Un écoscore Ressources Client qui reflète la façon dont les ressources client sont gérées du point de vue de la sobriété lors de l’accès à cette page 
  • Un écoscore Réseau qui reflète la sollicitation du réseau (et des serveurs)

Ecoscore Ressources Client

L’écoscore Client repose sur 12 contrôles effectués sur les métriques directement récupérées sur le terminal utilisateur (et collectées via son système d’exploitation). Celles-ci concernent entre autres les données transférées mais aussi la décharge de la batterie, le CPU et la mémoire. Pour chacune, 4 à 5 seuils sont définis afin de déterminer les valeurs acceptables. En fonction de ces seuils, une note est calculée. Les notes pour l’ensemble des métriques sont ensuite agrégées afin de calculer l’Ecoscore Client.  

Par exemple : 

  • La note maximale concernant les données transférées lors du chargement de la page ne pourra être obtenue que si leur poids total est inférieur à 500 ko 
  • Pour la décharge de la batterie, on compare à celle mesurée lors de l’étape de référence décrite précédemment 

Les seuils utilisés sont définis via une base de mesures afin de pouvoir, en fonction de la répartition statistique des mesures précédemment obtenues, déterminer les seuils attendus.

Ecoscore Réseau

Aujourd’hui, la méthodologie Greenspector repose sur des mesures uniquement réalisées sur des terminaux utilisateurs réels. En conséquence, la définition de l’écoscore Réseau est légèrement différente. Elle repose sur deux éléments :  

  • La comparaison des métriques liées au transfert de données avec des seuils définis de façon similaire à ceux utilisés pour le calcul de l’écoscore Client 
  • La vérification automatique de la mise en œuvre d’une trentaine de bonnes pratiques 

Ainsi, par exemple, on s’assure que les ressources textuelles sont bien compressées côté serveur, que les images ne sont pas retaillées dans le navigateur et qu’il n’y a pas plus de 25 requêtes HTTP en tout. Il s’agit donc ici de bonnes pratiques techniques (plutôt orientées efficience) que l’on retrouve dans la plupart des référentiels de bonnes pratiques d’écoconception ou de conception responsable de services numériques.

Conclusion

Tous ces éléments font du benchmark web un procédé très efficace pour évaluer les impacts d’une page web et la comparer avec d’autres pages web. Il s’agit aussi d’un excellent moyen d’amorcer une analyse plus poussée, notamment en regardant en priorité les pages les plus impactantes d’un site. Dans certains cas, il sera d’ailleurs plus judicieux de commencer par les pages les moins impactantes. Un défaut de conception sur une page plus impactante lui sera souvent propre alors que, sur une page moins impactante, il sera souvent commun à l’ensemble des pages.  

Le benchmark web, entre autres via le calcul de l’écoscore, illustre une fois de plus la nécessité d’utiliser à la fois des mesures et des bonnes pratiques dans une démarche de réduction des impacts environnementaux d’un service numérique.  

Comment auditer les requêtes générées par une application mobile Android ?

Reading Time: 5 minutes

Introduction

Request Map Generator est un outil disponible via webpagetest.org pour afficher une visualisation des différents noms de domaine appelés lors du chargement d’une page web. Les objectifs sont multiples :  

  • Identifier les services-tiers utilisés sur la page 
  • Identifier quels composants appellent ces services-tiers
  • Quantifier leur usage et leur impact afin de les challenger 
  • Identifier les principaux leviers d’actions

Par exemple, sur cette RequestMap, on constate que l’intégration de Twitter et Linkedin sont responsables du téléchargements de 71 ko de JavaScript. On observe également l’enchainement de requêtes conduisant jusqu’à Google. 

Le problème est que l’outil est mis à disposition pour auditer des sites web. Qu’en est-il des applications mobiles ? Nous proposons une démarche assez simple à mettre en œuvre pour générer la request map d’applications mobiles. 

HAR mapper

Le développeur de RequestMap, Simon Hearne, met également à disposition l’outil HAR mapper qui génère les mêmes request maps à partir de fichiers HAR. Les HAR sont des fichiers JSON qui permettent d’enregistrer le traffic capturé par divers outils d’analyse web comme les DevTools. Ainsi, plutôt que de demander un test entier de la suite webpagetest, on peut très bien choisir, d’enregistrer un fichier d’archive HTTP (.har) sur son propre PC. Cela nous permet de bâtir des RequestMaps plus précise, qui vont au-delà de la page d’accueil, tout en étant plus sobre numériquement. 

L’autre avantage est que l’on est désormais en mesure d’analyser des applications mobiles en utilisant un proxy SSL, sous condition que l’application autorise une certaine configuration réseau (voir Autoriser l’accès au certificat de Charles par l’application). 

CharlesProxy, le couteau-suisse du développeur 

Un proxy est un serveur qui sert d’intermédiaire entre le serveur et le client. Ce dernier envoie les requêtes au proxy qui est ensuite chargé de communiquer avec le serveur. Cela permet au proxy d’observer les différentes requêtes qui sont échangées. En outre, si le client accepte le certificat CA du proxy qui agira ainsi comme une Certificate Authority, le proxy sera capable de déchiffrer les requêtes HTTPS pour inspecter leur contenu. 

Charles Proxy est un serveur proxy dont l’usage est orienté pour les développeurs mobiles. En plus, d’agir comme un Proxy SSL, il propose de réécrire à la volée les headers (ou même le contenu !) des requêtes échangées. Il permet de tester la stabilité d’une application par rapport à des conditions de réseau, ou des problèmes serveur (throttling, répétition des requêtes, pas de cache, etc.). Dans notre cas, ce qui nous intéresse le plus est que Charles permet de sauvegarder les échanges client-serveur enregistrés sous forme de fichier .har. 

Nous proposons d’utiliser Charles Proxy car c’est un outil facile d’utilisation et assez complet mais sachez que d’autres serveurs proxy peuvent servir pour ce cas d’usage. Comme alternatives, il existe notamment mitmproxy, un outil en ligne de commande open-source ou HTTP toolkit très simple d’utilisation en version payante. 

Installer et configurer Charles 

Télécharger Charles et l’installer. Le serveur proxy est configuré automatiquement au lancement de Charles et les requêtes qui passent par lui sont enregistrées.  

Par défaut Charles n’active le SSL proxying uniquement pour une liste restreinte de noms de domaines. Pour changer ce comportement, aller dans Proxy > SSL Proxying settings. Vérifier que le SSL proxying est activé et ajouter une entrée * au tableau Include

Configurer le smartphone 

Il reste désormais à configurer notre smartphone Android pour se connecter à Charles. Le téléphone doit être dans le même réseau local que le PC sur lequel Charles est lancé. Dans les paramètres Wi-Fi, dans la configuration du réseau, définir le Proxy comme “Manual”. Rentrer l’adresse IP du PC sur lequel tourne Charles et définir le port de Charles (8888 par défaut). 

Si tout se passe bien, dès que le smartphone échange avec le réseau, Charles nous demande d’accepter ou de refuser la connexion au proxy. 

En acceptant, Charles devrait commencer à intercepter les échanges réseaux des applications. Néanmoins, les requêtes ne se font pas correctement. En effet, il nous reste à installer le certificat de Charles sur le téléphone. 

Installer le certificat de Charles 

Ouvrir le navigateur du smartphone, et visiter chls.pro/ssl. Le téléchargement du certificat se fait automatiquement. Si le fichier est ouvert, Android propose de l’installer, sous condition qu’un code PIN verrouille le téléphone. 

Attention à partir d’Android 11, la procédure est rendue plus compliquée. (Visiter l’aide de Charles pour installer le certificat sur d’autres systèmes). 

Il nous est désormais possible de transférer les requêtes émises par le processus de Chrome mais pas celles d’autres applications. En effet, pour raison de sécurité par défaut les applications Android n’acceptent que les certificats “système” (Ce n’est pas le cas pour iOS qui propose d’ailleurs une application Charles sur l’App Store). 

Autoriser l’accès au certificat de Charles par une application Android 

Trois cas de figure se présentent: 

  1. Vous disposez du code source de l’application. 

    Dans ce cas, il vous est facile d’autoriser l’usage de certificats CA “utilisateur”. Pour cela, ajouter un fichier `res/xml/network_security_config.xml` définissant les règles de configurations réseaux de l’application: 
<?xml version="1.0" encoding="utf-8"?> 

<network-security-config> 

<base-config cleartextTrafficPermitted="true"> 

<trust-anchors> 

<certificates src="system" /> 

<certificates src="user" overridePins="true" /> 

</trust-anchors> 

</base-config> 

</network-security-config> 

Il faut également spécifier son chemin dans le AndroidManifest.xml: 

<?xml version="1.0" encoding="utf-8"?> 

<manifest ... > 

<application android:networkSecurityConfig="@xml/network_security_config" ... > 

... 

</application> 

</manifest> 

Penser à ne garder cette configuration seulement pour l’application de debug, car elle peut engendrer des problèmes de sécurité MAJEURS. Voir la documentation officielle pour plus de détails. 

  1. Vous ne disposez que de l’apk de l’application. 

Dans ce cas il vous faudra décompiler l’application, utiliser la même méthode qu’en 2. et recompiler l’application et signer l’apk résultant. Pour cela certains outils (apk-mitm ou patch-apk) pourront vous aider dans le processus. La méthode n’est cependant pas garantie de fonctionner car l’application peut implémenter une vérification de la signature de l’apk. 

Attention ! En France, la décompilation d’un logiciel est strictement encadrée par la loi qui définit dans quels cas elle est légale. Dans le doute, assurez-vous d’obtenir l’autorisation de l’éditeur au préalable !

  1. Le smartphone de test est rooté. 

Dans ce cas, vous pouvez installer le certificat dans les certificats root du téléphone. 

Une fois que le certificat peut être utilisé par l’application, nous sommes en mesure d’inspecter les échanges entre le smartphone et le serveur. Pour générer un fichier .har, sélectionner toutes les requêtes, clic droit dans Charles sur les échanges réseaux > Export Session… et exporter en HAR.

Importer le fichier dans HAR Mapper, et nous avons notre Request Map ! 

Comment Greenspector évalue l’empreinte environnementale de l’utilisation d’un service numérique ?

Reading Time: 6 minutes

Avant-propos : Évaluer l’impact de l’usage

Cette note décrit succinctement la méthodologie que nous employons à la date de sa publication.​

Dans une démarche de progrès continu, nous sommes vigilants à améliorer sans cesse la cohérence de nos mesures ainsi que notre méthodologie de projection des données en impact environnemental. 

Il s’agit ici d‘évaluer les impacts environnementaux causés par l’usage d’un service numérique.

Cette analyse repose sur une méthode Analyse de Cycle de Vie (ACV), mais il ne s’agit pas de réaliser l’ACV du service numérique.​

Une telle analyse serait un exercice sur un périmètre beaucoup plus large, qui inclurait des éléments propres à l’organisation autrice du logiciel.​

Dans l’ACV d’un service numérique il conviendrait par exemple d’inclure pour sa phase de fabrication : les déplacements domicile-travail de l’équipe projet (internes et prestataires), le chauffage de leurs locaux, les PC et serveurs nécessaires au développement, à l’intégration et à la recette, les réunions sur place ou en distanciel, etc…

Méthodologie d’évaluation d’empreinte environnementale

Notre approche

La modélisation choisie s’appuie sur les principes d’Analyse du Cycle de Vie (ACV), et principalement par la définition donnée par l’ISO 14040. ​​

Elle se compose d’une partie Inventaire du cycle de vie (ICV) complète et d’une Analyse du cycle de vie (ACV) simplifiée. L’ICV est prépondérant dans notre modèle. Il va permettre de s’assurer d’avoir des données fiables et représentatives. De plus, l’ICV ainsi obtenu peut le cas échéant être intégré dans des ACV plus poussées.

Nous évaluons l’impact environnemental des services numériques sur un ensemble limité de critères :

Cette méthodologie a été revue par le cabinet EVEA – spécialiste en écoconception et analyses de cycle de vie.
Note sur l’eau : L’eau grise et l’eau bleu sont prises en compte sur toutes les étapes du cycle de vie. L’eau verte est ajoutée sur le cycle de fabrication des terminaux et des serveurs. Retrouvez la définition de l’empreinte Eau.

Gestion de la qualité des résultats

La qualité des résultats d’une ACV peut être modélisée de la façon suivante1 :​​

Qualité des données d’entrée  x  Qualité de la méthodologie  =  Qualité des résultats

Pour améliorer la qualité des données d’entrée, nous mesurons le comportement de votre solution sur des terminaux réels. Cela permet de limiter les modèles qui sont potentiellement sources d’incertitude.​

Pour gérer la qualité des résultats, nous appliquons une approche qui permet d’identifier les sources d’incertitudes et de calculer l’incertitude du modèle. Notre méthode de gestion des incertitudes utilise la logique floue et ses ensembles2.

Au final, contrairement à d’autres outils et méthodologies, nous pouvons fournir des marges d’erreurs par rapport aux résultats que nous vous donnons. Cela permet d’assurer une communication de l’impact environnemental plus sereine vers les parties prenantes (utilisateurs, équipes internes, partenaires…)

1Qualité des resultats : SETAC (Society of Environmental Toxicology and Chemistry 1992)

2Bien que mentionnée souvent dans la littérature traitant d’incertitudes en ACV, cette approche est peu utilisée. En effet les modèles stochastiques comme les simulations de Monte Carlo sont souvent préférés (Huijbregts MAJ, 1998). Dans notre cas, l’utilisation de la logique floue semble plus pertinente, car elle nous permet de gérer les inexactitudes épistémiques, notamment dues à des estimations d’expert. ​ ​

Étapes de calcul

Phases prises en compte pour le matériel utilisé

« Phases prises en compte dans le cycle de vie des matériels ​qui sont mobilisés en phase d’usage du service numérique »

Note sur le modèle d’impact de la partie terminal

Les méthodologies classiques d’analyse d’impact prennent comme hypothèse un impact uniforme du logiciel (consommation moyenne quel que soit le logiciel ou l’état du logiciel). Notre approche innovante permet d’affiner cet impact. De plus, nous améliorons la modélisation de l’impact du logiciel sur la phase de fabrication du matériel en prenant en compte l’usure de la batterie.

La batterie des smartphones et PC portables est un consommable, nous modélisons l’impact du logiciel sur celui-ci.

Données d’entrée de l’Inventaire du Cycle de Vie

Données mesurées
Énergie consommée sur smartphone
Données échangées sur le réseau
Requêtes traitées par le serveur

Données modélisées
Énergie consommée sur tablette et PC
Énergie et ressources consommées sur serveur​
Énergie et ressources consommées sur le réseau

Hypothèses Terminaux
Impact fabrication d’un Smartphone​
Impact fabrication batterie smartphone
Impact fabrication batterie tablette​
Impact fabrication batterie PC​
Nombre de cycles max avant usure smartphone
Nombre de cycles max avant usure Tablette
Nombre de cycles max avant usure Tablette
Capacité moyenne batterie smartphone
Capacité moyenne batterie tablette
Capacité moyenne batterie PC​
Voltage d’une batterie
Durée de vie smartphone
Durée de vie tablette
Durée de vie PC​
Ratio de remplacement batterie vs changement du smartphone​
Ratio de remplacement batterie vs changement de la Tablette​
Ratio de remplacement batterie vs changement du PC​
Vitesse de décharge de référence sur le terminal (mesurée)

Hypothèses Serveurs
Puissance du serveur​
Nb de cœurs​
PUE du datacenter
Puissance par cœur​
Server time (TTFB)
Number of max requests per second​
Puissance par requête​
Nb de cœurs par VM​
Nb de VM par appli simple​
Nb de VM par appli complexe​
Impact Fabrication Serveur​
Durée de vie serveur​
Débit CDN

Hypothèses Énergie
Facteur d’émissions électricité moyenne mondiale​
Facteur d’émissions électricité France

Exemple de travail sur les hypothèses :

La méthodologie de propagation des incertitudes nous oblige à identifier précisément la qualité de ces hypothèses. Voici quelques exemples, en particulier l’impact de fabrication du matériel.

L’analyse bibliographique nous permet d’identifier les impacts de différents smartphones et d’associer l’indice de confiance DQI. Ces chiffres sont principalement issus des constructeurs.

L’impact moyen calculé à partir de ces indices de confiance est de 52 kg eq Co2 avec un écart type de 16 kg.

Exemple de restitution

  • Dans cet exemple : impact médian de 0,14g eqCO2 principalement sur la partie « Réseau ».​

  • Cet impact correspond à la visualisation d’une page web pendant 20s

  • L’incertitude est calculée par le modèle Greenspector en appliquant le principe de propagation des incertitudes à partir du périmètre et de hypothèses décrits précédemment.

Éléments nécéssaires

Afin de déterminer l’impact de votre solution, nous avons besoin des informations suivantes :​​

  • Ratio de visualisation Smartphone/Tablette/PC 
  • Ratio de visualisation France/Monde
  • Localisation des serveurs France/Monde
  • Serveurs simples ou complexes (ou nombre de serveurs de la solution)

Sur devis, nous pouvons réaliser une ACV simplifiée se basant sur ce modèle mais adaptant d’autres éléments à contre cas particulier. Par exemple:​

  • Mesure de la consommation d’énergie de la partie serveur (via un partenaire)​
  • Précision des hypothèses serveur (PUE, type de serveur)​
  • Mesure de la partie PC (via mesure laboratoire)​
  • Précision des facteurs d’émissions électriques d’un pays en particulier…

Comparatifs des modèles d’estimation

Les calculs Greenspector sont intégrés dans un webservice actuellement utilisé par nos clients. Retrouvez très prochainement nos calculs d’empreinte environnementale de vos applications mobiles et sites web dans une interface SaaS.

Incertitudes – méthode de calcul

Les méthodes de calcul dans la sobriété numérique sont souvent peu justes et parfois, en même temps, peu fidèles.  Ceci vous amène potentiellement à utiliser des outils qui évaluent mal l’impact de vos solutions. Le risque est de faire travailler vos équipes sur des axes qui n’ont pas d’impact réel sur l’environnement.​

Certaines approches, plus utilisés dans les ACV (et pas dans les outils du marché), améliorent la fidélité mais posent un risque de donner un résultat peu juste (R. Heijungs 2019). ​

Notre approche repose sur une méthode de calcul innovante, l’arithmétique floue, proposée pour la première fois par Weckenmann et al. (2001).​

Cette approche est très performante pour modéliser des données vagues (épistémiques) non-probabilistes, ce qui est souvent le cas de données traitant de sobriété numérique. Nous ciblons de cette manière des résultats justes et fidèles.

Les solutions concurrentes font des choix qui les rendent généralement peu fidèles et peu fiables:​

Fidélité : Faible maîtrise de l’environnement, pas de méthodologie de gestion des écarts de mesures​

Justesse : Modèle basé sur des métriques non représentatives comme la consommation de données ou la taille du DOM, pas de mesure d’énergie…

Pourquoi est-il important de monitorer l’impact environnemental d’une URL ?

Reading Time: 4 minutes

Plus une URL est très couramment consultée, plus réduire son impact numérique est essentiel. Une simple mesure permet de vérifier et réagir face aux changements effectués sur la page : modifications liées à la charte graphique, à des évènements (les sites e-commerce en période de soldes) ou même des modifications techniques. Tous ces changements peuvent avoir un impact fort sur le niveau de sobriété d’une page web.

Quand intégrer la mesure de sobriété numérique d’une URL ?

Ces mesures peuvent être intégrées dans le cadre d’un monitoring quotidien sur n’importe quelle page. Des pages dynamiques dont le contenu est amené à régulièrement évoluer telles que des pages d’accueil e-commerce ou de site d’information presse sont importantes à monitorer. Même des pages moins « dynamiques » pourront être elles-aussi ciblées : la mise à jour d’une librairie CDN peut, par exemple, impacter ce type de site. Dans ce cas, la mesure permettra de s’assurer que le nouvel habillage de la page n’a pas un impact négatif sur le niveau de sobriété du site web : une image trop lourde pour une bannière pourra être facilement repérée.

La mesure peut aussi être utilisée lors de la phase de développement pour tester des choix avant la mise en production ou pour rectifier très tôt des changements trop impactants. Il est souvent difficile de changer le choix d’une technologie ou d’une implémentation une fois qu’un site est mis en production, la mesure d’une URL pendant la phase de développement permet de tester très tôt différentes options et de voir laquelle correspond le mieux en prenant en compte la sobriété numérique comme un des critères.

Exemple d’un suivi quotidien d’une page web

Comment mesurer la sobriété numérique d’une URL ?

Plusieurs possibilités s’offrent à vous chez Greenspector pour mesurer une URL.

Un premier outil nous permet d’effectuer une première mesure simple d’une URL et obtenir des constats rapides : l’outil Benchmark basé sur des tests standardisés.

Pour aller plus loin, nous pouvons effectuer la mesure d’un parcours utilisateur complet sur un site web grâce à App Scan. En général ce genre de mesure est effectuée pour représenter le chemin complet sur un site web ou application mobile, comme un parcours d’achat ou la réalisation d’un virement bancaire. Il permet d’identifier les points sur lesquels se concentrer pour obtenir rapidement une amélioration significative. Dans le cadre d’un App Scan, la mesure d’une URL est également possible via un parcours automatisé ce qui va permettre l’obtention de métriques spécifiques au-delà du benchmark.

Mesure d’URL (via App Scan) vs Benchmark

Voici les différentes étapes mesurées lors d’une mesure URL (via AppScan) vs l’outil Benchmark :

Étapes mesurées

  • Chargement sans cache
  • Pause après chargement sans cache
  • Pause sur la page sans cache
  • Scroll sur la page
  • Pause sur la page après le scroll
  • Chargement avec cache
  • Pause sur la page avec cache
  • Mesure de l’application en arrière-plan

Benchmark

Mesure d’URL

La mesure URL (via App Scan) contient plus d’étapes que le benchmark, nous y reviendrons. Contrairement au benchmark, la mesure URL est plus précise sur les chargements, la durée mesurée étant la durée réelle du chargement contrairement à l’outil benchmark qui réalise les mesures sur une durée fixe de 20 secondes. Une autre différence importante est qu’une mesure URL gère les fenêtres présentes sur la page, en particulier celles qui concernent les cookies, ce que ne fait pas l’outil benchmark.

Enfin, la mesure URL via App Scan par Greenspector permet de réaliser des mesures sur d’autres navigateurs que Google Chrome. L’outil benchmark est limité à ce dernier navigateur mais notre expertise GDSL nous permet de proposer un autre navigateur tel que Firefox par exemple pour aller encore plus loin.

Les étapes d’une mesure d’URL (via App Scan)

  • Chargement sans cache : Il s’agit du chargement de l’URL en ayant préalablement vider le cache et supprimer tous les cookies. Cette étape permet de mesurer le chargement de la page web lorsqu’un utilisateur s’y rend sans cache. C’est particulièrement important pour les URLs avec beaucoup de visites uniques.
  • Pause après chargement sans cache : La mesure d’une courte pause après le chargement permet de récupérer les échanges de données et autres opérations qui s’effectuent encore alors que l’affichage de l’écran est terminé. L’idéal étant bien entendu de n’avoir rien de tout ça. Dans le cas contraire cela nous permet de faire des constats et de proposer des pistes pour faire disparaitre ou réduire ces traitements. 
  • Pause sur la page sans cache : La mesure de pause sur la page représente l’action d’un utilisateur en train de lire le contenu. Aucun mouvement sur l’écran. L’idée de cette étape est de mesurer l’impact de l’affichage continu de la page.  
  • Scroll sur la page : Défilement jusqu’en bas de la page permettant de réaliser des constats sur les traitements pendant le scroll. Ici nous pouvons faire des constats sur les possibles échanges de données (pagination, téléchargement d’image, publicité) ainsi que la fluidité associée. 
  • Pause sur la page après le scroll : Mesure de pause après le défilement permettant d’observer des traitements qui continuent après la fin des interactions utilisateur.  
  • Chargement avec cache : Mesure du chargement de l’URL avec le cache des intéractions précédentes (chargement, scroll). Cette étape permet de constater l’impact de la mise en cache sur le site. C’est important pour les pages amenées à être consultées un grand nombre de fois par des visiteurs connus, comme par exemple une page d’accueil d’un site internet. 
  • Pause sur la page avec cache : La mesure de pause sur la page permettant de voir si malgré le cache il y a des traitements après le chargement.

Grâce à nos outils et notre expertise nous pouvons proposer des mesures fiables et pertinentes sur une URL. Que ce soit une mesure simple permettant des premiers constats à l’aide de notre outil de benchmark ou une mesure plus poussée avec notre langage GDSL. Ce monitoring régulier d’URL permet d’améliorer progressivement le niveau de sobriété de son site web. Cette approche par rapport à d’autres approches courament utilisées dans le web (Analyse uniquement du chargement de la page avec Lighthouse ou autres…), apporte plus de finesse sur la connaissance de la consommation de la page.

Comment nettoyer l’application Chrome pour réaliser des mesures de performances et d’énergie fiables ?

Reading Time: 5 minutes

Contexte

Bienvenue dans cette nouvelle rubrique « focus GDSL » qui explique en détail certaines méthodes du langage GDSL d’automatisation de Greenspector. Si vous n’avez pas encore lu l’article d’introduction du GDSL, n’hésitez pas avant de poursuivre la lecture de celui-ci.

Aujourd’hui, nous allons nous concentrer sur la méthode browserReset qui permet de nettoyer un navigateur pour réaliser des mesures de performances et d’énergie fiables.

Pour réaliser des mesures correctes sur navigateur, il faut pouvoir s’assurer que vous allez mesurer uniquement votre page web, sans aucun parasite pouvant provenir du navigateur comme des onglets ouverts par exemple. Sans ce travail, la mesure de la consommation d’une page web serait faussée par des pages en arrière plan effectuant des traitements et des échanges réseaux. De plus, cela nous permet de mesurer précisément la consommation du navigateur à vide, une fois le nettoyage effectué, et la comparer à la consommation du site.

En automatisation, ce que l’on ne supporte pas, c’est de ne pas connaître les conditions initiales de notre test. Cela pourrait perturber son bon fonctionnement, voire même aboutir à un test dont on ne peut rien tirer car on ne sait pas au final ce qui aura été mesuré.

Sur un banc de test automatisé, il est difficile de connaître l’état du navigateur au début de votre test : vous ignorez si un test précédent a laissé des onglets ouverts, a modifié la langue du navigateur ou quoi que ce soit d’autre. On pourrait aller voir dans la salle des téléphones me direz-vous. Oui c’est vrai, mais si elle est à l’autre bout du monde ça devient compliqué, sans parler de la situation sanitaire actuelle (cet article à été rédigé en pleine crise du Covid-19). On pourrait aussi se servir d’outils pour monitorer le téléphone à distance. Alors oui, mais cela n’est valable que si vous êtes présent au moment d’exécuter votre test. Pour des campagnes en intégration continue qui peuvent tourner toutes les heures, ou même la nuit, vous n’allez pas pouvoir surveiller en permanence.

Alors que faut-il faire ? Et bien, nettoyer le navigateur avant chaque test pardi !

Approche rapide

Pour notre cas, nous allons utiliser le navigateur Chrome, mais le raisonnement est le même avec un autre navigateur. Nous allons aussi partir du principe que ce navigateur est régulièrement mis à jour sur les téléphones.

Une méthode rapide et qui va fonctionner dans beaucoup de cas pour nettoyer un navigateur consiste à fermer les onglets ouverts et nettoyer le cache au début de chacun de nos tests. De cette manière, quand le navigateur s’ouvrira la prochaine fois pour prendre des mesures, il sera sur un onglet vide.

Cette méthode va fonctionner sur la majorité des smartphones mais va être à la peine sur tablette à cause de la gestion des onglets. Sur tablette, les onglets sont en général affichés sur une barre en haut (ou en bas) du navigateur, comme sur un ordinateur. La particularité de cette barre d’onglet est qu’elle est invisible pour les outils classiques d’automatisation, ce qui rend très compliqué de cliquer sur la croix pour fermer l’onglet. De plus, la taille d’un onglet va dépendre du nombre d’onglets ouverts, rendant le clic par coordonnées encore plus hasardeux.

Pour couronner le tout, le bouton pour fermer tous les onglets d’un coup n’apparait qu’avec un appui long sur la croix de fermeture du premier onglet, le rendant inutilisable pour nous.

La dernière difficulté que peut rencontrer cette méthode est sa maintenance. En effet en mettant à jour l’application, la gestion des onglets peut changer, tout comme l’architecture de l’application, obligeant à modifier régulièrement les scripts d’automatisation.

Solution complète

La solution utilisée chez Greenspector pour nettoyer le navigateur avant nos mesures et nous assurer de la pertinence de nos résultats est la suivante :

  • Nettoyer les données de l’application. Ceci est généralement fait à l’aide de la commande adb shell pm clear PACKAGE_NAME, mais peut aussi être réalisée dans le menu paramètres du téléphone.
  • Passer les popups de premier lancement du navigateur avec l’automatisation.

Une fois ceci effectué, il reste un dernier point qui peut poser problème : certains constructeurs ou opérateurs mobiles affichent une page d’accueil personnalisée sur le navigateur. Pour permettre de comparer des mesures entre plusieurs smartphones, il faut se débarrasser de cette page d’accueil. Nous avons choisi de désactiver la home page dans les paramètres du navigateur.

Il reste un dernier point concernant cette page d’accueil. En effet celle-ci à été chargée au premier lancement du navigateur et est donc ouverte, ce qui n’est pas pratique pour faire des mesures. Notre solution a été de naviguer vers la page « nouvel onglet » de Chrome à l’url suivante :

  • « chrome://newtab »

Une fois toutes ces opérations effectuées, votre navigateur est prêt pour réaliser des mesures sans risque d’avoir des conditions existantes pour venir le perturber.

L’idéal est même d’effectuer ce nettoyage aussi à la fin de votre test. De cette manière vous laissez le téléphone prêt à l’emploi pour la personne suivante.

MISE À JOUR : Pour nos besoins de mesures, nous nous intéressons aux données de performances, d’énergie et les données mobiles entre autres. Cette méthode répond parfaitement aux besoins de performances et d’énergie, mais ne convient pas pour les données sur le navigateur Chrome. En effet, en réinitialisant le navigateur, Chrome resynchronise automatiquement les données du compte Google, et sur au moins les deux premières minutes d’utilisation, il y a des échanges de données liées au compte Google. Se déconnecter du compte Google sur Chrome ou du téléphone ne semble pas régler le problème entièrement. Par conséquent, chez Greenspector, nous n’utilisons plus cette méthode pour nettoyer un navigateur. Aucune mesure n’a été effectuée sur d’autres navigateurs que Chrome permettant de dire que cette méthode n’est pas valide sur ceux-ci.

Voila vous savez tout sur la méthode browserReset. À bientôt pour un nouveau focus GDSL où je vous ferais découvrir une autre fonctionnalité du langage d’automatisation de Greenspector.

Introduction au GDSL : le langage d’automatisation par Greenspector

Reading Time: 3 minutes

Qu’est-ce que le GDSL ?

Le terme GDSL signifie Greenspector Domain-Specific Language. Il s’agit d’un langage créé par Greenspector pour simplifier l’automatisation de test sur Android et iOS. Concrètement c’est une surcouche basée sur les frameworks d’automatisation de Google et d’Apple agrémentée de fonctions pour faciliter l’automatisation de test. 

Ce langage est le fruit de l’expertise Greenspector accumulée depuis plusieurs années déjà. Il combine la simplicité d’écriture à la possibilité de mesurer les performances énergétiques d’une application ou d’un site internet. 

Le principe du GDSL est d’être un langage de description des actions qui seront effectuées sur le smartphone. En ce sens il peut être rapproché du Gherkin avec qui il partage la qualité de ne pas nécessiter de formation de développeur pour être lu.

Le GDSL est une suite d’actions qui seront exécutées dans l’ordre par le smartphone. Il dispose des actions basiques que sont les WAIT, CLICK ou encore PAUSE ainsi que d’actions plus complexes comme le lancement d’application ou la gestion du GPS. 

Avec le GDSL il est possible d’automatiser rapidement la plupart des parcours critiques de vos applications ou site web mobile. 

La syntaxe du GDSL

Voici une ligne de GDSL: 

waitUntilText,identifiants,10000

Le premier élément, en vert (waitUntilText), est le nom de la méthode. En général elle sera en anglais et explicite. Ici on va attendre un texte. Les principales actions de WAIT et de CLICK sont disponibles avec des déclinaisons pour id, texte ou content-description

Le second élément, en orange (identifiants), va être le paramètre principal de la méthode. Il s’agit généralement de l’élément graphique sur lequel doit être effectuée l’action. Selon la méthode appelée il s’agira d’un id, d’un texte ou encore d’une description. Dans l’exemple il s’agit d’un texte. 

Le dernier élément, en bleu (10000), est un second paramètre de la méthode. Il s’agit le plus souvent de paramètres optionnels donnant des conditions supplémentaires lors de l’exécution. Ici il s’agit d’un temps en milli secondes. 

Pour séparer chaque élément on utilise une virgule. 

La méthode présentée en exemple sert donc à attendre l’élément avec le texte “identifiants” pendant une durée maximum de 10 secondes. 

Dans l’état actuel du langage il n’y a pas de méthodes demandant plus de deux paramètres. Si la méthode échoue alors le test s’arrêtera et le rapport indiquera le test comme échoué. 

Les avantages du GDSL

  • Le GDSL ne demande aucune compétence en développement ou connaissance en langages de programmation pour être utilisé ou lu. Le nom des méthodes est explicite et permet à n’importe quelle personne arrivant sur le projet de lire et comprendre vos tests. 
  • Aucun IDE ou environnement de développement spécifique n’est nécessaire pour écrire du GDSL, un simple éditeur de texte suffit
  • Un test = un fichier. Avec le GDSL pas besoin d’architecture de fichier compliquée, un seul fichier contient votre test. 
  • Sa facilité d’utilisation permet d’écrire un test très rapidement sans dépendance au reste du projet de test comme le demanderaient d’autres langages de test automatique. 
  • De plus sa facilité d’exécution avec les outils associés chez Greenspector permet de mettre très rapidement en intégration continue chaque nouveau test. 
  • Mis à jour et maintenu régulièrement, le langage possède déjà des fonctions avancées pour l’automatisation de site internet telle que l’ouverture d’onglet ou la navigation d’url. 
  • En directe association avec les outils et l’expertise de Greenspector le GDSL est le seul langage d’automatisation qui vous permet de mesurer les performances et l’impact environnemental de votre application tout en effectuant vos tests quotidiens. 

Les limites actuelles du GDSL

  • Le GDSL ne permet pas encore d’effectuer des tests à logique complexe (exemple : si je suis connecté alors je vois l’élément 1, sinon je vois l’élément 2). Il faut écrire un test différent pour chaque cas. 
  • Le GDSL se base sur des éléments graphiques présents sous forme descriptive. Il est incapable d’interpréter le contenu d’une image ou d’analyser la mise en page de votre application. Impossible de faire un test vérifiant que le bouton est bien situé en bas à droite de l’écran. 

L’équipe Greenspector travaille au quotidien pour améliorer le langage et ajouter des fonctionnalités. L’état actuel permet d’automatiser la plupart des scénarios nécessaires à une campagne de mesure complète d’une application ou d’un site web ainsi que les parcours critiques de la plupart des applications. Dans un prochain article, nous vous parlerons des outils Greenspector permettant l’exécution des tests GDSL.

Les nouveautés Greenspector : release note v.2.9.0

Reading Time: 2 minutes

L’équipe Greenspector est fière d’annoncer la sortie de sa nouvelle release : la version 2.9.0.

Afin de mesurer la consommation des applications et des sites web, vous pouvez exécuter des parcours utilisateurs sur nos fermes de smartphone. Dans ce contexte, nous avons amélioré notre langage de test simplifié (le GDSL) avec par exemple des fonctionnalités de préparation des browsers, prise en compte de Firefox… Contrairement à de nombreux outils qui vous fournissent un impact environnemental uniquement sur la page principale et sur des environnements simulés, ces capacités vous permettront d’évaluer et de suivre précisément l’impact de votre solution numérique !

API Swagger pour les routes existantes
Vous pouvez désormais changer de navigateur très facilement

Mesurer la performance des applications mobiles : monitoring synthétique ou real user monitoring ?

Reading Time: 3 minutes

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 :

Pourquoi automatiser les tests de ses applications mobiles ?

Reading Time: 3 minutes

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

Adaptive Battery sous Android 9 Pie : Votre application risque d’être fortement impactée

Reading Time: 4 minutes

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 :

BucketsJobAlarmNetworkFCM
ActivePas de restrictionPas de restrictionPas de restrictionPas de restriction
Working setDécalé jusqu’à 2 heuresDécalé jusqu’à 6 minutesPas de restrictionPas de restriction
FrequentDécalé jusqu’à 8 heuresDécalé jusqu’à 30 minutesPas de restrictionHigh priority: 10/jour
RareDécalé jusqu’à 24 heuresDécalé jusqu’à 2 heuresDécalé jusqu’à 24 heuresHigh priority: 5/jour

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.