Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Gráficos

Icono de HAL de gráficos de Android

El marco de Android ofrece una variedad de API de representación de gráficos para 2D y 3D que interactúan con las implementaciones del fabricante de los controladores de gráficos, por lo que es importante comprender bien 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 que se construyen esos controladores.

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

Componentes gráficos de Android

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

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

componentes de representación de imágenes

Figura 1. Cómo se renderizan las superficies

Los componentes principales se describen a continuación:

Productores de flujo de imágenes

Un productor de flujo de imágenes puede ser cualquier cosa que produzca búferes gráficos para consumo. Los ejemplos incluyen decodificadores de video OpenGL ES, Canvas 2D y mediaserver.

Consumidores de flujo de imágenes

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 combina 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 de OpenGL ES también pueden consumir secuencias de imágenes, como la aplicación de la cámara que consume una secuencia de imágenes de vista previa de la cámara. Las aplicaciones no 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 cierto trabajo de composición al Compositor de hardware para descargar el trabajo de OpenGL y la GPU. SurfaceFlinger actúa como un cliente de OpenGL ES más. 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 sea más baja que si la GPU realiza todos los cálculos.

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

Gralloc

El asignador de memoria de gráficos (Gralloc) es necesario para asignar la memoria solicitada por los productores de imágenes. Para obtener más información, consulte 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 de la izquierda son renderizadores que producen búferes 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. Se trata de un par de colas que median el ciclo constante de búferes desde el productor hasta el consumidor. Una vez que los productores entregan sus búferes, SurfaceFlinger es responsable de componer todo en la pantalla.

Consulte el diagrama siguiente para conocer el proceso de comunicación de 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 secuencias de imágenes y los consumidores de secuencias de imágenes. Algunos ejemplos de productores de imágenes son las vistas previas de la cámara producidas por los juegos de cámara HAL o OpenGL ES. Algunos ejemplos de consumidores de imágenes son SurfaceFlinger u otra aplicación que muestra una transmisión OpenGL ES, como la aplicación de la 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 le pasa a alguien que quiere generar búferes gráficos, es IGraphicBufferProducer (parte de SurfaceTexture ). BufferQueue se usa a menudo para renderizar en una Surface y consumir con un GL Consumer, entre otras tareas.

BufferQueue puede funcionar en tres modos diferentes:

Modo de tipo síncrono: BufferQueue de forma predeterminada funciona en un modo de tipo síncrono, en el que cada búfer que llega del productor sale al consumidor. En este modo, nunca se descarta ningún búfer. Y si el productor es demasiado rápido y crea búferes más rápido de lo que se agotan, bloqueará y esperará a que haya búferes libres.

Modo sin bloqueo : BufferQueue también puede operar 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 aplicación que pueden no comprender las complejas dependencias del marco gráfico.

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

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

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