A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
Arquitectura de gráficos
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Qué debe saber todo desarrollador sobre las plataformas, SurfaceHolder, EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView, SurfaceFlinger y Vulkan.
En esta página, se describen los elementos esenciales de la arquitectura de gráficos a nivel del sistema de Android y cómo los usan el framework de la app y el sistema multimedia. El enfoque se centra en cómo los búferes de datos gráficos se mueven a través del sistema.
Si alguna vez te preguntaste por qué SurfaceView y TextureView se comportan de la manera en que lo hacen,
o cómo interactúan las superficies y EGLSurface, estás en el lugar correcto.
Se supone que tienes cierta familiaridad con los dispositivos Android y el desarrollo de apps.
No necesitas conocimientos detallados del framework de la app y se mencionan muy pocas llamadas a la API, pero el material no se superpone con otra documentación pública. El objetivo es proporcionar detalles sobre los eventos significativos que participan en la renderización de un fotograma para la salida para ayudarte a tomar decisiones fundamentadas cuando diseñes una app. Para lograrlo, trabajamos de abajo hacia arriba y describimos cómo funcionan las clases de la IU en lugar de cómo se pueden usar.
En esta sección, se incluyen varias páginas que abarcan desde el material de fondo hasta los detalles de HAL y los casos de uso. Comienza con una explicación de los búferes de gráficos de Android, describe el mecanismo de composición y visualización y, luego, continúa con los mecanismos de nivel superior que le proporcionan datos al compositor. Te recomendamos que leas las páginas en el orden que se indica a continuación en lugar de saltar a un tema que te resulte interesante.
Componentes de bajo nivel
- BufferQueue y gralloc. BufferQueue conecta algo que genera búferes de datos gráficos (el productor) a algo que acepta los datos para su visualización o procesamiento adicional (el consumidor). Las asignaciones de búfer se realizan a través del asignador de memoria gralloc implementado a través de una interfaz HAL específica del proveedor.
- SurfaceFlinger, Hardware Composer y pantallas virtuales SurfaceFlinger acepta búferes de datos de varias fuentes, los compone y los envía a la pantalla. El HAL de Hardware Composer (HWC) determina la forma más eficiente de combinar búferes con el hardware disponible, y las pantallas virtuales hacen que el resultado compuesto esté disponible dentro del sistema (grabar la pantalla o enviarla a través de una red).
- Surface, canvas y SurfaceHolder. Una superficie produce una cola de búfer que a menudo consume SurfaceFlinger. Cuando se renderiza en una superficie, el resultado termina en un búfer que se envía al consumidor. Las APIs de Canvas proporcionan una implementación de software
(con compatibilidad con la aceleración de hardware) para dibujar directamente en una superficie
(alternativa de bajo nivel a OpenGL ES). Todo lo que tenga que ver con una vista implica un SurfaceHolder, cuyas APIs permiten obtener y configurar parámetros de superficie, como el tamaño y el formato.
- EGLSurface y OpenGL ES OpenGL ES (GLES) define una API de renderización de gráficos diseñada para combinarse con EGL, una biblioteca que puede crear ventanas y acceder a ellas a través del sistema operativo (para dibujar polígonos con textura, usa llamadas a GLES; para colocar la renderización en la pantalla, usa llamadas a EGL). En esta página, también se explica ANativeWindow, el equivalente en C/C++ de la clase Java Surface que se usa para crear una superficie de ventana EGL a partir de código nativo.
- Vulkan. Vulkan es una API multiplataforma de baja sobrecarga para gráficos 3D de alto rendimiento. Al igual que OpenGL ES, Vulkan proporciona herramientas para crear gráficos de alta calidad en tiempo real en las apps. Las ventajas de Vulkan incluyen reducciones en la sobrecarga de la CPU y compatibilidad con el lenguaje SPIR-V Binary Intermediate.
Componentes de alto nivel
- SurfaceView y GLSurfaceView. SurfaceView combina una superficie y una vista. SurfaceFlinger (y no la app) compone los componentes de vista de SurfaceView, lo que permite la renderización desde un subproceso o proceso independiente y el aislamiento de la renderización de la IU de la app.
GLSurfaceView proporciona clases de ayuda para administrar contextos de EGL, comunicación entre subprocesos y la interacción con el ciclo de vida de la actividad (pero no es necesario usar GLES).
- SurfaceTexture.
SurfaceTexture combina una superficie y una textura de GLES para crear un BufferQueue para el que tu app es el consumidor. Cuando un productor pone en cola un búfer nuevo, notifica a tu app, que a su vez libera el búfer que se tenía anteriormente, adquiere el búfer nuevo de la cola y realiza llamadas a EGL para que el búfer esté disponible para GLES como una textura externa. Android 7.0 agregó compatibilidad con la reproducción de video con texturas seguras, lo que permite el procesamiento posterior de GPU de contenido de video protegido.
- TextureView.
TextureView combina una vista con una SurfaceTexture. TextureView une una SurfaceTexture y se responsabiliza de responder a las devoluciones de llamada y adquirir búferes nuevos. Cuando se dibuja, TextureView usa el contenido del búfer más recientemente recibido como su fuente de datos y lo renderiza donde y como lo indique el estado de la vista. La composición de vistas siempre se realiza con GLES, lo que significa que las actualizaciones de contenido pueden hacer que otros elementos de vista también se vuelvan a dibujar.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[null,null,["Última actualización: 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."]]
