Catégorie : Tutoriels GREENSPECTOR

Quelle est la corrélation entre écoconception et sobriété éditoriale ?

Reading Time: 4 minutes

Une démarche d’écoconception de services numériques ne peut réussir qu’en impliquant tous les acteurs du projet sur toutes les étapes du cycle de vie de celui-ci.
Parfois, malgré tous les efforts mis en œuvre pour appliquer les principes de l’écoconception lors de la réalisation d’un site web, les impacts environnementaux peuvent augmenter à cause d’éléments externes au périmètre défini. En particulier, il est indispensable d’embarquer celles et ceux qui vont produire du contenu sur le site. Pour cela, tout n’est pas si simple. Certaines bonnes pratiques peuvent être automatisées techniquement tandis que d’autres nécessitent de garder en tête l’ensemble des contenus proposés ainsi que leur pérennité.

Cet article propose des bonnes pratiques visant à faciliter la gestion des contenus dans une optique de réduction des impacts (environnementaux et autres) des contenus proposés.

Pour aller plus loin 

Le sujet a déjà été largement abordé par Ferréole Lespinasse : https://www.sobriete-editoriale.fr/  

L’agence Rose Primaire propose des checklists à ce sujet, qu’il s’agisse de publier sur un site web, un réseau social ou une newsletter : https://roseprimaire.com/checklists/

Le référentiel de l’INR (Institut du Numérique Responsable) propose une catégorie dédiée aux contenus : https://gr491.isit-europe.org/?famille=contenus  

De même pour le RGESN (Référentiel Général d’Ecoconception de Services Numériques) : https://www.arcep.fr/mes-demarches-et-services/entreprises/fiches-pratiques/referentiel-general-ecoconception-services-numeriques.html#c36438

Bonnes pratiques de sobriété éditoriale 

Intégrer le moins de contenu non-textuel possible 

Contexte  

Chaque contenu intégré va générer des requêtes et transferts de données. Il est donc important d’en intégrer le moins possible, tout en veillant à maintenir l’attractivité des publications.  Une fois qu’il ne reste que les contenus indispensables, il est nécessaire d’intégrer chacun d’entre eux de façon aussi efficiente que possible (voir plus loin).  

Le plus souvent, niveau impact : vidéo > podcast > image animée > image statique > texte   

Attention, les images animées de type GIF peuvent avoir une taille très conséquente et poser des problèmes d’accessibilité. 

Le MOOC de l’INRIA (Institut national de recherche en informatique et en automatique) propose une activité très simple pour comprendre ces impacts

Comment ?  

  • Limiter le nombre de contenus, en tenant compte de leurs impacts respectifs 
  • Éviter autant que possible les contenus purement décoratifs (par exemple, les images de stock ou carrousels) 
  • Garder en tête l’accessibilité  

Réduire le poids des vidéos 

Contexte  

D’autant plus à l’heure des réseaux sociaux, la vidéo est souvent privilégiée comme canal de communication.  

Aujourd’hui, la vidéo représenterait 60% des flux mondiaux de données.  

Comment ?  

Réduire le poids des fichiers audio 

Contexte  

Notamment avec les podcasts, les contenus audios se multiplient sur le web.  

Comment ?  

  • Privilégier les formats MP3, OGG ou AAC 
  • Utiliser des fichiers audios aussi concis que possible 
  • Plutôt que d’intégrer directement le contenu sur la page, intégrer une vignette cliquable menant à celui-ci 

Réduire le poids des images 

Contexte  

Au global, sur les pages web, les images sont à l’origine de la majorité des données transférées [EN].  

Comment ?  

  • Privilégier le format Webp et autres formats adaptés pour le web  
  • Proposer des images avec une taille et une qualité adaptée aux terminaux des utilisateurs 
  • Optimiser les images via un outil (exemple : Squoosh)  
  • Charger du texte par défaut et l’image seulement à la demande  

Tutoriel (en anglais) sur l’optimisation des images

Limiter l’impact des contenus tiers 

Contexte  

Il est facile d’intégrer des contenus provenant d’autres sites (vidéos Youtube/Dailymotion, messages ou fils Twitter/Facebook/Instagram/etc.).  

Leur intégration directe entraîne souvent de nombreuses requêtes (notamment des trackers) et données transférées.  

Comment ?  

Adopter une gestion sobre des publications 

Contexte  

Au-delà de la conception de chaque publication, il est important de garder en tête l’ensemble des publications disponibles. L’objectif ici est de garder du contenu pertinent et à jour. L’intérêt est d’éviter que le contenu ne soit noyé dans la masse, ce qui permet au passage d’améliorer le référencement naturel. 

Comment ?  

  • S’appuyer sur des indicateurs concrets : nombre de visites, nombre d’arrivées sur le site via cette page, taux de rebond, etc.  
  • Mettre à jour les publications plus anciennes qui restent intéressantes. Éventuellement en profiter pour changer le format : la vidéo devient un article  
  • Combiner les publications proches par leurs thèmes : des articles informatifs sont agrégés en un article de référence  
  • Supprimer les publications qui ne sont plus vues ou plus pertinentes (contenu obsolète ou relatif à des événements passés) 

Pour aller plus loin, il est également envisageable de :  

  • Définir une date d’expiration pour les publications créées (exemples : contenu chaud VS contenu froid, date de dépublication pour du contenu temporaire)  
  • Auditer les publications d’un site [EN] 
  • Publier le contenu de façon raisonnée et pertinente, notamment pour sa diffusion sur les réseaux sociaux et dans des newsletters. Ces dernières doivent elles-mêmes faire l’objet d’une démarche d’écoconception et de mise en accessibilité. Ce sujet pourrait à lui seul faire l’objet d’un article 

Proposer des libellés explicites pour les liens 

Contexte 

Lors de la navigation dans des contenus, il est fréquent de rencontrer des liens qui viennent enrichir le contenu en question. Afin d’éviter des mauvaises surprises pour les utilisateurs, les libellés de ces liens doivent être aussi explicites que possible. L’intérêt pour l’expérience utilisateur est évident mais il est également question ici d’éviter à l’utilisateur de charger du contenu qui ne lui est pas utile ou que son terminal ou sa connexion internet ne lui permettent pas d’utiliser dans de bonnes conditions. 

Les critères pour cette bonne pratique sont pour la plupart issus des règles OPQUAST (OPen QUality STandards). Il convient ici d’insister à nouveau sur la nécessité de proposer des liens (mais aussi plus généralement des contenus) accessibles. 

Comment ? 

Conclusion 

Nous avons évoqué ici ce qui peut être fait pour s’assurer de proposer du contenu aussi léger que possible. Si certaines actions reposent principalement sur les contributeurs, il est important à terme que les outils de gestion de contenu tels que les CMS (Content Management System) intègrent des outils pour assister les contributeurs. Il peut s’agir par exemple d’automatiser certaines optimisations techniques, de visualiser les impacts environnementaux du contenu produit mais aussi de faciliter la mise en place d’une démarche plus globale de gestion de contenu (expiration des documents, visualisation des consultations, etc.). Certains éditeurs ont déjà pris l’initiative d’entamer une telle démarche, il reste à espérer que celle-ci deviendra systématique. 

Comment estimer l’autonomie d’un smartphone en moins d’une heure chrono ?

Reading Time: 6 minutes

Connaître l’autonomie précise d’un téléphone est important car il s’agit de l’un des premiers critères d’achat des smartphones. Cela est d’autant plus critique pour les flottes de devices (en mode B2B) dans les entreprises. En effet, une mauvaise autonomie va engendrer des baisses de productivité voire des insastisfactions clients. Il est donc nécessaire d’avoir une bonne stratégie pour choisir ses devices ainsi que les applications qui seront hébergées dessus.

Les approches classiques d’estimation de l’autonomie

Une première approche est de se baser sur les données fournies par les constructeurs. Néanmoins, la limite de cette approche est que ces données se basent sur des scénarios d’usage qui ne sont pas forcément représentatifs des vôtres. Le risque est donc d’avoir une réalité d’autonomie très éloignée de ce que vous aurez estimé. D’autant plus que certaines fonctionnalités (comme la prise de photo par exemple..) seront peut être peu optimisées sur un certain type de smartphone et seront très utilisées dans votre usage. Cette critique est aussi valable pour des tests réalisés par des laboratoires externes.

Une seconde approche est de réaliser des tests sur des devices rééls et en effectuant le scénario cible. Des outils existent pour lancer des benchmarks automatiquement mais vous pouvez aussi effectuer manuellement vos tests. L’avantage est d’avoir une autonomie réaliste. Le seul problème est que ces tests sont très chronophages. Et cela ne donne pas le droit à l’erreur. En effet, si vous voulez changer un paramètre sur le smartphone (luminosité…) ou ajouter une application à tester, vous devez relancer toute la campagne de tests.

Une dernière approche consiste à laisser les utilisateurs faire les tests. Vous attendez les retours d’utilisateurs ou bien vous utilisez les outils de déploiement de flotte (MDM) pour remonter les informations. Cela a l’avantage d’être peu couteux, l’inconvénient c’est qu’il existe un coût caché : si il y a un problème, il y aura forcément de l’insatisfaction et de l’improductivité engendrées. Et cela vous oblige a choisir un device qui devra peut-être être remplacé.

L’approche innovante de GREENSPECTOR

Pour répondre à ce besoin de maîtriser l’autonomie des devices (et de choisir au plus tôt le bon device), GREENSPECTOR propose une approche basée sur des mesures réelles mais unitaires avec un algorithme de projection. La démarche se compose de 3 étapes :

  • Mesure des fonctionnalités principales sur les devices à évaluer
  • Configuration d’un scénario cible
  • Projection et analyse des données

Cas d’usage

Nous souhaitons estimer l’autonomie d’un usage classique sur un smartphone Samsung Galaxy S7. L’usage peut être un usage en entreprise mais aussi un usage intensif personnel:

  • 30 minutes de navigation internet
  • 30 minutes de réseau social
  • 30 minutes de conversation téléphonique
  • 30 minutes de prise de photo
  • 10 minutes d’enregistrement vidéo
  • 30 minutes d’e-mail
  • 30 minutes de visioconference
  • 30 minutes de Microsoft Word
  • 10 minutes de réservation de train
  • 30 minutes de géolocalisation

Ce scénario est volontairement générique mais nous pourrions y ajouter une application spécifique ou bien un usage exotique…

Mesure des fonctionnalités

Nous utilisons le module Free Runner de GREENSPECTOR qui permet d’effectuer des tests manuels. Ces actions peuvent être autonomatisées mais dans l’approche de cet article, nous nous concentrons vers des tests rapides orientés tests exploratoires. Si un benchmark de plus grande ampleur est nécessaire, l’automatisation aurait tout son intéret.

Pour chaque étape du scénario (navigation, prise de photo…), nous lançons le module Free Runner et nous effectuons un scénario représentatif d’un usage réél sur 1 minute.
Le module GREENSPECTOR envoie directement les mesures au serveur GREENSPECTOR. Au final cela nous a pris un peu plus de 10 minutes pour obtenir l’ensemble des mesures. Si l’on veut un peu plus de précision (ou de représentativité), nous pouvons relancer quelques itérations.

À cette étape, les fonctionnalités ou applications les plus consommatrices peuvent être identifiées.

Mise en place de la stratégie de budget

Au sein de l’interface GREENSPECTOR sur l’onglet Budget, vous allez pouvoir initier une projection d’autonomie :

Vous allez être guidé dans la configuration du budget. Une première étape est de préciser l’autonomie que vous souhaitez atteindre. Si vous êtes sur une flotte de device, vous voulez probablement que votre utilisateur ai au moins 9 heures d’autonomie pour finir la journée sans avoir à recharger le téléphone.

GREENSPECTOR vous propose alors les étapes possibles du scénario. Elles sont issues des mesures que vous aurez effectué précédemment.

L’étape la plus compliquée pour vous maintenant va être de préciser combien de fois ou combien de temps vous souhaitez que l’action se produise. Par exemple, on se base sur des durées cibles de 30 minutes, il faut donc entrer cette donnée pour chaque étape. Pas d’inquiétude, cela pourra être modifié plus tard .

Vous pouvez ensuite valider et laisser l’algorithme se calculer. Pas le temps de prendre un café, le résultat des projections est immédiat :

Analyse des resultats de l’algorithme

Le premier warning dans la fenêtre signifie que la projection d’autonomie en fonction de votre scénario et des mesures réélles permettent de dire que l’autonomie de 9 heures ne sera pas respectée.

On retrouve cette information dans le graphique de projection :

  • la 1ère barre est la capacité disponible d’énergie utilisable sur 9 heures : La capacité du téléphone S7 soit 3000 mAh.
  • la 2ème barre est la répartition d’énergie (les bugdets unitaires) par fonctionnalité si vous voulez respecter l’autonomie voulue.
  • La 3ème barre est la projection de consommation associée aux mesures réélles.

On le voit, la consommation réelle mesurée est de 3300 mAh alors que la capacité du téléphone est de 3000 mAh. Cela ne passe pas ! Nous verrons plus loin quoi faire pour corriger cela.

La notion de budget unitaire apparait sur le graphique et sur la partie de droite. Il s’agit de la répartition idéale de consommation d’énergie sur chaque fonctionnalité pour respecter l’autonomie. Voici les grands principes de l’algorithme:

  • Afin de rester proche d’un usage réel, l’algorithme ajoute une période d’inactivité qui correspond à ce que l’utilisateur ferait entre ses actions (Idle foreground)
  • Une période de veille profonde est ajoutée qui correspond à une inactivité de longue durée du téléphone (Idle background)
  • Aux périodes d’idle que vous allez définir (par exemple un idle correspondant à une pause le midi) vont être associées un budget qui se base sur la consommation de référence du téléphone
  • Aux actions, vont être affectés un budget qui correspond à une consommation maximum de x2 la consommation de référence.

Au final, le budget unitaire de chaque action est la quantité d’énergie qu’une action unitaire ne doit pas dépasser. Comme ça, vous pouvez vérifier par rapport à la mesure réelle si l’action consomme trop :

On voit ici que la consommation de la navigation est importante et dépasse le budget. Cette fonctionnalité contribue au non-respect de l’autonomie souhaitée.

Au final, vous pouvez analyser les données hors GREENSPECTOR et par exemple visualiser la courbe de décharge batterie :

Comment obtenir une autonomie correcte ?

Un premier axe est de remplacer le téléphone. En effet, vous avec peut être choisi le mauvais device par rapport à votre usage. Idéalement, les projections d’autonomie permettront d’effectuer un benchmark pour éviter un changement trop tardif.

Ensuite, peut-être que le scénario n’est pas réaliste. Il sera alors nécessaire de repenser à l’usage : est-ce que la video conférence via mobile est vraiment viable ? Malheureusement, cette approche est générablement écartée car on veut toujours plus de service numérique sur les devices. Les approches suivantes seront alors plus adaptées.

Le budget unitaire va être utile pour appliquer une meilleure stratégie :

  • Sur des applications du système (caméra par exemple), on étudiera la possibilité de paramètrer différement l’application pour trouver des optimisations et réduire la consommation pour rester dans le budget défini.
  • Pour d’autres applications comme les navigateurs on pourra benchmarker des applications alternatives. Il est probable par exemple que les solutions de visioconférence ne se valent pas toutes en se qui concerne la consommation d’énergie.
  • Pour les applications développées par un tiers et que vous maitrisez, vous pourrez intégrer un critère dans les cahiers des charges pour respecter le budget souhaité.
  • Enfin pour les applications ou sites web développés en interne, vous pourrez intégrer GREENSPECTOR et les budgets dans l’usine logicielle pour optimiser au plus tôt la consommation de vos applications et ainsi, détecter les problèmes d’énergie et de performance avant vos utilisateurs.

Lancer la mesure de consommation d’une application depuis votre PIC / usine logicielle

Reading Time: 2 minutes

Quelques indications sont nécessaires pour bien commencer une mesure de l’énergie et de ressource avec GREENSPECTOR. Trois notions sont à prendre en compte : où va être exécuter les tests (OÙ), quels sont les tests que je vais exécuter (QUOI) et comment je vais exécuter ces tests (COMMENT).

Plusieurs moyens de lancer les tests (COMMENT) sont possibles :

  • L’interface Web GREENSPECTOR
  • La ligne de commande avec le Testrunner
  • La ligne de commande avec le CLI
  • Manuellement avec le Free Runner Test
  • Le plugin Jenkins

Mesurer la consommation d’une application depuis votre PIC / usine logicielle

Une fois GREENSPECTOR intégré dans vos tests automatisés, il est possible de les lancer sur un banc de test Greenspector via un plugin Jenkins ou via le CLI installé sur votre PIC.

1) Si cela n’est pas déjà fait, installez le CLI (Voir le tutoriel « Benchmarker une application sur le Power Test Cloud« )

2) Ouvrez une ligne de commande à la racine du projet UIAutomator (Effectuez les actions 1 à 7 du précédent tutoriel « Benchmarker une application sur le Power Test Cloud« )

3) Envoyez les tests sur le cloud via la commande suivante :

gspt tb ct --apkFiles app/build/outputs/apk/app-debug-androidTest.apk --apkFiles app/build/outputs/apk/app-debug.apk --testPackages com.greenspector.sample.UIautomator --monitoredPackage com.android.chrome

4) Le job peut être suivi dans l’interface GREENSPECTOR comme dans le tutoriel « Benchmarker une application sur le Power Test Cloud« )

Remarque: Le principe de ce lancement s’applique dans le plugin Jenkins

Découvrez nos autres tutoriels :

Mesurer la consommation de ressources d’une application via des tests automatisés

Reading Time: 2 minutes

Quelques indications sont nécessaires pour bien commencer une mesure de l’énergie et de ressource avec GREENSPECTOR. Trois notions sont à prendre en compte : où va être exécuter les tests (OÙ), quels sont les tests que je vais exécuter (QUOI) et comment je vais exécuter ces tests (COMMENT).

Plusieurs moyens de lancer les tests (COMMENT) sont possibles :

  • L’interface Web GREENSPECTOR
  • La ligne de commande avec le Testrunner
  • La ligne de commande avec le CLI
  • Manuellement avec le Free Runner Test
  • Le plugin Jenkins

Mesurer la consommation de ressources d’une application via des tests automatisés

Afin de mieux caractériser la consommation d’une application, vous pouvez intégrer l’API GREENSPECTOR dans vos tests automatisés. Vous pourrez exécuter ces tests depuis votre environnement habituel (Android Studio) ou à l’aide du Test Runner GREENSPECTOR sur votre téléphone local. Par la suite, vous pourrez utiliser ces tests sur le Power Test Cloud.

1) Téléchargez l’API Android GREENSPECTOR (Meter API Android) sur la liste des modules ainsi que les exemples.

2) Installez la librairie AAR dans votre répertoire Maven :

mvn install:install-file
-Dfile=greenspector-probe-android-[version].aar
-DgroupId=com.greenspector.probe.android
-DartifactId=greenspector-probe-android
-Dversion=[version]
-Dpackaging=aar

3) Décompressez les exemples

4) Ouvrez le projet UIAutomator dans Android Studio

5) Ouvrez le fichier GreenspectorUIAutomator.java et éditez les informations suivantes :

{{% note %}}

  • APPLICATION : Même nom que celle configurée dans l’interface GREENSPECTOR;
  • VERSION : Même version que celle configurée dans l’interface GREENSPECTOR;
  • URL : URL de votre instance « https://my-instance.greenspector.com/api« ;
  • PRIVATETOKEN : Votre token trouvé dans vos préférences depuis votre interface GREENSPECTOR;
    {{% /note %}}

6) Connectez votre téléphone au même réseau Wifi que votre plateforme

7) Dans une interface CLI ,tapez la commande suivante :

adb tcpip 5555

8) Débranchez le câble et recherchez l’adresse IP de votre smartphone dans les paramètres.

9) Connectez-vous aux téléphones avec la commande suivante :

adb connect [IP]

10) Cliquez droit sur la classe GreenspectorUIAutomator et lancez le test (Run…).

Le test se lance sur votre mobile, vous retrouverez les résultats de vos mesures au sein de votre interface GREENSPECTOR.


Découvrez nos autres tutoriels :

Explorer manuellement une application avec le Free Runner Test

Reading Time: 3 minutes

Quelques indications sont nécessaires pour bien commencer une mesure de l’énergie et de ressource avec GREENSPECTOR. Trois notions sont à prendre en compte : où va être exécuter les tests (OÙ), quels sont les tests que je vais exécuter (QUOI) et comment je vais exécuter ces tests (COMMENT).

Plusieurs moyens de lancer les tests (COMMENT) sont possibles :

  • L’interface Web GREENSPECTOR
  • La ligne de commande avec le Testrunner
  • La ligne de commande avec le CLI
  • Manuellement avec le Free Runner Test
  • Le plugin Jenkins

Explorer manuellement une application avec le Free Runner Test

Il est possible de réaliser des tests manuels sur votre téléphone. Le Free Runner Test est une application Android qui permet de réaliser des mesures de ressource en même temps que vous réalisez vos tests manuels.

1) Si cela n’est pas fait, créez une application depuis l’interface GREENSPECTOR.

2) Sur votre téléphone, autorisez l’installation d’application externe au Store : dans les paramètres Options Avancées > Sécurité > Sources Inconnues.

3) Accédez à la page des modules depuis l’interface Greenspector et cliquez sur le Free Runner.

4) Suivez l’installation de l’application sur votre téléphone.

5) Lancez l’application Free Runner Test une fois celle-ci installée.

6) Récupérez votre token dans vos préférences au sein de l’interface GREENSPECTOR.

7) Accédez aux paramètres de l’application (Parameters > General) et configurez les informations relatives à votre instance GREENSPECTOR (l’url de votre instance : https://[instance]/api) ainsi que votre token).

8) Revenez à la page d’accueil de l’application Free Runner Test et entrez les informations

Application Name et Version : Mêmes informations que l’appplication créée depuis l’interface GREENSPECTOR

Package name to measure : Optionnel

Test name : Définissez un nom qui représente le test de vous souhaitez faire (Achat, recherche…). Vous le retrouverez dans l’interface GREENSPECTOR.

Test Duration : Vous pouvez définir une durée maximum de test en secondes. Au bout de ce temps prédéfini, la mesure s’arrêtera automatiquement. Vous pouvez aussi arrêter la mesure en appuyant simultanément sur les touches volume bas et haut de votre téléphone.
9) Quand vous êtes prêt, appuyez sur Start. L’application Free Runner Test se met en tâche de fond et la mesure se lance.

10) Effectuez vos actions sur l’application que vous souhaitez mesurer.

11) Une fois que la mesure est terminée, l’application Free Runner Test revient en avant plan. Les résultats de la mesure sont alors disponibles dans votre interface Web GREENSPECTOR.Découvrez nos autres tutoriels :

Benchmarker une application sur le Power Test Cloud

Reading Time: 3 minutes

Cet article fait partie d’une série de tutoriels qui vont vous expliquer différents cas d’usage de la mesure.

Quelques indications sont nécessaires pour bien commencer une mesure de l’énergie et de ressource avec GREENSPECTOR. Trois notions sont à prendre en compte : où va être exécuter les tests (OÙ), quels sont les tests que je vais exécuter (QUOI) et comment je vais exécuter ces tests (COMMENT).

Plusieurs moyens de lancer les tests (COMMENT) sont possibles :

  • L’interface Web GREENSPECTOR
  • La ligne de commande avec le Testrunner
  • La ligne de commande avec le CLI
  • Manuellement avec le Free Runner Test
  • Le plugin Jenkins

Benchmarker une application sur le Power Test Cloud

Le plus simple pour débuter est d’utiliser un smartphone disponible dans le Power Test Cloud (OÙ) et de lancer un test de Benchmark (QUOI). L’avantage du banc de test est d’avoir un device tout de suite disponible et configuré, ce qui permet d’obtenir des mesures très stables. À noter en fonction de la licence GREENSPECTOR, il est possible que ce banc de test soit installé au sein de vos locaux (et pas dans le cloud). Le benchmark permet de simuler l’application dans différents états (Lancement, inactivité, mise en tâche de fond…). Pour lancer les tests, nous allons utiliser le CLI sur une application.

1) Depuis l’interface GREENSPECTOR, créez une application MyFirstApp avec la version 1

2) Récupérez votre application sous forme d’APK ou téléchargez-en une sur un site comme Apkpure

3) Téléchargez le CLI sur votre plateforme et placez-le dans un répertoire. Vous pouvez renommer le fichier (par exemple gspt)

4) Vous pouvez mettre le path du CLI dans votre path pour simplifier le lancement

5) Ouvrez la ligne de commande dans le répertoire où se trouve l’application et lancez la commande

gspt init

L’invite de commande vous demande le token. Vous le trouverez dans vos préférences au sein de l’interface GREENSPECTOR.

6) Lancez la ligne de commande qui initialise un projet GREENSPECTOR en local

gspt ipc initprojectconfiguration --application MyFirstApp --version 1

7) Lancez la commande suivante pour choisir un smartphone

gspt testbench set-environment

8) Lancez le benchmark via la commande suivante:

gspt testbench benchmark-apk --apkFiles Instagram_v33.0.0.11.92_apkpure.com.apk  --iterations 3

9) Vous pouvez voir l’état d’avancement depuis l’interface GREENSPECTOR dans jobs

10) Quand le job est fini, vous pouvez voir les résultats :

Astuce : À chaque usage du CLI, vous pouvez ajouter –help pour avoir des indications sur les options. Pour rendre plus rapide la saisie, vous pourrez utiliser les alias de commande (-a au lieu de –application par exemple).

Découvrez prochainement nos autres tutoriels :

Intégrer les résultats Greenspector dans ses tableaux de bord via une API

Reading Time: 2 minutes

Lancer des mesures et avoir des préconisations d’amélioration via le dashboard Greenspector c’est bien, intégrer ces résultats dans son usine logicielle et ses propres dashboards, c’est mieux. C’est maintenant possible via l’API Greenspector.

La documentation de l’API est disponible à l’adresse https://[URL de votre instance Greenspector]/api/ui

Vous pouvez utiliser cette documentation pour tester l’API. Pour cela il est nécessaire de configurer votre token d’accès. Il est disponible dans vos préférences dans l’interface Greenspector.

Dans l’interface Swagger, cliquez sur Authorize.

Vous pouvez alors coller le token :

Une fois validé, vous êtes connecté et pouvez vous déconnecter à tout moment.

Pour tester l’API, vous devez récupérer l’ID du rapport à récupérer. Il est disponible dans l’URL du dashboard (Chiffres derrière /version/)

Vous pouvez alors entrer l’ID dans l’interface Swagger et exécuter la requête.

Le code de retour 200 indique que tout s’est bien passé. Le résultat du JSON est affiché.

La commande curl peut être copiée est mise en place dans votre PIC pour récupérer les résultats. Pour plus d’informations sur les données, le contrat de l’API est disponible dans la même page en cliquant sur model.

Si vous avez des questions supplémentaires, n’hésitez pas à contacter notre service support.

Power Test Cloud, ou comment un non-expert peut mesurer la consommation énergétique de son application web ou mobile

Reading Time: 4 minutes

Vous êtes Développeur Android ? Web Designer ? Ou non développeuse comme moi ?
Savez-vous combien d’énergie est consommée par votre site web ou votre application mobile ? Et surtout, savez-vous comment les optimiser pour gagner en efficience ?
GREENSPECTOR intègre la fonctionnalité qui vous permet en quelques clics de lancer un test, de mesurer la consommation d’énergie et ainsi d’auditer votre application : le Power Test Cloud.

Continue reading « Power Test Cloud, ou comment un non-expert peut mesurer la consommation énergétique de son application web ou mobile »