S'identifier / Créer un compte
  • Actualités
  • Dossiers
  • Tests
  • Commentaires
  • INpactiens
Publicité

Flash Info : Fêtons la TVA à 2,1 % : abonnez-vous dès 17 € par an !

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

Une vérité bien plus complexe

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.

Galaxy Nexus SFR

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.
Vincent Hermann

Rédacteur/journaliste spécialisé dans le logiciel et en particulier les systèmes d'exploitation. Ne se déplace jamais sans son épée.

Publiée le 13/12/2011 à 12:14

Soutenez l'indépendance de Next INpact en devenant Premium

  • Tout le contenu de Next INpact sans pub
  • Et bien plus encore...

Il y a 96 commentaires

Avatar de xdrh INpactien
xdrh Le mardi 13 décembre 2011 à 12:26:38
Inscrit le mardi 2 juin 09 - 355 commentaires
Il me semble que même les processeurs les plus bas de gamme qui aient été utilisés sur Android (autrement dit les tous premiers : des Qualcomm 7xxx) ont un GPU embarqué. Certes pas avec les mêmes capacités qu'un Adreno 220 ou un Tegra3, mais en tout cas largement plus efficace pour faire du rendu qu'un CPU, donc je comprends pas trop leur histoire de "besoin de faire un rendu logiciel".

En simplifiant (trollant ?), c'est comme si les jeux étaient restés en "software rendering" (1998 like) parce qu'il aurait fallu faire un rendu soft et un rendu hard.
Avatar de Kervala INpactien
Kervala Le mardi 13 décembre 2011 à 12:35:09
Inscrit le lundi 3 mars 08 - 238 commentaires
Il me semble que même les processeurs les plus bas de gamme qui aient été utilisés sur Android (autrement dit les tous premiers : des Qualcomm 7xxx) ont un GPU embarqué. Certes pas avec les mêmes capacités qu'un Adreno 220 ou un Tegra3, mais en tout cas largement plus efficace pour faire du rendu qu'un CPU, donc je comprends pas trop leur histoire de "besoin de faire un rendu logiciel".

En simplifiant (trollant ?), c'est comme si les jeux étaient restés en "software rendering" (1998 like) parce qu'il aurait fallu faire un rendu soft et un rendu hard.


Attention, ici on ne parle pas de 3d :) Il y a le dessin des interfaces et la composition. Le premier est, en général, réalisé par le CPU la plupart du temps (sous quasiment tous les OS mobiles ou desktop), c'est la composition qui va utiliser OpenGL ou DirectX.
Avatar de Malesendou INpactien
Malesendou Le mardi 13 décembre 2011 à 12:40:47
Inscrit le vendredi 21 mai 10 - 6045 commentaires
Trop de précipitation finalement chez Google. Espérons qu'ils réalisent ce travail sur les outils de développement.

Hep Asus, j'attends toujours ICS. >_<
Avatar de Alucard63 INpactien
Alucard63 Le mardi 13 décembre 2011 à 12:42:40
Inscrit le mardi 7 mars 06 - 8277 commentaires
Il me semble que même les processeurs les plus bas de gamme qui aient été utilisés sur Android (autrement dit les tous premiers : des Qualcomm 7xxx) ont un GPU embarqué. Certes pas avec les mêmes capacités qu'un Adreno 220 ou un Tegra3, mais en tout cas largement plus efficace pour faire du rendu qu'un CPU, donc je comprends pas trop leur histoire de "besoin de faire un rendu logiciel".

En simplifiant (trollant ?), c'est comme si les jeux étaient restés en "software rendering" (1998 like) parce qu'il aurait fallu faire un rendu soft et un rendu hard.

Il faut le matériel ET le logiciel....tout le monde n'a pas ICS.
Avatar de Tarpan INpactien
Tarpan Le mardi 13 décembre 2011 à 12:45:39
Inscrit le dimanche 2 mai 04 - 1041 commentaires
Ça me rappelle un peu qd pour Vista® il se disait qu'avec la prochaine génération de Core2Duo les problèmes de lenteur s'estomperaient...


Bref, quel est le résumé de cet article ?

La puissance brute va augmenter pour estomper les lenteurs, mais il va falloir soit attendre un certain temps le renouvellement du parc (quoi, 2-3 ans ?) , soit créer une rupture de compatibilité avec l'optimisation côté logiciel. C'est bien ça ?

Edité par tarpan le mardi 13 décembre 2011 à 12:46
Avatar de wagaf INpactien
wagaf Le mardi 13 décembre 2011 à 12:49:44
Inscrit le lundi 15 mai 06 - 1771 commentaires
Il me semble que même les processeurs les plus bas de gamme qui aient été utilisés sur Android (autrement dit les tous premiers : des Qualcomm 7xxx) ont un GPU embarqué. Certes pas avec les mêmes capacités qu'un Adreno 220 ou un Tegra3, mais en tout cas largement plus efficace pour faire du rendu qu'un CPU, donc je comprends pas trop leur histoire de "besoin de faire un rendu logiciel".

En simplifiant (trollant ?), c'est comme si les jeux étaient restés en "software rendering" (1998 like) parce qu'il aurait fallu faire un rendu soft et un rendu hard.

Certains téléphones Android très bas de gamme (mais vendus en Europe) que j'ai eu l'occasion de tester ont officiellement un GPU "intégré" mais en réalité les calculs de rendu sont simplement effectués par le CPU. Résultat : des performances OpenGL ES catastrophiques, moins bonnes que le dessin 2D utilisant les librairies Android non accélérées ! En fait, seuls quelques petites parties du pipeline 3D étaient réellement capables d'être calculées en hardware.

Android 2.x doit traîner derrière lui et assurer le support de ce genre de puces. Ça n'empèche pas d'accélérer certaines parties, mais ça a imposé à Android d'avoir à faire une rupture en terme de support matériel (avec les versions 3 et 4) pour pouvoir tout accélérer matériellement par défaut.

Par ailleurs Dianne Hackborn a tout à fait raison sur la différence entre les dev iOS et Android: développer pour iOS n'est certes pas donné (100$ par an) mais la qualité des outils est indéniable.

ADT+Eclipse n'est pas mal, mais clairement très lourd et beaucoup d'outils, dont l'émulateur, sont vraiment à revoir.

Les API ne sont pas mauvaises. Beaucoup de choses sont bien mieux fichues que sur iOS et on peut assez rapidement développer des design paterns. Les mauvais points: Java est très propre sur lui mais tellement verbeux !!


Edité par wagaf le mardi 13 décembre 2011 à 12:50
Avatar de chp2 INpactien
chp2 Le mardi 13 décembre 2011 à 12:54:29
Inscrit le mercredi 14 décembre 05 - 1101 commentaires
Quid des Schedulers?
Avatar de seb2411 INpactien
seb2411 Le mardi 13 décembre 2011 à 12:56:37
Inscrit le vendredi 24 octobre 08 - 3060 commentaires
Ça me rappelle un peu qd pour Vista® il se disait qu'avec la prochaine génération de Core2Duo les problèmes de lenteur s'estomperaient...


Bref, quel est le résumé de cet article ?

La puissance brute va augmenter pour estomper les lenteurs, mais il va falloir soit attendre un certain temps le renouvellement du parc (quoi, 2-3 ans ?) , soit créer une rupture de compatibilité avec l'optimisation côté logiciel. C'est bien ça ?

C'est justement pas une question de puissance mais plutôt de fonctionnalités.
Avatar de boontiikiller INpactien
boontiikiller Le mardi 13 décembre 2011 à 13:03:26
Inscrit le jeudi 7 mai 09 - 441 commentaires
Emulateur tellement peu performant que j'ai arrété de l'utiliser. J'installes direct mes applis sur mon télephone et je suis tranquille. Certes j'ai pas l'interface qui correspond à la version android que j'ai choisi pour mon dev, mais il est hors de question que je teste les jeux que je fais sur l'emulateur.
Avatar de atomusk Modérateur
atomusk Le mardi 13 décembre 2011 à 13:07:11
Inscrit le mardi 20 juillet 04 - 21714 commentaires
heuu, je trouve pas la source de cette phrase :

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, bien qu’équipée d’Android 3.1, n’est pas capable de réaliser le type d’accélération dont on parle ici.



Si c'est celle-ci :

Second, Android programmers need to support both software and hardware rendering for awhile. This requires more code. Some Android devices support only software rendering while others, like the Xoom, actually require hardware rendering to achieve any semblance of smooth animation


Je ne suis pas d'accord sur la traduction

Pour moi ici il explique qu'en raison de la résolution de l'écran, si tu ne forces pas l'accélération hardware, ton interface ne sera jamais fluide.

en tout cas pour mon appli le passage en accélération hardware est passé par :
- activation dans le manifest
- désactivation spécifique de l'accélaration pour les view dessinant les kanji le temps que je trouve la raison pour laquelle ça marche pas

Et du coup sur HoneyComb, mes listView & co sont super fluides
;