2012-03-21

[INTOX] Les applis avec pub ruinent la batterie


L'intox du jour est issue de l'article "Free apps eat up your phone battery just sending ads" de newscientist.com et est assez gratinée.

Le principe d'une bonne intox est de partir d'un fait plausible et de saupoudrer d’exagération et de mauvaise foi. Toutes les vues animées dans une application consomment du CPU, du GPU et de l'Affichage et donc épuisent la batterie. Ce n'est pas vendeur, alors il va falloir conchier du géant Android ou iOS.

Dans cette étude, Abhinav Pathak, nous fais une présentation sérieuse et rigoureuse de son outil eprof capable d'analyser la consommation électrique sans avoir le code source. L'étude est loin de la vulgarisation faite par newscientist : du pret-a-penser pour le mass-media.

Ce que NS laisse croire, à tort, de l'étude:

Lisons l'article ...
"STRUGGLING to make your smartphone battery last the whole day?"
Commençons par chercher l'information là où elle est avec l'outil de suivi de la consommation électrique inclus dans Android.
"Plate-forme Android 30%", "Ecran 29%", "Téléphone inactif 20%" blah blah ... la première application ne culmine qu'à 2% : l'excellent Carcast (avec pub). Se battre avec du 2% ... bon struggling mon gars !

Le Qualiticien en moi réagit au prisme de l'empirique principe de Pareto (vous vous en doutiez). Si je veux significativement améliorer la durée de vie de la batterie j'ai intérêt à agir sur les 80% des facteurs influant sur la consommation électrique. Fréquence du kernel (cpufreq )? Réduire les services tournant en tâche de fond (sms/mms) )
Ce raisonnement est vrai mais pas pertinent (vous vous doutez bien que Pareto c'est un peu plus subtil que 80/20) et c'est pour moi le grand interet de l'article de Abhinav.

L'accroche de l'article n'est pas pertinente... je continue.

Up to 75 per cent of the energy used by free versions of Android apps is spent serving up ads or tracking and uploading user data
Source des 75% ? Un étude universitaire avec l'aide de Ming ZHANG, salarié de Microsoft (concurrent d'Android) ce qui explique la présence de l'étude à cette adresse http://research.microsoft.com/en-us/people/mzh/eurosys-2012.pdf. On va garder le "beaucoup"/"significatif" mais le 75% est vraisemblablement orienté pour donner plus de poids à l'étude.

"For example, in Angry Birds only 20 per cent is used to display and run the game, while 45 per cent is spent finding and uploading the user's location with GPS then downloading location-appropriate ads over a 3G connection."
Ahem ... Angry Birds utilise le GPS ? Et bien non ... D'après le Play Store il n'est question que de géopositionnement par triangularisation GSM. 
A priori l'utilisation du GPS et la double version avec publicité ou payante sont des spécificités iOS donc il serait honnête de cesser de nous râper les raisins avec des généralisations foireuses appliquées à l'arrache sur Android. L'ISO 1664 j'aime bien, mais uniquement entre potes.

Ce que l'étude dit :

Contrairement à ce que le buzz nous laisse croire, les données ne portent pas sur TOUT le secteur de la mobilité mais uniquement sur ... Android. Le logiciel eProf a été réalisé sur Android et Windows Mobile 6.5 mais malheureusement la partie de l'étude sur Windows Mobile n'est pas accessible. Rien sur iOS quel dommage.

L'étude ne se focalise que sur Flurry. Pourquoi avoir mis de côté Admob réalisée par Google ? Toujours sur Flurry qui consomme 45% de l’énergie dépensée pendant une partie d'Angry Birds (dans le chapitre 7.2.2) il est question d'une consommation à hauteur de 15% du GPS. Oh wait !!! Comment peut-on associer à Flurry la consommation du chip GPS alors que l'application n'a pas accès ? Comme nous l'indique le Manifest.xml de l'Angry Birds, la seule permission de géo-positionnement est ACCESS_COARSE_LOCATION qui ne nécessite que peu de calcul.

L'étude version Android porte sur une 20aine d'applications représentatives du monde Android, sur 2 terminaux Android (HTC Magic avec Android 2.0 et HTC Passion avec Android 2.3 que des nouveautés. Aucun Galaxy Nexus ? Étonnamment non, les tests sont réalisés avec des dinosaures (partouseur de droite) équipé d'une surcouche constructeur.

L'étude a été menée en collaboration avec un cadre d'Intel. Hé hé hé ....

PARETO, mon poto. TAGUCHI mon ami :

Revenons une seconde à notre bon Pareto. L'amélioration de la durée de la batterie ne passera malheureusement pas par les 80% de postes de dépenses de l'énergie. L'approche est tentante mais inaccessible : la réduction de "Ecran 29%" passe par une analyse des facteurs et de leurs multiples interactions. Je n'ai pas la prétention de résoudre avec un oscillo, un oeil et les tables du Dr TAGUCHI ce que des armées d'ingénieurs chez Sharp et Samsung peinent à faire.

Abhinav Pathak a du avoir le même raisonnement (hem). Sa pré-étude lui a permis d'évaluer les 3 gros postes de dépenses triviaux : fréquence de "redraw" d'une vue trop élevée, trop de requetes http courtes et trop de sollicitation des chipsets GPS. Tout triviaux que sont ces trois points, ne nous privons pas de la confirmation scientifique (par Abhinav Pathak) de nos acquis empiriques.

C'est là le point, à mon avis majeur, de son étude. Les publicités comme Flurry (mais pas que), utilisent intensivement les trois points, en simultané et en continu. Si le gain absolu est ridicule, la marge de progression relative est impressionnante. Certains développeurs mettent une fréquence de rafraichissement ahurissante de la publicité. C'est mon cas et je vais mettre la pédale douce pour les prochaines versions de mes applications.

Moralité

L'étude est supervisée par Microsoft (concurrent Android), un cadre d'Intel (concurrent arm), ne se focalise QUE sur Android et lui fait porter la responsabilité de l'indigence de Flurry et est réalisé avec des systèmes d'exploitations obsolètes sur des terminaux trop vieux pour être pris au sérieux en 2012.

Le travail de Abhinav Pathak est un travail universitaire qui peut apporter de bonnes pistes d'amélioration pour la génération actuelle de smartphones. Le prix du quart d'heure de gloire est une synthèse détournée en FUD.
 
Enregistrer un commentaire