El framework de Android ofrece una variedad de APIs de renderizació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 comprender cómo funcionan esas APIs en un nivel superior. En esta página, se presenta la capa de abstracción de hardware (HAL) de gráficos en la que se compilan esos controladores. Antes de continuar con esta sección, familiarízate con los siguientes términos:
Canvas (elemento de la API)Surface. Canvas tiene métodos para el dibujo estándar por computadora 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 de dibujar objetos en 2D en la pantalla. La clase base es Canvas.
android.graphics.drawable.
Para obtener más información sobre los elementos de diseño y otros recursos, consulta Recursos.
android.opengl y javax.microedition.khronos.opengles exponen la funcionalidad de OpenGL ES.Surface (elemento de la API)Surface. Usa la clase SurfaceView en lugar de la clase Surface directamente.
SurfaceView (elemento de la API)View que une un objeto Surface para dibujar y expone métodos que permiten especificar su tamaño y su formato de forma dinámica. SurfaceView proporciona una forma de dibujar independientemente del subproceso de la IU para operaciones que requieren un uso intensivo de los recursos (como juegos o vistas previas de cámara), pero, como resultado, utiliza memoria adicional. Una vista de superficie admite gráficos de lienzo y de OpenGL ES. La clase base para un objeto SurfaceView es SurfaceView.
R.style y que comienzan con Theme_.View (elemento de 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 los cuadros de texto y las ventanas. Un objeto View recibe llamadas de su objeto superior (consulta ViewGroup) para dibujarse y le informa a su objeto superior sobre su tamaño y ubicación preferidos, que el objeto superior puede no respetar. Para obtener más información, consulta
View.
ViewGroup (elemento de la API)widget, pero se extienden a la clase ViewGroup.
android.widget. Window (elemento de la API)Window que especifica los elementos de una ventana genérica, como el estilo, el texto de la barra de título y la ubicación y el contenido de los menús. Los diálogos y las actividades usan una implementación de la clase Window para renderizar un objeto Window. No necesitas implementar la clase Window ni usar ventanas en tu app.Los desarrolladores de apps dibujan imágenes en la pantalla de tres maneras: con Canvas, OpenGL ES o Vulkan.
Componentes gráficos de Android
No importa qué API de renderización usen los desarrolladores, todo se renderiza en una superficie. La superficie representa el lado del productor de una fila de búferes que SurfaceFlinger suele consumir. Cada ventana que se crea en la plataforma de Android está respaldada por una superficie. SurfaceFlinger combina todas las superficies visibles renderizadas en la pantalla.
En el siguiente diagrama, se muestra cómo funcionan juntos los componentes clave:
Figura 1: Cómo se renderizan las plataformas
A continuación, se describen los componentes principales:
Productores de transmisiones de imágenes
Un productor de flujo de imágenes puede ser cualquier elemento que produzca búferes gráficos para el consumo. Entre los ejemplos, se incluyen OpenGL ES, Canvas 2D y decodificadores de video de MediaServer.
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 visibles actualmente y las combina en la pantalla con la información que proporciona el Administrador de ventanas. SurfaceFlinger es el único servicio que puede modificar el contenido de la pantalla. SurfaceFlinger usa OpenGL y el compositor de hardware para componer un grupo de superficies.
Otras apps de OpenGL ES también pueden consumir transmisiones de imágenes, como la app de cámara que consume una transmisión de imágenes de vista previa de la cámara. Las apps que no son de GL también pueden ser consumidores, por ejemplo, la clase ImageReader.
Hardware Composer
Es 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 trabajo de OpenGL y la GPU. SurfaceFlinger actúa como otro cliente de OpenGL ES. Por lo tanto, cuando SurfaceFlinger compone activamente uno o dos búferes en un tercero, por ejemplo, usa OpenGL ES. Esto hace que la composición sea menos potente que si la GPU realizara todo el procesamiento.
El HAL de Hardware Composer realiza la otra mitad del trabajo y es el punto central de toda la renderización de gráficos de Android. El compilador de hardware debe admitir eventos, uno de los cuales es VSYNC (otro es hotplug para la compatibilidad con HDMI plug-and-play).
Gralloc
El asignador de memoria gráfica (Gralloc) es necesario para asignar la memoria que solicitan los productores de imágenes. Para obtener más información, consulta HAL de Gralloc.
Flujo de datos
Consulta 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 renderizadores que producen búferes gráficos, como la pantalla principal, la barra de estado y la IU 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 del productor al consumidor. Una vez que los productores entregan sus búferes, SurfaceFlinger es responsable de combinar todo en la pantalla.
Consulta el siguiente diagrama para ver el proceso de comunicación de BufferQueue.
Figura 3: Proceso de comunicación de 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 la cámara que producen el HAL de la cámara o los juegos de OpenGL ES. Algunos ejemplos de consumidores de imágenes son SurfaceFlinger o cualquier otra app que muestre una transmisión de OpenGL ES, como la app 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 usa el IPC de Binder para pasar búferes entre procesos. La interfaz de productor, o lo que le pasas 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 funcionar en tres modos diferentes:
Modo síncrono: BufferQueue opera de forma predeterminada en un modo síncrono, en el que cada búfer que ingresa 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, se bloqueará y esperará a que haya búferes libres.
Modo no bloqueador: BufferQueue también puede funcionar en un modo no bloqueador, en el que 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 la aplicación que podrían no comprender las dependencias complejas del framework de gráficos.
Modo de descarte: Por último, BufferQueue se puede configurar para descartar búferes antiguos en lugar de generar errores o esperar. Por ejemplo, si se realiza la renderización de 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. Por lo tanto, cuando SurfaceFlinger compone activamente uno o dos búferes en un tercero, por ejemplo, usa OpenGL ES.
La HAL de Hardware Composer realiza la otra mitad del trabajo. Este HAL actúa como el punto central de toda la renderización de gráficos de Android.