Graphismes

Le framework Android propose une variété d'API de rendu graphique pour la 2D et la 3D qui interagissent avec les implémentations de pilotes graphiques par les fabricants. Il est donc important d'avoir une bonne compréhension du 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 construits. Avant de continuer avec cette section, familiarisez-vous avec les termes suivants :

canvas (terme générique), Canvas (élément API)

Un canevas est une surface de dessin qui gère la composition des bits réels par rapport à un bitmap ou un objet Surface . Canvas dispose de méthodes de 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 et le plus simple de dessiner des objets 2D sur l'écran. La classe de base est Canvas .

dessinable

Un dessinable est une ressource visuelle compilée qui peut être utilisée comme arrière-plan, titre ou autre partie de l'écran. Un dessinable est généralement chargé dans un autre élément de l'interface utilisateur, par exemple en tant qu'image d'arrière-plan. Un drawable n'est pas capable de recevoir des événements, mais 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 dessinables sont chargés à partir de fichiers de ressources dessinables : fichiers XML ou bitmap qui décrivent l'image. Les ressources dessinables sont compilées en sous-classes de android.graphics.drawable . Pour plus d'informations sur les drawables et autres ressources, consultez 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 plus d’informations, consultez Ressource de mise en page .

neuf patchs (9 patchs, NinePatch)

Un neuf patchs est une ressource bitmap redimensionnable qui peut être utilisée pour les arrière-plans ou d'autres images sur l'appareil. Pour plus d’informations, consultez Nine-patch .

OpenGL ES

OpenGL ES est une API multiplateforme pour le rendu de graphiques 2D et 3D. Android fournit des bibliothèques OpenGL ES pour un rendu 3D accéléré matériellement. 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 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 directement la classe SurfaceView au lieu de la classe Surface .

vue de surface (terme générique), SurfaceView (élément API)

Une vue de surface est un objet View qui enveloppe un objet Surface pour le dessin et expose des méthodes pour spécifier dynamiquement sa taille et son format. Une vue de surface permet de dessiner indépendamment du thread de l'interface utilisateur pour les opérations gourmandes en ressources, telles que les jeux ou les aperçus de la caméra, mais elle utilise par conséquent de la mémoire supplémentaire. Une vue de surface prend en charge à la fois les graphiques Canvas et OpenGL ES. La classe de base d'un objet SurfaceView 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 propose quelques thèmes standards, répertoriés dans R.style et précédés de Theme_ .

view (terme générique), View (élément API)

Une vue dessine une zone rectangulaire sur 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 présentation d'un écran d'activité ou 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, et informe son objet parent de sa taille et de son emplacement préférés, qui pourraient ne pas être respectés par le parent. Pour plus d'informations, voir View .

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

Un groupe de vues regroupe un ensemble de vues enfants. Le groupe de vues est chargé de décider où les vues enfants sont positionnées et quelle peut être leur taille, ainsi que d'appeler chacun à se dessiner le cas échéant. Certains groupes de vues sont invisibles et servent uniquement à la mise en page, tandis que d'autres disposent d'une interface utilisateur intrinsèque, telle qu'une zone de liste déroulante. Les groupes de vues sont dans le package widget , mais étendent la classe ViewGroup .

afficher la hiérarchie

Une hiérarchie de vues est un arrangement 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 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 de la visionneuse de hiérarchie fournie avec le SDK Android.

Vulcan

Vulkan est une API multiplateforme à faible surcharge pour les graphiques 3D hautes performances.

widget

Un widget fait partie d'un ensemble de sous-classes de vue entièrement implémentées qui restituent les éléments de formulaire et d'autres composants de l'interface utilisateur, tels qu'une zone de texte ou un menu contextuel. Parce qu'un widget est entièrement implémenté, il gère les mesures, le dessin et la réponse aux événements de l'écran. Les widgets se trouvent dans le package android.widget .

window (terme générique), Window (élément 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 restituer un objet Window . Vous n'avez pas besoin d'implémenter la classe Window ni d'utiliser Windows 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 tampon 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 diagramme suivant montre comment les composants clés fonctionnent ensemble :

Figure 1. Comment les surfaces sont rendues.

Les principaux composants sont décrits ci-dessous :

Producteurs de flux d'images

Un producteur de flux d'images peut être tout ce qui produit des tampons graphiques destinés à la consommation. Les exemples incluent les décodeurs vidéo OpenGL ES, Canvas 2D et 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 capable de modifier le contenu de l'affichage. SurfaceFlinger utilise OpenGL et Hardware Composer pour composer un groupe de surfaces.

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

Compositeur de matériel

L'abstraction matérielle pour le sous-système d'affichage. SurfaceFlinger peut déléguer certains travaux de composition à Hardware Composer 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 en un troisième, par exemple, il utilise OpenGL ES. Cela rend la composition moins gourmande que le fait que le GPU effectue tous les calculs.

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

Gralloc

L'allocateur de mémoire graphique (Gralloc) est nécessaire pour allouer la mémoire demandée par les producteurs d'images. Pour plus de détails, voir Gralloc HAL .

Flux de données

Consultez le diagramme suivant pour 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'interface utilisateur du système. SurfaceFlinger est le compositeur et Hardware Composer est le compositeur.

File d'attente tampon

BufferQueues fournit le lien entre les composants graphiques Android. Il s'agit d'une paire de files d'attente qui assurent le cycle constant de tampons du producteur au consommateur. Une fois que les producteurs ont remis leurs tampons, SurfaceFlinger est responsable de tout composer sur l'écran.

Consultez le diagramme suivant pour le processus de communication BufferQueue.

Figure 3. Processus de communication BufferQueue

BufferQueue contient la logique qui relie les producteurs de flux d'images et les consommateurs de flux d'images. Quelques exemples de producteurs d'images sont les aperçus de caméra produits par les jeux de caméra HAL ou OpenGL ES. Quelques exemples de consommateurs d'images sont SurfaceFlinger ou une autre application qui affiche un flux OpenGL ES, telle que l'application appareil photo affichant le viseur de l'appareil photo.

BufferQueue est une structure de données qui combine un pool de tampons avec une file d'attente et utilise Binder IPC pour transmettre des tampons entre les processus. L'interface du producteur, 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 le rendu sur une Surface et consommer avec un consommateur GL, entre autres tâches.

BufferQueue peut fonctionner selon trois modes différents :

Mode de type synchrone - BufferQueue fonctionne par défaut dans un mode de type synchrone, dans lequel chaque tampon provenant du producteur sort vers le consommateur. Aucun tampon n'est jamais supprimé dans ce mode. Et si le producteur est trop rapide et crée des tampons plus rapidement qu'ils ne sont épuisés, il se bloquera et attendra des tampons libres.

Mode non bloquant - BufferQueue peut également fonctionner dans un 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 non plus. Ceci est utile pour éviter les blocages potentiels dans les logiciels d'application qui pourraient ne pas comprendre les dépendances complexes du cadre 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 dessinez le plus rapidement possible, les tampons doivent être supprimés.

Pour effectuer la majeure partie de ce travail, SurfaceFlinger agit comme un simple client OpenGL ES. Ainsi, lorsque SurfaceFlinger compose activement un ou deux tampons en un troisième, par exemple, il utilise OpenGL ES.

Le Hardware Composer HAL réalise l’autre moitié du travail. Ce HAL sert de point central pour tous les rendus graphiques Android.