Graphismes

Le framework Android propose diverses API de rendu graphique pour les formats 2D et 3D qui interagissent avec les implémentations des pilotes graphiques par les fabricants. Il est donc important de bien comprendre le fonctionnement de ces API à un niveau supérieur. Cette page présente la couche d'abstraction matérielle graphique (HAL) sur laquelle ces pilotes sont basés. Avant de poursuivre cette section, familiarisez-vous avec les termes suivants:

canevas (terme générique), Canvas (élément d'API)

Un canevas est une surface de dessin qui gère la composition des bits réels sur un bitmap ou un objet Surface. Canvas dispose de méthodes pour le dessin informatique standard de bitmaps, de lignes, de cercles, de rectangles, de texte, etc., et est lié à un bitmap ou à une surface. Un canevas est le moyen le plus simple de dessiner des objets 2D à l'écran. La classe de base est Canvas.

drawable

Un drawable est une ressource visuelle compilée qui peut être utilisée comme arrière-plan, titre ou autre partie de l'écran. Un drawable est généralement chargé dans un autre élément d'interface utilisateur, par exemple en tant qu'image de fond. Un drawable ne peut pas recevoir d'événements, mais il attribue d'autres propriétés telles que l'état et la planification pour activer des sous-classes telles que des objets d'animation ou des bibliothèques d'images. De nombreux objets drawable sont chargés à partir de fichiers de ressources drawable (fichiers XML ou bitmap qui décrivent l'image). Les ressources drawables sont compilées en sous-classes de android.graphics.drawable. Pour en savoir plus sur les drawables et les autres ressources, consultez la section Ressources.

ressource de mise en page

Une ressource de mise en page est un fichier XML qui décrit la mise en page d'un écran d'activité. Pour en savoir plus, consultez la section Ressource de mise en page.

nine-patch (9-patch, NinePatch)

Un nine-patch est une ressource bitmap redimensionnable qui peut être utilisée pour les arrière-plans ou d'autres images sur l'appareil. Pour en savoir plus, consultez la section Neuf patches.

OpenGL ES

OpenGL ES est une API multiplate-forme permettant de créer des graphismes 2D et 3D. Android fournit des bibliothèques OpenGL ES pour le rendu 3D avec accélération matérielle. Pour le rendu 2D, un canevas est l'option la plus simple. OpenGL ES est disponible dans le kit de développement natif Android (NDK). Les packages android.opengl et javax.microedition.khronos.opengles exposent les fonctionnalités OpenGL ES.

surface (terme générique), Surface (élément d'API)

Une surface représente un bloc de mémoire qui est composé à l'écran. Une surface contient un canevas pour le dessin et fournit diverses méthodes d'assistance pour dessiner des calques et redimensionner l'objet Surface. Utilisez la classe SurfaceView au lieu de la classe Surface directement.

Vue de surface (terme générique), SurfaceView (élément d'API)

Une vue de surface est un objet View qui encapsule un objet Surface pour le dessin et expose des méthodes permettant de spécifier sa taille et son format de manière dynamique. Une vue de surface permet de dessiner indépendamment du thread d'UI pour les opérations gourmandes en ressources, telles que les jeux ou les aperçus de l'appareil photo, mais elle utilise de la mémoire supplémentaire. Une vue de surface est compatible avec le canevas et les graphiques OpenGL ES. La classe de base d'un objet SurfaceView est SurfaceView.

theme

Un thème est un ensemble de propriétés, telles que la taille du texte et la couleur d'arrière-plan, regroupées pour définir différents paramètres d'affichage par défaut. Android fournit quelques thèmes standards, listés dans R.style et précédés de Theme_.

vue (terme générique), View (élément d'API)

Une vue dessine une zone rectangulaire à l'écran et gère les clics, les frappes au clavier et d'autres événements d'interaction. La classe View est la classe de base pour la plupart des composants de mise en page d'une activité ou d'un écran de boîte de dialogue, tels que les zones de texte et les fenêtres. Un objet View reçoit des appels de son objet parent (voir ViewGroup) pour s'afficher et informe son objet parent de sa taille et de son emplacement préférés, qui peuvent ne pas être respectés par le parent. Pour en savoir plus, consultez View.

groupe de vues (terme générique), ViewGroup (élément d'API)

Un groupe de vues regroupe un ensemble de vues enfants. Le groupe de vues est chargé de déterminer l'emplacement des vues enfants et leur taille, ainsi que d'appeler chacune d'elles pour qu'elle s'affiche si nécessaire. Certains groupes de vues sont invisibles et ne servent qu'à la mise en page, tandis que d'autres disposent d'une UI intrinsèque, comme une zone de liste à faire défiler. Les groupes de vues se trouvent dans le package widget, mais étendent la classe ViewGroup.

hiérarchie des vues

Une hiérarchie de vues est une disposition d'objets de vue et de groupe de vues qui définit l'interface utilisateur pour chaque composant d'une application. La hiérarchie se compose de groupes de vues contenant une ou plusieurs vues ou groupes de vues enfants. Vous pouvez obtenir une représentation visuelle d'une hiérarchie de vues pour le débogage et l'optimisation à l'aide du Visionneuse de hiérarchie fourni avec le SDK Android.

Vulkan

Vulkan est une API multiplate-forme simple permettant la création de graphiques 3D hautes performances.

widget

Un widget fait partie d'un ensemble de sous-classes de vues entièrement implémentées qui affichent des éléments de formulaire et d'autres composants d'UI, tels qu'une zone de texte ou un menu pop-up. Étant donné qu'un widget est entièrement implémenté, il gère la mesure, le dessin et la réponse aux événements d'écran. Les widgets se trouvent dans le package android.widget.

fenêtre (terme générique), Window (élément d'API)

Dans une application Android, une fenêtre est un objet dérivé de la classe abstraite Window qui spécifie les éléments d'une fenêtre générique, tels que l'apparence, le texte de la barre de titre, ainsi que l'emplacement et le contenu des menus. Les boîtes de dialogue et les activités utilisent une implémentation de la classe Window pour afficher un objet Window. Vous n'avez pas besoin d'implémenter la classe Window ni d'utiliser de fenêtres dans votre application.

Les développeurs d'applications dessinent des images à l'écran de trois manières: avec Canvas, OpenGL ES ou Vulkan.

Composants graphiques Android

Quelle que soit l'API de rendu utilisée par les développeurs, tout est affiché sur une surface. La surface représente le côté producteur d'une file d'attente de tampon souvent consommée par SurfaceFlinger. Chaque fenêtre créée sur la plate-forme Android est associée à une surface. Toutes les surfaces visibles affichées sont composées sur l'écran par SurfaceFlinger.

Le schéma suivant montre comment les principaux composants interagissent:

Figure 1 : Comment les surfaces sont-elles affichées ?

Les principaux composants sont décrits ci-dessous:

Producteurs de flux d'images

Un producteur de flux d'images peut être n'importe quel élément qui produit des tampons graphiques à consommer. Par exemple, OpenGL ES, Canvas 2D et les décodeurs vidéo du mediaserver.

Utilisateurs du flux d'images

Le consommateur le plus courant des flux d'images est SurfaceFlinger, le service système qui consomme les surfaces actuellement visibles et les compose sur l'écran à l'aide des informations fournies par le gestionnaire de fenêtres. SurfaceFlinger est le seul service pouvant modifier le contenu de l'écran. SurfaceFlinger utilise OpenGL et le compositeur matériel pour composer un groupe de surfaces.

D'autres applications OpenGL ES peuvent également consommer des flux d'images, comme l'application d'appareil photo qui consomme un flux d'image d'aperçu de l'appareil photo. Les applications non GL peuvent également être des consommateurs, par exemple la classe ImageReader.

Hardware Composer

Abstraction matérielle du sous-système d'affichage. SurfaceFlinger peut déléguer certaines tâches de composition au compilateur matériel pour décharger OpenGL et le GPU. SurfaceFlinger n'est qu'un autre client OpenGL ES. Par conséquent, lorsque SurfaceFlinger compose activement un ou deux tampons dans un troisième, par exemple, il utilise OpenGL ES. Cela réduit la consommation d'énergie de la composition par rapport à la réalisation de tous les calculs par le GPU.

Le HAL Hardware Composer effectue l'autre moitié du travail et constitue le point central de tous les rendus graphiques Android. Le compilateur matériel doit prendre en charge les événements, dont VSYNC (un autre est le hotplug pour la prise en charge du plug-and-play HDMI).

Gralloc

L'outil d'allocation de mémoire graphique (Gralloc) est nécessaire pour allouer la mémoire demandée par les producteurs d'images. Pour en savoir plus, consultez la section HAL Gralloc.

Flux de données

Consultez le schéma suivant pour voir une représentation du pipeline graphique Android:

Figure 2. Flux de données graphiques via Android

Les objets de gauche sont des moteurs de rendu produisant des tampons graphiques, tels que l'écran d'accueil, la barre d'état et l'UI du système. SurfaceFlinger est le compositeur, et le compositeur matériel est le compositeur.

BufferQueue

Les files d'attente de tampons servent de liaison entre les composants graphiques Android. Il s'agit d'une paire de files d'attente qui médiatisent le cycle constant de tampons du producteur au consommateur. Une fois que les producteurs ont transmis leurs tampons, SurfaceFlinger est chargé de tout composer sur l'écran.

Consultez le schéma suivant pour connaître le processus de communication de BufferQueue.

Figure 3. Processus de communication BufferQueue

BufferQueue contient la logique qui lie les producteurs de flux d'images et les consommateurs de flux d'images. Les aperçus de l'appareil photo produits par le HAL de l'appareil photo ou les jeux OpenGL ES sont des exemples de producteurs d'images. SurfaceFlinger ou une autre application qui affiche un flux OpenGL ES, comme l'application Appareil photo qui affiche le viseur de l'appareil photo, sont des exemples de consommateurs d'images.

BufferQueue est une structure de données qui combine un pool de mémoire tampon avec une file d'attente et utilise l'IPC Binder pour transmettre des tampons entre les processus. L'interface de production, ou ce que vous transmettez à quelqu'un qui souhaite générer des tampons graphiques, est IGraphicBufferProducer (qui fait partie de SurfaceTexture). BufferQueue est souvent utilisé pour effectuer un rendu sur une surface et la consommer avec un consommateur GL, entre autres tâches.

BufferQueue peut fonctionner dans trois modes différents:

Mode semblable à la synchronisation : par défaut, BufferQueue fonctionne en mode semblable à la synchronisation, dans lequel chaque tampon provenant du producteur est transmis au consommateur. Aucun tampon n'est jamais supprimé dans ce mode. Si le producteur est trop rapide et crée des tampons plus rapidement qu'ils ne sont vidés, il se bloque et attend des tampons libres.

Mode non bloquant : BufferQueue peut également fonctionner en mode non bloquant, où il génère une erreur plutôt que d'attendre un tampon dans ces cas. Aucun tampon n'est jamais supprimé dans ce mode. Cela permet d'éviter les interblocages potentiels dans les logiciels d'application qui ne comprennent peut-être pas les dépendances complexes du framework graphique.

Mode de suppression : enfin, BufferQueue peut être configuré pour supprimer les anciens tampons plutôt que de générer des erreurs ou d'attendre. Par exemple, si vous effectuez un rendu GL vers une vue de texture et un dessin aussi rapidement que possible, les tampons doivent être abandonnés.

Pour effectuer la majeure partie de ce travail, SurfaceFlinger ne fait que jouer le rôle de client OpenGL ES. Par exemple, lorsque SurfaceFlinger compose activement un ou deux tampons dans un troisième, il utilise OpenGL ES.

Le HAL Hardware Composer effectue l'autre moitié du travail. Ce HAL sert de point central pour tout le rendu graphique Android.