A estrutura do Android oferece uma variedade de APIs de renderização de gráficos para 2D e 3D que interagem com implementações de drivers gráficos de fabricantes, portanto, é importante ter um bom entendimento de como essas APIs funcionam em um nível superior. Esta página apresenta a camada de abstração de hardware gráfico (HAL) sobre a qual esses drivers são construídos.
Os desenvolvedores de aplicativos desenham imagens na tela de três maneiras: com Canvas , OpenGL ES ou Vulkan .
Componentes gráficos do Android
Não importa o que os desenvolvedores de API de renderização usam, tudo é renderizado em uma superfície . A superfície representa o lado do produtor de uma fila de buffer que é frequentemente consumida pelo SurfaceFlinger. Cada janela criada na plataforma Android é apoiada por uma superfície. Todas as superfícies visíveis renderizadas são compostas na tela pelo SurfaceFlinger.
O diagrama a seguir mostra como os principais componentes funcionam juntos:
Figura 1. Como as superfícies são renderizadas
Os principais componentes são descritos abaixo:
Produtores de fluxo de imagem
Um produtor de fluxo de imagem pode ser qualquer coisa que produza buffers gráficos para consumo. Exemplos incluem OpenGL ES, Canvas 2D e decodificadores de vídeo mediaserver.
Consumidores de fluxo de imagem
O consumidor mais comum de fluxos de imagem é o SurfaceFlinger, o serviço do sistema que consome as superfícies visíveis no momento e as compõe na tela usando informações fornecidas pelo Window Manager. SurfaceFlinger é o único serviço que pode modificar o conteúdo da exibição. SurfaceFlinger usa OpenGL e o Hardware Composer para compor um grupo de superfícies.
Outros aplicativos OpenGL ES também podem consumir fluxos de imagem, como o aplicativo de câmera que consome um fluxo de imagem de visualização da câmera. Aplicativos não GL também podem ser consumidores, por exemplo, a classe ImageReader.
Compositor de Hardware
A abstração de hardware para o subsistema de exibição. O SurfaceFlinger pode delegar determinado trabalho de composição ao Hardware Composer para descarregar o trabalho do OpenGL e da GPU. O SurfaceFlinger atua como apenas outro cliente OpenGL ES. Então, quando o SurfaceFlinger está compondo ativamente um buffer ou dois em um terceiro, por exemplo, ele está usando o OpenGL ES. Isso torna a composição de energia mais baixa do que a GPU realizar toda a computação.
O Hardware Composer HAL conduz a outra metade do trabalho e é o ponto central para toda a renderização gráfica do Android. O Hardware Composer deve suportar eventos, um dos quais é VSYNC (outro é hotplug para suporte plug-and-play HDMI).
Gralloc
O alocador de memória gráfica (Gralloc) é necessário para alocar a memória solicitada pelos produtores de imagens. Para obter detalhes, consulte Gralloc HAL .
Fluxo de dados
Consulte o diagrama a seguir para obter uma representação do pipeline de gráficos do Android:
Figura 2. Fluxo de dados gráficos pelo Android
Os objetos à esquerda são renderizadores que produzem buffers gráficos, como a tela inicial, a barra de status e a interface do usuário do sistema. SurfaceFlinger é o compositor e o Hardware Composer é o compositor.
BufferQueue
BufferQueues fornecem a cola entre os componentes gráficos do Android. Estes são um par de filas que medeiam o ciclo constante de buffers do produtor ao consumidor. Uma vez que os produtores entregam seus buffers, o SurfaceFlinger é responsável por compor tudo na tela.
Consulte o diagrama a seguir para o processo de comunicação do BufferQueue.
Figura 3. Processo de comunicação do BufferQueue
BufferQueue contém a lógica que une os produtores de fluxo de imagem e os consumidores de fluxo de imagem. Alguns exemplos de produtores de imagens são as prévias de câmeras produzidas pelos jogos de câmera HAL ou OpenGL ES. Alguns exemplos de consumidores de imagem são SurfaceFlinger ou outro aplicativo que exibe um fluxo OpenGL ES, como o aplicativo de câmera exibindo o visor da câmera.
BufferQueue é uma estrutura de dados que combina um buffer pool com uma fila e usa o Binder IPC para passar buffers entre processos. A interface do produtor, ou o que você passa para alguém que deseja gerar buffers gráficos, é IGraphicBufferProducer (parte de SurfaceTexture ). BufferQueue é frequentemente usado para renderizar em uma superfície e consumir com um consumidor GL, entre outras tarefas.
BufferQueue pode operar em três modos diferentes:
Modo síncrono - BufferQueue por padrão opera em um modo síncrono, no qual todo buffer que vem do produtor sai no consumidor. Nenhum buffer é descartado neste modo. E se o produtor for muito rápido e criar buffers mais rápido do que eles estão sendo drenados, ele bloqueará e aguardará buffers livres.
Modo sem bloqueio - BufferQueue também pode operar em um modo sem bloqueio, onde gera um erro em vez de aguardar um buffer nesses casos. Nenhum buffer é descartado neste modo também. Isso é útil para evitar possíveis impasses no software aplicativo que pode não entender as dependências complexas da estrutura gráfica.
Modo de descarte - Finalmente, o BufferQueue pode ser configurado para descartar buffers antigos em vez de gerar erros ou esperar. Por exemplo, se estiver realizando a renderização GL para uma visualização de textura e desenho o mais rápido possível, os buffers devem ser descartados.
Para realizar a maior parte desse trabalho, o SurfaceFlinger atua como apenas mais um cliente OpenGL ES. Então, quando o SurfaceFlinger está compondo ativamente um buffer ou dois em um terceiro, por exemplo, ele está usando o OpenGL ES.
O Hardware Composer HAL conduz a outra metade do trabalho. Este HAL atua como o ponto central para toda a renderização gráfica do Android.