Grafica

Icona HAL di Android Graphics

Il framework Android offre una serie di API di rendering grafico per 2D e 3D che interagiscono con le implementazioni dei driver grafici dei produttori, quindi è importante avere una buona comprensione di come funzionano queste API a un livello superiore. Questa pagina introduce l'Hardware Abstraction Layer (HAL) grafico su cui si basano questi driver. Prima di continuare con questa sezione, familiarizza con i seguenti termini:

canvas (termine generico), Canvas (elemento API)
Un canvas è una superficie di disegno che gestisce la composizione dei bit effettivi rispetto a una bitmap o a un Surface oggetto. La classe Canvas ha metodi per il disegno standard di bitmap, linee, cerchi, rettangoli, testo e così via e viene associata a una bitmap o a una superficie. Un canvas è il modo più semplice e facile per disegnare oggetti 2D sullo schermo. La classe base è Canvas.
risorsa drawable
Una risorsa drawable è una risorsa visiva compilata che può essere utilizzata come sfondo, titolo o altra parte dello schermo. In genere, una risorsa drawable viene caricata in un altro elemento dell'interfaccia utente ad esempio come immagine di sfondo. Una risorsa drawable non può ricevere eventi, ma assegna varie altre proprietà, come stato e pianificazione, per consentire sottoclassi come oggetti di animazione o librerie di immagini. Molti oggetti drawable vengono caricati da file di risorse drawable — ovvero file XML o bitmap che descrivono l'immagine. Le risorse drawable vengono compilate in sottoclassi di android.graphics.drawable. Per ulteriori informazioni sulle risorse drawable e su altre risorse, consulta la panoramica sulle risorse dell'app.
risorsa di layout
Una risorsa di layout è un file XML che descrive il layout di una schermata di attività. Per ulteriori informazioni, consulta Risorsa di layout.
nine-patch (9-patch, NinePatch)
Una risorsa nine-patch è una risorsa bitmap ridimensionabile che può essere utilizzata per sfondi o altre immagini sul dispositivo. Per ulteriori informazioni, consulta Nine-patch.
OpenGL ES
OpenGL ES è un'API multipiattaforma per il rendering di grafica 2D e 3D. Android fornisce librerie OpenGL ES per il rendering 3D con accelerazione hardware. Per il rendering 2D un canvas è l'opzione più semplice. OpenGL ES è disponibile nel Android Native Development Kit (NDK). I pacchetti android.opengl e javax.microedition.khronos.opengles espongono la funzionalità OpenGL ES.
superficie (termine generico), Surface (elemento API)
Una superficie rappresenta un blocco di memoria che viene composto sullo schermo. Una superficie contiene un canvas per il disegno e fornisce vari metodi di assistenza per disegnare i livelli e ridimensionare l'oggetto Surface. Utilizza la SurfaceView classe anziché la Surface classe direttamente.
visualizzazione della superficie (termine generico), SurfaceView (elemento API)
Una visualizzazione della superficie è un oggetto View che racchiude un oggetto Surface per il disegno ed espone metodi per specificarne dinamicamente le dimensioni e il formato. Una visualizzazione della superficie fornisce un modo per disegnare indipendentemente dal thread dell'interfaccia utente per operazioni che richiedono molte risorse, come giochi o anteprime della fotocamera, ma di conseguenza utilizza memoria aggiuntiva. Una visualizzazione della superficie supporta la grafica canvas e OpenGL ES La classe base per un SurfaceView oggetto è SurfaceView.
tema
Un tema è un insieme di proprietà, come la dimensione del testo e il colore di sfondo, raggruppate per definire varie impostazioni di visualizzazione predefinite. Android fornisce alcuni temi standard, elencati in R.style e preceduti da Theme_.
visualizzazione (termine generico), View (elemento API)
Una visualizzazione disegna un'area rettangolare sullo schermo e gestisce gli eventi di clic, tasti e altre interazioni. La classe View è la classe base per la maggior parte dei componenti di layout di una schermata di attività o di dialogo, come caselle di testo e finestre. Un oggetto View riceve chiamate dal relativo oggetto principale (vedi ViewGroup) per disegnarsi e informa l'oggetto principale delle dimensioni e della posizione preferite, che potrebbero non essere rispettate dal principale. Per ulteriori informazioni, consulta View.
gruppo di oggetti View (termine generico), ViewGroup (elemento API)
Un gruppo di oggetti View raggruppa un insieme di visualizzazioni secondarie. Il gruppo di oggetti View è responsabile della decisione della posizione e delle dimensioni delle visualizzazioni secondarie, nonché della chiamata di ciascuna per disegnarsi quando appropriato. Alcuni gruppi di oggetti View sono invisibili e sono solo per il layout, mentre altri hanno un'interfaccia utente intrinseca, ad esempio una casella di riepilogo a scorrimento. I gruppi di visualizzazioni si trovano nel pacchetto android.widget, ma estendono la classe ViewGroup.
gerarchia di oggetti View
Una gerarchia di visualizzazioni è una disposizione di oggetti View e di gruppi di oggetti View che definisce l'interfaccia utente per ogni componente di un'app. La gerarchia è costituita da gruppi di oggetti View che contengono una o più visualizzazioni o gruppi di oggetti View secondarie. Puoi ottenere una rappresentazione visiva di una gerarchia di oggetti View per il debug e l'ottimizzazione utilizzando il visualizzatore gerarchia fornito con l'SDK Android.
Vulkan
Vulkan è un'API multipiattaforma a basso overhead per la grafica 3D ad alte prestazioni.
widget
Un widget è una delle sottoclassi di visualizzazione completamente implementate che eseguono il rendering di elementi del modulo e di altri componenti dell'interfaccia utente, come una casella di testo o un menu popup. Poiché un widget è completamente implementato, gestisce la misurazione, il disegno se stesso e la risposta agli eventi dello schermo. I widget si trovano nel android.widget pacchetto.
finestra (termine generico), Window (elemento API)
In un'app per Android, una finestra è un oggetto derivato dalla Window classe astratta che specifica gli elementi di una finestra generica, come l'aspetto, il testo della barra del titolo, la posizione e il contenuto dei menu. Le finestre di dialogo e le attività utilizzano un'implementazione della Window classe per eseguire il rendering di un Window oggetto. Non è necessario implementare la classe Window o utilizzare le finestre nell'app.

Gli sviluppatori di app disegnano le immagini sullo schermo in tre modi: con Canvas, OpenGL ES o Vulkan.

Componenti grafici di Android

Indipendentemente dall'API di rendering utilizzata dagli sviluppatori, tutto viene sottoposto a rendering su una superficie. La superficie rappresenta il lato del producer di una coda di buffer spesso utilizzata da SurfaceFlinger. Ogni finestra creata sulla piattaforma Android è supportata da una superficie. Tutte le superfici visibili sottoposte a rendering vengono composte sul display da SurfaceFlinger.

Il seguente diagramma mostra l'interazione tra i componenti chiave:

componenti di rendering delle immagini

Figura 1. Come vengono sottoposte a rendering le superfici.

I componenti principali sono descritti nelle sezioni seguenti.

Producer di flussi di immagini

Un producer di flussi di immagini può essere qualsiasi elemento che produce buffer grafici per il consumo. Esempi: OpenGL ES, Canvas 2D e decodificatori video mediaserver.

Consumer di flussi di immagini

Il consumer più comune di flussi di immagini è SurfaceFlinger, il servizio di sistema che utilizza le superfici attualmente visibili e le compone sul display utilizzando le informazioni fornite da Window Manager. SurfaceFlinger è l'unico servizio che può modificare il contenuto del display. SurfaceFlinger utilizza OpenGL e Hardware Composer (HWC) per comporre un gruppo di superfici.

Anche altre app OpenGL ES possono utilizzare i flussi di immagini, ad esempio l'app Fotocamera che utilizza un flusso di immagini di anteprima della fotocamera. Anche le app non GL possono essere consumer, ad esempio la classe ImageReader.

Hardware Composer

L'astrazione hardware per il sottosistema di visualizzazione. SurfaceFlinger può delegare determinati lavori di composizione all'HWC per ridurre il carico di lavoro di OpenGL e della GPU. SurfaceFlinger funge da un altro client OpenGL ES. Ad esempio, quando SurfaceFlinger compone attivamente uno o due buffer in un terzo, utilizza OpenGL ES. In questo modo, la composizione consuma meno energia rispetto a quando la GPU esegue tutti i calcoli.

L'Hardware Composer HAL esegue l'altra metà del lavoro ed è il punto centrale per tutto il rendering grafico di Android. L'HWC 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 producer di immagini. Per maggiori dettagli, consulta BufferQueue e Gralloc.

Flusso di dati

Il seguente diagramma illustra la pipeline grafica di Android:

flusso di dati grafici

Figura 2. Flusso di dati grafici tramite Android.

Gli oggetti a sinistra sono renderer che producono buffer grafici, come la schermata Home, la barra di stato e l'interfaccia utente di sistema. SurfaceFlinger è il compositore e l'HWC è il compositore.

BufferQueue

BufferQueue fornisce il collegamento tra i componenti grafici di Android. Si tratta di una coppia di code che mediano il ciclo costante di buffer dal producer al consumer. Dopo che i producer hanno consegnato i buffer, SurfaceFlinger è responsabile della composizione di tutti gli elementi sul display.

Il seguente diagramma illustra il processo di comunicazione di BufferQueue:

Processo di comunicazione BufferQueue

Figura 3. Processo di comunicazione di BufferQueue.

BufferQueue contiene la logica che collega i producer e i consumer di flussi di immagini. Alcuni esempi di producer di immagini sono le anteprime della fotocamera prodotte dall'HAL della fotocamera o dai giochi OpenGL ES. Alcuni esempi di consumer di immagini sono SurfaceFlinger o un'altra app che visualizza un flusso OpenGL ES, ad esempio l'app Fotocamera che visualizza il mirino della fotocamera.

BufferQueue è una struttura di dati che combina un pool di buffer con una coda e utilizza la comunicazione interprocesso (IPC) di Binder per passare i buffer tra i processi. L'interfaccia del producer, o ciò che passi a chi vuole generare buffer grafici, è IGraphicBufferProducer (parte di SurfaceTexture). BufferQueue viene spesso utilizzato per il rendering su una superficie e per il consumo con un consumer GL, tra le altre attività.

BufferQueue può operare in tre modalità diverse:

modalità simile a quella sincrona
Per impostazione predefinita, BufferQueue opera in una modalità simile a quella sincrona, in cui ogni buffer in entrata dal producer viene inviato al consumer. In questa modalità non viene mai eliminato alcun buffer. Se il producer è troppo veloce e crea buffer più velocemente di quanto vengano svuotati, si blocca e attende i buffer liberi.
modalità non bloccante
BufferQueue può anche operare in modalità non bloccante, in cui genera un errore anziché attendere un buffer in questi casi. Anche in questa modalità non viene mai eliminato alcun buffer. Questa opzione è utile per evitare potenziali deadlock nel software applicativo che potrebbe non comprendere le complesse dipendenze del framework grafico.
modalità di eliminazione
BufferQueue può essere configurato per eliminare i buffer precedenti anziché generare errori o attendere. Ad esempio, se esegui il rendering GL su una visualizzazione della texture e disegni il più rapidamente possibile, i buffer devono essere eliminati.

Per eseguire la maggior parte di questo lavoro, SurfaceFlinger funge da un altro client OpenGL ES. Ad esempio, quando SurfaceFlinger compone attivamente uno o due buffer in un terzo, utilizza OpenGL ES.

L'HAL di Hardware Composer esegue l'altra metà del lavoro. Questo HAL funge da punto centrale per tutto il rendering grafico di Android.