C’est une question difficile à poser pour un passionné d’Android, néanmoins elle revient souvent dans les discussions et les études. Dernièrement, le média américain Which? a dévoilé une étude comparant l’autonomie des différents iPads et de plusieurs tablettes Android, dont la Nexus 7 (2013) ou encore la Samsung Galaxy Note 10.1 (Edition 2014). Ces tests semblent avoir été réalisés dans des conditions correctes, et montrent une meilleure autonomie de l’iPad Air pour la navigation web et la lecture vidéo. Mais ce n’est pas cette problématique que je me pose, c’est un tout autre sujet. Cela concerne les grosses différences entre l’autonomie en navigation web et en lecture de vidéo sur les tablettes Android. On observe de fortes disparités entre ces deux tests. Je n’ai pas trouvé d’explication magique, néanmoins j’ai des débuts de réponses.

which-tablet-battery-life-ipad-air

Le test a été réalisé dans des conditions similaires, les auteurs ont noté que la luminosité avait été réglée à 200 nits, néanmoins on ne connaît pas avec exactitude l’ensemble des paramètres. Par exemple, le navigateur utilisé, le lecteur vidéo ou encore le type de contenu chargé lors des tests de navigation web. En réalité, que l’iPad ait une plus grande autonomie dans ces tests précis, ce n’est pas si important. Je suis persuadé que certaines tablettes Android auraient une meilleure autonomie avec des paramètres différents. Capacité de la batterie, version d’Android, taille et résolution de l’écran, applications utilisées… les paramètres sont bien trop nombreux. De plus, nous sommes conscients que l’iPad (iOS) possède une meilleure intégration et une meilleure optimisation, car Apple maîtrise un gros bout de la chaîne de valeurs. 

En réalité, ce que je trouve le plus intrigant dans cette étude, c’est la forte disparité entre les deux tests. Ce test semble montrer qu’Android est plus efficace pour lire de la vidéo que pour afficher des pages web. A quoi cela est-il dû ?

 

Lié à la méthode de rendu des pages ?

La différence fondamentale entre Android et iOS tient dans la distribution des priorités des tâches : sur iOS, toute intervention de l’utilisateur interrompt les calculs en cours pour rendre l’interface fluide, alors qu’Android fait son possible pour tout traiter de manière simultanée (y compris ce qui n’apparaît pas à l’écran). Cette différence de « culture » a un impact sur la fluidité de l’interface mais aussi sur l’autonomie de l’appareil.

En effet, vous avez compris que la différence de fluidité tient à la méthode de rendu des page basée sur des tuiles indépendantes dans iOS et pas dans Android 1, 2 ou 3. Néanmoins, les choses ont vraiment changé avec Android 4.4 KitKat… Cette explication est incomplète, car elle ne justifie pas à elle seule les disparités observées.

 

L’accélération matérielle en cause ?

L’accélération matérielle consiste à confier une fonction spécifique effectuée par le processeur à un circuit intégré dédié qui se chargera de cette fonction de façon plus efficace. En outre, ces optimisations et ces jeux d’instructions sont orientés pour des utilisations spécifiques. Les usages multimédias ont clairement été le point le plus évoqué par les concepteurs de SoC (NVIDIA, Qualcomm, Intel, etc.), et les puces mobiles actuelles sont capables d’encoder et de décoder de la vidéo 4K. On ne peut pas en dire autant des puces « desktop ».

Les applications (navigateurs compris) doivent être capables d’exploiter au mieux ces fameuses ressources de la machine. Sur Android, la grosse majorité des navigateurs web sont capables d’exploiter la puissance de traitement du GPU, grâce à que l’on appelle “l’accélération matérielle”. En réalité, c’est toute l’interface Android qui bénéficie de ces évolutions avec la re-écriture régulière des couches basses d’Android, néanmoins le travail est énorme.

Le code d’application Android nécessite de fonctionner sur un ensemble hétérogène de matériel, dont parfois des matériels très différents. Même l’architecture ARM (plus de 90 % des appareils Android sous Qualcomm, NVIDIA, TI) existe actuellement en différentes version — avec et sans VFP, avec et sans NEON, et avec un nombre différent de registres. En plus d’ARM, Android existe également sur d’autres type de microprocesseurs ou SoC, telle que l’architecture MIPS ou que l’architecture x86 d’Intel, toutes ces architectures pouvant contenir différents type de processeurs graphiques et de traitement de signal.

Cependant, la puce graphique (GPU) est capable de fournir à la fois une exécution plus rapide et une plus faible consommation électrique. Nicolas Roard, ingénieur chez Google, avait expliqué lors d’un rendez-vous GDG comment l’accélération GPU (avec Renderscript, une API de bas niveau) avait permis d’améliorer les performances de l’outil d’édition des vidéos sur Android 4.4 (KitKat). Pour vous rendre compte du travail effectué, vous pouvez utiliser l’outil présent sur KitKat, les traitements sont plus rapides et la consommation a fortement baissé.

 

Android semble être la cause

De nombreux composants d’Android nécessitent d’être réécrits, Android 4.4 KitKat a introduit de nombreuses nouveautés invisibles pour les utilisateurs. Certaines d’entre elles sont accessibles, c’est le cas de l’outil de gestion de la mémoire RAM (dans les paramètres). Pour la mémoire vive (RAM), la puissance peut être assez élevée (supérieure à 100 mW dans certains scénarios), mais est toujours à corréler avec l’utilisation du processeur. Elle peut dépasser la puissance du processeur dans certaines charges de travail, mais dans des situations concrètes, la puissance du processeur éclipse celle de la mémoire par un facteur de deux ou plus. C’est en particulier le cas dans les pages Web dynamiques comme JavaScript et Flash sont largement utilisés dans de nombreux sites.

Une modification du comportement d’Android sur ce point nécessiterait cependant la création d’un nouveau toolkit pour l’interface, qui exigerait une réécriture des applications existantes pour en tirer parti, ainsi qu’un mode autorisant la rétro-compatibilité. Cela aurait bien entendu des conséquences directes sur l’autonomie des appareils, et cela permettra sans doute d’obtenir des résultats plus homogènes entre différentes utilisations (vidéo, web, jeux, etc.).

 

Qu’est-ce que ça veut dire exactement ?

Android est un OS dont le développement a débuté en 2003. De plus, les décisions prises qui ont permis de développer rapidement un écosystème posent aujourd’hui des questions. L’arrivée de ART, qui remplacera la machine virtuelle Dalvik dans un futur assez proche, est déjà un début de réponse…

Eh bien, Google et l’ensemble de l’Open Handset Alliance ont encore du travail à effectuer sur Android.  Les nouveaux SoC quadruple-coeur et octo-cœur n’apportent qu’un bout de la solution, une sorte de rustine. La vraie solution viendra des prochaines versions d’Android. Android 5.0 ?

L’autonomie est la clef de voûte des éco-systèmes mobiles, c’est pour cela que l’on s’y intéresse autant.