Architettura grafica

Cosa deve sapere ogni sviluppatore su superfici, SurfaceHolder, EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView, SurfaceFlinger e Vulkan.

Questa pagina descrive gli elementi essenziali dell'architettura grafica di livello di sistema di Android e come vengono utilizzati dal framework dell'app e dal sistema multimediale. L'attenzione è incentrata sul modo in cui i buffer di dati grafici si spostano all'interno del sistema. Se ti sei mai chiesto perché SurfaceView e TextureView si comportano in un determinato modo o come interagiscono le superfici e EGLSurface, sei nel posto giusto.

Si presume una certa familiarità con i dispositivi Android e lo sviluppo di app. Non è necessaria una conoscenza dettagliata del framework dell'app e vengono menzionate pochissime chiamate API, ma il materiale non si sovrappone ad altra documentazione pubblica. L'obiettivo è fornire dettagli sugli eventi significativi coinvolti nel rendering di un frame per l'output per aiutarti a fare scelte consapevoli quando progetti un'app. Per raggiungere questo obiettivo, lavoriamo dal basso verso l'alto, descrivendo il funzionamento delle classi UI anziché il modo in cui possono essere utilizzate.

Questa sezione include diverse pagine che trattano di tutto, dai materiali di sfondo ai dettagli dell'HAL ai casi d'uso. Inizia con una spiegazione dei buffer grafici di Android, descrive il meccanismo di composizione e visualizzazione, quindi passa ai meccanismi di livello superiore che forniscono i dati al compositore. Ti consigliamo di leggere le pagine nell'ordine elencato di seguito anziché passare a un argomento che ti sembra interessante.

Componenti di basso livello

  • BufferQueue e gralloc. BufferQueue connette un elemento che genera buffer di dati grafici (il producer) a un elemento che accetta i dati per la visualizzazione o un ulteriore elaborazione (il consumer). Le allocazioni dei buffer vengono eseguite tramite l'allocatore di memoria gralloc implementato tramite un'interfaccia HAL specifica del fornitore.
  • SurfaceFlinger, Hardware Composer e display virtuali. SurfaceFlinger accetta buffer di dati da più origini, li compone e li invia al display. L'HAL (Hardware Composer) determina il modo più efficiente per comporre i buffer con l'hardware disponibile e i display virtuali rendono disponibile l'output composito all'interno del sistema (registrando lo schermo o inviandolo su una rete).
  • Surface, canvas e SurfaceHolder. Una superficie produce una coda di buffer che viene spesso utilizzata da SurfaceFlinger. Quando viene eseguito il rendering su una superficie, il risultato viene inserito in un buffer che viene inviato al consumatore. Le API Canvas forniscono un'implementazione software (con supporto dell'accelerazione hardware) per disegnare direttamente su una superficie (alternativa a basso livello ad OpenGL ES). Tutto ciò che riguarda una visualizzazione coinvolge un SurfaceHolder, le cui API consentono di ottenere e impostare i parametri della superficie, come dimensioni e formato.
  • EGLSurface e OpenGL ES. OpenGL ES (GLES) definisce un'API di rendering grafico progettata per essere combinata con EGL, una libreria che può creare e accedere alle finestre tramite il sistema operativo (per disegnare poligoni con texture, utilizza le chiamate GLES; per mettere il rendering sullo schermo, utilizza le chiamate EGL). Questa pagina illustra anche ANativeWindow, l'equivalente in C/C++ della classe Java Surface utilizzata per creare una superficie della finestra EGL da codice nativo.
  • Vulkan. Vulkan è un'API multipiattaforma a basso overhead per la grafica 3D ad alte prestazioni. Come OpenGL ES, Vulkan fornisce strumenti per creare grafica in tempo reale di alta qualità nelle app. I vantaggi di Vulkan includono la riduzione del sovraccarico della CPU e il supporto per il linguaggio SPIR-V Binary Intermediate.

Componenti di alto livello

  • SurfaceView e GLSurfaceView. SurfaceView combina una superficie e una visualizzazione. I componenti della vista di SurfaceView vengono composti da SurfaceFlinger (e non dall'app), consentendo il rendering da un thread/processo separato e l'isolamento dal rendering dell'interfaccia utente dell'app. GLSurfaceView fornisce classi di supporto per gestire i contesti EGL, la comunicazione tra thread e l'interazione con il ciclo di vita dell'attività (ma non è necessario utilizzare GLES).
  • SurfaceTexture. SurfaceTexture combina una superficie e una texture GLES per creare una BufferQueue di cui la tua app è il consumatore. Quando un produttore mette in coda un nuovo buffer, ne invia una notifica alla tua app, che a sua volta rilascia il buffer precedentemente trattenuto, acquisisce il nuovo buffer dalla coda ed esegue chiamate EGL per renderlo disponibile a GLES come texture esterna. Android 7.0 ha aggiunto il supporto per la riproduzione di video con texture sicure, consentendo la post-elaborazione dei contenuti video protetti tramite GPU.
  • TextureView. TextureView combina una vista con una SurfaceTexture. TextureView avvolge una SurfaceTexture e si assume la responsabilità di rispondere ai callback e acquisire nuovi buffer. Durante il disegno, TextureView utilizza i contenuti del buffer ricevuto più di recente come origine dati, eseguendo il rendering dove e come indicato dallo stato della visualizzazione. La composizione della visualizzazione viene sempre eseguita con GLES, il che significa che gli aggiornamenti dei contenuti possono causare anche il ricalcolo di altri elementi della visualizzazione.