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

Posted on by Olivier PHILIPPOT
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.