Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Gráficos

Icono de Android Graphics HAL

El marco de Android ofrece una variedad de API de representación de gráficos para 2D y 3D que interactúan con implementaciones de controladores de gráficos del fabricante, por lo que es importante tener una buena comprensión de cómo funcionan esas API en un nivel superior. Esta página presenta la capa de abstracción de hardware de gráficos (HAL) sobre la cual se construyen esos controladores.

Los desarrolladores de aplicaciones dibujan imágenes en la pantalla de tres maneras: con Canvas , OpenGL ES o Vulkan .

Componentes gráficos de Android

No importa qué desarrolladores de API de representación utilicen, todo se representa en una "superficie". La superficie representa el lado productor de una cola de búfer que SurfaceFlinger suele consumir. Cada ventana que se crea en la plataforma Android está respaldada por una superficie. SurfaceFlinger compone todas las superficies visibles representadas en la pantalla.

El siguiente diagrama muestra cómo los componentes clave funcionan juntos:

componentes de representación de imágenes

Figura 1. Cómo se representan las superficies

Los componentes principales se describen a continuación:

Productores de flujo de imagen

Un productor de flujo de imágenes puede ser cualquier cosa que produzca memorias intermedias gráficas para el consumo. Los ejemplos incluyen OpenGL ES, Canvas 2D y decodificadores de video de servidor de medios.

Consumidores de flujo de imagen

El consumidor más común de secuencias de imágenes es SurfaceFlinger, el servicio del sistema que consume las superficies actualmente visibles y las compone en la pantalla utilizando la información proporcionada por el Administrador de ventanas. SurfaceFlinger es el único servicio que puede modificar el contenido de la pantalla. SurfaceFlinger usa OpenGL y Hardware Composer para componer un grupo de superficies.

Otras aplicaciones OpenGL ES también pueden consumir transmisiones de imágenes, como la aplicación de cámara que consume una transmisión de imágenes de vista previa de la cámara. Las aplicaciones que no son GL también pueden ser consumidores, por ejemplo, la clase ImageReader.

Compositor de hardware

La abstracción de hardware para el subsistema de visualización. SurfaceFlinger puede delegar ciertos trabajos de composición al Hardware Composer para descargar el trabajo de OpenGL y la GPU. SurfaceFlinger actúa como otro cliente de OpenGL ES. Entonces, cuando SurfaceFlinger está componiendo activamente un búfer o dos en un tercero, por ejemplo, está usando OpenGL ES. Esto hace que la composición tenga una potencia más baja que hacer que la GPU realice todos los cálculos.

Hardware Composer HAL realiza la otra mitad del trabajo y es el punto central para toda la representación gráfica de Android. El Compositor de hardware debe admitir eventos, uno de los cuales es VSYNC (otro es hotplug para compatibilidad con plug-and-playHDMI).

Gralloc

El asignador de memoria de gráficos (Gralloc) es necesario para asignar la memoria solicitada por los productores de imágenes. Para más detalles, ver Gralloc HAL .

Flujo de datos

Consulte el siguiente diagrama para ver una descripción de la canalización de gráficos de Android:

flujo de datos gráficos

Figura 2. Flujo de datos gráficos a través de Android

Los objetos a la izquierda son renderizadores que producen memorias intermedias de gráficos, como la pantalla de inicio, la barra de estado y la interfaz de usuario del sistema. SurfaceFlinger es el compositor y Hardware Composer es el compositor.

BufferQueue

BufferQueues proporciona el pegamento entre los componentes gráficos de Android. Estas son un par de colas que median el ciclo constante de buffers del productor al consumidor. Una vez que los productores entregan sus memorias intermedias, SurfaceFlinger es responsable de componer todo en la pantalla.

Vea el siguiente diagrama para el proceso de comunicación BufferQueue.

Proceso de comunicación BufferQueue

Figura 3. Proceso de comunicación de BufferQueue

BufferQueue contiene la lógica que une a los productores de flujo de imagen y a los consumidores de flujo de imagen. Algunos ejemplos de productores de imágenes son las vistas previas de la cámara producidas por los juegos HAL u OpenGL ES de la cámara. Algunos ejemplos de consumidores de imágenes son SurfaceFlinger u otra aplicación que muestra una transmisión de OpenGL ES, como la aplicación de cámara que muestra el visor de la cámara.

BufferQueue es una estructura de datos que combina un grupo de búferes con una cola y utiliza Binder IPC para pasar búferes entre procesos. La interfaz del productor, o lo que pasa a alguien que quiere generar memorias intermedias gráficas, es IGraphicBufferProducer (parte de SurfaceTexture ). BufferQueue se usa a menudo para renderizar a una Surface y consumir con un consumidor GL, entre otras tareas. BufferQueue puede operar en tres modos diferentes:

Modo de tipo síncrono: BufferQueue funciona de manera predeterminada en un modo de tipo síncrono, en el que cada búfer que entra del productor se apaga en el consumidor. Ningún búfer se descarta en este modo. Y si el productor es demasiado rápido y crea buffers más rápido de lo que se están drenando, bloqueará y esperará los buffers gratuitos.

Modo sin bloqueo : BufferQueue también puede funcionar en un modo sin bloqueo donde genera un error en lugar de esperar un búfer en esos casos. Tampoco se descarta ningún búfer en este modo. Esto es útil para evitar posibles puntos muertos en el software de aplicaciones que pueden no comprender las complejas dependencias del marco gráfico.

Modo de descarte: finalmente, BufferQueue puede configurarse para descartar buffers antiguos en lugar de generar errores o esperar. Por ejemplo, si realiza el renderizado GL a una vista de textura y dibuja lo más rápido posible, los búferes se deben soltar.

Para realizar la mayor parte de este trabajo, SurfaceFlinger actúa como otro cliente de OpenGL ES. Entonces, cuando SurfaceFlinger está componiendo activamente un búfer o dos en un tercero, por ejemplo, está usando OpenGL ES.

El Hardware Composer HAL realiza la otra mitad del trabajo. Este HAL actúa como el punto central para toda la representación gráfica de Android.