O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Gráficos

Gráficos Android ícone HAL

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 de gráficos do fabricante; portanto, é importante entender bem 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 criados.

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 da API de renderização usem, tudo é renderizado em uma "superfície". A superfície representa o lado do produtor de uma fila de buffer que é frequentemente consumida pelo SurfaceFlinger. Toda 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:

componentes de renderização de imagem

Figura 1. Como as superfícies são renderizadas

Os principais componentes estão descritos abaixo:

Produtores de Image Stream

Um produtor de fluxo de imagens pode ser qualquer coisa que produz buffers gráficos para consumo. Os exemplos incluem decodificadores de vídeo OpenGL ES, Canvas 2D e 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 as informações fornecidas pelo Gerenciador de Janelas. SurfaceFlinger é o único serviço que pode modificar o conteúdo da exibição. O SurfaceFlinger usa o 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 da 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 mais um cliente OpenGL ES. Portanto, quando o SurfaceFlinger compõe ativamente um buffer ou dois em um terceiro, por exemplo, ele usa o OpenGL ES. Isso reduz a potência da composição do que a GPU realiza todo o cálculo.

O Hardware Composer HAL realiza a outra metade do trabalho e é o ponto central de toda a renderização gráfica de Android. O Hardware Composer deve suportar eventos, um dos quais é VSYNC (outro é o hotplug para suporte 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 detalhes, consulte Gralloc HAL .

Fluxo de dados

Consulte o diagrama a seguir para obter uma representação do pipeline de gráficos do Android:

fluxo de dados gráficos

Figura 2. Fluxo de dados gráficos através do Android

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

BufferQueue

BufferQueues fornece a cola entre os componentes gráficos do Android. Essas são duas filas que mediam o ciclo constante de buffers do produtor para o 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.

Processo de comunicação BufferQueue

Figura 3. Processo de comunicação BufferQueue

BufferQueue contém a lógica que une produtores e consumidores de fluxos de imagens. Alguns exemplos de produtores de imagens são as visualizações da câmera produzidas pelos jogos HAL ou OpenGL ES da câmera. Alguns exemplos de consumidores de imagens são o SurfaceFlinger ou outro aplicativo que exibe um fluxo OpenGL ES, como o aplicativo da câmera que exibe 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 do SurfaceTexture ). O 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 do tipo síncrono - O BufferQueue, por padrão, opera em um modo do tipo síncrono, no qual todo buffer que chega do produtor sai para o consumidor. Nenhum buffer é descartado neste modo. E se o produtor for muito rápido e criar buffers mais rapidamente do que eles estão sendo drenados, ele bloqueará e aguardará buffers gratuitos.

Modo sem bloqueio - o 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 conflitos no software de aplicativo que podem não entender as dependências complexas da estrutura gráfica.

Modo Descartar - Finalmente, o BufferQueue pode ser configurado para descartar buffers antigos em vez de gerar erros ou aguardar. Por exemplo, se você realizar renderização GL em uma vista de textura e desenhar o mais rápido possível, os buffers deverão ser descartados.

Para conduzir a maior parte desse trabalho, o SurfaceFlinger atua apenas como outro cliente do OpenGL ES. Portanto, quando o SurfaceFlinger compõe ativamente um buffer ou dois em um terceiro, por exemplo, ele usa o OpenGL ES.

O Hardware Composer HAL realiza a outra metade do trabalho. Este HAL atua como o ponto central de toda a renderização gráfica de Android.