El marco de trabajo 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 maneras: con Canvas , OpenGL ES o Vulkan .
Componentes gráficos de Android
No importa qué renderización API usen 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. Todas las superficies visibles renderizadas están compuestas en la pantalla por SurfaceFlinger.
El siguiente diagrama muestra cómo los componentes clave funcionan juntos:
Figura 1. Cómo se renderizan las superficies
Los componentes principales se describen a continuación:
Productores de transmisión de imágenes
Un productor de secuencias de imágenes puede ser cualquier cosa que produzca búferes gráficos para el consumo. Los ejemplos incluyen OpenGL ES, Canvas 2D y decodificadores de video mediaserver.
Consumidores de secuencias 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 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 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 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 compositor de hardware para descargar el trabajo de OpenGL y la GPU. SurfaceFlinger actúa como otro cliente de OpenGL ES. Entonces, cuando SurfaceFlinger está componiendo activamente uno o dos búfer en un tercero, por ejemplo, está usando OpenGL ES. Esto hace que la composición sea de menor consumo que si la GPU realizara 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. El compositor de hardware debe admitir eventos, uno de los cuales es VSYNC (otro es hotplug para soporte 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, consulte Gralloc HAL .
Flujo de datos
Consulte el siguiente diagrama para ver una representació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 procesadores 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 vínculo entre los componentes gráficos de Android. Estos son 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 siguiente diagrama para el proceso de comunicación de BufferQueue.
Figura 3. Proceso de comunicación de BufferQueue
BufferQueue contiene la lógica que vincula a los productores de secuencias de imágenes con los consumidores de secuencias de imágenes. Algunos ejemplos de productores de imágenes son las vistas previas de 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 un flujo de 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 pasa a alguien que quiere generar búferes 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 operar en tres modos diferentes:
Modo síncrono: BufferQueue funciona de forma predeterminada en un modo 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 vacían, se 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 interbloqueos en el software de aplicación que puede no comprender las dependencias complejas del marco de gráficos.
Modo de descarte: finalmente, BufferQueue puede configurarse para descartar búfer 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 descartar los búferes.
Para realizar la mayor parte de este trabajo, SurfaceFlinger actúa como otro cliente de OpenGL ES. Entonces, cuando SurfaceFlinger está componiendo activamente uno o dos búfer en un tercero, por ejemplo, está usando OpenGL ES.
El compositor de hardware 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.