À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
Architecture graphique
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
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.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/27 (UTC)."],[],[],null,["# Graphics architecture\n\n*What every developer should know about surfaces, SurfaceHolder,\nEGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView,\nSurfaceFlinger, and Vulkan.*\n\nThis page describes essential elements of the Android system-level graphics\narchitecture and how they are used by the app framework and multimedia\nsystem. The focus is on how buffers of graphical data move through the system.\nIf you've ever wondered why SurfaceView and TextureView behave the way they do,\nor how surfaces and EGLSurface interact, you're in the correct place.\n\nSome familiarity with Android devices and app development is assumed.\nYou don't need detailed knowledge of the app framework and very few API calls\nare mentioned, but the material doesn't overlap with other public\ndocumentation. The goal is to provide details on the significant events\ninvolved in rendering a frame for output to help you make informed choices\nwhen designing an app. To achieve this, we work from the bottom up,\ndescribing how the UI classes work rather than how they can be used.\n\nThis section includes several pages covering everything from background\nmaterial to HAL details to use cases. It starts with an explanation of Android\ngraphics buffers, describes the composition and display mechanism, then proceeds\nto the higher-level mechanisms that supply the compositor with data. We\nrecommend reading pages in the order listed below rather than skipping to a\ntopic that sounds interesting.\n\nLow-level components\n--------------------\n\n- [BufferQueue and\n gralloc](/docs/core/graphics/arch-bq-gralloc). BufferQueue connects something that generates buffers of graphical data (the *producer* ) to something that accepts the data for display or further processing (the *consumer* ). Buffer allocations are performed through the *gralloc* memory allocator implemented through a vendor-specific HAL interface.\n- [SurfaceFlinger,\n Hardware Composer, and virtual displays](/docs/core/graphics/arch-sf-hwc). SurfaceFlinger accepts buffers of data from multiple sources, composites them, and sends them to the display. The Hardware Composer HAL (HWC) determines the most efficient way to composite buffers with the available hardware, and virtual displays make composited output available within the system (recording the screen or sending the screen over a network).\n- [Surface, canvas, and\n SurfaceHolder](/docs/core/graphics/arch-sh). A surface produces a buffer queue that is often consumed by SurfaceFlinger. When rendering onto a surface, the result ends up in a buffer that gets shipped to the consumer. Canvas APIs provide a software implementation (with hardware-acceleration support) for drawing directly on a surface (low-level alternative to OpenGL ES). Anything having to do with a view involves a SurfaceHolder, whose APIs enable getting and setting surface parameters such as size and format.\n- [EGLSurface and\n OpenGL ES](/docs/core/graphics/arch-egl-opengl). [OpenGL ES (GLES)](https://www.khronos.org/opengles/) defines a graphics-rendering API designed to be combined with [EGL](https://www.khronos.org/egl), a library that can create and access windows through the operating system (to draw textured polygons, use GLES calls; to put rendering on the screen, use EGL calls). This page also covers ANativeWindow, the C/C++ equivalent of the Java Surface class used to create an EGL window surface from native code.\n- [Vulkan](/docs/core/graphics/arch-vulkan). Vulkan is a low-overhead, cross-platform API for high-performance 3D graphics. Like OpenGL ES, Vulkan provides tools for creating high-quality, real-time graphics in apps. Vulkan advantages include reductions in CPU overhead and support for the [SPIR-V Binary Intermediate](https://www.khronos.org/spir) language.\n\nHigh-level components\n---------------------\n\n- [SurfaceView and\n GLSurfaceView](/docs/core/graphics/arch-sv-glsv). SurfaceView combines a surface and a view. SurfaceView's view components are composited by SurfaceFlinger (and not the app), enabling rendering from a separate thread/process and isolation from app UI rendering. GLSurfaceView provides helper classes to manage EGL contexts, interthread communication, and interaction with the activity lifecycle (but isn't required to use GLES).\n- [SurfaceTexture](/docs/core/graphics/arch-st). SurfaceTexture combines a surface and GLES texture to create a BufferQueue for which your app is the consumer. When a producer queues a new buffer, it notifies your app, which in turn releases the previously-held buffer, acquires the new buffer from the queue, and makes EGL calls to make the buffer available to GLES as an external texture. Android 7.0 added support for secure texture video playback enabling GPU post-processing of protected video content.\n- [TextureView](/docs/core/graphics/arch-tv). TextureView combines a view with a SurfaceTexture. TextureView wraps a SurfaceTexture and takes responsibility for responding to callbacks and acquiring new buffers. When drawing, TextureView uses the contents of the most recently received buffer as its data source, rendering wherever and however the view state indicates it should. View composition is always performed with GLES, meaning updates to contents may cause other view elements to redraw as well."]]
