SurfaceFlinger e WindowManager

SurfaceFlinger accetta buffer, compone buffer e invia buffer al display. WindowManager fornisce a SurfaceFlinger buffer e metadati delle finestre, che SurfaceFlinger utilizza per comporre le superfici sul display.

SurfaceFlinger

SurfaceFlinger può accettare buffer in due modi: tramite BufferQueue e SurfaceControl o tramite ASurfaceControl.

Un modo in cui SurfaceFlinger accetta i buffer è tramite BufferQueue e SurfaceControl. Quando un'app viene in primo piano, richiede buffer da WindowManager . WindowManager richiede quindi un livello da SurfaceFlinger. Un livello è una combinazione di una superficie , che contiene BufferQueue, e un SurfaceControl , che contiene i metadati del livello come la cornice di visualizzazione. SurfaceFlinger crea il livello e lo invia a WindowManager. WindowManager invia quindi la superficie all'app, ma mantiene SurfaceControl per manipolare l'aspetto dell'app sullo schermo.

Android 10 aggiunge ASurfaceControl, che è un altro modo in cui SurfaceFlinger può accettare buffer. ASurfaceControl combina una superficie e un SurfaceControl in un unico pacchetto di transazioni inviato a SurfaceFlinger. Un ASurfaceControl è associato a un livello, che le app aggiornano tramite ASurfaceTransactions. Le app ottengono quindi informazioni su ASurfaceTransactions tramite callback che passano ASurfaceTransactionStats contenente informazioni, ad esempio il tempo di latch, i tempi di acquisizione e così via.

La tabella seguente include ulteriori dettagli su AsurfaceControl e i suoi componenti associati.

Componente Descrizione
ASuperfaceControl Avvolge SurfaceControl e consente a un'app di creare SurfaceControls che corrispondono ai livelli sul display.

Può essere creato come figlio di ANativeWindow o come figlio di un altro ASuperfaceControl.
ASuperfaceTransaction Avvolge la transazione per consentire al client di modificare le proprietà descrittive di un livello, come la geometria, e invia i buffer aggiornati a SurfaceFlinger.
ASuperfaceTransactionStats Invia informazioni sulle transazioni che sono state presentate, ad esempio il tempo di latch, i tempi di acquisizione e il limite di rilascio precedente, a un'app tramite una richiamata preregistrata.

Sebbene le app possano inviare buffer in qualsiasi momento, SurfaceFlinger si attiva per accettare buffer solo tra gli aggiornamenti del display, che possono variare a seconda del dispositivo. Ciò riduce al minimo l'utilizzo della memoria ed evita strappi visibili sullo schermo, che possono verificarsi durante l'aggiornamento del display durante l'aggiornamento.

Quando il display è tra un aggiornamento e l'altro, il display invia il segnale VSYNC a SurfaceFlinger. Il segnale VSYNC indica che il display può essere aggiornato senza strappi. Quando SurfaceFlinger riceve il segnale VSYNC, SurfaceFlinger scorre l'elenco dei livelli alla ricerca di nuovi buffer. Se SurfaceFlinger trova un nuovo buffer, SurfaceFlinger acquisisce il buffer; in caso contrario, SurfaceFlinger continua a utilizzare il buffer precedentemente acquisito. SurfaceFlinger deve sempre visualizzare qualcosa, quindi si blocca su un buffer. Se su un livello non è mai stato inviato alcun buffer, il livello viene ignorato.

Dopo che SurfaceFlinger ha raccolto tutti i buffer per i livelli visibili, chiede all'Hardware Composer (HWC) come deve essere eseguita la composizione. Se l'HWC contrassegna il tipo di composizione dei livelli come composizione client, SurfaceFlinger compone tali livelli. Quindi, SurfaceFlinger passa il buffer di output all'HWC .

Gestore finestre

WindowManager controlla gli oggetti finestra , che sono contenitori per oggetti vista . Gli oggetti finestra sono sempre supportati da oggetti superficie. WindowManager supervisiona i cicli di vita, gli eventi di input e focus, l'orientamento dello schermo, le transizioni, le animazioni, la posizione, le trasformazioni, l'ordine z e molti altri aspetti di una finestra. WindowManager invia tutti i metadati della finestra a SurfaceFlinger in modo che SurfaceFlinger possa utilizzare tali dati per superfici composite sul display.

Pre-rotazione

Molti overlay hardware non supportano la rotazione (e anche se lo fanno, costa potenza di elaborazione); la soluzione è trasformare il buffer prima che raggiunga SurfaceFlinger. Android supporta un suggerimento per la query ( NATIVE_WINDOW_TRANSFORM_HINT ) in ANativeWindow per rappresentare la trasformazione più probabile da applicare al buffer da SurfaceFlinger. I driver GL possono utilizzare questo suggerimento per pre-trasformare il buffer prima che raggiunga SurfaceFlinger in modo che quando arriva il buffer venga trasformato correttamente.

Ad esempio, quando ricevi un suggerimento per ruotare di 90 gradi, genera e applica una matrice al buffer per evitare che fuoriesca dalla fine della pagina. Per risparmiare energia, eseguire questa pre-rotazione. Per i dettagli, consultare l'interfaccia ANativeWindow definita in system/core/include/system/window.h .