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

Quand des (ex) employés de Google se penchent sur la fluidité d'Android

Le débat est ouvert, les solutions plurielles

Plusieurs messages postés par des employés et ex-employés de Google viennent éclairer la question des performances de l’interface d’Android d’un jour nouveau. Lorsque l’on évoque le système mobile, la fluidité de l’interface est régulièrement pointée du doigt comme n’étant pas d’une fluidité parfaite. Pourquoi ? Éléments de réponse.

galaxy nexus

L'accélération graphique existe depuis Android 1.0

Les éléments de réponse ont commencé à être donnés par Dianne Hackborn, ingénieur logiciel sur Android. Elle indique dans un billet sur Google+ qu’elle s’est décidée à aborder le sujet car les critiques sur la fluidité de l’interface d’Android reviennent régulièrement sur le tapis. Elle ne prétend pas contester ce manque de fluidité, mais a tenu à rétablir quelques vérités techniques.

Ainsi, l’accélération graphique existe au sein d’Android depuis la version 1.0. Bien entendu, elle a grandement évolué et n’est devenue totale qu’avec la mouture 3.0 (Honeycomb). La conséquence de cette accélération est que la grande majorité des animations visibles à l’écran ainsi que l’affichage des fenêtres elle-même a bénéficié de cette accélération. Il faut savoir cependant que toutes les versions d’Android antérieures à la 3.0 utilisent une méthode logicielle pour mettre à jour le contenu au sein d’une fenêtre. Cependant, cette mise à jour ne provoque pas un rafraichissement de tous les autres éléments.

L'accélération a ses propres problèmes

Elle indique également que si l’accélération complète est arrivée avec Android 3.0, la version 4.0 l’a rendue plus systématique. Pourquoi ? Parce qu'une application visant la dernière mouture du système sera automatiquement accélée. Comme elle le précise toutefois, il n’y a pas de recette magique avec l’accélération : chaque élément en bénéficiant consomme tout simplement plus de mémoire vive. Ce n’est pas forcément un problème sur des téléphones récents comme le Galaxy SII, mais ce peut l’être sur des modèles plus anciens.

L’ingénieure cite également un cas pratique, celui d’Android 4.0 sur le Nexus S. les développeurs ont remarqué que l’interface pouvait parfois être plus lente qu’avec Android 3.0. Pourquoi ? Parce qu’une application peut gérer un événement tactile pendant qu’elle dessine du contenu à l’écran et sauter à l’événement suivant sans que ce dernier soit réellement prêt, ce qui provoque un saut dans les images. Elle précise cependant dans une mise à jour de son billet que la puissance du GPU est un élément crucial quand la définition de l’écran augmente, comme dans le cas du Galaxy Nexus et ses 720p.

Une question de priorité ?

Mais Andrew Munn, anciennement stagiaire chez Google,  a publié lui aussi un billet venant compléter celui de Dianne Hackborn. Il a décidé de s’attaquer à une question qu’il entend régulièrement : « Pourquoi Android manque-t-il de fluidité alors qu’iOS, Windows Phone 7, QNX et WebOs sont fluides ? ». Il fournit quelques éléments de réponses en indiquant bien que ses connaissances peuvent être incomplètes et que ses explications ne concernent que lui.

Premièrement, il tord le cou à quelques idées reçues, notamment le fait que le code d’iOS (pris en exemple) soit natif explique la différence de performances face au bytecode d’Android (machine virtuelle Java). La différence se situe ailleurs : iOS (et Windows Phone 7) ont un processus dédié en charge de la gestion des évènements tactiles. Or, ce processus dispose d’une priorité temps réel.

Il donne exemple le chargement d’une page dans Safari : à mi-chemin du chargement, poser le doigt sur l’écran et « remuer » l’image stoppe l’apparition des éléments suivants. La même manipulation sur Android donne des résultats différents. Le système de Google calcule l’ensemble des évènements en même temps, le tactile comme le chargement de la page.

Il s’agit d’une explication très simplifiée complétée d’ailleurs par une mise à jour. Dans celle-ci, il cite l’un de ses lecteurs pour ajouter une précision de taille : certes un développeur iOS peut faire basculer l’intégralité du code de son application sur le processus principal, mais cela n’a rien d’obligatoire, et ce n’est en fait pas recommandé. La composition de l’affichage et le lot des animations sont calculés dans un processus en arrière-plan. Tout nouveau contenu est ensuite basculé sur le processus principal.

D'autres facteurs sont à prendre en compte

La priorité du processus n’est pas la seule explication : la puissance du GPU a une importance directe sur les performances ressenties. D’autres explications sont données :
  • Les performances du ramasse-miette dans la machine virtuelle Dalvik ont un impact réel, pour les raisons que nous évoquions d’ailleurs au sujet d’un changement important en préparation dans Chrome
  • D’un GPU à un autre, les possibilités peuvent être différentes. Le Tegra 2 de NVIDIA ne possède par exemple pas les instructions NEON que l’on peut comparer grossièrement au SSE des processeurs Intel.
  • Sur iOS, chaque élément de l’interface utilisateur dispose d’un rendu séparé et le GPU peut les manipuler dans le désordre. Sur Android, ce n’est pas le cas : chaque animation nécessite que soit redessinés tous les éléments affectés.
  • Une bonne partie de l’interface s’appuie sur Dalvik et ses performances ne sont parfois pas suffisantes.
Pour Munn, il n’y aura pas d’amélioration franche de la fluidité tant que le framework responsable de l’interface ne serai pas rebâti autrement. Il cite Romain Guy, ingénieur chez Google responsable d’une partie de travail effectué sur l’accélération graphique dans Android 3.0. Selon Guy, Google réfléchit actuellement à des solutions pour contourner les problèmes soulevés, notamment la manière dont le système traite les animations.

Pourtant, Romain Guy, même s’il est d’accord sur le concept d’un nouveau framework, soulève les gros défauts d’une telle décision. La plus importante serait l’énorme modification que cela entraine dans la base du système et la cassure dans la compatibilité des applications. Il faudrait alors créer un mode Legacy (héritage) pour que les anciennes applications fonctionnent tout en promouvant le nouveau framework. En outre, de nombreuses parties du système ne pourraient plus évoluer tant que ce framework ne serait pas prêt.

Le problème est donc soulevé, mais Google est parfaitement au courant de la situation. Les différences entre les systèmes apparaissent comme étant davantage de l’ordre décisionnel/culturel mais il est clair que la réactivité et la fluidité sont deux éléments cruciaux aujourd’hui dans l’appréciation d’un produit tactile.
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 07/12/2011 à 18:11

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 65 commentaires

Avatar de Myosis INpactien
Myosis Le mercredi 7 décembre 2011 à 18:21:07
Inscrit le lundi 26 janvier 04 - 532 commentaires
Le problème est donc soulevé, mais Google est parfaitement au courant de la situation. Les différences entre les systèmes apparaissent comme étant davantage de l’ordre décisionnel/culturel mais il est clair que la réactivité et la fluidité sont deux éléments cruciaux aujourd’hui dans l’appréciation d’un produit tactile.


C'est une bonne nouvelle si ils se penchent dessus, c'est vrai qu'il n'y a rien de plus désagréable qu'une interface tactile qui lag... On se croirait sur une borne SNCF...

De là à imposer un nouveau framework... et perdre toutes ses anciennes applications...

Edité par myosis le mercredi 7 décembre 2011 à 18:24
Avatar de ErGo_404 INpactien
ErGo_404 Le mercredi 7 décembre 2011 à 18:26:33
Inscrit le lundi 16 mai 05 - 3903 commentaires
Le galaxy nexus ne souffre pas de ralentissements contrairement aux versions d'avant. C'est probablement dû à un puissance brute énorme, et cela peut donc être encore optimisé (pour gagner en batterie par exemple). C'est bien qu'ils reconnaissent le problème.

Pour moi ça a été un peu l'effet Vista, sur le coup ça me paraissait parfaitement fluide, mais en passant à 7 je me suis rendu compte que ça l'était pas toujours tant que ça. Sur Android ça a été pareil, ce n'est qu'en voyant les dernières versions que je me suis rendu compte que les anciennes n'étaient pas tip top. Seule exception : Honeycomb, qui a des ralentissements inexplicables sur un Tegra 2.

Par contre ça me ferait pas trop chier qu'ils se repenchent un peu sur la création d'IHM sous Android (et donc pourquoi pas refaire le framework complet de l'affichage), c'est pas encore la panacée je trouve.
Avatar de Seth-Erminatores INpactien
Seth-Erminatores Le mercredi 7 décembre 2011 à 18:27:09
Inscrit le dimanche 13 novembre 05 - 8214 commentaires
Premièrement, il tord le cou à quelques idées reçues, notamment le fait que le code d’iOS (pris en exemple) soit natif explique la différence de performances face au bytecode d’Android (machine virtuelle Java). La différence se situe ailleurs : iOS (et Windows Phone 7) ont un processus dédié en charge de la gestion des évènements tactiles. Or, ce processus dispose d’une priorité temps réel.
ceci explique cela, même si pour mon cas perso entre mon ipod touch et mon desire Z je ne sens pas réellement de différence
Avatar de Khalev INpactien
Khalev Le mercredi 7 décembre 2011 à 18:29:03
Inscrit le mercredi 1 avril 09 - 5643 commentaires
De toute façon c'était sur que iOS/WP7/RIMOS/... surpasse l'OS de pauvre qu'est Android. Même au niveau de la conception.troll.gif

Ça c'est fait, passons aux discussion intelligentes maintenant.

Il faudrait alors créer un mode Legacy (héritage) pour que les anciennes applications fonctionnent tout en promouvant le nouveau framework.

C'est la même problématique que microsoft avait avec IE6. Comment évoluer sans tout casser.

Et un mode legacy sur un système mobile, ça va pas commencer à faire un peu lourd?

P.S: il fait froid sur PCI, vous ne trouvez pas?

Edité par khalev le mercredi 7 décembre 2011 à 18:30
Avatar de jmanici INpactien
jmanici Le mercredi 7 décembre 2011 à 18:34:44
Inscrit le mardi 20 septembre 11 - 1244 commentaires
Une bonne partie de l’interface s’appuie sur Dalvik et ses performances ne sont parfois pas suffisantes.


c'est un peu paradoxal...

google autorise le code natif pour les appli tierces mais se sert de code managé pour une partie de son interface (alors qu'ils ont largement les compétences et le temps humain pour tout coder en natif)

sous wp7 c'est exactement le contraire:
MS n'autorise pas le code natif pour les applis tierces (officiellement), mais l'intégralité du systeme et des applis de base qui composent l'interface sont en code natif.


Pourtant, Romain Guy, même s’il est d’accord sur le concept d’un nouveau framework, soulève les gros défauts d’une telle décision. La plus importante serait l’énorme modification que cela entrainement dans la base du système et la cassure dans la compatibilité des applications. Il faudrait alors créer un mode Legacy (héritage) pour que les anciennes applications fonctionnent tout en promouvant le nouveau framework. En outre, de nombreuses parties du système ne pourraient plus évoluer tant que ce framework ne serait pas prêt


entre ça et les problemes de malwares, android commence à devenir windows

Il y a 65 commentaires

;