Dianne Hackborn, ingénieur chez Google, a publié un long billet qui s'exaspère au sujet des idées reçues concernant l'accélération matérielle sur Android.

L'enjeu de cette question repose essentiellement sur le manque de fluidité apparent d'Android comparé à d'autres OS mobiles, iOS en tête.

Pour autant, Hackborn tient à corriger quelques idées reçues : Android tire parti de l'accélération graphique pour certaines tâches depuis la toute première version, notamment la composition des fenêtres. Cependant, le rendu de l'intérieur des fenêtres est lui fait entièrement de manière logicielle. A partir de la version 3 d'Android, il est devenu possible d'utiliser l'accélération matérielle pour le rendu du contenu des fenêtres, mais uniquement sur l'initiative des développeurs d'applications. Android 4 rend la chose systématique.

Dianne Hackborn remet en question le fait que l'accélération graphique soit une solution universelle qui permettrait des animations fluides, tout en insistant sur le fait qu'Android en a toujours bénéficié. D'autres éléments viennent également jouer, comme par exemple le plus grand nombre de pixels à gérer sur un appareil comme le Galaxy Nexus.

De fait, qu'Android exploite ou non l'accélération matérielle n'est qu'une question secondaire, puisque ce qui pose problème c'est le manque de fluidité manifeste de l'interface. Dianne Hackborn se préoccupe plus de venir à bout de certaines idées reçues que d'expliquer cet état de fait.

C'est à cette question que s'est attelé Andrew Munn, étudiant et ancien stagiaire chez Google sur Android, et futur stagiaire chez Microsoft sur Windows Phone, en publiant à son tour un article de fond sur ce problème.

La différence fondamentale entre Android et iOS tient dans la distribution des priorités des tâches : sur iOS toute intervention de l'utilisateur interrompt les calculs en cours pour rendre l'interface fluide, alors qu'Android fait son possible pour tout traiter de manière simultanée. Mais si Apple fournit tous les outils nécessaires pour basculer une tâche donnée en tâche de fond, cela reste au développeur de l'application de faire ces choix : une application qui ferait l'impasse dessus pourrait s'avérer tout aussi saccadée que sur Android.

En réponse à Andrew Munn, Brent Royal-Gordon indique qu'il s'agit là plus d'une différence culturelle que technique entre les différents développeurs : sur iOS, les développeurs portent une attention particulière à la fluidité de leurs applications (sans doute facilitée par le nombre plus limité d'appareils sur lesquels tester).

Cependant, s'il incombe effectivement au développeur de faire le tri entre les tâches prioritaires, iOS fait de lui-même certaines modifications lorsqu'un contact du doigt est détecté : certains threads sont basculés dans des modes spéciaux, et des rappels de fonctions sont mis en pause.

Pour autant, sur Android l'interface utilisateur ne bénéficie d'aucune priorité particulière, et son rendu a lieu sur le thread principal des applications. Ce problème structurel existait également sur Windows Phone 6.5, BlackBerry OS, et Symbian, et n'a été résolu qu'en reprenant les choses à la base, voire en abandonnant l'OS pour un autre.

Andrew Munn ne considère pas que cette différence condamne Android à demeurer éternellement saccadé, mais pour l'heure du moins elle explique cet état de fait. Une modification du comportement d'Android sur ce point nécessiterait cependant la création d'un nouveau toolkit pour l'interface, qui exigerait une réécriture des applications existantes pour en tirer parti, ainsi qu'un mode permettant la rétro-compatibilité.