Corrige problemas de estabilidad

Cuando te encuentres con una clase inestable que cause problemas de rendimiento, debes estabilizarla. En este documento, se describen varias técnicas que puedes usar para hacerlo.

Importante: Antes de corregir los problemas de estabilidad, debes aprender a diagnosticarlos correctamente. Para obtener más información, consulta la guía Diagnostica problemas de estabilidad.

Cómo habilitar la omisión avanzada

Primero, debes intentar habilitar el modo de omisión avanzada. El modo de omisión avanzado permite omitir elementos componibles con parámetros inestables y es el método más sencillo para corregir los problemas de rendimiento causados por la inestabilidad.

Consulta Omisión avanzada para obtener más información.

Haz que la clase sea inmutable

También puedes intentar hacer que una clase inestable sea completamente inmutable.

• Inmutable: Indica un tipo en el que el valor de cualquier propiedad nunca puede cambiar después de que se construye una instancia de ese tipo y todos los métodos son transparentes de forma referencial.
  • Asegúrate de que todas las propiedades de la clase sean val en lugar de var y de tipos inmutables.
  • Los tipos primitivos, como String, Int y Float, siempre son inmutables.
  • Si esto no es posible, debes usar el estado de Compose para cualquier propiedad mutable.
• Estable: Indica un tipo que es mutable. El tiempo de ejecución de Compose no detecta si alguna de las propiedades públicas o el comportamiento de los métodos del tipo producirían resultados diferentes de una invocación anterior.

Importante: En la práctica, esto significa que debes usar el estado de Compose para cualquier propiedad mutable. Por ejemplo, mutableStateOf(...).

Colecciones inmutables

Un motivo común por el que Compose considera que una clase es inestable son las colecciones. Como se indica en la página Diagnostica problemas de estabilidad, el compilador de Compose no puede tener la certeza absoluta de que las colecciones como List, Map y Set son realmente inmutables y, por lo tanto, las marca como inestables.

Para resolver este problema, puedes usar colecciones inmutables. El compilador de Compose incluye compatibilidad con Kotlinx Immutable Collections. Se garantiza que estas colecciones son inmutables, y el compilador de Compose las trata como tales. Esta biblioteca aún está en versión alfa, por lo que es posible que haya cambios en su API.

Considera nuevamente esta clase inestable de la guía Diagnose stability issues:

unstable class Snack {
  …
  unstable val tags: Set<String>
  …
}

Nota: Este fragmento es el resultado del compilador de Compose, no la definición de la clase. Para obtener más información, consulta la guía de estabilidad.

Puedes hacer que tags sea estable con una colección inmutable. En la clase, cambia el tipo de tags a ImmutableSet<String>:

data class Snack{
    …
    val tags: ImmutableSet<String> = persistentSetOf()
    …
}

Después de hacerlo, todos los parámetros de la clase son inmutables y el compilador de Compose marca la clase como estable.

Anota con Stable o Immutable

Una posible ruta para resolver problemas de estabilidad es anotar las clases inestables con @Stable o @Immutable.

Advertencia: Estas anotaciones no hacen que una clase sea inmutable o estable por sí sola. En cambio, cuando usas estas anotaciones, aceptas un contrato con el compilador. Si se anota una clase de forma incorrecta, se puede interrumpir la recomposición.

Anotar una clase anula lo que el compilador inferiría sobre tu clase. Es similar al operador !! en Kotlin. Debes tener mucho cuidado con el uso de estas anotaciones. Anular el comportamiento del compilador podría generar errores imprevistos, como que tu elemento componible no se recomonga cuando esperas que lo haga.

Si es posible hacer que tu clase sea estable sin una anotación, debes esforzarte por lograr la estabilidad de esa manera.

En el siguiente fragmento, se proporciona un ejemplo mínimo de una clase de datos anotada como inmutable:

@Immutable
data class Snack(
…
)

Ya sea que uses la anotación @Immutable o @Stable, el compilador de Compose marca la clase Snack como estable.

Clases anotadas en colecciones

Considera un elemento componible que incluye un parámetro de tipo List<Snack>:

restartable scheme("[androidx.compose.ui.UiComposable]") fun HighlightedSnacks(
  …
  unstable snacks: List<Snack>
  …
)

Incluso si anotas Snack con @Immutable, el compilador de Compose sigue marcando el parámetro snacks en HighlightedSnacks como inestable.

Los parámetros enfrentan el mismo problema que las clases cuando se trata de tipos de colección, el compilador de Compose siempre marca un parámetro de tipo List como inestable, incluso cuando es una colección de tipos estables.

No puedes marcar un parámetro individual como estable ni anotar un elemento componible para que siempre se pueda omitir. Hay varios caminos a seguir.

Existen varias formas de solucionar el problema de las colecciones inestables. En las siguientes subsecciones, se describen estos diferentes enfoques.

Archivo de configuración

Si aceptas cumplir con el contrato de estabilidad en tu base de código, puedes habilitar la opción para considerar las colecciones de Kotlin como estables. Para ello, agrega kotlin.collections.* a tu archivo de configuración de estabilidad.

Colección inmutable

Para garantizar la seguridad de la inmutabilidad en el tiempo de compilación, puedes usar una colección inmutable de kotlinx en lugar de List.

@Composable
private fun HighlightedSnacks(
    …
    snacks: ImmutableList<Snack>,
    …
)

Wrapper

Si no puedes usar una colección inmutable, puedes crear la tuya. Para ello, incluye List en una clase estable anotada. Es probable que un wrapper genérico sea la mejor opción para esto, según tus requisitos.

@Immutable
data class SnackCollection(
   val snacks: List<Snack>
)

Luego, puedes usarlo como el tipo del parámetro en tu elemento componible.

@Composable
private fun HighlightedSnacks(
    index: Int,
    snacks: SnackCollection,
    onSnackClick: (Long) -> Unit,
    modifier: Modifier = Modifier
)

Solución

Después de adoptar cualquiera de estos enfoques, el compilador de Compose ahora marca el elemento HighlightedSnacks componible como skippable y restartable.

restartable skippable scheme("[androidx.compose.ui.UiComposable]") fun HighlightedSnacks(
  stable index: Int
  stable snacks: ImmutableList<Snack>
  stable onSnackClick: Function1<Long, Unit>
  stable modifier: Modifier? = @static Companion
)

Durante la recomposición, Compose ahora puede omitir HighlightedSnacks si ninguna de sus entradas cambió.

Archivo de configuración de estabilidad

A partir de la versión 1.5.5 del compilador de Compose, se puede proporcionar un archivo de configuración de clases para considerar estables en el momento de la compilación. Esto permite considerar como estables las clases que no controlas, como las clases de bibliotecas estándar, como LocalDateTime.

Advertencia: Estas configuraciones no hacen que una clase sea estable por sí sola. En cambio, cuando usas estas configuraciones, aceptas un contrato con el compilador. Configurar una clase de forma incorrecta podría provocar que se interrumpa la recomposición.

El archivo de configuración es un archivo de texto sin formato con una clase por fila. Se admiten comentarios, comodines simples y dobles.

Nota: A diferencia de la configuración de Proguard, los comodines solo pueden indicar el nombre completo del símbolo (paquete, nombre de clase, etcétera). No se admiten coincidencias parciales, como *ClassName o *Model*.

Ejemplo de configuración:

// Consider LocalDateTime stable
java.time.LocalDateTime
// Consider my datalayer stable
com.datalayer.*
// Consider my datalayer and all submodules stable
com.datalayer.**
// Consider my generic type stable based off it's first type parameter only
com.example.GenericClass<*,_>

Para habilitar esta función, pasa la ruta de acceso del archivo de configuración al bloque de opciones composeCompiler de la configuración del complemento de Gradle del compilador de Compose.

composeCompiler {
  stabilityConfigurationFile = rootProject.layout.projectDirectory.file("stability_config.conf")
}

Como el compilador de Compose se ejecuta en cada módulo de tu proyecto por separado, puedes proporcionar diferentes configuraciones a diferentes módulos si es necesario. Como alternativa, puedes tener una configuración en el nivel raíz de tu proyecto y pasar esa ruta de acceso a cada módulo.

Varios módulos

Otro problema común involucra la arquitectura de varios módulos. El compilador de Compose solo puede inferir si una clase es estable si todos los tipos no primitivos a los que hace referencia están marcados de forma explícita como estables o en un módulo que también se compiló con el compilador de Compose.

Si tu capa de datos se encuentra en un módulo independiente de tu capa de IU, que es el enfoque recomendado, es posible que te encuentres con este problema.

Solución

Para solucionar este problema, puedes seguir uno de los siguientes enfoques:

1. Agrega las clases a tu archivo de configuración del compilador.
2. Habilita el compilador de Compose en los módulos de la capa de datos o etiqueta tus clases con @Stable o @Immutable según corresponda.
   • Esto implica agregar una dependencia de Compose a tu capa de datos. Sin embargo, solo es la dependencia del tiempo de ejecución de Compose y no de Compose-UI.
3. Dentro de tu módulo de IU, incluye tus clases de capa de datos en clases de wrapper específicas de la IU.

El mismo problema también se produce cuando se usan bibliotecas externas si no usan el compilador de Compose.

No todos los elementos componibles deben poder omitirse

Cuando trabajes para corregir problemas de estabilidad, no intentes hacer que todos los elementos componibles se puedan omitir. Intentar hacerlo puede generar una optimización prematura que introduzca más problemas de los que soluciona.

Hay muchas situaciones en las que poder omitir no tiene ningún beneficio real y puede generar código difícil de mantener. Por ejemplo:

• Es un elemento componible que no se recompondrá a menudo o no se recompondrá en absoluto.
• Es un elemento componible que, en sí mismo, solo llama a elementos componibles que se pueden omitir.
• Un elemento componible con una gran cantidad de parámetros con implementaciones de equals costosas. En este caso, el costo de verificar si algún parámetro cambió podría superar el costo de una recomposición económica.

Cuando un elemento componible se puede omitir, agrega una pequeña sobrecarga que puede no valer la pena. Incluso puedes anotar tu elemento componible como no reiniciable en los casos en los que determines que ser reiniciable genera más sobrecarga de la que vale la pena.