Auteur : Olivier PHILIPPOT

Auteur des livres «Green Patterns», «Green IT - Gérer la consommation d’énergie de vos systèmes informatiques», ... Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, ...) Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels Porteur du projet de label Green Code Label Responsable du projet de l’étiquette énergétique WebEnergyArchive

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

Écouter de la musique sur son smartphone sans vider sa batterie c’est possible ?

Reading Time: 5 minutes

Votre batterie de téléphone se décharge trop vite ? Lors de l’achat de votre smartphone, le vendeur vous a promis une autonomie de 3 jours. Au bout d’un mois, vous le rechargez tous les jours (le téléphone, pas le vendeur). Peut-être que le vendeur (voir le constructeur de mèche avec lui) vous a menti sur les capacités réelles du téléphone ? Depuis l’affaire Volkswagen, nous ne sommes plus sûrs de rien… Mais le problème est probablement plus complexe. Vous n’utilisez peut-être pas correctement votre smartphone ou alors vous ne choisissez pas les services les plus adaptés à vos usages.

Article à lire avec quelques pistes à écouter

Musiques associées au thème de l’article et en fonction des goûts (Avec un rapport lointain au sujet, je l’avoue):

Damso – Batterie faible

MattLm – Battery Low

Metallica – Battery

La musique ou l’autonomie du téléphone, il faut choisir !

Il est loin le temps où vous écoutiez de la musique avec un lecteur MP3 ou même un lecteur cassette (pour les plus anciens d’entre nous). Maintenant, comme pour beaucoup d’usages, le smartphone a remplacé les différents lecteurs. On ne recharge plus de pile, mais on recharge la batterie du smartphone. Surtout que les moments sont nombreux au quotidien pour écouter de la musique : dans les transports en commun, au bureau, en voiture, le soir pour s’endormir…

Et les moyens d’écouter de la musique sont multiples : applications telles que Deezer, Live Radio, Youtube, MP3 stocké localement… Mais quel est le moyen le moins consommateur pour votre batterie ?

Protocole de mesure

Cette étude a été réalisée sur un smartphone Samsung Galaxy S7. Certains résultats peuvent varier sur différents devices, cependant ils permettent d’obtenir une tendance sur les services numériques qui ont été évalués.

Je veux choisir le service le moins consommateur

Vous avez donc toujours l’écran allumé et vous aimez particulièrement zapper entre les pistes. Considérons que vous êtes en Wi-Fi et que le volume du son est sur un niveau moyen.

Vous pouvez réduire jusqu’à 3h30 l’autonomie de votre téléphone en fonction du service utilisé. Il est généralement préférable de lire un MP3 que vous aurez stocké sur le téléphone. Vous n’utilisez pas de connexion internet, il y a donc moins de consommation qui en découle. Cependant, on observe que des applications comme Google Play auront tendance à consommer beaucoup plus d’autonomie qu’une lecture de musique sur Internet (Deezer, Spotify, Youtube…). Attention donc au choix du lecteur pour vos fichiers MP3. Android vous indiquera dans tous les cas les applications les plus consommatrices, vous pourrez alors faire votre choix.

La radio sur Internet n’est pas la solution la plus intéressante. On préférera des podcasts téléchargés de façon anticipée. En effet, la connexion internet couplée au navigateur font que les players radio ne ne sont pas les plus efficaces.

Et si je baisse le volume du son ?

Est-ce que le volume du son a une incidence sur la consommation de batterie ?

Oui et non, pour un niveau bas à moyen, la consommation ne varie pas beaucoup. Cependant, si vous utilisez votre smarphone comme une enceinte pour diffuser du son autour de vous, la consommation va être plus élevée (2h20 d’autonomie en moins). Si vous souhaitez écouter le son plus fort, le casque sera plus utile. N’attendez cependant pas à une réduction importante de la consommation avec un casque.

Et si je suis en mobilité avec de la 4G ?

Écouter de la musique dans les transports en commun où il n’y pas de réseau Wi-Fi, c’est bien ?

Et bien cela à un coût, et un coût non négligeable. Il est préférable de se connecter à un Hotspot Wi-Fi.

Le summum de la consommation étant d’écouter de la musique à fond sur l’application Youtube et le tout en 4G.

Et si j’éteins mon écran ?

Certaines applications permettent de passer en mode veille (ou en arrière-plan) et de laisser l’écran s’éteindre. Si c’est le cas, vous allez pouvoir économiser de la batterie. Le classement entre les services ne varie presque pas, vous diminuez “juste” la consommation. Deezer devient en effet le plus consommateur. Il semble que les traitements en tâche de fond ne soit pas assez optimisés au sein de l’application.

Et alors ?

Les usages varient, en fonction des goûts, des habitudes, du smartphone… et les consommations d’énergie aussi. On peut ainsi obtenir une “fourchette” d’autonomie en lecture continue de 4h à 13h.

Il est également possible de modifier ses habitudes pour augmenter l’autonomie. Pour aller plus loin dans cette démarche : identifier les applications consommatrices sur les OS et interpeller les éditeurs en leur demandant de s’améliorer est tout à fait possible.

C’est green ?

Oui, moins consommer d’énergie va permettre de réduire la sollicitation de la batterie, vous allez ainsi effectuer moins de cycles de charge, la longévité de la batterie sera plus élevée (ce sont les cycles de rechargement/déchargement qui l’use), et vous prolongerez ainsi la durée de vie globale de la batterie (qui est très polluante) voir de votre smartphone. CQFD.

Cette étude a été réalisée avec les outils GREENSPECTOR qui permettent de mesurer la consommation d’énergie des applications sur des téléphones. Pour plus d’information sur les méthodologies et les outils, je vous invite à parcours ce blog.

Top 2018 des navigateurs les moins énergivores pour votre smartphone

Reading Time: 5 minutes

Édition 2020 : quels sont les meilleurs navigateurs à utiliser sur mobile ?

Le navigateur internet est l’une des applications les plus critiques de votre smartphone. Il vous permet d’accéder à une multitude de services (Réseaux sociaux, actualités, jeux…). Il l’est d’autant plus lorsque vous ne souhaitez pas télécharger d’application et que vous préférez utiliser plutôt un site mobile. Votre navigateur est donc utilisé quasi en continu sur votre téléphone. Il est donc responsable d’une partie de la baisse de l’autonomie de votre smartphone.

Il est donc important de choisir le meilleur navigateur si vous souhaitez augmenter la durée de vie de votre smartphone.

Classement

Retrouvez la méthodologie de ce classement en fin d’article.

On obtient une autonomie des différents navigateurs qui varie entre 6h15 et 7h26. Cela peut sembler faible comme écart mais sur la durée totale de vie de votre smartphone, vous allez moins solliciter votre batterie et au final éviter l’obsolescence programmée. Sans compter une autonomie prolongée en fin de journée !

Les navigateurs en liste

Top 1 : Brave

Nouveau navigateur sur le marché, Brave souhaite faire de la vie privée un cheval de bataille. Il bloque automatiquement les publicités et les trackers. Cela semble payer sur l’autonomie puisque Brave prend la tête du classement avec 7h26mn d’autonomie estimée pour un usage web en continu.

Top2 : Firefox Focus

Mozilla publie Firefox Focus, un navigateur centré sur le respect de la vie privée : politique de confidentialité par défaut, blocage de tackers… Il semble que tout comme Brave, cette stratégie permet de gagner en autonomie.

Top 3 : Dolphin

Beaucoup moins connu que Chrome ou Firefox, Dolphin est pourtant très téléchargé. Avec des fonctionnalités similaires à Chrome ou Firefox, c’est un challenger à prendre très au sérieux.

Top 4 : Opera

Le navigateur Opera possède un bloqueur de publicité et la possibilité de créer une page d’accueil personnalisée avec un flux d’actualité. Sa version Mini existe mais n’a pas pu être évaluée dans cette étude. L’autonomie est respectable mais inférieure de 30 minutes par rapport à notre top 1 : Brave.

Top 5 : Ecosia

Basé sur Chromium, ce navigateur Allemand finance des actions de développement durable (comme la replantation d’arbre) avec les recherches effectuées par les utilisateurs. Même si l’autonomie n’est pas la pire, il est dommage que ce navigateur qui ne souhaite que le bien de la planète ne soit mieux placé dans le classement !

Top 6 : Samsung internet

Il s’agit du navigateur pré-installé sur tous les téléphones Samsung : Samsung Internet. Une consommation proche de celle d’Ecosia, probablement du au fait que le navigateur se base aussi sur Chromium.

Top 7 : Chrome

Chrome, le navigateur Android de Google, l’un des navigateurs les plus utilisé. La page d’accueil permet de consulter une sélection d’articles de presse. Il est dans le top 3 des pires navigateurs. Une certaine lourdeur provenant potentiellement de l’historique de la solution et de la non-priorité sur la vie privée.

Top 8 : Microsoft Edge

Le nouveau moteur de Microsoft est maintenant disponible sur Android. Peut-être que le bas du classement est du à la non-adaptation du moteur pour Android.

Top 9 : Firefox

Edité par Mozilla, le navigateur annonce une fiabilité sur le respect de la vie privée. Nous sommes cependant déçu de sa place dans ce classement.

Conclusion

Le choix du navigateur ne doit pas uniquement se faire sur l’autonomie, mais il s’agit d’un critère important. On observe que les 3 acteurs historiques et reconnus (Microsoft, Google et Mozilla) sont en bas du classement. Ceci est surement dû à l’ancienneté des applications, et donc à une surcharge pondérale du code (Obésiciel ou bloatware). Mais on peut aussi aller observer une course à la performance qui a été faite au détriment de l’autonomie. Peut-être que la course entre les 3 n’a pas été bénéfique à leur amélioration. On se souvient par exemple du benchmark de Microsoft Edge … avec uniquement Chrome et Firefox. Peut-être que l’arrivée de nouveaux navigateurs sérieux va changer la donne.

On peut noter que les différences d’autonomie entre navigateurs sont aussi liées à certaines fonctionnalités comme les fils d’actualités sur les pages d’accueil par défaut. L’utilisateur a cependant une marge de manoeuvre : désactiver ces fonctionnalités s’il ne les utilise pas.

A noter que la base open source Chromium qui se retrouve dans différents navigateurs (Brave, Samsung Internet, Ecosia…) n’est pas forcément la plus optimisée (On retrouve la plupart des navigateurs en milieu de classement.) Une optimisation du coeur (et potentiellement une meilleur intégration par les éditeurs) permettrait de diminuer la consommation de plusieurs navigateurs. On voit ici le potentiel de l’open source qui n’est pas utilisé pleinement.

Fait marquant de ce benchmark, les nouveaux arrivants sur le marché avec un vrai positionnement sur la vie privée sont au top du classement (Brave et Firefox Focus). Respect de la vie privée et environnement vont dans le même sens. C’est un bon signal pour les utilisateurs.

Méthodologie

Nous effectuons nos mesures de la consommation réélle d’énergie du téléphone avec l’outil GREENSPECTOR. Le smartphone Samsung Galaxy S7 a été utilisé pour ce Benchmark.

La méthodologie vise à réaliser un parcours qui est représentatif de l’usage d’un utilisateur. Nous étudions comment le navigateur se comporte sur le même parcours. Le parcours dure 5 minutes et est réalisé 4 fois pour obtenir des mesures fiables.

Au préalable une préparation du téléphone est réalisée :

Configuration maitrisée (luminosité, Wi-Fi activé(e)…)

Fermeture de toutes les applications et services : Permet de ne pas être pollué par d’autres applications et d’avoir des mesures fiables

Suppression des caches des navigateurs

Accès réseau stabilisé

Le parcours suivant est ensuite réalisé :

Lancement du navigateur sur la page d’accueil configurée à l’installation

Attente de 20 secondes (foreground) : permet de mesurer l’impact de la page d’accueil.

Pour 3 sites de type différents (Wikipedia, lemonde.fr, pinterest) : Lancement de la page, Scroll en bas de page, attente de 20 secondes

Lancement à nouveau des 3 sites pour évaluer l’impact de la mise en cache

Mise en tache de fond du navigateur (background) : permet de voir comment la navigateur se comporte quand il n’est pas en avant sur le téléphone.

On projette ensuite la consommation d’énergie unitaire obtenue sur un usage continu pour obtenir l’autonomie finale.

Pour information, voici les données brutes d’énergie mesurée :

{{< gsp-image title=”” src=”/assets/img/articles/2018-11-19-navigateurs/ConsommationScénario.png” >}}

Faut-il activer le mode nuit pour augmenter l’autonomie de ma batterie ? Le cas de l’application Twitter

Reading Time: 2 minutes

Quelques applications comme Youtube, Google Chrome ou Twitter proposent un fond d’écran non pas blanc mais noir. Ce mode “Nuit” ou thème Dark dédié à une utilisation nocturne, facilite la lecture la nuit, repose vos yeux et surtout vous évite de vous transformer en phare. Cependant qu’en est-il réellement pour votre batterie ?

Nous avons choisi de comparer le mode “Jour” et “Nuit” de l’application Twitter pour cette battle d’efficience.

(Re)découvrez nos autres articles comparatifs sur Twitter & Twitter Lite ainsi qu’Instagram & Instagram Lite.

Mode “Nuit” pour l’application Twitter

Le passage en mode “Nuit” est très simple :

Ouvrez votre application Twitter

Cliquez sur la bulle de votre profil en haut à gauche

Cliquez sur l’icone de croissant de lune en bas à gauche de votre écran

Vous pouvez également activer ou désactiver le mode “Nuit” depuis les Paramètres :
– Allez dans “Paramètres et confidentialité” (Settings and privacy)
– Allez dans “Affichage et Son” (Display and sound)
– Cliquez sur mode “Nuit” (Night mode).

Et voici le résultat du mode “Nuit” versus le mode “Jour” :

Quel gain pour l’énergie ?

Sur 30 secondes, le mode “Jour” va consommer 3,92 mAh et le mode “Nuit” 2,98 mAh. Le mode “Nuit” est donc moins consommateur de -23%. Pourquoi ? La mesure a été effectuée sur un Samsung Galaxy S7 qui possède un écran AMOLED. Ces écrans sont beaucoup moins consommateurs sur des couleurs sombres, retrouvez notre article explicatif à ce propos sur notre blog.

Est-ce que cela fait une différence sur l’autonomie de mon téléphone ? Absolument ! Avec le mode “Jour” activé, 1 heure de réseau social (notamment Twitter) va décharger la batterie de 15% alors qu’en mode “Nuit”, la décharge ne va être que de 11%.

C’est donc une victoire pour le mode “Nuit” !

Note : Les mesures ont été effectuées simplement avec l’outil GREENSPECTOR sur un Samsung Galaxy S7. Je vous invite à parcourir ce blog pour plus d’informations sur les outils et la méthodologie.

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.

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.