Fasi di Jetpack Compose

Come la maggior parte degli altri toolkit UI, Compose esegue il rendering di un frame attraverso diverse fasi distinte. Ad esempio, il sistema di visualizzazione Android ha tre fasi principali: misura, layout e disegno. Compose è molto simile, ma all'inizio ha un'importante fase aggiuntiva chiamata composizione.

La documentazione di Compose descrive la composizione in Pensare in Compose e Stato e Jetpack Compose.

Le tre fasi di un frame

Compose ha tre fasi principali:

1. Composizione: quale UI mostrare. Compose esegue funzioni componibili e crea una descrizione della tua UI.
2. Layout: dove posizionare la UI. Questa fase è composta da due passaggi: misurazione e posizionamento. Gli elementi di layout misurano e posizionano se stessi e tutti gli elementi secondari in coordinate 2D, per ogni nodo dell'albero di layout.
3. Disegno: come viene eseguito il rendering. Gli elementi della UI vengono disegnati in un Canvas, in genere uno schermo del dispositivo.

Figura 1. Le tre fasi in cui Compose trasforma i dati in UI.

L'ordine di queste fasi è in genere lo stesso, il che consente ai dati di fluire in una direzione dalla composizione al layout al disegno per produrre un frame (noto anche come flusso di dati unidirezionale). BoxWithConstraints, LazyColumn, e LazyRow sono eccezioni notevoli, in cui la composizione dei relativi elementi secondari dipende dalla fase di layout dell'elemento principale.

A livello concettuale, ciascuna di queste fasi si verifica per ogni frame; tuttavia, per ottimizzare il rendimento, Compose evita di ripetere il lavoro che calcolerebbe gli stessi risultati dagli stessi input in tutte queste fasi. Compose salta l'esecuzione di una funzione componibile se può riutilizzare un risultato precedente e la UI di Compose non esegue nuovamente il layout o il disegno dell'intero albero se non è necessario. Compose esegue solo la quantità minima di lavoro necessaria per aggiornare la UI. Questa ottimizzazione è possibile perché Compose tiene traccia delle letture dello stato nelle diverse fasi.

Comprendere le fasi

Questa sezione descrive in modo più dettagliato come vengono eseguite le tre fasi di Compose per i componibili.

Composizione

Nella fase di composizione, il runtime di Compose esegue le funzioni componibili e genera una struttura ad albero che rappresenta la UI. Questo albero della UI è costituito da nodi di layout che contengono tutte le informazioni necessarie per le fasi successive, come mostrato nel video seguente:

Figura 2. L'albero che rappresenta la UI creata nella fase di composizione.

Una sottosezione del codice e dell'albero della UI è simile alla seguente:

Figura 3. Una sottosezione di un albero della UI con il codice corrispondente.

In questi esempi, ogni funzione componibile nel codice viene mappata a un singolo nodo di layout nell'albero della UI. In esempi più complessi, i componibili possono contenere logica e flusso di controllo e produrre un albero diverso in base a stati diversi.

Layout

Nella fase di layout, Compose utilizza come input l'albero della UI prodotto nella fase di composizione. La raccolta di nodi di layout contiene tutte le informazioni necessarie per decidere le dimensioni e la posizione di ogni nodo nello spazio 2D.

Figura 4. La misurazione e il posizionamento di ogni nodo di layout nell'albero della UI durante la fase di layout.

Durante la fase di layout, l'albero viene attraversato utilizzando il seguente algoritmo in tre passaggi:

1. Misura gli elementi secondari: un nodo misura i relativi elementi secondari, se presenti.
2. Decidi le dimensioni: in base a queste misurazioni, un nodo decide le proprie dimensioni.
3. Posiziona gli elementi secondari: ogni nodo secondario viene posizionato rispetto alla posizione del nodo.

Al termine di questa fase, ogni nodo di layout ha:

• Una larghezza e un'altezza assegnate
• Una coordinata x, y in cui deve essere disegnato

Ricorda l'albero della UI della sezione precedente:

Per questo albero, l'algoritmo funziona nel seguente modo:

1. Row misura i relativi elementi secondari, Image e Column.
2. Viene misurato Image. Non ha elementi secondari, quindi decide le proprie dimensioni e le comunica a Row.
3. Viene misurato Column. Misura prima i propri elementi secondari (due componibili Text).
4. Viene misurato il primo Text. Non ha elementi secondari, quindi decide le proprie dimensioni e le comunica a Column.
   1. Viene misurato il secondo Text. Non ha elementi secondari, quindi decide le proprie dimensioni e le comunica a Column.
5. Column utilizza le misurazioni degli elementi secondari per decidere le proprie dimensioni. Utilizza la larghezza massima degli elementi secondari e la somma dell'altezza dei relativi elementi secondari.
6. Column posiziona i relativi elementi secondari rispetto a se stesso, mettendoli uno sotto l'altro in verticale.
7. Row utilizza le misurazioni degli elementi secondari per decidere le proprie dimensioni. Utilizza l'altezza massima degli elementi secondari e la somma delle larghezze dei relativi elementi secondari. Poi posiziona gli elementi secondari.

Tieni presente che ogni nodo è stato visitato una sola volta. Il runtime di Compose richiede un solo passaggio nell'albero della UI per misurare e posizionare tutti i nodi, il che migliora il rendimento. Quando il numero di nodi nell'albero aumenta, il tempo impiegato per attraversarlo aumenta in modo lineare. Al contrario, se ogni nodo venisse visitato più volte, il tempo di attraversamento aumenterebbe in modo esponenziale.

Disegno

Nella fase di disegno, l'albero viene attraversato di nuovo dall'alto verso il basso e ogni nodo si disegna a turno sullo schermo.

Figura 5. La fase di disegno disegna i pixel sullo schermo.

Utilizzando l'esempio precedente, i contenuti dell'albero vengono disegnati nel seguente modo:

1. Row disegna tutti i contenuti che potrebbe avere, ad esempio un colore di sfondo.
2. Image si disegna.
3. Column si disegna.
4. Il primo e il secondo Text si disegnano, rispettivamente.

Figura 6. Un albero della UI e la relativa rappresentazione disegnata.

Letture dello stato

Quando leggi il value di uno snapshot state durante una delle fasi elencate in precedenza, Compose tiene automaticamente traccia di ciò che stava facendo quando ha letto il value. Questo monitoraggio consente a Compose di eseguire nuovamente il lettore quando il value dello stato cambia ed è la base dell'osservabilità dello stato in Compose.

In genere crei lo stato utilizzando mutableStateOf() e poi vi accedi in due modi: accedendo direttamente alla proprietà value o utilizzando un delegato di proprietà Kotlin. Puoi scoprire di più in Stato nei componibili. Ai fini di questa guida, per "lettura dello stato" si intende uno di questi metodi di accesso equivalenti.

// State read without property delegate.
val paddingState: MutableState<Dp> = remember { mutableStateOf(8.dp) }
Text(
    text = "Hello",
    modifier = Modifier.padding(paddingState.value)
)
PhasesSnippets.kt

// State read with property delegate.
var padding: Dp by remember { mutableStateOf(8.dp) }
Text(
    text = "Hello",
    modifier = Modifier.padding(padding)
)
PhasesSnippets.kt

Sotto il cofano del delegato di proprietà, vengono utilizzate le funzioni "getter" e "setter" per accedere e aggiornare lo stato value. Queste funzioni getter e setter vengono richiamate solo quando fai riferimento alla proprietà come valore e non quando viene creata, motivo per cui i due modi descritti in precedenza sono equivalenti.

Ogni blocco di codice che può essere eseguito nuovamente quando cambia uno stato di lettura è un ambito di riavvio. Compose tiene traccia delle modifiche del value dello stato e degli ambiti di riavvio in fasi diverse.

Letture dello stato in fasi

Come accennato in precedenza, in Compose esistono tre fasi principali e Compose tiene traccia dello stato letto in ciascuna di esse. In questo modo, Compose può notificare solo le fasi specifiche che devono eseguire il lavoro per ogni elemento interessato della UI.

Nota: la posizione in cui viene creata e archiviata un'istanza di stato ha poca importanza per le fasi, ma è importante quando e dove viene letto il value di uno stato.

Le sezioni seguenti descrivono ogni fase e cosa succede quando viene letto un valore di stato al suo interno.

Fase 1: composizione

Le letture dello stato all'interno di una funzione @Composable o di un blocco lambda influiscono sulla composizione e potenzialmente sulle fasi successive. Quando il value dello stato cambia, il ricompositore pianifica le riproduzioni di tutte le funzioni componibili che leggono il value dello stato. Tieni presente che il runtime potrebbe decidere di saltare alcune o tutte le funzioni componibili se gli input non sono cambiati. Per ulteriori informazioni, consulta Salto se gli input non sono cambiati.

A seconda del risultato della composizione, la UI di Compose esegue le fasi di layout e disegno. Potrebbe saltare queste fasi se i contenuti rimangono invariati e le dimensioni e il layout non cambiano.

var padding by remember { mutableStateOf(8.dp) }
Text(
    text = "Hello",
    // The `padding` state is read in the composition phase
    // when the modifier is constructed.
    // Changes in `padding` will invoke recomposition.
    modifier = Modifier.padding(padding)
)
PhasesSnippets.kt

Fase 2: layout

La fase di layout è composta da due passaggi: misurazione e posizionamento. Il passaggio di misurazione esegue la lambda di misurazione passata al Layout componibile, il MeasureScope.measure metodo dell'interfaccia LayoutModifier e così via. Il passaggio di posizionamento esegue il blocco di posizionamento della funzione layout, il blocco lambda di Modifier.offset { … } e funzioni simili.

Le letture dello stato durante ciascuno di questi passaggi influiscono sul layout e potenzialmente sulla fase di disegno. Quando il value dello stato cambia, la UI di Compose pianifica la fase di layout. Esegue anche la fase di disegno se le dimensioni o la posizione sono cambiate.

Punto chiave: il passaggio di misurazione e il passaggio di posizionamento hanno ambiti di riavvio separati, il che significa che le letture dello stato nel passaggio di posizionamento non richiamano il passaggio di misurazione prima di questo. Tuttavia, questi due passaggi sono spesso interconnessi, quindi una lettura dello stato nel passaggio di posizionamento può influire su altri ambiti di riavvio appartenenti al passaggio di misurazione.

var offsetX by remember { mutableStateOf(8.dp) }
Text(
    text = "Hello",
    modifier = Modifier.offset {
        // The `offsetX` state is read in the placement step
        // of the layout phase when the offset is calculated.
        // Changes in `offsetX` restart the layout.
        IntOffset(offsetX.roundToPx(), 0)
    }
)
PhasesSnippets.kt

Fase 3: disegno

Le letture dello stato durante il codice di disegno influiscono sulla fase di disegno. Esempi comuni includono Canvas(), Modifier.drawBehind e Modifier.drawWithContent. Quando il value dello stato cambia, la UI di Compose esegue solo la fase di disegno.

var color by remember { mutableStateOf(Color.Red) }
Canvas(modifier = modifier) {
    // The `color` state is read in the drawing phase
    // when the canvas is rendered.
    // Changes in `color` restart the drawing.
    drawRect(color)
}
PhasesSnippets.kt

Ottimizzare le letture dello stato

Poiché Compose esegue il monitoraggio localizzato delle letture dello stato, puoi ridurre al minimo la quantità di lavoro eseguito leggendo ogni stato in una fase appropriata.

Considera l'esempio seguente. Questo esempio ha un Image() che utilizza il modificatore di offset per compensare la posizione finale del layout, con conseguente effetto di parallasse durante lo scorrimento dell'utente.

Box {
    val listState = rememberLazyListState()

    Image(
        // ...
        // Non-optimal implementation!
        Modifier.offset(
            with(LocalDensity.current) {
                // State read of firstVisibleItemScrollOffset in composition
                (listState.firstVisibleItemScrollOffset / 2).toDp()
            }
        )
    )

    LazyColumn(state = listState) {
        // ...
    }
}
PhasesSnippets.kt

Questo codice funziona, ma comporta un rendimento non ottimale. Come scritto, il codice legge il value dello stato firstVisibleItemScrollOffset e lo passa a la funzione Modifier.offset(offset: Dp). Quando l'utente scorre, il value di firstVisibleItemScrollOffset cambierà. Come hai appreso, Compose tiene traccia di tutte le letture dello stato in modo da poter riavviare (richiamare nuovamente) il codice di lettura, che in questo esempio è il contenuto di Box.

Questo è un esempio di lettura di uno stato nella fase di composizione. Non è necessariamente una cosa negativa e, di fatto, è la base della ricomposizione, che consente alle modifiche dei dati di generare una nuova UI.

Punto chiave: questo esempio non è ottimale perché ogni evento di scorrimento comporta la rivalutazione, la misurazione, il layout e infine il disegno dell'intero contenuto componibile. Attivi la fase di Compose a ogni scorrimento, anche se i contenuti visualizzati non sono cambiati, ma solo la loro posizione. Puoi ottimizzare la lettura dello stato in modo da riattivare solo la fase di layout.

Offset con lambda

È disponibile un'altra versione del modificatore di offset: Modifier.offset(offset: Density.() -> IntOffset).

Questa versione accetta un parametro lambda, in cui l'offset risultante viene restituito dal blocco lambda. Aggiorna il codice per utilizzarlo:

Box {
    val listState = rememberLazyListState()

    Image(
        // ...
        Modifier.offset {
            // State read of firstVisibleItemScrollOffset in Layout
            IntOffset(x = 0, y = listState.firstVisibleItemScrollOffset / 2)
        }
    )

    LazyColumn(state = listState) {
        // ...
    }
}
PhasesSnippets.kt

Perché è più efficiente? Il blocco lambda che fornisci al modificatore viene richiamato durante la fase di layout (in particolare, durante il passaggio di posizionamento della fase di layout), il che significa che lo stato firstVisibleItemScrollOffset non viene più letto durante la composizione. Poiché Compose tiene traccia di quando viene letto lo stato, questa modifica significa che se il value di firstVisibleItemScrollOffset cambia, Compose deve solo riavviare le fasi di layout e disegno.

Nota: potresti chiederti se l'utilizzo di un parametro lambda possa comportare costi aggiuntivi rispetto all'utilizzo di un valore. Sì. Tuttavia, in questo caso il vantaggio di limitare la lettura dello stato alla fase di layout supera il costo. Il value di firstVisibleItemScrollOffset cambia ogni frame durante lo scorrimento e, posticipando la lettura dello stato alla fase di layout, puoi evitare le ricomposizioni.

Naturalmente, spesso è assolutamente necessario leggere gli stati nella fase di composizione. Anche in questo caso, puoi ridurre al minimo il numero di ricomposizioni filtrando le modifiche dello stato. Per ulteriori informazioni, consulta derivedStateOf: convertire uno o più oggetti di stato in un altro stato.

Ciclo di ricomposizione (dipendenza di fase ciclica)

In questa guida è stato detto che le fasi di Compose vengono sempre richiamate nello stesso ordine e che non è possibile tornare indietro nello stesso frame. Tuttavia, ciò non impedisce alle app di entrare in loop di composizione in frame diversi. Considera questo esempio:

Box {
    var imageHeightPx by remember { mutableIntStateOf(0) }

    Image(
        painter = painterResource(R.drawable.rectangle),
        contentDescription = "I'm above the text",
        modifier = Modifier
            .fillMaxWidth()
            .onSizeChanged { size ->
                // Don't do this
                imageHeightPx = size.height
            }
    )

    Text(
        text = "I'm below the image",
        modifier = Modifier.padding(
            top = with(LocalDensity.current) { imageHeightPx.toDp() }
        )
    )
}
PhasesSnippets.kt

Questo esempio implementa una colonna verticale, con l'immagine in alto e il testo sotto. Utilizza Modifier.onSizeChanged() per ottenere le dimensioni risolte dell'immagine e poi utilizza Modifier.padding() sul testo per spostarlo verso il basso. La conversione innaturale da Px a Dp indica già che il codice presenta un problema.

Il problema di questo esempio è che il codice non raggiunge il layout "finale" in un singolo frame. Il codice si basa su più frame, il che comporta un lavoro non necessario e fa sì che la UI salti sullo schermo per l'utente.

Composizione del primo frame

Durante la fase di composizione del primo frame, imageHeightPx è inizialmente 0. Di conseguenza, il codice fornisce al testo Modifier.padding(top = 0). La fase di layout successiva richiama il callback del modificatore onSizeChanged, che aggiorna imageHeightPx all'altezza effettiva dell'immagine. Compose pianifica quindi una ricomposizione per il frame successivo. Tuttavia, durante la fase di disegno corrente, il testo viene sottoposto a rendering con un padding di 0, poiché il valore imageHeightPx aggiornato non è ancora stato applicato.

Composizione del secondo frame

Compose avvia il secondo frame, attivato dalla modifica del valore di imageHeightPx. Nella fase di composizione di questo frame, lo stato viene letto all'interno del blocco di contenuti Box. Al testo viene ora fornito un padding che corrisponde esattamente all'altezza dell'immagine. Durante la fase di layout, imageHeightPx viene impostato di nuovo; tuttavia, non viene pianificata alcuna ricomposizione perché il valore rimane coerente.

Punto chiave :alla fine, il testo viene sottoposto al padding scelto, ma non è ottimale spendere un frame aggiuntivo per passare il valore del padding a una fase diversa e verrà prodotto un frame con contenuti sovrapposti.

Questo esempio può sembrare forzato, ma fai attenzione a questo pattern generale:

• Modifier.onSizeChanged(), onGloballyPositioned() o altre operazioni di layout
• Aggiorna uno stato
• Utilizza questo stato come input per un modificatore di layout (padding(), height() o simili)
• Potenzialmente ripeti

La correzione per l'esempio precedente consiste nell'utilizzare le primitive di layout appropriate. L'esempio precedente può essere implementato con un Column(), ma potresti avere un esempio più complesso che richiede qualcosa di personalizzato, che richiederà la scrittura di un layout personalizzato. Per ulteriori informazioni, consulta la guida Layout personalizzati.

Il principio generale è di avere un'unica fonte di verità per più elementi della UI che devono essere misurati e posizionati l'uno rispetto all'altro. L'utilizzo di una primitiva di layout appropriata o la creazione di un layout personalizzato significa che l'elemento principale condiviso minimo funge da fonte di verità che può coordinare la relazione tra più elementi. L'introduzione di uno stato dinamico viola questo principio.