A estrutura do Android oferece uma variedade de APIs de renderização gráfica para 2D e 3D que interagem com implementações de drivers gráficos do fabricante, por isso é 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 criados.
Os desenvolvedores de aplicativos desenham imagens na tela de três maneiras: com Canvas , OpenGL ES ou Vulkan .
Componentes gráficos Android
Não importa qual API de renderização os desenvolvedores usam, tudo é renderizado em uma superfície . A superfície representa o lado 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 imagens
Um produtor de fluxo de imagens pode ser qualquer coisa que produza buffers gráficos para consumo. Os exemplos incluem OpenGL ES, Canvas 2D e decodificadores de vídeo mediaserver.
Consumidores de fluxo de imagem
O consumidor mais comum de fluxos de imagens é o SurfaceFlinger, o serviço do sistema que consome as superfícies atualmente visíveis 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 imagens, 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. SurfaceFlinger pode delegar determinado trabalho de composição ao Hardware Composer para descarregar o trabalho do OpenGL e da GPU. SurfaceFlinger atua apenas como mais um cliente OpenGL ES. Portanto, quando o SurfaceFlinger está compondo ativamente um ou dois buffers em um terceiro, por exemplo, ele está usando OpenGL ES. Isso torna a composição menos energética do que fazer com que a GPU conduza todos os cálculos.
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 HDMI plug-and-play).
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 gráfico do Android:
Figura 2. Fluxo de dados gráficos através do Android
Os objetos à esquerda são renderizadores que produzem buffers gráficos, como tela inicial, barra de status e interface do sistema. SurfaceFlinger é o compositor e Hardware Composer é o compositor.
BufferQueue
BufferQueues fornece a ligação entre os componentes gráficos do Android. Trata-se de um par de filas que medeiam o ciclo constante de buffers do produtor ao consumidor. Depois que os produtores entregam seus buffers, o SurfaceFlinger é responsável por compor tudo no display.
Consulte o diagrama a seguir para o processo de comunicação BufferQueue.
Figura 3. Processo de comunicação BufferQueue
BufferQueue contém a lógica que une produtores e consumidores de fluxo de imagens. Alguns exemplos de produtores de imagens são as visualizações de câmera 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 que exibe o visor da câmera.
BufferQueue é uma estrutura de dados que combina um buffer pool com uma fila e usa 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 um Surface 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 modo síncrono, no qual todo buffer que chega 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 modo sem bloqueio, onde gera um erro em vez de esperar por 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 compreender as dependências complexas da estrutura gráfica.
Modo de descarte - Finalmente, BufferQueue pode ser configurado para descartar buffers antigos em vez de gerar erros ou esperar. Por exemplo, se estiver conduzindo a renderização GL para uma visualização de textura e desenhando o mais rápido possível, os buffers deverão ser eliminados.
Para conduzir a maior parte deste trabalho, o SurfaceFlinger atua como apenas mais um cliente OpenGL ES. Portanto, quando o SurfaceFlinger está compondo ativamente um ou dois buffers em um terceiro, por exemplo, ele está usando OpenGL ES.
O Hardware Composer HAL conduz a outra metade do trabalho. Este HAL atua como ponto central para toda a renderização gráfica do Android.