Il framework Android offre una varietà di API di rendering grafico per 2D e 3D che interagiscono con le implementazioni dei produttori di driver grafici, quindi è importante comprendere bene come funzionano tali API a un livello superiore. Questa pagina introduce il livello di astrazione dell'hardware grafico (HAL) su cui sono costruiti questi driver.
Gli sviluppatori di applicazioni disegnano immagini sullo schermo in tre modi: con Canvas , OpenGL ES o Vulkan .
Componenti grafici Android
Indipendentemente dall'API di rendering utilizzata dagli sviluppatori, tutto viene renderizzato su una superficie . La superficie rappresenta il lato produttore di una coda buffer che viene spesso utilizzata da SurfaceFlinger. Ogni finestra creata sulla piattaforma Android è supportata da una superficie. Tutte le superfici visibili renderizzate vengono composte sul display da SurfaceFlinger.
Il diagramma seguente mostra come interagiscono i componenti chiave:
Figura 1. Come vengono renderizzate le superfici
I componenti principali sono descritti di seguito:
Produttori di flussi di immagini
Un produttore di flusso di immagini può essere qualsiasi cosa che produca buffer grafici per il consumo. Gli esempi includono OpenGL ES, Canvas 2D e decoder video mediaserver.
Consumatori del flusso di immagini
Il consumatore più comune di flussi di immagini è SurfaceFlinger, il servizio di sistema che consuma le superfici attualmente visibili e le compone sul display utilizzando le informazioni fornite dal Window Manager. SurfaceFlinger è l'unico servizio in grado di modificare il contenuto del display. SurfaceFlinger utilizza OpenGL e Hardware Composer per comporre un gruppo di superfici.
Anche altre app OpenGL ES possono consumare flussi di immagini, ad esempio l'app della fotocamera che consuma un flusso di immagini di anteprima della fotocamera. Anche le applicazioni non GL possono essere consumer, ad esempio la classe ImageReader.
Compositore hardware
L'astrazione hardware per il sottosistema di visualizzazione. SurfaceFlinger può delegare determinati lavori di composizione all'Hardware Composer per scaricare il lavoro da OpenGL e dalla GPU. SurfaceFlinger agisce come un altro client OpenGL ES. Pertanto, quando SurfaceFlinger sta componendo attivamente uno o due buffer in un terzo, ad esempio, utilizza OpenGL ES. Ciò rende la composizione meno potente rispetto a quando la GPU esegue tutti i calcoli.
L' HAL del compositore hardware svolge l'altra metà del lavoro ed è il punto centrale per tutto il rendering grafico di Android. L'Hardware Composer deve supportare gli eventi, uno dei quali è VSYNC (un altro è hotplug per il supporto HDMI plug-and-play).
Gralloc
L'allocatore di memoria grafica (Gralloc) è necessario per allocare la memoria richiesta dai produttori di immagini. Per i dettagli, vedere Gralloc HAL .
Flusso di dati
Consulta il diagramma seguente per una rappresentazione della pipeline grafica Android:
Figura 2. Flusso di dati grafici attraverso Android
Gli oggetti a sinistra sono renderer che producono buffer grafici, come la schermata iniziale, la barra di stato e l'interfaccia utente del sistema. SurfaceFlinger è il compositore e Hardware Composer è il compositore.
BufferQueue
BufferQueues forniscono il collante tra i componenti grafici Android. Si tratta di una coppia di code che mediano il ciclo costante di buffer dal produttore al consumatore. Una volta che i produttori consegnano i loro buffer, SurfaceFlinger è responsabile della composizione di tutto sul display.
Vedere il diagramma seguente per il processo di comunicazione BufferQueue.
Figura 3. Processo di comunicazione BufferQueue
BufferQueue contiene la logica che lega insieme i produttori del flusso di immagini e i consumatori del flusso di immagini. Alcuni esempi di produttori di immagini sono le anteprime della fotocamera prodotte dai giochi HAL o OpenGL ES della fotocamera. Alcuni esempi di consumatori di immagini sono SurfaceFlinger o un'altra app che visualizza un flusso OpenGL ES, ad esempio l'app della fotocamera che mostra il mirino della fotocamera.
BufferQueue è una struttura dati che combina un pool di buffer con una coda e utilizza Binder IPC per passare i buffer tra i processi. L'interfaccia del produttore, o ciò che passi a qualcuno che vuole generare buffer grafici, è IGraphicBufferProducer (parte di SurfaceTexture ). BufferQueue viene spesso utilizzato per eseguire il rendering su una superficie e utilizzarlo con un consumatore GL, tra le altre attività.
BufferQueue può funzionare in tre diverse modalità:
Modalità di tipo sincrono : BufferQueue per impostazione predefinita funziona in modalità di tipo sincrono, in cui ogni buffer in arrivo dal produttore esce dal consumatore. Nessun buffer viene mai scartato in questa modalità. E se il produttore è troppo veloce e crea buffer più velocemente di quanto vengano svuotati, si bloccherà e attenderà i buffer liberi.
Modalità non bloccante : BufferQueue può anche funzionare in modalità non bloccante in cui genera un errore anziché attendere un buffer in questi casi. Nessun buffer viene mai scartato neanche in questa modalità. Ciò è utile per evitare potenziali blocchi nel software applicativo che potrebbe non comprendere le complesse dipendenze del framework grafico.
Modalità Scarta : infine, BufferQueue può essere configurato per eliminare i vecchi buffer anziché generare errori o attendere. Ad esempio, se si esegue il rendering GL su una vista texture e si disegna il più rapidamente possibile, i buffer devono essere eliminati.
Per svolgere la maggior parte di questo lavoro, SurfaceFlinger agisce come un altro client OpenGL ES. Pertanto, quando SurfaceFlinger sta componendo attivamente uno o due buffer in un terzo, ad esempio, utilizza OpenGL ES.
L'HAL del compositore hardware esegue l'altra metà del lavoro. Questo HAL funge da punto centrale per tutto il rendering grafico Android.