![Ícone HAL de gráficos Android](https://source.android.google.cn/static/docs/core/graphics/images/ape-fwk-hal-graphics.png?authuser=00&hl=pt)
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) na qual esses drivers são criados. Antes de continuar com esta seção, familiarize-se com os seguintes termos:
Canvas
(elemento API)Surface
. Canvas
possui métodos para desenho padrão de computador de bitmaps, linhas, círculos, retângulos, texto e assim por diante, e está vinculado a um bitmap ou superfície. Uma tela é a maneira mais simples e fácil de desenhar objetos 2D na tela. A classe base é Canvas
.android.graphics.drawable
. Para obter mais informações sobre drawables e outros recursos, consulte Recursos .android.opengl
e javax.microedition.khronos.opengles
expõem a funcionalidade do OpenGL ES.Surface
(elemento API)Surface
. Use a classe SurfaceView
em vez da classe Surface
diretamente.SurfaceView
(elemento API)View
que envolve um objeto Surface
para desenho e expõe métodos para especificar seu tamanho e formato dinamicamente. Uma visualização de superfície fornece uma maneira de desenhar independentemente do thread de UI para operações que consomem muitos recursos, como jogos ou visualizações de câmera, mas, como resultado, usa memória extra. Uma visualização de superfície oferece suporte a gráficos de tela e OpenGL ES. A classe base para um objeto SurfaceView
é SurfaceView
.R.style
e precedidos por Theme_
.View
(elemento API)View
é a classe base para a maioria dos componentes de layout de uma atividade ou tela de diálogo, como caixas de texto e janelas. Um objeto View
recebe chamadas de seu objeto pai (consulte ViewGroup
) para desenhar a si mesmo e informa seu objeto pai sobre seu tamanho e localização preferidos, o que pode não ser respeitado pelo pai. Para obter mais informações, consulte View
.ViewGroup
(elemento API)widget
, mas estendem a classe ViewGroup
.android.widget
.Window
(elemento API)Window
que especifica os elementos de uma janela genérica, como aparência, texto da barra de título e localização e conteúdo dos menus. Diálogos e atividades usam uma implementação da classe Window
para renderizar um objeto Window
. Você não precisa implementar a classe Window
ou usar janelas em seu aplicativo.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 usem, 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:
![componentes de renderização de imagem](https://source.android.google.cn/static/docs/core/graphics/images/ape-fwk-graphics.png?authuser=00&hl=pt)
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:
![fluxo de dados gráficos](https://source.android.google.cn/static/docs/core/graphics/images/graphics-pipeline.png?authuser=00&hl=pt)
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.
![Processo de comunicação BufferQueue](https://source.android.google.cn/static/docs/core/graphics/images/bufferqueue.png?authuser=00&hl=pt)
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.