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:
Canvas (élément d'API)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.
android.graphics.drawable.
Pour en savoir plus sur les drawables et les autres ressources, consultez la section Ressources.
android.opengl et javax.microedition.khronos.opengles exposent les fonctionnalités OpenGL ES.Surface (élément d'API)Surface. Utilisez la classe SurfaceView au lieu de la classe Surface directement.
SurfaceView (élément d'API)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.
R.style et précédés de Theme_.View (élément d'API)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.
ViewGroup (élément d'API)widget, mais étendent la classe ViewGroup.
android.widget. Window (élément d'API)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.