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