A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release
anziché aosp-main
per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
Architettura grafica
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Cosa deve sapere ogni sviluppatore su superfici, SurfaceHolder,
EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView,
SurfaceFlinger e Vulkan.
Questa pagina descrive gli elementi essenziali dell'architettura grafica di livello di sistema di Android e come vengono utilizzati dal framework dell'app e dal sistema multimediale. L'attenzione è incentrata sul modo in cui i buffer di dati grafici si spostano all'interno del sistema.
Se ti sei mai chiesto perché SurfaceView e TextureView si comportano in un determinato modo o come interagiscono le superfici e EGLSurface, sei nel posto giusto.
Si presume una certa familiarità con i dispositivi Android e lo sviluppo di app.
Non è necessaria una conoscenza dettagliata del framework dell'app e vengono menzionate pochissime chiamate API, ma il materiale non si sovrappone ad altra documentazione pubblica. L'obiettivo è fornire dettagli sugli eventi significativi coinvolti nel rendering di un frame per l'output per aiutarti a fare scelte consapevoli quando progetti un'app. Per raggiungere questo obiettivo, lavoriamo dal basso verso l'alto, descrivendo il funzionamento delle classi UI anziché il modo in cui possono essere utilizzate.
Questa sezione include diverse pagine che trattano di tutto, dai materiali di sfondo ai dettagli dell'HAL ai casi d'uso. Inizia con una spiegazione dei buffer grafici di Android, descrive il meccanismo di composizione e visualizzazione, quindi passa ai meccanismi di livello superiore che forniscono i dati al compositore. Ti consigliamo di leggere le pagine nell'ordine elencato di seguito anziché passare a un argomento che ti sembra interessante.
Componenti di basso livello
- BufferQueue e
gralloc. BufferQueue connette un elemento che genera buffer di dati grafici (il producer) a un elemento che accetta i dati per la visualizzazione o un ulteriore elaborazione (il consumer). Le allocazioni dei buffer vengono eseguite tramite l'allocatore di memoria gralloc implementato tramite un'interfaccia HAL specifica del fornitore.
- SurfaceFlinger,
Hardware Composer e display virtuali. SurfaceFlinger accetta buffer di
dati da più origini, li compone e li invia al display. L'HAL (Hardware Composer) determina il modo più efficiente per comporre i buffer con l'hardware disponibile e i display virtuali rendono disponibile l'output composito all'interno del sistema (registrando lo schermo o inviandolo su una rete).
- Surface, canvas e
SurfaceHolder. Una superficie produce una coda di buffer che viene spesso utilizzata da
SurfaceFlinger. Quando viene eseguito il rendering su una superficie, il risultato viene inserito in un buffer
che viene inviato al consumatore. Le API Canvas forniscono un'implementazione software (con supporto dell'accelerazione hardware) per disegnare direttamente su una superficie (alternativa a basso livello ad OpenGL ES). Tutto ciò che riguarda una visualizzazione coinvolge un SurfaceHolder, le cui API consentono di ottenere e impostare i parametri della superficie, come dimensioni e formato.
- EGLSurface e
OpenGL ES. OpenGL ES (GLES)
definisce un'API di rendering grafico progettata per essere
combinata con EGL, una libreria che
può creare e accedere alle finestre tramite
il sistema operativo (per disegnare poligoni con texture, utilizza le chiamate GLES; per mettere
il rendering sullo schermo, utilizza le chiamate EGL). Questa pagina illustra anche ANativeWindow,
l'equivalente in C/C++ della classe Java Surface utilizzata per creare una superficie della finestra EGL
da codice nativo.
- Vulkan. Vulkan è un'API multipiattaforma a basso overhead per la grafica 3D ad alte prestazioni. Come OpenGL ES, Vulkan fornisce strumenti per creare grafica in tempo reale di alta qualità nelle app. I vantaggi di Vulkan includono la riduzione del sovraccarico della CPU e il supporto per il linguaggio SPIR-V Binary Intermediate.
Componenti di alto livello
- SurfaceView e GLSurfaceView. SurfaceView combina una superficie e una visualizzazione. I componenti della vista di SurfaceView vengono composti da SurfaceFlinger (e non dall'app), consentendo il rendering da un thread/processo separato e l'isolamento dal rendering dell'interfaccia utente dell'app.
GLSurfaceView fornisce classi di supporto per gestire i contesti EGL, la comunicazione tra thread e l'interazione con il ciclo di vita dell'attività (ma non è necessario utilizzare GLES).
- SurfaceTexture.
SurfaceTexture combina una superficie e una texture GLES per creare una BufferQueue di cui la tua app è il consumatore. Quando un produttore mette in coda un nuovo buffer, ne invia una notifica alla tua app, che a sua volta rilascia il buffer precedentemente trattenuto, acquisisce il nuovo buffer dalla coda ed esegue chiamate EGL per renderlo disponibile a GLES come texture esterna. Android 7.0 ha aggiunto il supporto per la riproduzione di video con texture sicure, consentendo la post-elaborazione dei contenuti video protetti tramite GPU.
- TextureView.
TextureView combina una vista con una SurfaceTexture. TextureView avvolge una
SurfaceTexture e si assume la responsabilità di rispondere ai callback e
acquisire nuovi buffer. Durante il disegno, TextureView utilizza i contenuti del buffer ricevuto più di recente come origine dati, eseguendo il rendering dove e come indicato dallo stato della visualizzazione. La composizione della visualizzazione viene sempre eseguita con GLES,
il che significa che gli aggiornamenti dei contenuti possono causare anche il ricalcolo di altri elementi della visualizzazione.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]