Tout ce que les développeurs doivent 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 de cette manière, ou comment les surfaces et EGLSurface interagissent, vous êtes au bon endroit.
Nous partons du principe que vous connaissez déjà les appareils Android et le développement d'applications. Vous n'avez pas besoin de connaissances détaillées sur le framework de l'application et très peu d'appels d'API sont mentionnés, mais le contenu ne chevauche pas d'autres documents publics. L'objectif est de fournir des informations 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, ce document fonctionne de bas en haut, décrivant le fonctionnement des classes d'UI plutôt que leur utilisation.
Cette section comprend plusieurs pages couvrant tous les aspects, des informations générales aux détails du HAL en passant par les cas d'utilisation. Il commence par expliquer les 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 suivant plutôt que de passer directement à un sujet qui vous intéresse.
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 pour l'affichage ou le traitement ultérieur (le consommateur). Les allocations de mémoire tampon sont effectuées par le biais de l'allocateur de mémoire gralloc implémenté par le biais d'une interface HAL spécifique au fournisseur.
- SurfaceFlinger, Hardware Composer et écrans virtuels SurfaceFlinger accepte les tampons de données provenant de plusieurs sources, les compose et les envoie à l'écran. Le HAL (Hardware Composer) HWC détermine la manière la plus efficace de composer des tampons avec le matériel disponible, et les affichages virtuels rendent la sortie composée disponible dans le système (enregistrement de l'écran ou envoi de l'écran 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 avec EGL, une bibliothèque qui peut créer des fenêtres et y accéder via le système d'exploitation (pour dessiner des polygones texturés, utilisez les appels GLES ; pour afficher le rendu à l'écran, utilisez les 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 offre des avantages tels que la réduction de la surcharge du processeur et la compatibilité avec le 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 entre les threads 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 BufferQueue dont votre application est le consommateur. Lorsqu'un producteur met en file d'attente un nouveau tampon, il en informe votre application, qui à son tour libère le tampon précédemment détenu, acquiert le nouveau tampon à partir de la file d'attente et effectue des appels EGL pour rendre le tampon disponible pour GLES en tant que texture externe. Android 7.0 a ajouté la prise en charge de la lecture sécurisée de vidéos de texture, ce qui permet le post-traitement GPU du contenu vidéo protégé.
- TextureView. TextureView combine une vue avec une SurfaceTexture. TextureView encapsule une SurfaceTexture et est responsable de la réponse aux rappels et de l'acquisition de nouveaux tampons. Lors du dessin, TextureView utilise le contenu du tampon le plus récemment reçu comme source de données, en effectuant le rendu où et comme l'indique l'état de la vue. La composition des vues est toujours effectuée avec GLES, ce qui signifie que les modifications apportées au contenu peuvent également entraîner le redessin d'autres éléments de vue.