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

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 sepas INpactien
sepas Le mardi 13 décembre 2011 à 23:11:13
Inscrit le jeudi 20 août 09 - 2165 commentaires
A quand un visual studio like pour Android?
Avatar de canti INpactien
canti Le mardi 13 décembre 2011 à 23:37:43
Inscrit le lundi 5 mai 03 - 4350 commentaires
A quand un visual studio like pour Android?


genre eclipse?
Avatar de atomusk Modérateur
atomusk Le mercredi 14 décembre 2011 à 07:55:30
Inscrit le mardi 20 juillet 04 - 21745 commentaires


genre eclipse?


Mais créé par Microsoft quoi
Avatar de sepas INpactien
sepas Le mercredi 14 décembre 2011 à 08:08:54
Inscrit le jeudi 20 août 09 - 2165 commentaires


genre eclipse?


Oui mais un truc mieux fait comme visual studio quoi :)
Avatar de bambou51 INpactien
bambou51 Le mercredi 14 décembre 2011 à 08:41:13
Inscrit le lundi 9 mai 05 - 318 commentaires


Oui mais un truc mieux fait comme visual studio quoi :)


Non mais franchement eclipse pour le dev java est 100 fois supérieur à visual studio pour le c++, c#
Pour arriver à les comparer il faut ajouter des plugins qui coutent la peau des fesses sous Visual studio, genre Resharper...

Encore une fois, c'est l'émulateur qui est mauvais, mais aucunement l'IDE ou l'API... ou alors ceux qui disent ça n'ont jamais développé en Java/android ou sont de simples haters...
Avatar de oposs INpactien
oposs Le mercredi 14 décembre 2011 à 08:48:38
Inscrit le lundi 11 octobre 04 - 9248 commentaires


Non mais franchement eclipse pour le dev java est 100 fois supérieur à visual studio pour le c++, c#
Pour arriver à les comparer il faut ajouter des plugins qui coutent la peau des fesses sous Visual studio, genre Resharper...

Encore une fois, c'est l'émulateur qui est mauvais, mais aucunement l'IDE ou l'API... ou alors ceux qui disent ça n'ont jamais développé en Java/android ou sont de simples haters...

mdr2.gifmdr2.gif
Ils ont enfin ajoute des trucs super sophistiques comme le line-wrap a Eclipse par exemple? C'etait un truc qui etait sur les premiers IDE a fenetre a la fin des annees 80 mais apparemment Eclipse ne sait toujours pas le faire de maniere fiable.
Perso j'utilise Eclipse au boulot parce que pas vraiment le choix et franchement a part le cote open-source/libre je n'ai jamais vu aucun avantage compare a VS ou XCode.

Edité par oposs le mercredi 14 décembre 2011 à 08:49
Avatar de bambou51 INpactien
bambou51 Le mercredi 14 décembre 2011 à 08:56:52
Inscrit le lundi 9 mai 05 - 318 commentaires

mdr2.gifmdr2.gif
Ils ont enfin ajoute des trucs super sophistiques comme le line-wrap a Eclipse par exemple? C'etait un truc qui etait sur les premiers IDE a fenetre a la fin des annees 80 mais apparemment Eclipse ne sait toujours pas le faire de maniere fiable.
Perso j'utilise Eclipse au boulot parce que pas vraiment le choix et franchement a part le cote open-source/libre je n'ai jamais vu aucun avantage compare a VS ou XCode.


Non mais n'importe quoi, un petit Ctrl + I et ton code est parfaitement indenté avec line wrapping en fonction de la mise en page sélectionnée.
La navigation dans le code via eclipse est ultra puissante avec tous les raccourcis dispo pour les 'open call hierarchy', 'type hierarchy', ...
Une fois qu'on maitrise les raccourcis, eclipse est vraiment imbattable pour la navigation de code.

J'utilise eclipse et VS au quotidien, et je préfère je franchement VS n'est pas au niveau (même avec resharper intégré).
Alors bien sur celui qui bosse sans raccourci, ou qui n'utilise pas toutes les fonctions intégrées risque de trouvé ça un peu trop complexe...

Bref, eclipse est l'ami du power user ;)
Avatar de canti INpactien
canti Le mercredi 14 décembre 2011 à 08:59:11
Inscrit le lundi 5 mai 03 - 4350 commentaires

mdr2.gifmdr2.gif
Ils ont enfin ajoute des trucs super sophistiques comme le line-wrap a Eclipse par exemple? C'etait un truc qui etait sur les premiers IDE a fenetre a la fin des annees 80 mais apparemment Eclipse ne sait toujours pas le faire de maniere fiable.
Perso j'utilise Eclipse au boulot parce que pas vraiment le choix et franchement a part le cote open-source/libre je n'ai jamais vu aucun avantage compare a VS ou XCode.


en utilisation java, Eclipse a comme gros avantage ses outils d'aide a la correction de code, et j'aime d'amour le racourcis clavier "ctrl+click" qui permet de retourner a la déclaration d'un element

quand je retourne sous visual studio ca me fait mal de pas avoir ces services sous C++ (mais c'est ptet que dans ma boite on a VS2003)

j'ai jamais testé xcode donc je peux pas parler...

mais oui, c'est vrai qu'eclipse a parfois des comportement surprenant, et une emprunte mémoire énorme. Ca n'en reste pas moins un IDE que j'aprécis
Avatar de bambou51 INpactien
bambou51 Le mercredi 14 décembre 2011 à 09:05:07
Inscrit le lundi 9 mai 05 - 318 commentaires


en utilisation java, Eclipse a comme gros avantage ses outils d'aide a la correction de code, et j'aime d'amour le racourcis clavier "ctrl+click" qui permet de retourner a la déclaration d'un element

quand je retourne sous visual studio ca me fait mal de pas avoir ces services sous C++ (mais c'est ptet que dans ma boite on a VS2003)

j'ai jamais testé xcode donc je peux pas parler...

mais oui, c'est vrai qu'eclipse a parfois des comportement surprenant, et une emprunte mémoire énorme. Ca n'en reste pas moins un IDE que j'aprécis


euh le ctrl + click oui ok, c'est bien, mais franchement tu peux tout faire au clavier.
un ctrl + o: pour lister toutes tes fonctions avec filtre pour acceder à celle que tu recherche direct, ctrl + j: pour rechercher tout en naviguant dans ton code au fur et à mesure que tu frappes, F3 pour aller à la définition, ctrl+shift+t pour rechercher/ouvrir une classe (avec une gestion exemplaire du filtre), ctrl+alt+h pour lister les appels à une méthodes, ctrl+t pour visualiser la hierarchy, ...

bref on peut tout faire ultra efficacement au clavier et gagner un temps fou !
Avatar de bambou51 INpactien
bambou51 Le mercredi 14 décembre 2011 à 09:13:35
Inscrit le lundi 9 mai 05 - 318 commentaires
j'oubliais la completion surpuissante, les macro de génération de code (taper 'sysout' et faire ctrl+space, 'instanceof' + ctrl+space, ...)
;