[11 au 12 Décembre] Greenspector se mobilise lors de la semaine mondiale de la transition à Tech for Planet et aux World Efficiency Solutions à Paris

Reading Time: 2 minutes

Du 11 au 14 Décembre, Paris sera la capitale mondiale de la transition, accueillant le One Planet Summit ainsi que plusieurs autres évènements en parallèle tels que le Tech for Planet (le 11 décembre) ou les World Efficiency Solutions (du 12 au 14 décembre). GREENSPECTOR participe et se mobilise pour cette semaine Green.

Continue reading « [11 au 12 Décembre] Greenspector se mobilise lors de la semaine mondiale de la transition à Tech for Planet et aux World Efficiency Solutions à Paris »

Twitter Lite est-il si léger pour l’autonomie de votre batterie ?

Reading Time: 5 minutes

Au printemps dernier, Twitter a lancé Twitter Lite, qui est, comme son nom l’indique, une alternative plus légère à son application mobile.

Nous avons vu que de nombreux utilisateurs se demandaient si Twitter Lite respectait ses promesses: est-ce vraiment une version allégée ? Consomme-t-il moins de données? Diminue-t-il vraiment l’impact sur la batterie du téléphone?

GREENSPECTOR fournit un logiciel de benchmarking et un moyen de quantifier la consommation d’énergie des applications mobiles et web, nous avons donc voulu le vérifier par nous-mêmes.
Aujourd’hui, nous allons donc comparer Twitter Lite avec son aîné, l’application mobile native.

Présentation des challengers

Un mot sur les PWA (Progressive Web Applications)

Nous avons dit plus tôt que Twitter Lite était une Progressive Web Application, mais de quoi s’agit-il au juste?

Sur notre blog, nous vous avions déjà parlé des applications mobiles hybrides dans notre analyse de la consommation mémoire d’une application Cordova, qui sont des applications semi-natives dans le sens où il s’agit d’applications web qui s’exécutent dans une web-view au sein d’un conteneur natif.

Les PWA ne fonctionnent pas exactement de la même manière, ce sont des applications web mobiles d’un nouveau genre qui se veulent légères, rapides et fiables même dans de mauvaises conditions réseau. Elles s’exécutent à travers votre navigateur web (Google Chrome pour l’instant) comme des applications web normales, vous n’avez donc rien à installer d’autre.
Elles suivent un ensemble de pratiques normalisées en utilisant les derniers standards et technologies Web telles que le offline storage, l’API push-notification et les service workers pour fournir une expérience aussi proche que possible des « vraies » applications.

Google fournit un outil appelé Lighthouse qui permet de valider la performance et l’application des bonnes pratiques des PWA. Vous pouvez consulter l’évolution des metriques de Twitter Lite depuis son lancement.

Méthodologie de benchmark

Outils

Pour collecter toutes les données dont nous avions besoin, nous avons utilisé un Nexus 5 de Google sous Android 5 Lollipop installé dans le GREENSPECTOR Power Test Cloud. Le Power Test Cloud est une plate-forme automatisée que nous avons conçue pour réaliser des benchmarks d’applications web et mobile sur des téléphones physiques dans le cloud, selon les cas de test que nous avons standardisés:

  • Référence -> mesure la consommation de ressources sans aucune application
  • Lancement de l’Application -> mesure la consommation de ressources lors du lancement de l’application
  • Application Idle au premier plan -> mesure la consommation de ressources pendant que l’application est inactive au premier plan
  • Application Idle en arrière plan -> mesure la consommation de ressources pendant que l’application est inactive et mise en arrière-plan

Conditions des mesures:

Nous avons mesuré chacun des cas de test précédents sous différents paramètres qui sont notés comme suit:

Application Twitter pour Android (v7.22.0):

  • Application Twitter avec paramètres par défaut -> Twitter
  • Application Twitter avec paramètres éconômes (désactivation de l’aperçu des images/videos, etc) -> Twitter_datasaver

Twitter Lite (https://mobile.twitter.com):

  • Twitter Lite avec paramètres par défaut -> TwitterLite
  • Twitter Lite avec paramètres éconômes -> TwitterLite_datasaver

Chaque cas de test a été exécuté au moins cinq fois sur ces configurations afin d’obtenir des mesures stables et fiables.
La batterie a été chargée entre 30% et 80% de sa pleine capacité et tous les services inutiles – tels que Bluetooth, GPS, reconnaissance vocale (alias « OK Google »), etc – ont été désactivés, réduisant autant que possible le « bruit » dans les résultats.

Mesures, FIGHT!

Première manche: Twitter vs Twitter Lite (paramètres par défaut)

Résultats globaux

Ce tête-à-tête donne des résultats intéressants. Twitter Lite PWA semble consommer environ 10% de moins de batterie que son équivalent natif. D’autre part, les résultats montrent une augmentation de 116MB sur la consommation de mémoire et une autre augmentation de 4000% sur l’activité réseau. Regardons les détails pour mieux comprendre d’où vient cette différence.

Démarrage

Tout d’abord, nous vérifions les résultats de l’étape de chargement:

Comme nous pouvons le voir, Twitter Lite consomme 480KB de données réseau en plus par rapport à l’application native. C’est logique, dans ce cas, le navigateur Google Chrome exécute la PWA doit charger tout le code et la logique de l’application, puis les données du fil d’actualité. Avec l’application native, il n’y a que ce dernier à charger.

Etat inactif

Ce que nous observons de l’état inactif au premier plan (les résultats de l’état inactif en arrière-plan ne sont pas considérés ici, nous n’avons pas de point de comparaison sur la PWA) confirme ce que nous venons de voir. Twitter Lite affiche une consommation de données un peu plus élevée mais assez équivalente à celle de l’application native. En ce qui concerne l’énergie, la consommation du PWA est légèrement supérieure (environ 12% de plus) à celle de l’application mobile.

Seconde manche: Twitter vs Twitter Lite (paramètres éconômes)

Démarrage

Lorsque l’économiseur de données est actif, nous observons un gain d’environ 50% sur la quantité de données transférées pendant l’étape de chargement de l’application dans les deux cas. Pourtant, la consommation de ressources Twitter Lite est bien supérieure à celle de l’application Twitter.
De plus, la version Lite draine presque deux fois plus de capacité de batterie durant cette étape que l’application native.

Etat inactif

Ici, on observe les mêmes comportements que précédemment. L’application Lite consomme plus d’énergie que l’application native, près de 25%, et deux fois plus de données lorsque celle-ci est inactive au premier plan.

Conclusion

L’ambition de Twitter Lite était d’être léger et donc de contribuer à réduire la consommation de ressources, principalement la bande passante, mais nous aurions pu supposer qu’il ait également un avantage sur la durée de vie de la batterie.
Comme nous l’avons vu à travers les mesures et leurs comparaisons, Twitter Lite consomme plus de ressources et d’énergie que son équivalent natif dans tous les scénarios que nous avons testés. Le seul avantage d’utiliser la version Lite est de ne pas avoir à installer une application sur votre téléphone. L’application mobile remporte ce match, mais cela ne signifie pas que la PWA n’est pas légère, elle l’est, les chiffres ne sont pas si élevés après tout, cela signifie juste qu’elle n’est pas plus légère.

Consommation énergétique de l’IoT: mesurer Raspberry avec Arduino !

Reading Time: 3 minutes

Lors du développement d’un objet connecté, l’autonomie est un de critères les plus importants à tester. Ne pas mesurer la consommation énergétique do votre plateforme peut potentiellement mener à certains problèmes, comme:

  • Une insatisfaction des utilisateurs
  • Une baisse de la durée de vie d’une batterie
  • Une augmentation du coût de maintenance de la plateforme

Mais comment pouvons-nous donc mesurer l’énergie ?

Sur ce blog, nous avons déjà expliqué plusieurs fois comment mesurer l’énergie avec uniquement un logiciel, plus particulièrement sur Android. Mais la mesure sur plateforme IoT n’est pas si simple : pas de sonde énergétique embarquée, pas d’API… Il faudra donc faire des mesures du matériel.

Explications électriques

Pour mesurer la consommation énergétique il faut utiliser un shunt. C’est un resistor qui est à placer dans votre circuit électrique : quand le courant passe à travers le resistor, une tension différentielle se crée. Et l’énergie peut se calculer avec la loi d’Ohm : Energie = Tension x Courant.

On intègre ce shunt de deux manières : haute tension et basse tension. Le fait de choisir haute ou basse dépend de la position du shunt, selon la batterie et l’énergie à l’intérieur. La position « Haute » est localisée entre le point positif de la batterie et votre charge (plateforme), et la « Basse » se positionne entre la masse de batterie et la masse de plateforme.

Le côté Basse tension présente quelques désavantages, plus particulièrement liés à la commutation de la charge qui crée des problèmes de boucle de masse. C’est généralement le cas pour l’IoT, avec les capteurs, régulateurs, etc… Choisissons plutôt donc de mesurer le côté Haute tension !

Mesure rapide d’une plateforme IoT

Arduino fournit un tutoriel axé sur la mesure d’énergie avec une breakout board INA219 et une précision à 1%.

La câblage est plûtot facile à réaliser en utilisant une breadboard et en suivant le tutoriel Adafruit.

Pour tester votre installation, vous pouvez essayer avec un exemple. Vous obtiendrez alors quatre informations :

  • Tension du Bus : la tension totale perçue par le circuit pendant un test. (Tension d’alimentation – tension shunt)
  • Tension du Shunt : et bien… la tension du shunt !
  • Courant : le courant dérivé via la loi d’Ohm et la mesure de la tension
  • Tension sur charge : la tension globale

Mesure d’un objet IoT

Nous pouvons maintenant intégrer la plateforme IoT et pour cela nous avons choisi un Raspberry, ce qui est plutôt cool à mesurer avec un Arduino !

La première difficulté rencontrée est l’insertion du shunt entre le point d’énergie positif de la batterie et le Vin du Raspberry.
Dans un premier temps, vous pouvez l’intégrer directement sur la board Raspberry, en coupant le circuit. Mais nous avons choisi une option moins intrusive, consistant à l’intégrer dans le câble d’alimentation. Raspberry étant alimenté par USB, nous devons donc placer le shunt entre le V+ de l’ordinateur et le V+ du Raspberry :

En situation réelle, cela donne cela :

Vous devez maintenant lancer le code exemple pour obtenir le courant et la tension de la plateforme. Pour un Raspberry sans aucune configuration particulière (sans OS, sans carte) j’ai obtenu une puissance moyenne de 230 mW.

Ensuite, vous n’avez plus qu’à initier les mesures de vos différents projets ! Par exemple, vous verrez ici comment j’ai mesuré une station météo Arduino.

Découvrez « Dill Pickle », la version 1.13.0 de GREENSPECTOR !

Reading Time: < 1 minute

Suite logique des versions Avocado, Broccoli et Cucumber, l’équipe GREENSPECTOR a le plaisir de vous présenter la toute nouvelle Release 1.13.0 Dill Pickle ! Vous trouverez le détail ci-dessous des mises à jour et dernières features implémentées.

Continue reading « Découvrez « Dill Pickle », la version 1.13.0 de GREENSPECTOR ! »

[Retour d’expérience] Le projet ETG du Groupe La Poste

Reading Time: 3 minutes

La Poste est devenu opérateur national pour le passage du code de la route depuis 2016. Cet examen appelé ETG (Examen Technique Général) se traduit par la mise à disposition d’une tablette dans une salle d’examen d’un bureau de poste et d’une série de questions posées à chaque candidat. Chaque bureau de poste est donc équipé de tablette de type Galaxy Tab A.

Continue reading « [Retour d’expérience] Le projet ETG du Groupe La Poste »

Premiers pas avec UI Automator : votre 1er scénario de test

Reading Time: 4 minutes

UI Auto…quoi ?

Comme son nom l’indique, UI Automator est un framework fourni par Android permettant d’exécuter des tests fonctionnels d’interface utilisateur (UI pour User Interface en anglais) de façon automatisée.

Ce framework permet d’interagir avec les éléments visibles sur l’écran du smartphone : cliquer sur un bouton, remplir un champ texte, scroller, etc.
Grâce à UI Automator, vous pouvez par exemple lancer une application, remplir un formulaire de login, naviguer dans les menus…

Écrivons ensemble un premier scénario de test avec UI Automator !
Notre objectif sera modeste : lancer une vidéo depuis l’application YouTube pour Android.

UI Automator, Espresso, Appium…

Dans le framework Android, vous trouverez aussi Espresso : quelle est la différence ?

UI Automator est plutôt orienté tests « boîte noire » : vous pouvez tester n’importe quelle application (même si vous n’avez pas le code) ou même accéder à des paramètres systèmes d’Android (par exemple le panneau de configuration).

Espresso, lui est plutôt orienté tests « boîte blanche » : vous devez avoir le code de l’application à tester, vous pouvez effectuer des assertions plus fines (par exemple sur la création d’activité dans l’application).

Il existe également d’autres outils, comme Appium, mais qui ne sont pas intégrés dans le framework Android.
Ils ont l’avantage d’offrir des fonctionnalités en plus et des couches d’abstractions supplémentaires. C’est cependant au prix d’une certaines complexité de mise en place.

Vous l’aurez compris, UI Automator est pour nous le plus adapté et le plus simple pour commencer rapidement !

Première étape : mettre en place l’environnement de travail

Les tests UI Automator font partie de la famille des test instrumentés : ils doivent être exécutés sur un smartphone ou sur un émulateur Android.
Pendant le test, deux APK s’exécutent au sein du même processus : un premier APK pour l’application à tester et un deuxième APK pour le test.

Vous avez donc besoin d’une application (et d’un scénario !) à tester.

Le code source d’une application Android est usuellement organisé de la façon suivante :

module
|---src
    |---androidTest
    |---main
    |---test

Premier cas : vous êtes le développeur de l’application à tester.
La solution la plus simple consiste alors à développer les tests dans le même module que l’application.
Le dossier main contiendra alors le code source de votre application et le dossier androidTest vos tests UI Automator.

Deuxième cas : vous n’avez pas le code source de l’application à tester.
Il vous suffit alors de créer un nouveau module : le dossier main sera vide et, comme précédemment, le dossier androidTest contiendra vos test UI Automator.

Dans le fichier build.gradle du module, ajoutez les configurations suivantes (UI Automator fonctionne avec AndroidJUnitRunner) :

android {
    ...
    defaultConfig {
        ...
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    ...
}
dependencies {
    ...
    androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.2'
    androidTestCompile 'com.android.support.test:runner:0.5'
}

Après vous être assuré que le projet compile correctement, il est temps d’ajouter une nouvelle classe dans module/src/androidTest :

@RunWith(AndroidJUnit4.class)
public class YouTubeTest {
    @Test
    public void watchVideo() throws Exception {
        // TODO
    }
}

Tout est maintenant prêt pour l’implémentation du scénario de test !

Deuxième étape : écrire les tests

Quelques petites précisions avant de se lancer…

UI Automator permet d’interagir avec les éléments visibles sur l’écran.
Chaque élément possède un certain nombre de propriétés, parmi lesquelles : content-description, class, resource-id, text.

UI Automator permet de rechercher un élément vérifiant une propriété donnée.
Par exemple, pour accéder au bouton Valider affiché sur votre écran, vous pouvez rechercher l’élément dont la propriété text vaut Valider.
Mais vous pouvez aussi être plus spécifique, par exemple : l’élément dont la class est android.widget.EditText et la content-description est text_name.

La (ou les) propriété(s) utilisée(s) pour rechercher un élément a son importance.
Par exemple, méfiez-vous des libellés, notamment si votre application est disponible en plusieurs langues !

Afin de connaître les propriétés des éléments visibles sur l’écran, il est très pratique d’utiliser l’outil Android uiautomatorviewer (que vous trouverez dans le répertoire tools de votre SDK Android).
Une fois lancé, cet outil permet de faire des captures d’écran d’un smartphone Android.
À chaque capture d’écran est associée un arbre représentant la hiérarchie des éléments visibles, avec leurs propriétés respectives.

Revenons à notre scénario de test, pour lequel nous nous proposons d’effectuer les actions suivantes :

  • lancer l’application YouTube ;
  • cliquer sur la loupe pour effectuer une recherche ;
  • indiquer le texte « greenspector » dans le champ de recherche ;
  • lancer la vidéo « Power Test Cloud – Greenspector (FR) » ;
  • regarder les 20 premières secondes de la vidéo.

Avant de démarrer toute interaction avec les éléments sur l’écran, il faut instancier un objet UiDevice qui représentera l’état actuel de l’écran du smartphone.

UiDevice mDevice = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation());

Commençons par lancer l’application YouTube, comme expliqué dans la documentation Android.
L’objet de cet article étant de dérouler quelques fonctionnalités les plus simples d’UI Automator, cette étape n’est pas détaillée.

L’étape suivante consiste à cliquer sur la loupe pour effectuer une recherche.
Après avoir repéré le resource-id de la loupe grâce à uiautomatorviewer, nous utilisons la méthode waitForExists permettant d’attendre que l’élément apparaisse avant de cliquer sur l’objet.

UiObject icon = mDevice.findObject(new UiSelector().resourceId("com.google.android.youtube:id/menu_search"));
icon.waitForExists(TIMEOUT);
icon.click();

Nous nous servons ensuite de la méthode setText pour renseigner le mot clé de recherche souhaité.

UiObject editText = mDevice.findObject(new UiSelector().text("Search YouTube"));
editText.waitForExists(TIMEOUT);
editText.setText("greenspector");
mDevice.pressEnter();

Précédemment, nous n’avons utilisé qu’un seul critère pour rechercher les éléments sur l’écran.
Mais il est possible d’en combiner plusieurs (si certaines propriétés ont la même valeur pour plusieurs éléments), par exemple :

UiObject video = mDevice.findObject(new UiSelector()
        .resourceId("com.google.android.youtube:id/title")
        .text("Power Test Cloud - Greenspector (FR)"));

Enfin, attendons quelques secondes en regardant le début de la vidéo.

synchronized (mDevice) {
    mDevice.wait(20000);
}

Troisième étape : exécuter les tests

Afin d’exécuter les tests, il est nécessaire d’être connecté via ADB à un smartphone (soit un smartphone physique « réel », soit un émulateur Android).
Le lancement peut s’effectuer directement depuis Android Studio, ou bien en ligne de commande avec ADB.

Premier cas : depuis Android Studio.

Se rendre dans le menu Run, puis Edit configurations.
Cliquer sur le signe + pour ajouter une configuration, sélectionner le modèle Android Instrumented Tests.
Adapter la configuration avec le nom du module à tester, le type de test, le smartphone (réel ou émulateur).

Deuxième cas : en ligne de commande avec ADB.

Tout d’abord, compiler l’application ainsi que les tests, par exemple en utilisant les tâches assemble et assembleAndroidTest du wrapper Gradle :

$ ./gradlew clean assemble assembleAndroidTest

Puis installer sur le smartphone les fichiers .apk générés :

$ adb install module/build/outputs/apk/module-debug.apk
$ adb install module/build/outputs/apk/module-debug-androidTest.apk

Enfin, lancer le test :

$ adb shell am instrument com.package.test/android.test.InstrumentationTestRunner

Conclusion

Et voilà ! Objectif atteint pour ce premier test simple UI Automator, c’est maintenant à vous de jouer !

Pour aller plus loin

Documentation Android sur UI Automator.

Documentation Android sur ADB.

Faut-il changer son fond d’écran pour consommer moins de batterie ?

Reading Time: 7 minutes

L’influence des couleurs sur la consommation d’énergie des smartphones ou des tablettes est un débat récurrent. On entend beaucoup d’affirmations péremptoires (du type «choisis un fond noir pour consommer moins») qui bien souvent ne tiennent pas compte des technologies sous-jacentes – pourtant très diverses – ou d’études précises sur le sujet. Alors comme d’habitude, en tant qu’obsédé des mesures d’énergie sur appareils mobiles, j’ai voulu en savoir plus.

Pourquoi cette étude ?

La réduction des consommations d’énergie des appareils mobiles est un leitmotiv pour tous les constructeurs. En effet,l’autonomie est un des critères de choix principaux avant l’achat d’un appareil. Les fabricants travaillent donc à optimiser tous les composants: amélioration de l’efficience des processeurs, technologies de senseurs moins consommatrices, augmentation de la capacité des batteries… Lorsque j’ai mis au point la méthodologie de mesure de consommation d’énergie des logiciels chez GREENSPECTOR, j’ai été amené à étudier tous les paramètres qui peuvent influencer cette consommation. Oui, les écrans en font partie, mais il me semblait intéressant de creuser un peu ce sujet. Allons-y.

Méthode de test

Pour mesurer les comportements énergétiques des écrans, je crée une petite batterie de tests qui fait varier la luminosité de l’écran par paliers (0%, 25%, 50%, 75% et 100%) et d’afficher une page complète d’une certaine couleur (Rouge, Vert, Bleu, Noir, Blanc). Puis j’exécute les tests sur les divers appareils dont nous disposons dans notre Power Test Cloud. Les consommations d’énergie (et d’autres ressources) sont mesurées par les sondes GREENSPECTOR qui sont installées sur ces appareils. Puis je récupère les résultats des mesures, et je trace des jolis graphes pour les interpréter plus facilement.

Premières mesures sur Nexus 6

Je commence par mon appareil favori, le Motorola Nexus 6 dont l’écran utilise la technologie AMOLED. On obtient la cartographie suivante des consommations suivantes : en abscisse les différentes couleurs affichées, dans la profondeur les variations de luminosité, et sur l’axe vertical, on retrouve la consommation de batterie qui en résulte :

Premières conclusions

  • La consommation est plus faible pour le noir. Je suis content, car cela confirme d’autres études telle que celle-ci ou celle-là, et cela correspond aussi à ce que nous attendons théoriquement de la technologie AMOLED.
  • La différence de consommation entre les couleurs est plus faible quand la luminosité est basse. Cela semble intuitif, mais la mesure permet de le confirmer.
  • La consommation est croissante dans l’ordre suivant : Noir < Vert < Rouge < Blanc < Bleu
  • Les différences peuvent être significatives : à luminosité maximale, le bleu consomme 78% d’énergie de plus que le noir (donc un écran bleu avec une luminosité à 100 % videra la batterie en 5h30, alors qu’un écran noir avec la même luminosité videra la batterie en 12h !).

Quelques explications

Le Nexus 6 se base sur une technologie AMOLED : Matrice Active LED ou de l’anglais Active-Matrix Organic Light-Emitting Diode. C’est une technologie qui lie la technologie OLED (diode électroluminescente organique) et celle des matrices actives (commande de chaque pixel indépendamment). C’est une alternative à la technologie historique des LCD (écrans à Cristaux Liquides).
Le noir est facile à réaliser pour les écrans AMOLED car il faut juste éteindre des pixels. C’est pourquoi le noir consomme moins. Le blanc est une composition du bleu, rouge et vert, on le retrouve donc dans la moyenne des couleurs.

Mesure sur Samsung Galaxy S6

Afin de confirmer ce comportement énergétique, je mesure celui du Galaxy S6 qui exploite une technologie dérivée, baptisée Super AMOLED:

On observe le même comportement avec une légère différence : cette fois c’est le blanc qui consomme le plus (44% de plus que le noir) en devançant légèrement le bleu. Globalement les constats sont les mêmes : le noir est beaucoup moins consommateur, et le blanc et le bleu consomment plus que les autres couleurs.

Mesure sur Nexus 5

Pour les AMOLED, c’est clair. Mais qu’en est-il pour les autres technologies ? Prenons par exemple le Nexus 5 qui est sur une technologie LCD IPS+:

On voit clairement qu’avec un écran LCD IPS+, la couleur ne joue pas sur la consommation. On peut juste noter qu’à la luminosité maximale, le blanc sera très légèrement plus consommateur (4% d’écart soit 10 à 15 mn de différence sur l’autonomie théorique).
La technologie IPS (In-Plane Switching) est une technologie LCD. IPS+ ajoute des LED pour améliorer l’affichage. Sur les écrans LCD la théorie veut que la consommation soit indépendante de la couleur : tout est bon donc ! Au passage, notons que la technologie Retina des écrans Apple reposait jusqu’à présent sur une technologie IPS, mais il semble que cela va changer avec le nouvel iPhone 8S basé sur un écran OLED : designers d’apps iOS, prenez-en note.

Mesure sur Nexus 9

La mesure sur une tablette Nexus 9, elle aussi basée sur une technologie IPS donne les résultats suivants :

Les constats sont les mêmes que le Nexus 5, avec un écart de 2% à peine entre les couleurs.

Mesure sur Pixel C

En effectuant les mesures sur la tablette Google PixelC, modèle récent en technologie toujours LCD mais dans sa variante LTPS , on obtient ceci :

Il y a toujours une indépendance globale de la consommation de batterie vis-à-vis de la couleur. Cependant une couleur se détache légèrement: l’impact du blanc à luminosité maximale est 12% plus fort que celui du noir (soit 9h d’autonomie en noir contre 8h en blanc).
Le LCD LTPS (Low Temperature Poly-Silicon) est en fait une technologie Thin Film Transistor (TFT) avec une technologie à matrice active (comme les AMOLED). La différence sur les blancs provient probablement de la possibilité d’activer ou non les pixels.

Comparaison pour l’utilisateur

Maintenant que nous avons fait ces quelques tests, essayons de comparer ces différents modèles entre eux. Pour cela, prenons la consommation causée par l’affichage d’un écran blanc ou noir, divisée par la taille de l’écran. Pour exprimer la notion de taille, nous ne prenons pas sa surface (ce qui serait scientifiquement plus exact) mais simplement sa diagonale exprimée en pouces, car c’est la seule information dont dispose l’utilisateur : c’est donc celle-là qui lui importe lorsqu’il doit faire un choix :

Basé sur une technologie AMOLED, le Galaxy S6 a une consommation assez élevée. Idem pour le Pixel C avec sa technologie LTPS IPS (avec une augmentation exponentielle de la consommation quand la luminosité augmente). Dans les blancs, aucune technologie ne sort du lot en fait. Cette analyse est cependant à considérer avec précaution car nous n’avons pas mesuré beaucoup d’appareils.

En observant le comportement du noir, on retrouve l’intérêt de la technologie AMOLED dont la consommation est constante. Cependant à luminosité minimale (0 %), la consommation est plus importante que pour les autres technologies. Sur la plage 25% – 50% il n’y a pas de différence ; et l’avantage est clair pour des luminosités fortes où l’AMOLED tire son épingle du jeu.

Conclusion

Voici venu le moment de délivrer notre verdict. Faut-il choisir un fond d’écran noir pour son smartphone ou sa tablette ?

Utilisateurs

Si vous avez un écran AMOLED : oui ! Sans hésiter, choisissez pour votre fond d’écran une image avec une couleur prédominante noire. (Pour savoir quel type d’écran vous avez-, , regardez les spécifications sur le site du constructeur ou sur des sites dédiés). Si votre appareil est basé sur une technologie différente, vous pouvez toujours appliquer cette bonne pratique, cependant les gains d’autonomie seront moindres.
Dans la même logique, préférez les applications avec des interfaces ou des skins noirs (comme Google Black par exemple, ou le « mode nuit » de Twitter…). Et si votre application préférée ne propose pas de version « sombre », demandez-la à l’éditeur….
Pour tous : configurez la luminosité au minimum nécessaire pour assurer un bon confort d’utilisation. A 25% les technologies actuelles permettent souvent d’avoir un bon rendu. Évitez le 100% permanent – c’est une valeur que je réserve pour l’extérieur les jours ensoleillés. Si vous en disposez sur votre appareil, activez l’adaptation automatique de la luminosité… Mais vérifez cependant qu’elle n’est pas trop lumineuse, dans ce cas une configuration manuelle pourrait être plus efficiente.

Professionnels avec une flotte d’entreprise

Comme l’usage, les paramètres et les designs d’écran sont maîtrisés, il est possible de choisir le smartphone le plus adapté à l’usage. Ne vous fiez pas uniquement aux données constructeurs, vous pouvez effectuer des tests adaptés qui vous donneront une idée plus claire de l’autonomie réelle. Spécifiez des interfaces adaptées à vos téléphones. Si vous avez une flotte avec écrans AMOLED, il est important pour l’autonomie de vos appareils d’avoir des interfaces plutôt sombres que claires.

Designers

Le choix des couleurs dépend principalement de la charte graphique et de la marque mais la consommation d’énergie peut être un critère supplémentaire qui rendra votre design plus efficient. Il est intéressant de spécifier idéalement deux thèmes : un sombre et un gris. Cela permettra à l’utilisateur de choisir le thème le plus adapté à son appareil.

Développeurs

Afin d’adapter le design au contexte matériel, il est intéressant d’offrir à l’utilisateur le choix d’un thème plus sombre. Il faudra donc implémenter une option de modification de l’écran (facile avec des CMS, plus compliqué avec un framework).