Graphismes

Le framework Android propose diverses API de rendu graphique pour la 2D et la 3D qui interagissent avec les implémentations des pilotes graphiques des 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 (HAL, Hardware Abstraction Layer) 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 par rapport à un bitmap ou à un Surface objet. La classe Canvas comporte des méthodes permettant de dessiner des bitmaps, des lignes, des cercles, des rectangles, du texte, etc. sur un ordinateur standard, et est liée à un bitmap ou à une surface. Un canevas est le moyen le plus simple et le plus facile 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 comme image d'arrière-plan. Un drawable ne peut pas recevoir d'événements, mais il attribue diverses 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 drawables sont chargés à partir de fichiers de ressources drawables (fichiers XML ou bitmap qui décrivent l'image). Les ressources drawables sont compilées dans des sous-classes de android.graphics.drawable. Pour en savoir plus sur les drawables et autres ressources, consultez la présentation des ressources d'application.

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 Nine-Patch.

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 accéléré par le matériel. Pour le rendu 2D un canevas est l'option la plus simple. OpenGL ES est disponible dans le kit de développement natif (NDK) Android. 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 SurfaceView classe au lieu de la Surface classe 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 UI pour les opérations gourmandes en ressources, telles que les jeux ou les aperçus de caméra, mais elle utilise davantage de mémoire. Une vue de surface est compatible avec les graphismes de canevas et OpenGL ES graphiques. La classe de base d'un SurfaceView objet est SurfaceView.

thème

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 divers 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 événements de clic, de frappe et autres événements d'interaction. La classe View est la classe de base pour la plupart des composants de mise en page d'un écran d'activité ou 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 se dessiner lui-même, 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 responsable de la position et de la taille des vues enfants ainsi que de l'appel de chacune d'elles pour qu'elles se dessinent elles-mêmes le cas échéant. Certains groupes de vues sont invisibles et ne sont utilisés que pour la mise en page, tandis que d'autres ont une interface utilisateur intrinsèque, comme une zone de liste à défilement. Les groupes de vues se trouvent dans le android.widget package, mais étendent la ViewGroup classe.

hiérarchie des vues

Une hiérarchie de vues est un arrangement d'objets de vue et de groupe de vues qui définit l'interface utilisateur de chaque composant d'une application. La hiérarchie se compose de groupes de vues qui contiennent une ou plusieurs vues enfants ou groupes de vues. Vous pouvez obtenir une représentation visuelle d'une hiérarchie de vues pour le débogage et l'optimisation à l'aide du Hierarchy Viewer 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 est l'une des sous-classes de vues entièrement implémentées qui affichent des éléments de formulaire et d'autres composants d'interface utilisateur, tels qu'une zone de texte ou un menu pop-up. Comme un widget est entièrement implémenté, il gère la mesure, le dessin lui-même et la réponse aux événements d'écran. Les widgets se trouvent dans le android.widget package.

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 Window classe abstraite qui spécifie les éléments d'une fenêtre générique, tels que l'apparence, le texte de la barre de titre, l'emplacement et le contenu des menus. Les boîtes de dialogue et les activités utilisent une implémentation de la Window classe pour afficher un Window objet. Vous n'avez pas besoin d'implémenter la classe Window ni d'utiliser des 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 rendu sur une surface. La surface représente le côté producteur d'une file d'attente de tampons souvent consommée par SurfaceFlinger. Chaque fenêtre créée sur la plate-forme Android est soutenue par une surface. Toutes les surfaces visibles rendues sont composées sur l'écran par SurfaceFlinger.

Le schéma suivant montre comment les composants clés fonctionnent ensemble :

Figure 1. Rendu des surfaces

Les principaux composants sont décrits dans les sections suivantes.

Producteurs de flux d'images

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

Consommateurs de flux d'images

Le consommateur le plus courant de 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 qui peut modifier le contenu de l'écran. SurfaceFlinger utilise OpenGL et Hardware Composer (HWC) pour composer un groupe de surfaces.

D'autres applications OpenGL ES peuvent également consommer des flux d'images, comme l'application de l'appareil photo qui consomme un flux d'images 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 pour le sous-système d'affichage. SurfaceFlinger peut déléguer certaines tâches de composition au HWC pour décharger le travail d'OpenGL et du GPU. SurfaceFlinger agit comme un autre client OpenGL ES. Ainsi, lorsque SurfaceFlinger compose activement un ou deux tampons dans un troisième, par exemple, il utilise OpenGL ES. Cela permet de réduire la consommation d'énergie par rapport à un GPU qui effectue tous les calculs.

Le HAL Hardware Composer effectue l'autre moitié du travail et constitue le point central de tout le rendu graphique Android. Le HWC doit être compatible avec les événements, dont VSync (l'autre est le branchement à chaud pour la prise en charge HDMI plug-and-play).

Gralloc

L'allocateur 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 BufferQueue et Gralloc.

Flux de données

Le schéma suivant illustre le pipeline graphique Android :

Figure 2. Flux de données graphiques via Android

Les objets de gauche sont des moteurs de rendu qui produisent des tampons graphiques, tels que l'écran d'accueil, la barre d'état et l'interface utilisateur du système. SurfaceFlinger est le compositeur et le HWC est le compositeur.

BufferQueue

Les BufferQueues fournissent le lien entre les composants graphiques Android. Il s'agit d'une paire de files d'attente qui gèrent le cycle constant des tampons du producteur au consommateur. Une fois que les producteurs ont transmis leurs tampons, SurfaceFlinger est responsable de la composition de tous les éléments sur l'écran.

Le schéma suivant illustre le processus de communication 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. Par exemple, les aperçus de l'appareil photo produits par le HAL de l'appareil photo ou les jeux OpenGL ES. Par exemple, SurfaceFlinger ou une autre application qui affiche un flux OpenGL ES, comme l'application de l'appareil photo qui affiche le viseur.

BufferQueue est une structure de données qui combine un pool de tampons avec une file d'attente et utilise la communication interprocessus (IPC) Binder pour transmettre des tampons entre les processus. L'interface du producteur, ou ce que vous transmettez à une personne 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 consommer avec un consommateur GL Consumer, entre autres tâches.

BufferQueue peut fonctionner dans trois modes différents :

mode de type synchrone

Par défaut, BufferQueue fonctionne dans un mode de type synchrone, 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 dans un mode non bloquant où il génère une erreur au lieu d'attendre un tampon dans ces cas. Aucun tampon n'est jamais supprimé dans ce mode non plus. 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

BufferQueue peut être configuré pour supprimer les anciens tampons au lieu de générer des erreurs ou d'attendre. Par exemple, si vous effectuez un rendu GL sur une vue de texture et que vous dessinez aussi rapidement que possible, les tampons doivent être supprimés.

Pour effectuer la plupart de ces tâches, SurfaceFlinger agit comme un autre client OpenGL ES. Ainsi, lorsque SurfaceFlinger compose activement un ou deux tampons dans un troisième, par exemple, il utilise OpenGL ES.

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