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 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 formas: con Canvas , OpenGL ES o Vulkan .
Componentes gráficos de Android
No importa qué API de renderizado utilicen los desarrolladores, todo se renderiza 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. Todas las superficies visibles renderizadas se componen en la pantalla mediante SurfaceFlinger.
El siguiente diagrama muestra cómo funcionan juntos los componentes clave:
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 buffers gráficos para consumo. Los ejemplos incluyen OpenGL ES, Canvas 2D y decodificadores de video de servidor de medios.
Consumidores de flujo de imágenes
El consumidor más común de flujos 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 utiliza OpenGL y Hardware Composer para componer un grupo de superficies.
Otras aplicaciones 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 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 cierto trabajo de composición al Hardware Composer para descargar el trabajo de OpenGL y la GPU. SurfaceFlinger actúa como un cliente más de OpenGL ES. Entonces, cuando SurfaceFlinger está componiendo activamente uno o dos buffers en un tercero, por ejemplo, está usando OpenGL ES. Esto hace que la composición consuma menos energía 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 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 obtener una descripción de la canalización de gráficos de Android:
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.
Cola de búfer
BufferQueues proporciona el pegamento entre los componentes gráficos de Android. Se trata de un par de colas que median en el ciclo constante de buffers desde el productor hasta el consumidor. Una vez que los productores entregan sus buffers, SurfaceFlinger es responsable de componer todo en la pantalla.
Consulte el siguiente diagrama para conocer el proceso de comunicación de BufferQueue.
Figura 3. Proceso de comunicación BufferQueue
BufferQueue contiene la lógica que une a los productores y consumidores de flujos de imágenes. Algunos ejemplos de productores de imágenes son las vistas previas de cámara producidas por la cámara HAL o los juegos 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úfer con una cola y utiliza Binder IPC para pasar búfer entre procesos. La interfaz del productor, o lo que le pasa a alguien que quiere generar buffers gráficos, es IGraphicBufferProducer (parte de SurfaceTexture ). BufferQueue se usa a menudo para renderizar en una superficie y consumir con un consumidor GL, entre otras tareas.
BufferQueue puede funcionar en tres modos diferentes:
Modo síncrono : BufferQueue funciona de forma predeterminada en un modo síncrono, en el que cada búfer que ingresa desde el productor sale hacia el consumidor. En este modo nunca se descarta ningún buffer. Y si el productor es demasiado rápido y crea buffers más rápido de lo que se agotan, bloqueará y esperará a que se liberen buffers.
Modo sin bloqueo : BufferQueue también puede funcionar en modo sin bloqueo donde genera un error en lugar de esperar un búfer en esos casos. En este modo tampoco se descarta ningún buffer. Esto es útil para evitar posibles bloqueos en el software de la aplicación que puede no comprender las complejas dependencias del marco de gráficos.
Modo de descarte : finalmente, BufferQueue se puede configurar para descartar búferes antiguos en lugar de generar errores o esperar. Por ejemplo, si se realiza el renderizado GL en una vista de textura y se dibuja lo más rápido posible, se deben eliminar los buffers.
Para realizar la mayor parte de este trabajo, SurfaceFlinger actúa como un cliente OpenGL ES más. Entonces, cuando SurfaceFlinger está componiendo activamente uno o dos buffers 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 de gráficos de Android.