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 gouessej INpactien
gouessej Le mardi 13 décembre 2011 à 16:10:54
Inscrit le dimanche 8 août 10 - 361 commentaires
un framework en lean C au dessus de linux et des bindings pour les caprices des développeurs d'apps (javascript/lua/ruby/python2/python3/perl5/perl6/java/C++/objective-C/C#/ocaml/D/haskell/smalltalk/tintin/milou).

Il en faut pour tous les goûts et à ma connaissance, Android ne propose pas de bindings pour tous les langages que tu cites dans son SDK standard, je ne connais que le SDK en Java et le NDK qui permet d'écrire des applications Android en C et en C++. Souhaiter programmer dans un autre langage que le C n'est pas un caprice. Si tous les informaticiens suivaient ton raisonnement et se passaient de ces "caprices", même le C n'existerait pas, tous les logiciels seraient programmés en assembleur. Je trouve légitime de vouloir réutiliser du code source existant écrit dans un autre langage que le C (Java par exemple) surtout quand on sait qu'Android est très utilisé sur les smartphones et que beaucoup de développeurs se sont servis de J2ME pendant des années.

Pour information, mon ancien HTC Dream G1 marchait très bien... ce qui n'est pas le cas de mon HTC Desire Z. J'aimerais bien qu'HTC arrête de mettre des applications par défaut qu'on ne peut pas retirer à moins de passer à Cyanogen et compagnies surtout que certaines ont pas mal d'autorisations. Ca me gêne que non seulement elles consomment du temps CPU et elles ont accès à mon répertoire.

Edité par gouessej le mardi 13 décembre 2011 à 16:15
Avatar de AlexRNL INpactien
AlexRNL Le mardi 13 décembre 2011 à 16:41:41
Inscrit le samedi 7 novembre 09 - 1199 commentaires

Tu as lu la news ?

Depuis quand on lit les news avant de commenter ?

Serais-tu nouveau sur PCI ? pastaper.gif
Avatar de sylnivhp INpactien
sylnivhp Le mardi 13 décembre 2011 à 17:02:27
Inscrit le samedi 11 février 06 - 6009 commentaires


Voila le type même de news totalement inutile....!

Inutile parce que :

1): - je n'ai rien compris à la news.
2): - je n'ai rien compris aux coms.
3): - je n'utilise ni IOS ni Android.

les news ousque je sais pas quicékitroll et quicéki est sérieux avec des trucs techniques que je comprends rien à rien, ça me gonfle, et donc, elles ne devraient pas avoir lieu d'être.....!

c'tout !


Nanfume.gif
Avatar de Spydeus INpactien
Spydeus Le mardi 13 décembre 2011 à 17:14:28
Inscrit le samedi 3 décembre 05 - 54 commentaires
Il est vrai que développer avec les outils fournis par Google est un vrai calvaire :
  • L'émulateur est vraiment nul à ch*** (lent, couleurs qui n'ont rien à voir avec le tel)
  • Pas d'informations sur les ressources CPU/RAM
  • Manque cruel de formation des développeurs : je tiens à remercier tous les blogs et forums pour leurs aides. Malheureusement, bien souvent il s'agit de reprise d'explication fournies sur le site Andoid developpers.
  • Franchement, faire un peu de design en XML avec Eclipse c'est du suicide : quand vous lancez l'appli pour tester vous obtenez une erreur : il suffit bien souvent de rafraichir le projet, et ensuite les fichiers XML sont tout cassé, il faut fermer/laner Eclispe pour résoudre le bug.


Manque cruel de formation des développeurs : je tiens à remercier tous les blogs et forums pour leurs aides. Malheureusement, bien souvent il s'agit de reprise d'explication fournies sur le site Andoid developpers.

D'ailleurs, est-ce que chez Google ils savent construire un tutoriel ? Parce que bien souvent il n'y a que 3 lignes de code, pas de sources et ça ne marche pas parfois.
Avatar de bambou51 INpactien
bambou51 Le mardi 13 décembre 2011 à 17:24:15
Inscrit le lundi 9 mai 05 - 318 commentaires
Il est vrai que développer avec les outils fournis par Google est un vrai calvaire :
  • L'émulateur est vraiment nul à ch*** (lent, couleurs qui n'ont rien à voir avec le tel)
  • Pas d'informations sur les ressources CPU/RAM
  • Manque cruel de formation des développeurs : je tiens à remercier tous les blogs et forums pour leurs aides. Malheureusement, bien souvent il s'agit de reprise d'explication fournies sur le site Andoid developpers.
  • Franchement, faire un peu de design en XML avec Eclipse c'est du suicide : quand vous lancez l'appli pour tester vous obtenez une erreur : il suffit bien souvent de rafraichir le projet, et ensuite les fichiers XML sont tout cassé, il faut fermer/laner Eclispe pour résoudre le bug.



Manque cruel de formation des développeurs : je tiens à remercier tous les blogs et forums pour leurs aides. Malheureusement, bien souvent il s'agit de reprise d'explication fournies sur le site Andoid developpers.

D'ailleurs, est-ce que chez Google ils savent construire un tutoriel ? Parce que bien souvent il n'y a que 3 lignes de code, pas de sources et ça ne marche pas parfois.



Je suis d'accord pour l'émulateur qui est vraiment trop lent pour être vraiment utilisable, en revanche la doc est plutot complete et bien foutue.
Dans le pire des cas tu te prend un bon bouquin...
Et concernant tes problèmes de resources, c'est ton workspace qui doit etre cassé, car je n'ai jamais rencontré le moindre problème et ce sur différents poste de dev ;)

Edité par bambou51 le mardi 13 décembre 2011 à 17:25
Avatar de canti INpactien
canti Le mardi 13 décembre 2011 à 17:28:18
Inscrit le lundi 5 mai 03 - 4337 commentaires



Je suis d'accord pour l'émulateur qui est vraiment trop lent pour être vraiment utilisable, en revanche la doc est plutot complete et bien foutue.
Dans le pire des cas tu te prend un bon bouquin...
Et concernant tes problèmes de resources, c'est ton workspace qui doit etre cassé, car je n'ai jamais rencontré le moindre problème et ce sur différents poste de dev ;)

je confirme
Avatar de atomusk Modérateur
atomusk Le mardi 13 décembre 2011 à 17:45:47
Inscrit le mardi 20 juillet 04 - 21714 commentaires

pareil
Avatar de Myosis INpactien
Myosis Le mardi 13 décembre 2011 à 17:48:12
Inscrit le lundi 26 janvier 04 - 532 commentaires

Tu as lu la news ?
Nulle par il est dit que c'est lié exclusivement aux éditeurs tiers.


J'ai beau la lire et la relire, je ne vois pas pourquoi Google Maps rame sur un AsusTransformer...

Qu'ICS fasse la part belle à l'accélération matérielle ok. Mais une app comme Maps n'en bénéficie toujours pas sous HC ?
Avatar de atomusk Modérateur
atomusk Le mardi 13 décembre 2011 à 17:53:39
Inscrit le mardi 20 juillet 04 - 21714 commentaires


J'ai beau la lire et la relire, je ne vois pas pourquoi Google Maps rame sur un AsusTransformer...

Qu'ICS fasse la part belle à l'accélération matérielle ok. Mais une app comme Maps n'en bénéficie toujours pas sous HC ?


pour le coup, tu as lu la partie du message que je quote ?

Personne ne parle d'opérateur, et pour les raisons du lag de Google Map sur un Asus transformer, il faudrait demander au developpeur de GMAP, aux developpeurs de Drivers de Asus, et au developpeur des autres process qui tournent peut être en tache de fond et déclanchent peut être des GC en masse
Avatar de Myosis INpactien
Myosis Le mardi 13 décembre 2011 à 18:00:14
Inscrit le lundi 26 janvier 04 - 532 commentaires

il faudrait demander au developpeur de GMAP, aux developpeurs de Drivers de Asus, et au developpeur des autres process qui tournent peut être en tache de fond


Une façon courtoise de dire que personne ne sait pourquoi ça rame ça !
;