SurfaceFlinger accetta i buffer, li compone e li invia ai display. WindowManager fornisce a SurfaceFlinger buffer e finestre , che SurfaceFlinger utilizza per le superfici composte del 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 passa in primo piano, richiede buffer WindowManager. WindowManager richiede quindi un livello SurfaceFlinger. Un livello è la combinazione di una surface, che contiene la coda del buffer, e un SurfaceControl, che contiene i metadati del livello come la cornice di visualizzazione. 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 transazioni che viene inviato SurfaceFlinger. Un ASurfaceControl è associato a un livello, che le app aggiornano tramite ASurfaceTransactions. Le app ricevono quindi informazioni ASurfaceTransaction tramite callback che passano ASurfaceTransactionStats contenenti informazioni come tempo di latch, tempi di acquisizione e così via.
La tabella seguente include ulteriori dettagli su ASurfaceControl e sui relativi componenti associati.
| Componente | Descrizione |
|---|---|
| ASurfaceControl | Aggrega SurfaceControl e consente a un'app di creare SurfaceControls che
corrispondono ai livelli sul display. Possono essere creati come elementi secondari di A NativeWindow o come elemento secondario di un altro ASurfaceControl. |
| TransazioneSuperficie | Esegue il wrapping della transazione per consentire al cliente di modificare il testo descrittivo di un livello proprietà, come la geometria, e invia i buffer aggiornati SurfaceFlinger. |
| ASurfaceTransactionStats | Invia informazioni sulle transazioni presentate, ad esempio: tempo di attesa, tempi di acquisizione e periodo di release precedente in 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 si riduce al minimo l'utilizzo della memoria ed evita interruzioni visibili schermo, cosa che può verificarsi durante l'aggiornamento del display durante l'aggiornamento centrale.
Quando il display è tra un aggiornamento e l'altro, invia VSYNC a SurfaceFlinger. Il segnale VSYNC indica che è possibile rigenerato senza strappi. Quando SurfaceFlinger riceve il segnale VSYNC, SurfaceFlinger percorre il suo elenco di strati alla ricerca di nuovi buffer. Se SurfaceFlinger trova un nuovo buffer, SurfaceFlinger acquisisce il buffer; in caso contrario, SurfaceFlinger continua per utilizzare il buffer acquisito in precedenza. SurfaceFlinger deve sempre visualizzare qualcosa, quindi rimane attaccato a un buffer. Se non sono mai stati inviati buffer su una , questo viene ignorato.
Dopo che SurfaceFlinger ha raccolto tutti i buffer per i livelli visibili, chiede all'HWC (Hardware Composer) come eseguire 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 di oggetti superficiali. 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 quest'ultimo possa utilizzare questi dati per comporre le superfici sul display.
Pre-rotazione
Molti overlay hardware non supportano la rotazione e, anche se li supportano, costa
potenza di elaborazione); La soluzione è trasformare il buffer prima che raggiunga
SurfaceFlinger. Android supporta un suggerimento per le query
(NATIVE_WINDOW_TRANSFORM_HINT) nel mese di ANativeWindow per
la trasformazione più probabile da applicare al buffer
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 le ANativeWindow
dell'interfaccia definita in system/core/include/system/window.h.