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.
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’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.
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.
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.
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.
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.
