Note : L'article ci-dessous traite principalement des optimisations sur les Views. Ne perdez pas à l'esprit que les concepts décrits ici sont aussi applicables à toutes notions graphiques sur Android (Drawable, Canvas, etc.)
Une belle interface graphique passe généralement par une utilisation souvent excessive de la transparence dans le design. Lorsqu'on regarde de plus prêt le code source d'Android et notamment les ressource graphiques disponibles dans le dossier res/drawable (images, 9-patchs, etc.), on se rend même compte qu'il est difficile de “vivre” sans transparence. C'est une des raisons pour laquelle le format PNG24 est largement préconisé dans le développement sous Android (le fait que ce soit un format ouvert et efficace joue également énormément dans la balance). Développer une interface graphique qui s'adapte à différentes tailles d'écran mais sans avoir accès à une notion de transparence s'avère malheureusement un calvaire et ne sera pas sans rappeler le développement web sous IE6 il y a encore peu de temps …
La transparence (ou parfois appelée “l'alpha”) engendre quelques conséquences sur l'interface graphique. En effet gérer l'alpha signifie forcément faire des calculs supplémentaires pour déterminer la couleur finale d'un pixel. Imaginons par exemple avoir 2 couches à superposer : une première couche (couche 1) totalement verte (#0f0) et une seconde (couche 2), qu'on pose sur la précédente, rouge transparent (#7f00). Le rendu s'effectue donc en 2 phases :
On applique/dessine la couche verte (couche 1)
On dessine ensuite la couche rouge transparente en effectuant, pour chaque pixel, un calcul permettant de déterminer la couleur résultante en fonction de actuel l'état (de la couleur) du pixel de coordonnée (x, y) à l'écran et du pixel (x, y) à appliquer.
Déterminer la couleur résultante passe par un calcul qui s'effectue sur chaque pixel. Bien que ce calcul se fasse via JNI (en C) - ou même parfois de façon matérielle, il n'en reste pas moins que c'est un calcul coûteux. L'utilisation de la transparence dans vos interfaces graphiques est donc forcément synonyme de “baisse de la rapidité/fluidité”. Votre objectif est donc maintenant de déterminer la valeur de cette baisse …
Une optimisation instaurée dans l'API level 7 sur View est isOpaque. Elle permet tout simplement d'informer le système si la vue est opaque (sans aucune transparence) ou non. Cette méthode peut sembler inutile mais elle peut pourtant permettre de nombreuses optimisations graphiques. En effet, si une vue opaque recouvre intégralement une autre vue, il n'est pas nécessaire de dessiner la vue sous-jacente. Les premières version d'Android n'intégraient pas ce mécanisme et redessinaient de façon totalement stupide l'intégralité des vues à chaque passe de dessin. Cette méthode apporte donc quelques optimisations permettant d'accélérer votre UI.
N'allez pas vous tracassez pour vos interfaces graphiques. Il n'est vraiment pas nécessaire de supprimer toute occurrence à la transparence dans vos UIs tant que ces dernières sont statiques. L'intérêt d'une telle optimisation est surtout applicable lorsque les vues sont animées car c'est à ce stade que les ralentissements peuvent se faire sentir. La ListView est probablement le widget le plus concerné par ces problèmes.