Diagnostica problemas de estabilidad

Si tienes problemas de rendimiento debido a problemas excesiva, debes depurar la estabilidad de tu app. Esta guía describe varios métodos para hacerlo.

Inspector de diseño

El Inspector de diseño de Android Studio te permite ver qué elementos componibles recomponer en tu app. Muestra el recuento de la cantidad de veces que Compose recompone o se omite un componente.

La recomposición y omite los recuentos en el Inspector de diseño

Informes del compilador de Compose

El compilador de Compose puede generar los resultados de su inferencia de estabilidad para para cada inspección. Con este resultado, puedes determinar cuáles de tus elementos componibles son que se pueden omitir y cuáles no. En las siguientes subsecciones, se resume cómo usar estas informes, pero para obtener información más detallada consulta la página documentación.

Configuración

Los informes del compilador de Compose no están habilitados de forma predeterminada. Puedes activarlos con una marca de compilador. La configuración exacta varía según tu pero, en el caso de los proyectos que usan el complemento de Gradle del compilador de Compose, puedes agrega lo siguiente en cada archivo build.gradle de los módulos.

  android { ... }

  composeCompiler {
    reportsDestination = layout.buildDirectory.dir("compose_compiler")
    metricsDestination = layout.buildDirectory.dir("compose_compiler")
  }

Los informes del compilador de Compose ahora se generarán cuando compiles tu proyecto.

Ejemplo de resultado:

reportsDestination genera tres archivos. Los siguientes son ejemplos de resultados de JetSnack.

  • <modulename>-classes.txt: Un informe sobre la estabilidad de las clases en este módulo. Muestra.
  • <modulename>-composables.txt: Es un informe sobre cómo se pueden reiniciar y los elementos componibles que se pueden omitir están en el módulo. Muestra.
  • <modulename>-composables.csv: Es una versión CSV del informe de elementos componibles. que puedes importar a una hoja de cálculo o procesar con una secuencia de comandos. Ejemplo

Informe de elementos componibles

El archivo composables.txt detalla cada función de componibilidad para el archivo especificado módulo, incluida la estabilidad de sus parámetros y si son es reiniciable o se puede omitir. El siguiente es un ejemplo hipotético JetSnack:

restartable skippable scheme("[androidx.compose.ui.UiComposable]") fun SnackCollection(
  stable snackCollection: SnackCollection
  stable onSnackClick: Function1<Long, Unit>
  stable modifier: Modifier? = @static Companion
  stable index: Int = @static 0
  stable highlight: Boolean = @static true
)

Este elemento SnackCollection componible se puede reiniciar por completo, se puede omitir y sea estable. Por lo general, es preferible, aunque no es obligatorio.

Por otro lado, veamos otro ejemplo.

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

El elemento HighlightedSnacks componible no se puede omitir. Compose nunca lo omite. durante la recomposición. Esto ocurre incluso si no cambió ninguno de sus parámetros. Esto se debe al parámetro unstable, snacks.

Informe de clases

El archivo classes.txt contiene un informe similar sobre las clases de la clase módulo. El siguiente fragmento es el resultado de la clase Snack:

unstable class Snack {
  stable val id: Long
  stable val name: String
  stable val imageUrl: String
  stable val price: Long
  stable val tagline: String
  unstable val tags: Set<String>
  <runtime stability> = Unstable
}

A modo de referencia, la siguiente es la definición de Snack:

data class Snack(
    val id: Long,
    val name: String,
    val imageUrl: String,
    val price: Long,
    val tagline: String = "",
    val tags: Set<String> = emptySet()
)

El compilador de Compose marcó Snack como inestable. Esto se debe a que el tipo de el parámetro tags es Set<String>. Este es un tipo inmutable, dado que no es un MutableSet. Sin embargo, las clases de colección estándar, como Set, List, y Map son, en última instancia, interfaces. Como tal, la implementación subyacente puede aun así pueden ser mutables.

Por ejemplo, puedes escribir val set: Set<String> = mutableSetOf("foo"). El variable es constante y su tipo declarado no es mutable, pero su implementación aún es mutable. El compilador de Compose no puede estar seguro de la de la clase, ya que solo ve el tipo declarado. Por lo tanto, marca tags como inestable.