Phases de Jetpack Compose

Comme la plupart des autres kits d'outils de l'interface utilisateur, Compose affiche un frame à l'aide de plusieurs phases distinctes. Par exemple, le système de vues Android comporte trois phases principales : la mesure, la mise en page et le dessin. Compose est très similaire, mais inclut une phase supplémentaire clé appelée composition au début.

La documentation Compose décrit la composition dans les articles Raisonnement dans Compose et États et Jetpack Compose.

Les trois phases d'un frame

Compose compte trois phases principales :

1. Composition : quels éléments d'interface utilisateur afficher. Compose exécute des fonctions modulables et crée une description de votre UI.
2. Mise en page : où positionner les éléments d'interface utilisateur. Cette phase comprend deux étapes : la mesure et le positionnement. Les éléments de mise en page se mesurent et se placent eux-mêmes ainsi que tous les éléments enfants en coordonnées 2D, pour chaque nœud de l'arborescence de mise en page.
3. Dessin : comment effectuer le rendu de l'interface utilisateur. Les éléments de l'interface utilisateur apparaissent dans un canevas, habituellement l'écran d'un d'appareil.

Figure 1. Les trois phases dans lesquelles Compose transforme les données en interface utilisateur.

L'ordre de ces phases est généralement le même, ce qui permet aux données de circuler dans un sens (de la composition à la mise en page, en passant par le dessin) afin de générer un frame (également appelé flux de données unidirectionnel). BoxWithConstraints, LazyColumn et LazyRow sont des exceptions notables, où la composition de leurs enfants dépend de la phase de mise en page du parent.

Conceptuellement, chacune de ces phases se produit pour chaque frame. Toutefois, pour optimiser les performances, Compose évite de répéter une tâche qui calculerait les mêmes résultats à partir des mêmes entrées dans toutes ces phases. Compose ignore l'exécution d'une fonction composable si un ancien résultat peut être réutilisé, et l'interface utilisateur de Compose ne recommence pas la mise en page ou le dessin de toute l'arborescence s'il n'y a pas lieu de le faire. Il ne fournit que les efforts minimums nécessaires pour mettre à jour l'interface utilisateur. Cette optimisation est possible, car Compose suit les lectures d'état au cours des différentes phases.

Comprendre les phases

Cette section décrit plus en détail comment les trois phases de Compose sont exécutées pour les composables.

Composition

Lors de la phase de composition, l'environnement d'exécution Compose exécute des fonctions modulables et génère une structure arborescente qui représente votre interface utilisateur. Cette arborescence d'interface utilisateur est constituée de nœuds de mise en page qui contiennent toutes les informations nécessaires pour les phases suivantes, comme illustré dans la vidéo suivante :

Figure 2. L'arborescence représentant votre interface utilisateur créée lors de la phase de composition.

Une sous-section du code et de l'arborescence de l'interface utilisateur se présente comme suit :

Figure 3. Une sous-section d'une arborescence d'interface utilisateur avec le code correspondant.

Dans ces exemples, chaque fonction composable du code correspond à un seul nœud de mise en page dans l'arborescence de l'interface utilisateur. Dans des exemples plus complexes, les composables peuvent contenir une logique et un flux de contrôle, et produire une arborescence différente en fonction des états.

Mise en page

Lors de la phase de mise en page, Compose utilise l'arborescence d'interface utilisateur produite lors de la phase de composition comme entrée. La collection de nœuds de mise en page contient toutes les informations nécessaires pour déterminer la taille et l'emplacement de chaque nœud dans l'espace 2D.

Figure 4. La mesure et le positionnement de chaque nœud de mise en page dans l'arborescence de l'interface utilisateur lors de la phase de mise en page.

Lors de la phase de mise en page, l'arborescence est parcourue à l'aide de l'algorithme en trois étapes suivant :

1. Mesurer les enfants : un nœud mesure ses enfants, le cas échéant.
2. Déterminer sa propre taille : en fonction de ces mesures, un nœud détermine sa propre taille.
3. Placer les enfants : chaque nœud enfant est placé par rapport à la propre position d'un nœud.

À la fin de cette phase, chaque nœud de mise en page comporte les éléments suivants :

• Une largeur et une hauteur attribuées
• Des coordonnées x, y où il doit être dessiné

Rappelons l'arborescence de l'interface utilisateur de la section précédente :

Pour cette arborescence, l'algorithme fonctionne comme suit :

1. La Row mesure ses enfants, Image et Column.
2. L'Image est mesurée. Elle n'a pas d'enfants. Elle détermine donc sa propre taille et la signale à la Row.
3. La Column est ensuite mesurée. Elle mesure d'abord ses propres enfants (deux composables Text).
4. Le premier Text est mesuré. Il n'a pas d'enfants. Il détermine donc sa propre taille et la signale à la Column.
   1. Le deuxième Text est mesuré. Il n'a pas d'enfants. Il détermine donc sa propre taille et la signale à la Column.
5. La Column utilise les mesures des enfants pour déterminer sa propre taille. Elle utilise la largeur maximale de l'enfant et la somme de la hauteur de ses enfants.
6. La Column place ses enfants par rapport à elle-même, en les plaçant les uns sous les autres verticalement.
7. La Row utilise les mesures des enfants pour déterminer sa propre taille. Elle utilise la hauteur maximale de l'enfant et la somme des largeurs de ses enfants. Elle place ensuite ses enfants.

Notez que chaque nœud n'a été visité qu'une seule fois. L'environnement d'exécution Compose ne nécessite qu'un seul passage dans l'arborescence de l'interface utilisateur pour mesurer et placer tous les nœuds, ce qui améliore les performances. Lorsque le nombre de nœuds dans l'arborescence augmente, le temps passé à la parcourir augmente de manière linéaire. En revanche, si chaque nœud était visité plusieurs fois, le temps de parcours augmenterait de manière exponentielle.

Dessin

Lors de la phase de dessin, l'arborescence est à nouveau parcourue de haut en bas, et chaque nœud se dessine à l'écran à son tour.

Figure 5. La phase de dessin dessine les pixels à l'écran.

En utilisant l'exemple précédent, le contenu de l'arborescence est dessiné de la manière suivante :

1. La Row dessine tout contenu qu'elle peut contenir, comme une couleur d'arrière-plan.
2. L'Image se dessine.
3. La Column se dessine.
4. Les premier et deuxième Text se dessinent respectivement.

Figure 6. Une arborescence d'interface utilisateur et sa représentation dessinée.

Lectures d'état

Lorsque vous lisez le value d'un snapshot state lors de l'une des phases listées précédemment, Compose suit automatiquement ce qu'il faisait lorsqu'il a lu le value. Ce suivi permet à Compose de réexécuter le lecteur lorsque la value de l'état change. Il constitue la base de l'observabilité de l'état dans Compose.

Vous créez généralement un état à l'aide de mutableStateOf(), puis vous y accédez de l'une des deux manières suivantes : directement via la propriété value ou via un délégué de propriété Kotlin. Pour en savoir plus à ce sujet, consultez la section État dans les composables. Dans ce guide, une "lecture d'état" fait référence à l'une de ces méthodes d'accès équivalentes.

// 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

En arrière-plan du délégué de propriété, les fonctions "getter" et "setter" permettent d'accéder à la value de l'état et de la mettre à jour. Ces fonctions ne sont appelées que lorsque vous référencez la propriété en tant que valeur, et non lorsqu'elle est créée. C'est pourquoi les deux méthodes décrites précédemment sont équivalentes.

Chaque bloc de code pouvant être réexécuté lorsqu'un état de lecture est modifié correspond à un champ d'application de redémarrage. Compose effectue le suivi des changements de value d'état et redémarre les champs d'application en plusieurs phases.

Lectures d'état par phases

Comme indiqué précédemment, Compose comporte trois phases principales, et Compose suit l'état lu dans chacune d'elles. Cela permet à Compose de n'informer que les phases spécifiques qui doivent effectuer un travail pour chaque élément affecté de votre interface utilisateur.

Remarque : L'endroit où une instance d'état est créée et stockée a peu d'incidence sur les phases. Seuls le moment et l'endroit où la value d'un état est lue sont importants.

Les sections suivantes décrivent chaque phase et ce qui se passe lorsqu'une valeur d'état y est lue.

Phase 1: Composition

Les lectures d'état dans une fonction @Composable ou un bloc lambda concernent la composition et potentiellement les phases suivantes. Lorsque la value de l'état change, le recomposeur programme de nouveau l'exécution de toutes les fonctions modulables qui lisent cette value. Notez que l'environnement d'exécution peut ignorer une partie ou la totalité des fonctions modulables si les entrées n'ont pas changé. Pour en savoir plus, consultez la section Ignorer si les entrées n'ont pas changé.

Selon le résultat de la composition, l'interface utilisateur de Compose exécute les phases de mise en page et de dessin. Elle peut ignorer ces phases si le contenu reste le même, et que la taille et la mise en page ne changent pas.

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

Phase 2 : Mise en page

La phase de mise en page comprend deux étapes : la mesure et le positionnement. L'étape de mesure exécute le lambda de mesure transmis au Layout composable, la MeasureScope.measure méthode de l'interface LayoutModifier, entre autres. L'étape de positionnement exécute le bloc de positionnement de la fonction layout, le bloc lambda de Modifier.offset { … } et des fonctions similaires.

Les lectures d'état lors de chacune de ces étapes concernent la mise en page et, potentiellement, la phase de dessin. Lorsque l'état value change, l'interface utilisateur de Compose planifie la phase de mise en page. Elle exécute également la phase de dessin si la taille ou la position a changé.

Point clé : L'étape de mesure et l'étape de positionnement impliquent des champs d'application de redémarrage distincts. Autrement dit, les lectures d'état dans l'étape de positionnement n'appellent pas l'étape de mesure avant cela. Cependant, ces deux étapes sont souvent liées, de sorte qu'un état lu dans l'étape de positionnement peut avoir une incidence sur les autres champs d'application de redémarrage appartenant à l'étape de mesure.

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

Phase 3 : Dessin

Les lectures d'état pendant le dessin concernent la phase de dessin. Canvas(), Modifier.drawBehind et Modifier.drawWithContent sont des exemples courants. Lorsque la value de l'état change, l'interface utilisateur de Compose n'exécute que la phase de dessin.

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

Optimiser les lectures d'état

Étant donné que Compose effectue le suivi des lectures d'état localisé, la quantité de travail effectuée peut être réduite en lisant chaque état dans une phase appropriée.

Prenons un exemple. Cet exemple comporte une Image() qui utilise le modificateur de décalage pour décaler sa position finale de mise en page, ce qui entraîne un effet de parallaxe lorsque l'utilisateur fait défiler l'écran.

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

Ce code fonctionne, mais génère des performances non optimales. Tel qu'il est écrit, le code lit la value de l'état firstVisibleItemScrollOffset et la transmet à la Modifier.offset(offset: Dp) fonction. La value de firstVisibleItemScrollOffset change à mesure que l'utilisateur fait défiler l'écran. Comme vous l'avez appris, Compose suit toutes les lectures d'état afin de pouvoir relancer (rappeler) le code de lecture qui, dans cet exemple, correspond au contenu de Box.

Il s'agit d'un exemple de lecture d'un état pendant la phase de composition. Ce n'est pas nécessairement une mauvaise chose. En réalité, c'est là la base de la recomposition : permettre les modifications de données pour émettre une nouvelle UI.

Point clé : Cet exemple n'est pas optimal, car chaque événement de défilement entraîne la réévaluation de l'intégralité du contenu composable, ainsi que sa mesure, sa mise en page et son dessin. La phase Compose est déclenchée à chaque défilement, même si le contenu affiché ne change pas. Seule sa position change. Vous pouvez optimiser la lecture de l'état pour ne déclencher que la phase de mise en page.

Décalage avec lambda

Une autre version du modificateur de décalage est disponible: Modifier.offset(offset: Density.() -> IntOffset).

Cette version utilise un paramètre lambda, où le décalage obtenu est renvoyé par le bloc lambda. Mettez à jour le code pour l'utiliser :

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

Pourquoi est-il plus performant ? Le bloc lambda que vous fournissez au modificateur est appelé pendant la phase de mise en page (plus spécifiquement lors de l'étape de positionnement pendant la phase de mise en page). Autrement dit, l'état firstVisibleItemScrollOffset n'est plus lu pendant la composition. Étant donné que Compose suit la lecture de l'état, cette modification signifie que si la value de firstVisibleItemScrollOffset change, Compose doit uniquement redémarrer les phases de mise en page et de dessin.

Remarque : Vous vous demandez peut-être si l'utilisation d'un paramètre lambda peut entraîner des coûts supplémentaires par rapport à une valeur. La réponse est oui. Cependant, dans ce cas, l'avantage de limiter la lecture de l'état à la phase de mise en page l'emporte sur le coût. La value de firstVisibleItemScrollOffset change à chaque frame pendant le défilement. En reportant la lecture de l'état à la phase de mise en page, vous pouvez éviter de tout recomposer.

Certes, il est souvent absolument nécessaire de lire les états dans la phase de composition. Toutefois, il reste possible de réduire le nombre de recompositions à leur minimum en filtrant les changements d'état. Pour en savoir plus à ce sujet, consultez la page derivedStateOf : convertir un ou plusieurs objets d'état en un autre état.

Recomposition en boucle (dépendance de phase cyclique)

Ce guide a précédemment mentionné que les phases de Compose sont toujours appelées dans le même ordre et qu'il n'est pas possible de revenir en arrière dans le même frame. Toutefois, cela n'empêche pas les applications de réaliser des compositions en boucle sur différents frames. Prenons l'exemple suivant :

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

Cet exemple implémente une colonne verticale, avec l'image en haut, puis le texte en dessous. Il utilise Modifier.onSizeChanged() pour obtenir la taille résolue de l'image, puis utilise Modifier.padding() au niveau du texte pour le décaler vers le bas. La conversion non naturelle de Px en Dp indique déjà que le code présente un problème.

Le problème avec cet exemple est que le code ne parvient pas à la mise en page "finale" dans un seul frame. Le code repose sur l'affichage de plusieurs frames, ce qui entraîne un travail inutile et l'instabilité de l'interface utilisateur à l'écran.

Composition du premier frame

Lors de la phase de composition du premier frame, imageHeightPx est initialement 0. Par conséquent, le code fournit le texte avec Modifier.padding(top = 0). La phase de mise en page suivante appelle le rappel du modificateur onSizeChanged, qui met à jour imageHeightPx avec la hauteur réelle de l'image. Compose planifie ensuite une recomposition pour le frame suivant. Toutefois, lors de la phase de dessin actuelle, le texte est affiché avec une marge intérieure correspondant à 0, car la valeur imageHeightPx mise à jour n'est pas encore reflétée.

Composition du deuxième frame

Compose lance le deuxième frame, déclenché par la modification de la valeur de imageHeightPx. Lors de la phase de composition de ce frame, l'état est lu dans le bloc de contenu Box. Le texte est désormais fourni avec une marge intérieure qui correspond précisément à la hauteur de l'image. Lors de la phase de mise en page, imageHeightPx est à nouveau défini. Toutefois, aucune autre recomposition n'est planifiée, car la valeur reste cohérente.

Point clé : Au final, vous obtenez la marge intérieure choisie sur le texte, mais il n'est pas optimal d'utiliser un frame supplémentaire pour transmettre la valeur de la marge intérieure à une autre phase et de générer ainsi un frame dont le contenu se chevauche.

Cet exemple peut sembler artificiel, mais faites attention à ce schéma général :

• Modifier.onSizeChanged(), onGloballyPositioned() ou autres opérations de mise en page
• Mise à jour d'un état
• Utilisation de cet état comme entrée d'un modificateur de mise en page (padding(), height() ou similaire)
• Répétition potentielle

Pour résoudre le problème ci-dessus, la solution consiste à utiliser les primitives de mise en page appropriées. L'exemple précédent peut être implémenté avec un Column(), mais vous pouvez disposer d'un exemple plus complexe nécessitant une personnalisation et, par conséquent, une mise en page personnalisée. Pour en savoir plus, consultez le guide Mises en page personnalisées.

Le principe général ici est d'avoir une source unique et fiable pour tous les éléments d'interface utilisateur qui doivent être mesurés et placés les uns par rapport aux autres. Si vous utilisez une primitive de mise en page appropriée ou si vous créez une mise en page personnalisée, le parent partagé minimal sert de source fiable pouvant coordonner la relation entre divers éléments. L'introduction d'un état dynamique enfreint ce principe.