SurfaceFlinger accetta i buffer, li compone e li invia al display. WindowManager fornisce a SurfaceFlinger buffer e metadati della finestra, 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 messa in primo piano, richiede buffer da WindowManager. WindowManager richiede quindi un livello da SurfaceFlinger. Un livello è una combinazione di una superficie, che contiene la BufferQueue, e di un SurfaceControl, che contiene i metadati del livello, come la cornice del display. SurfaceFlinger crea il livello e lo invia a WindowManager. WindowManager quindi invia la superficie all'app, ma mantiene SurfaceControl per manipulare l'aspetto dell'app sullo schermo.
Android 10 aggiunge ASurfaceControl, un altro modo in cui SurfaceFlinger può accettare i buffer. ASurfaceControl combina una superficie e un SurfaceControl in un unico pacchetto di transazione che viene inviato a SurfaceFlinger. Un ASurfaceControl è associato a un livello, che le app aggiornano tramite ASurfaceTransactions. Le app ricevono quindi informazioni su ASurfaceTransactions tramite callback che trasmettono ASurfaceTransactionStats contenenti informazioni quali tempo di aggancio, tempi di acquisizione e così via.
La tabella seguente include ulteriori dettagli su ASurfaceControl e sui relativi componenti associati.
| Componente | Descrizione |
|---|---|
| ASurfaceControl | Avvolge SurfaceControl e consente a un'app di creare SurfaceControl che
corrispondono ai livelli sul display. Può essere creato come elemento figlio di ANativeWindow o come elemento figlio di un altro ASurfaceControl. |
| ASurfaceTransaction | Avvolge Transaction per consentire al client di modificare le proprietà descriptive di un livello, ad esempio la geometria, e invia i buffer aggiornati a SurfaceFlinger. |
| ASurfaceTransactionStats | Invia informazioni sulle transazioni che sono state presentate, ad esempio il tempo di blocco, i tempi di acquisizione e la recinzione di rilascio precedente, a un'app tramite un callback preregistrato. |
Sebbene le app possano inviare buffer in qualsiasi momento, SurfaceFlinger si attiva solo per accettare i buffer tra gli aggiornamenti del display, che possono variare a seconda del dispositivo. In questo modo, l'utilizzo della memoria viene ridotto al minimo ed è possibile evitare lo sfarfallio visibile sullo schermo, che può verificarsi quando si aggiorna il display durante l'aggiornamento.
Quando il display è tra un aggiornamento e l'altro, invia il segnale VSYNC a SurfaceFlinger. Il segnale VSYNC indica che il display può essere aggiornato senza tearing. Quando SurfaceFlinger riceve l'indicatore VSYNC, esamina il proprio elenco di livelli alla ricerca di nuovi buffer. Se SurfaceFlinger trova un nuovo buffer, lo acquisisce; in caso contrario, continua a utilizzare il buffer acquisito in precedenza. SurfaceFlinger deve sempre mostrare qualcosa, quindi si blocca su un buffer. Se non sono mai stati inviati buffer su un livello, il livello viene ignorato.
Dopo aver raccolto tutti i buffer per gli strati visibili, SurfaceFlinger chiede a Hardware Composer (HWC) come deve essere eseguita la composizione. Se l'HWC contrassegni il tipo di composizione dei livelli come composizione client, SurfaceFlinger compone questi livelli. Quindi, SurfaceFlinger passa il buffer di output all'HWC.
WindowManager
WindowManager controlla gli oggetti finestra, che sono contenitori per gli oggetti vista. Gli oggetti finestra sono sempre supportati da oggetti di superficie. WindowManager supervisiona i cicli di vita, gli eventi di input e di messa a fuoco, 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 questi dati per comporre superfici sul display.
Pre-rotazione
Molti overlay hardware non supportano la rotazione (e anche se lo fanno, costa
energia di elaborazione); la soluzione è trasformare il buffer prima che raggiunga
SurfaceFlinger. Android supporta un suggerimento di 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, venga trasformato correttamente.
Ad esempio, quando ricevi un suggerimento per ruotare di 90 gradi, genera e applica una matrice al buffer per evitare che venga visualizzato oltre la fine della pagina. Per risparmiare energia, esegui questa pre-rotazione. Per maggiori dettagli, consulta l'interfaccia ANativeWindow
definita in system/core/include/system/window.h.