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) en la que se basan esos controladores. Antes de continuar con esta sección, familiarícese con los siguientes términos:
Canvas (elemento API)Surface . Canvas tiene métodos para el dibujo por computadora estándar de mapas de bits, líneas, círculos, rectángulos, texto, etc., y está vinculado a un mapa de bits o una superficie. Un lienzo es la forma más sencilla y sencilla de dibujar objetos 2D en la pantalla. La clase base es Canvas .android.graphics.drawable . Para obtener más información sobre elementos dibujables y otros recursos, consulte Recursos .android.opengl y javax.microedition.khronos.opengles exponen la funcionalidad OpenGL ES.Surface (elemento API)Surface . Utilice la clase SurfaceView en lugar de la clase Surface directamente.SurfaceView (elemento API)View que envuelve un objeto Surface para dibujar y expone métodos para especificar su tamaño y formato dinámicamente. Una vista de superficie proporciona una forma de dibujar independientemente del subproceso de la interfaz de usuario para operaciones que consumen muchos recursos, como juegos o vistas previas de la cámara, pero como resultado utiliza memoria adicional. Una vista de superficie admite gráficos de lienzo y OpenGL ES. La clase base para un objeto SurfaceView es SurfaceView .R.style y precedidos de Theme_ .View (elemento API)View es la clase base para la mayoría de los componentes de diseño de una actividad o pantalla de diálogo, como cuadros de texto y ventanas. Un objeto View recibe llamadas de su objeto principal (consulte ViewGroup ) para dibujarse a sí mismo e informa a su objeto principal sobre su tamaño y ubicación preferidos, que podrían no ser respetados por el padre. Para obtener más información, consulte View .ViewGroup (elemento API)widget , pero amplían la clase ViewGroup .android.widget .Window (elemento API)Window que especifica los elementos de una ventana genérica, como la apariencia, el texto de la barra de título y la ubicación y el contenido de los menús. Los diálogos y actividades utilizan una implementación de la clase Window para representar un objeto Window . No es necesario implementar la clase Window ni usar Windows en su aplicación.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.