Ce que chaque développeur doit savoir sur les surfaces, SurfaceHolder, EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView, SurfaceFlinger et Vulkan
Cette page décrit les éléments essentiels de l'architecture graphique au niveau du système Android et la façon dont ils sont utilisés par le framework d'application et le système multimédia. L'accent est mis sur la façon dont les tampons de données graphiques se déplacent dans le système. Si vous vous êtes déjà demandé pourquoi SurfaceView et TextureView se comportent comme ils le font, ou comment les surfaces et EGLSurface interagissent, vous êtes au bon endroit.
Une certaine connaissance des appareils Android et du développement d'applications est supposée. Vous n'avez pas besoin de connaissances détaillées sur le framework d'application, et très peu d'appels d'API sont mentionnés, mais le contenu ne se chevauche pas avec d'autres documentations publiques. L'objectif est de fournir des détails sur les événements importants impliqués dans le rendu d'un frame pour la sortie afin de vous aider à faire des choix éclairés lors de la conception d'une application. Pour ce faire, nous travaillons de bas en haut, en décrivant le fonctionnement des classes d'UI plutôt que leur utilisation.
Cette section comprend plusieurs pages couvrant tout, du matériel de fond aux détails de l'HAL aux cas d'utilisation. Il commence par une explication des tampons graphiques Android, décrit le mécanisme de composition et d'affichage, puis passe aux mécanismes de niveau supérieur qui fournissent des données au compositeur. Nous vous recommandons de lire les pages dans l'ordre indiqué ci-dessous plutôt que de passer directement à un sujet qui vous semble intéressant.
Composants de bas niveau
- BufferQueue et gralloc. BufferQueue connecte un élément qui génère des tampons de données graphiques (le producteur) à un élément qui accepte les données à afficher ou à traiter ultérieurement (le consommateur). Les allocations de tampons sont effectuées via l'outil d'allocation de mémoire gralloc implémenté via une interface HAL spécifique au fournisseur.
- SurfaceFlinger, le compositeur matériel et les écrans virtuels SurfaceFlinger accepte les tampons de données de plusieurs sources, les compose et les envoie à l'écran. Le HAL (Hardware Composer) détermine le moyen le plus efficace de composer des tampons avec le matériel disponible, et les écrans virtuels rendent la sortie composée disponible dans le système (en enregistrant l'écran ou en l'envoyant sur un réseau).
- Surface, canevas et SurfaceHolder Une surface produit une file d'attente de tampon qui est souvent consommée par SurfaceFlinger. Lors du rendu sur une surface, le résultat se retrouve dans un tampon qui est envoyé au consommateur. Les API Canvas fournissent une implémentation logicielle (avec prise en charge de l'accélération matérielle) pour dessiner directement sur une surface (alternative de bas niveau à OpenGL ES). Tout ce qui concerne une vue implique un SurfaceHolder, dont les API permettent d'obtenir et de définir des paramètres de surface tels que la taille et le format.
- EGLSurface et OpenGL ES OpenGL ES (GLES) définit une API de rendu graphique conçue pour être combinée à EGL, une bibliothèque pouvant créer et accéder aux fenêtres via le système d'exploitation (pour dessiner des polygones texturés, utilisez des appels GLES ; pour afficher le rendu à l'écran, utilisez des appels EGL). Cette page aborde également ANativeWindow, l'équivalent C/C++ de la classe Java Surface utilisée pour créer une surface de fenêtre EGL à partir de code natif.
- Vulkan Vulkan est une API multiplate-forme simple permettant la création de graphiques 3D hautes performances. Comme OpenGL ES, Vulkan fournit des outils permettant de créer des graphiques en temps réel de haute qualité dans les applications. Vulkan présente des avantages, comme la réduction des frais généraux du processeur et la prise en charge du langage SPIR-V Binary Intermediate.
Composants de haut niveau
- SurfaceView et GLSurfaceView SurfaceView combine une surface et une vue. Les composants de vue de SurfaceView sont composés par SurfaceFlinger (et non par l'application), ce qui permet le rendu à partir d'un thread/processus distinct et l'isolation du rendu de l'UI de l'application. GLSurfaceView fournit des classes d'assistance pour gérer les contextes EGL, la communication interthread et l'interaction avec le cycle de vie de l'activité (mais n'est pas nécessaire pour utiliser GLES).
- SurfaceTexture. SurfaceTexture combine une surface et une texture GLES pour créer une file d'attente de tampons dont votre application est le consommateur. Lorsqu'un producteur met en file d'attente un nouveau tampon, il en informe votre application, qui libère le tampon précédemment détenu, acquiert le nouveau tampon de la file d'attente et effectue des appels EGL pour le mettre à la disposition de GLES en tant que texture externe. Android 7.0 a ajouté la prise en charge de la lecture vidéo de texture sécurisée, ce qui permet le post-traitement du contenu vidéo protégé par GPU.
- TextureView TextureView combine une vue avec une SurfaceTexture. TextureView encapsule une SurfaceTexture et se charge de répondre aux rappels et d'acquérir de nouveaux tampons. Lors du dessin, TextureView utilise le contenu du tampon le plus récemment reçu comme source de données, en affichant où et comment l'état de la vue l'indique. La composition de la vue est toujours effectuée avec GLES, ce qui signifie que les mises à jour des contenus peuvent également entraîner le redessin d'autres éléments de la vue.