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 avere una buona comprensione del funzionamento di 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 le immagini sullo schermo in tre modi: con Canvas , OpenGL ES o Vulkan .
Componenti grafici Android
Indipendentemente da ciò che gli sviluppatori di API di rendering usano, 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 flussi di immagini può essere qualsiasi cosa che produca buffer grafici per il consumo. Gli esempi includono i decoder video OpenGL ES, Canvas 2D e mediaserver.
Consumatori di flussi 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 da 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, come l'app della fotocamera che utilizza 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 solo come un altro client OpenGL ES. Quindi, quando SurfaceFlinger compone attivamente uno o due buffer in un terzo, ad esempio, utilizza OpenGL ES. Ciò rende il compositing meno potente rispetto al fatto che la GPU esegua tutto il calcolo.
Hardware Composer HAL svolge l'altra metà del lavoro ed è il punto centrale per tutto il rendering grafico Android. Hardware Composer deve supportare gli eventi, uno dei quali è VSYNC (un altro è hotplug per il supporto plug-and-play HDMI).
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
Vedere il diagramma seguente per una rappresentazione della pipeline grafica Android:
Figura 2. Flusso di dati grafici tramite 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 fornisce il collante tra i componenti grafici di Android. Si tratta di una coppia di code che mediano il ciclo costante di buffer dal produttore al consumatore. Una volta che i produttori hanno distribuito i loro buffer, SurfaceFlinger è responsabile del compositing 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 di flussi di immagini ei consumatori di flussi di immagini. Alcuni esempi di produttori di immagini sono le anteprime della fotocamera prodotte dai giochi della fotocamera HAL o OpenGL ES. Alcuni esempi di consumatori di immagini sono SurfaceFlinger o un'altra app che visualizza uno stream OpenGL ES, come 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 consumare con un consumatore GL, tra le altre attività.
BufferQueue può funzionare in tre diverse modalità:
Modalità sincrona - BufferQueue per impostazione predefinita opera in una modalità sincrona, in cui ogni buffer che arriva dal produttore esce al consumatore. Nessun buffer viene mai eliminato in questa modalità. E se il produttore è troppo veloce e crea buffer più velocemente di quanto vengano scaricati, si bloccherà e attenderà buffer liberi.
Modalità non bloccante - BufferQueue può anche operare in una modalità non bloccante in cui genera un errore anziché attendere un buffer in quei casi. Anche in questa modalità nessun buffer viene mai eliminato. Ciò è utile per evitare potenziali deadlock nel software applicativo che potrebbe non comprendere le complesse dipendenze del framework grafico.
Modalità di eliminazione: infine, BufferQueue può essere configurato per eliminare i vecchi buffer anziché generare errori o attendere. Ad esempio, se si esegue il rendering GL in una vista texture e si disegna il più rapidamente possibile, è necessario eliminare i buffer.
Per condurre la maggior parte di questo lavoro, SurfaceFlinger funge solo da un altro client OpenGL ES. Quindi, quando SurfaceFlinger compone attivamente uno o due buffer in un terzo, ad esempio, utilizza OpenGL ES.
Il compositore hardware HAL esegue l'altra metà del lavoro. Questo HAL funge da punto centrale per tutto il rendering grafico Android.