Google is committed to advancing racial equity for Black communities. See how.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Gráficos

Ícone Android Graphics HAL

A estrutura do Android oferece uma variedade de APIs de renderização de gráficos para 2D e 3D que interagem com as implementações dos fabricantes de drivers gráficos, 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) na 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 qual renderização os desenvolvedores de API usam, tudo é renderizado em uma superfície . A superfície representa o lado do produtor de uma fila de buffer que geralmente é 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 exibição por SurfaceFlinger.

O diagrama a seguir mostra como os componentes principais funcionam juntos:

componentes de renderização de imagem

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. 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 imagem é 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 Gerenciador de Janelas. SurfaceFlinger é o único serviço que pode modificar o conteúdo da tela. SurfaceFlinger usa OpenGL e o Hardware Composer para compor um grupo de superfícies.

Outros aplicativos OpenGL ES podem consumir fluxos de imagem também, como o aplicativo de câmera consumindo um fluxo de imagem de visualização da câmera. Os aplicativos não GL também podem ser consumidores, por exemplo, a classe ImageReader.

Hardware Composer

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. 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. Isso faz com que a composição tenha menos energia do que ter a GPU conduzindo todos os cálculos.

O Hardware Composer HAL conduz a outra metade do trabalho e é o ponto central para toda a renderização de gráficos do Android. O Hardware Composer deve oferecer suporte a eventos, um dos quais é VSYNC (outro é hotplug para suporte a plug-and-playHDMI).

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 uma representação do pipeline de gráficos do Android:

fluxo de dados gráficos

Figura 2. Fluxo de dados gráficos por meio do Android

Os objetos à esquerda são renderizadores que produzem buffers gráficos, como tela inicial, barra de status e IU do sistema. SurfaceFlinger é o compositor e Hardware Composer é o compositor.

BufferQueue

BufferQueues fornece a cola entre os componentes gráficos do Android. 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, SurfaceFlinger é responsável por compor tudo no display.

Consulte o diagrama a seguir para o processo de comunicação BufferQueue.

Processo de comunicação BufferQueue

Figura 3. Processo de comunicação BufferQueue

BufferQueue contém a lógica que une produtores de fluxo de imagem e consumidores de fluxo de imagem. Alguns exemplos de produtores de imagens são as visualizações 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 pool de buffer 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 uma superfície e consumir com um consumidor GL, entre outras tarefas.

BufferQueue pode operar em três modos diferentes:

Modo semelhante ao síncrono - BufferQueue por padrão opera em um modo semelhante ao síncrono, no qual cada buffer que vem do produtor sai para o 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á por buffers livres.

Modo sem bloqueio - BufferQueue também pode operar em um modo sem bloqueio, onde ele gera um erro em vez de esperar por um buffer nesses casos. Nenhum buffer é descartado neste modo. Isso é útil para evitar deadlocks em potencial no software de 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 conduzir a renderização GL para uma visualização de textura e desenhar o mais rápido possível, os buffers devem ser eliminados.

Para conduzir a maior parte desse 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 o ponto central para toda a renderização gráfica do Android.