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 a livello di sistema Android e il modo in cui vengono utilizzati dal framework dell'app e dal sistema multimediale. L'attenzione è rivolta al modo in cui i buffer di dati grafici si spostano nel 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 sono necessarie conoscenze dettagliate 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 informate quando progetti un'app. Per raggiungere questo obiettivo, questo documento procede dal basso verso l'alto, descrivendo il funzionamento delle classi UI anziché il loro utilizzo.
Questa sezione include diverse pagine che trattano argomenti che vanno dal materiale di base ai dettagli dell'HAL e 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 nel seguente ordine anziché passare direttamente a un argomento che ti sembra interessante.
Componenti di basso livello
- BufferQueue e gralloc. BufferQueue collega un elemento che genera buffer di dati grafici (il producer) a un elemento che accetta i dati per la visualizzazione o l'ulteriore elaborazione (il consumer). L'allocazione dei buffer viene eseguita 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 (registrazione dello schermo o invio dello schermo su una rete).
- Surface, canvas e SurfaceHolder. Una superficie produce una coda buffer che viene spesso utilizzata da SurfaceFlinger. Durante il rendering su una superficie, il risultato finisce in un buffer che viene spedito al consumatore. Le API Canvas forniscono un'implementazione software (con supporto dell'accelerazione hardware) per disegnare direttamente su una superficie (alternativa di basso livello a OpenGL ES). Qualsiasi elemento che ha a che fare con una visualizzazione coinvolge un SurfaceHolder, le cui API consentono di ottenere e impostare parametri di 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 visualizzare il rendering sullo schermo, utilizza le chiamate EGL). Questa pagina tratta anche di ANativeWindow, l'equivalente C/C++ della classe Java Surface utilizzata per creare una superficie della finestra EGL dal codice nativo.
- Vulkan. Vulkan è un'API multipiattaforma a basso overhead per 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 visualizzazione 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 helper per gestire i contesti EGL, la comunicazione interthread e l'interazione con il ciclo di vita dell'attività (ma non è necessario per utilizzare GLES).
- SurfaceTexture. SurfaceTexture combina una superficie e una texture GLES per creare una BufferQueue per cui la tua app è il consumer. Quando un produttore mette in coda un nuovo buffer, invia una notifica alla tua app, che a sua volta rilascia il buffer precedentemente mantenuto, acquisisce il nuovo buffer dalla coda ed effettua chiamate EGL per rendere il buffer disponibile per GLES come texture esterna. Android 7.0 ha aggiunto il supporto per la riproduzione di video con texture sicure, consentendo la post-elaborazione GPU dei contenuti video protetti.
- TextureView. TextureView combina una visualizzazione con una SurfaceTexture. TextureView esegue il wrapping di 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 ovunque e comunque lo stato della visualizzazione indica che deve farlo. La composizione della visualizzazione viene sempre eseguita con GLES, il che significa che gli aggiornamenti ai contenuti potrebbero causare anche il ridisegno di altri elementi della visualizzazione.