Google répond aux problèmes de performances d'Android

Mercredi dernier, nous décrivions dans un article les problèmes soulevés par Andrew Munn au sujet des performances graphiques de l’interface d’Android, inférieures à celle d'iOS. L’ancien stagiaire chez Google faisait écho à un billet posté sur Google+ par Dianne Hackborn, ingénieur logiciel sur Android. Cette dernière est revenue à la charge sur les points abordés, ainsi que Bob Lee, ancien ingénieur en chef de la bibliothèque de développement d’Android.


Dianne Hackborn et Bob Lee ont en commun de s’être attaqués à certaines erreurs faites lorsque Android et iOS sont comparés. Au centre du débat se trouve la répartition des calculs liés à une application dans des processus principaux ou en arrière-plan. La lecture des billets, particulièrement techniques, donne un nouvel éclairage du problème : Android et iOS sont finalement assez proches dans leur fonctionnement, et les problèmes ne se situent pas forcément là où on les attend.

Le GPU doit avoir les capacités nécessaires à l'accélération complète

Dianne Hackborn commence par expliquer un point essentiel du fonctionnement d’Android. C’est ainsi que le système d’exploitation a été imaginé pour que les applications puissent s’y ébrouer en sécurité. Afin de réaliser cet objectif, chacune tourne dans une sandbox (espace mémoire isolé) et l’identifiant de l’utilisateur est utilisé en complément pour vérifier qu’une application n’accède pas au système ou d’autres éléments en-dehors des sentiers balisés.

L’un des rouages essentiels pour y parvenir est de permettre aux éléments de l’interface de partager l’écran de manière sécurisée, ce qui explique la présence des fenêtres. Exemple : la barre de statut et la zone de notification sont des fenêtres du système et ne peuvent pas être affectées par une application.

Conséquence : quand l’utilisateur voit des animations de l’interface, il s’agit en fait d’animations de fenêtres. Ainsi, lancer Contacts provoque les animations de l’écran d’accueil et de la liste des contacts. Chaque fenêtre est représentée à l’écran par une surface, et toutes les surfaces sont assemblées et gérées par un service système séparé et dédié à la composition. Ce service détient une priorité supérieure à la normale. Selon Dianne Hackborn, le mécanisme ressemble à celui d’iOS mais est mieux sécurisé.

Mais quel rapport avec les performances de l’interface ? L’ingénieur l’explique : jusqu’à récemment, il n’était pas possible d’intégrer l’accélération matérielle à l’intérieur des fenêtres. Android est en effet conçu pour afficher plusieurs fenêtres, et donc surfaces, à l’écran. Conséquence : le GPU et son pilote doivent obligatoirement gérer des éléments multiples issus de processus différents et simultanément actifs. Et sur ce point particulier, Bob Lee donne des informations complémentaires.

Le parc Android et les outils de développement

L’ancien ingénieur en chef de chez Google indique lui aussi dans son propre billet qu’Android et iOS ont de nombreux points communs. Il existe cependant des différences fondamentales dans « l’existant » d’Android qui expliquent l’état des lieux qui est fait aujourd’hui.

En effet, ce n’est parce que l’accélération matérielle existe qu’elle est forcément utilisée. C’est là que réside selon lui le cœur du problème. Premièrement, l’hétérogénéité du parc Android, même version du système mise à part, offre un panel très varié de capacités. Il cite la Xoom qui, équipée d’Android 3.1, réclame absolument l'accélération matérielle pour afficher un degré satisfaisant de fluidité.

Cet exemple est un cas d’école car il illustre la longue migration dans laquelle Android s’engage. Les nouveaux smartphones, surtout ceux sous Android 4.0, ont des capacités techniques les mettant à égalité avec ce qu’il est possible de faire sous iOS. Seulement voilà : les développeurs sont obligés de prévoir tous les cas de figure. De fait, ils doivent réfléchir à l’accélération matérielle, mais également au pendant logiciel au cas où le GPU n’aurait pas les capacités requises. Résultat, il faut tout simplement écrire plus de code.

Il s’agit d’un problème de temps disponible, donc de moyens, et pas seulement. Bob Lee estime que les développeurs iOS sont bien mieux formés à exploiter leur plateforme que les développeurs Android. Une situation largement accentuée par des outils fournis par Apple, nettement supérieurs à ceux existant pour Android selon lui. Il s’en prend en particulier à l’émulateur système qu’il juge sévèrement.

L’efficacité des outils permet de réaliser beaucoup plus rapidement des tests sur l’interface pour mesurer l’impact en termes de performances. Il s’agit pour Bob Lee d’un problème crucial : les développeurs Android ont plus de travail et les outils leurs compliquent encore davantage la tâche.

Les deux problèmes sont différents mais se rejoignent. La migration ne sera réellement terminée que lorsque les appareils utilisant des versions d’Android antérieures à la 3.0 (Honeycomb) n’existeront plus (ou ne seront plus supportés). Concernant les outils, il enjoint Google à faire de gros efforts sur leur qualité et leur support, car si le temps peut régler certains soucis, il ne peut rien contre celui-là.

En attendant, il conseille aux développeurs Android d’identifier clairement les opérations bloquantes et à les basculer sur un processus d’arrière-plan afin de ne pas provoquer de saccades dans l’affichage. Android utilise en effet une fonctionnalité Linux baptisée « cgroups » qui récupère tous les processus en arrière-plan et octroie à l’ensemble un maximum de 10 % des ressources processeur.

Le 13 décembre 2011 à 12:14 (34 801 lectures)

Tweeter

Actu Précédente Actu Suivante