Le framework Android offre une variété d'API de rendu graphique pour la 2D et la 3D qui interagissent avec les implémentations des fabricants de pilotes graphiques, il est donc important de bien comprendre comment ces API fonctionnent à un niveau supérieur. Cette page présente la couche d'abstraction matérielle graphique (HAL) sur laquelle ces pilotes sont construits.
Les développeurs d'applications dessinent des images à l'écran de trois manières : avec Canvas , OpenGL ES ou Vulkan .
Composants graphiques Android
Peu importe ce que les développeurs d'API de rendu utilisent, tout est rendu sur une surface . La surface représente le côté producteur d'une file d'attente de tampon qui est 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'affichage par SurfaceFlinger.
Le schéma 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 pour la consommation. Les exemples incluent OpenGL ES, Canvas 2D et les décodeurs vidéo de serveur multimédia.
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'affichage à 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, telles que l'application caméra 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 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 dans un troisième, par exemple, il utilise OpenGL ES. Cela rend la composition moins puissante que si le GPU effectuait tous les calculs.
Le Hardware Composer HAL réalise l'autre moitié du travail et est le point central de tous les rendus graphiques Android. Le compositeur de matériel 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 schéma suivant pour une description du pipeline graphique Android :
Figure 2. Flux de données graphiques via Android
Les objets sur la gauche sont des rendus 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.
BufferQueue
BufferQueues fournit la colle entre les composants graphiques Android. Il s'agit d'une paire de files d'attente qui assurent la médiation du 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.
Voir le schéma 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. Certains exemples de consommateurs d'images sont SurfaceFlinger ou une autre application qui affiche un flux OpenGL ES, comme 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 veut 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, entre autres tâches.
BufferQueue peut fonctionner dans 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 chez 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 vidés, il 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 peuvent ne pas comprendre les dépendances complexes du cadre graphique.
Mode Discard - 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 aussi rapidement que possible, les tampons doivent être supprimés.
Pour effectuer la majeure partie de ce travail, 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 Hardware Composer HAL réalise l'autre moitié du travail. Ce HAL agit comme le point central pour tous les rendus graphiques Android.