Stabilité dans Compose

Compose considère les types comme stables ou instables. Un type est stable s'il est immuable, ou s'il est possible pour Compose de savoir si sa valeur a modifié entre les recompositions. Un type est instable si Compose ne peut pas savoir sa valeur a changé entre les recompositions.

Compose utilise la stabilité des paramètres d'un composable pour déterminer s'il Vous pouvez ignorer le composable lors de la recomposition:

  • Stable parameters (Paramètres stables) : si un composable comporte des paramètres stables qui n'ont pas modifié, Compose l'ignore.
  • Paramètres instables:si un composable comporte des paramètres instables, Compose le recompose toujours lorsqu'il recompose le parent du composant.

Si votre application inclut de nombreux composants inutilement instables que Compose se recompose, vous pouvez rencontrer des problèmes de performances et d'autres problèmes.

Ce document explique comment améliorer la stabilité de votre application les performances et l'expérience utilisateur globale.

Objets immuables

Les extraits de code suivants montrent les principes généraux de la stabilité et la recomposition.

La classe Contact est une classe de données immuable. En effet, tous ses composants Les paramètres sont des primitives définies avec le mot clé val. Une fois que vous avez créé un instance de Contact, vous ne pouvez pas modifier la valeur des propriétés de l'objet. Dans ce cas, vous devez créer un objet.

data class Contact(val name: String, val number: String)

Le composable ContactRow comporte un paramètre de type Contact.

@Composable
fun ContactRow(contact: Contact, modifier: Modifier = Modifier) {
   var selected by remember { mutableStateOf(false) }

   Row(modifier) {
      ContactDetails(contact)
      ToggleButton(selected, onToggled = { selected = !selected })
   }
}

Tenez compte de ce qui se passe lorsque l'utilisateur clique sur le bouton d'activation et sur le bouton Changements d'état de selected:

  1. Compose évalue s'il doit recomposer le code dans ContactRow.
  2. Il voit que le seul argument pour ContactDetails est de type Contact.
  3. Comme Contact est une classe de données immuable, Compose est sûr qu'aucun des les arguments de ContactDetails ont été modifiés.
  4. Par conséquent, Compose ignore ContactDetails et ne la recompose pas.
  5. En revanche, les arguments de ToggleButton ont changé, et Compose recompose ce composant.

Objets modifiables

Bien que l'exemple précédent utilise un objet immuable, il est possible de créer un modifiable. Prenons l'exemple de l'extrait suivant:

data class Contact(var name: String, var number: String)

Comme chaque paramètre de Contact est désormais var, la classe n'est plus immuable. Si ses propriétés étaient modifiées, Compose n'en serait pas informé. En effet, Compose ne suit que les modifications apportées aux objets d'état Compose.

Compose considère cette classe comme instable. Compose n'ignore pas la recomposition instables. Par conséquent, si les Contact ont été définis de cette manière, ContactRow dans l'exemple précédent, se recomposerait chaque fois que selected change.

Implémentation dans Compose

Il peut être utile, mais pas crucial, de considérer le fonctionnement exact de Compose détermine les fonctions à ignorer lors de la recomposition.

Lorsque le compilateur Compose s'exécute sur votre code, il marque chaque fonction et chaque type avec l'un des différents tags. Ces balises reflètent la façon dont Compose gère la fonction ou lors de la recomposition.

Fonctions

Compose peut marquer des fonctions comme skippable ou restartable. Notez qu'il est possible marquer une fonction comme étant une, les deux ou aucune de ces options:

  • Désactivable: si le compilateur marque un composable comme désactivable, Compose peut l'ignorer lors de la recomposition si tous ses arguments sont égaux à leurs les valeurs précédentes.
  • Redémarrable: un composable redémarrable sert de "niveau d'accès". où La recomposition peut commencer. En d'autres termes, la fonction peut être un point entrée indiquant où Compose peut commencer à réexécuter le code pour la recomposition après les changements d'état.

Types

Compose marque les types comme immuables ou stables. Chaque type est un ou le autre:

  • Immuable: Compose marque un type comme immuable si la valeur de son les propriétés ne peuvent jamais changer, et toutes les méthodes font l'objet d'une transparence référentielle.
    • Notez que tous les types primitifs sont marqués comme immuables. Il s'agit notamment String, Int et Float.
  • Stable: indique un type dont les propriétés peuvent être modifiées après la construction. Si et quand ces propriétés changent pendant l'exécution, Compose a connaissance du ces changements.

Stabilité du débogage

Si votre application recompose un composable dont les paramètres n'ont pas changé, commencez par vérifiez sa définition pour les paramètres clairement modifiables. Toujours rédiger recompose un composant si vous transmettez un type avec des propriétés var ou un élément val. utilisant un type instable connu.

Pour des informations détaillées sur le diagnostic de problèmes complexes liés à la stabilité dans Compose, consultez le guide de stabilité du débogage.

Résoudre les problèmes de stabilité

Pour en savoir plus sur la stabilité de votre implémentation Compose, consultez consultez le guide Résoudre les problèmes de stabilité.

Résumé

D'une manière générale, notez les points suivants:

  • Paramètres: Compose détermine la stabilité de chaque paramètre de votre pour déterminer les composables à ignorer la recomposition.
  • Corrections immédiates: si vous remarquez que votre composable n'est pas ignoré et que à l'origine d'un problème de performances, vérifiez les causes évidentes instabilité comme les paramètres var.
  • Rapports du compilateur: vous pouvez utiliser les rapports du compilateur pour déterminer la stabilité déduite de vos classes.
  • Collections: Compose considère toujours les classes de collection comme instables, telles que en tant que List, Set et Map. En effet, nous ne pouvons pas garantir sont immuables. Vous pouvez utiliser les collections immuables Kotlinx à la place ou annoter vos classes en tant que @Immutable ou @Stable.
  • Autres modules: Compose considère toujours leur origine comme instable. modules dans lesquels le compilateur Compose ne s'exécute pas. Encapsuler les classes dans l'UI les classes de modèle, si nécessaire.

Complément d'informations