Architecture graphique

Ce que tout 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 comment 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 familiarité avec les appareils Android et le développement d'applications est supposée. Vous n'avez pas besoin d'une connaissance détaillée du framework de l'application et très peu d'appels API sont mentionnés, mais le matériel ne chevauche pas d'autres documentations publiques. L'objectif est de fournir des détails sur les événements importants impliqués dans le rendu d'un cadre de sortie afin de vous aider à faire des choix éclairés lors de la conception d'une application. Pour y parvenir, nous travaillons de bas en haut, décrivant comment fonctionnent les classes d’interface utilisateur plutôt que comment elles peuvent être utilisées.

Cette section comprend plusieurs pages couvrant tout, des documents de base aux détails HAL en passant par les 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 semble intéressant.

Composants de bas niveau

  • BufferQueue et graloc . BufferQueue connecte quelque chose qui génère des tampons de données graphiques (le producteur ) à quelque chose qui accepte les données pour affichage ou traitement ultérieur (le consommateur ). Les allocations de tampon sont effectuées via l'allocateur de mémoire gralloc implémenté via une interface HAL spécifique au fournisseur.
  • SurfaceFlinger, Hardware Composer et écrans virtuels . SurfaceFlinger accepte des tampons de données provenant de plusieurs sources, les compose et les envoie à l'écran. Le Hardware Composer HAL (HWC) détermine le moyen le plus efficace de composer des tampons avec le matériel disponible, et les écrans virtuels rendent la sortie composite disponible au sein du 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 tampon qui est souvent consommée par SurfaceFlinger. Lors du rendu sur une surface, le résultat se retrouve dans un tampon qui est expédié 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 capable de créer et d'accéder à des fenêtres via le système d'exploitation (pour dessiner des polygones texturés, utilisez les appels GLES ; pour mettre le rendu à l'écran, utilisez les appels EGL ). Cette page couvre é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.
  • Vulcan . Vulkan est une API multiplateforme à faible surcharge pour les 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. Les avantages de Vulkan incluent des réductions de la surcharge 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), permettant le rendu à partir d'un thread/processus distinct et l'isolation du rendu de l'interface utilisateur de l'application. GLSurfaceView fournit des classes d'assistance pour gérer les contextes EGL, la communication entre threads et l'interaction avec le cycle de vie de l'activité (mais n'est pas obligatoire pour utiliser GLES).
  • Texture de surface . SurfaceTexture combine une surface et une texture GLES pour créer une BufferQueue dont votre application est le consommateur. Lorsqu'un producteur met un nouveau tampon en file d'attente, il en informe votre application, qui à son tour libère le tampon précédemment détenu, acquiert le nouveau tampon de la file d'attente et effectue des appels EGL pour rendre le tampon disponible à GLES en tant que texture externe. Android 7.0 a ajouté la prise en charge de la lecture vidéo à texture sécurisée permettant le post-traitement GPU du contenu vidéo protégé.
  • TextureView . TextureView combine une vue avec une SurfaceTexture. TextureView encapsule une SurfaceTexture et prend la responsabilité 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, rendant le rendu où et comme l'état d'affichage l'indique. La composition des vues est toujours effectuée avec GLES, ce qui signifie que les mises à jour du contenu peuvent également entraîner le redessin d'autres éléments de la vue.