Recomposiciones descontroladas: estabilidad, lambdas y lecturas altas

Hay una ironía incómoda en la relación entre MVI y Compose. La arquitectura que mejor encaja con un modelo declarativo —un objeto de estado inmutable que describe la pantalla entera— es también la que más fácilmente produce el peor patrón de recomposición posible, porque concentra en un solo valor toda la información y hace trivial la tentación de leerlo entero en la raíz. Cuando eso ocurre, cada tecla pulsada en un buscador cambia la identidad del objeto completo y con ella la de todo lo que dependía de él, de modo que la pantalla entera se reconstruye para reflejar una letra. El fallo no es de Compose, que se comporta exactamente como prometió, ni de MVI, que no obliga a nada de esto. Es de la traducción entre ambos, y esa traducción es un contrato que se puede cumplir o incumplir de tres maneras distintas y con tres costes muy diferentes.

Medir antes de tocar

La optimización de recomposiciones es el terreno donde la intuición falla con más regularidad, porque el coste real no está donde está el código sospechoso sino donde está el trabajo caro, y ambos rara vez coinciden. Un componente que se recompone cien veces por segundo y solo escribe un texto es irrelevante; otro que se recompone tres veces y decodifica una imagen o reconstruye una lista larga puede costar una animación entera. Por eso la primera acción no es cambiar nada sino obtener dos medidas.

La primera son los informes de estabilidad del compilador, que se activan con una opción de compilación y producen, por cada función componible, si es reiniciable y si es omitible, y por cada clase, si el compilador la considera estable. Ese informe es la única fuente autorizada sobre la estabilidad de tus tipos: sustituye la conjetura por un dato, y suele revelar que la clase que todo el mundo daba por estable no lo es por culpa de un campo anidado que nadie miraba. La segunda medida son los contadores de recomposición del inspector de diseño, que enseñan qué partes del árbol se reconstruyen y cuáles se omitieron, es decir, la consecuencia observable de lo que el informe describe en abstracto.

Hay un tercer dato que ordena los dos anteriores y que se olvida sistemáticamente: en qué fase se paga el coste. Compose ejecuta tres fases por fotograma —componer, medir y colocar, y dibujar— y una invalidación no siempre alcanza a las tres. Un cambio que solo afecta al dibujo es órdenes de magnitud más barato que uno que obliga a recomponer y volver a medir todo un árbol. Por eso la pregunta útil no es cuántas recomposiciones hay, sino cuánta de la cascada se podría haber detenido antes: mover una lectura de la fase de composición a la de dibujo suele ganar más que cualquier cantidad de memorización dentro de la composición.

La lectura demasiado alta

De las tres causas, esta es la más cara y la única específica de la combinación entre MVI y Compose, así que va primero. Ocurre cuando un componente alto del árbol lee el objeto de estado completo y va repartiendo campos hacia abajo. Como leer un valor en Compose establece una dependencia, ese componente queda suscrito a cualquier cambio del estado, y como todo lo demás cuelga de él, la invalidación se propaga hacia abajo por defecto y solo se detiene donde el mecanismo de omisión pueda demostrar que los argumentos no cambiaron.

// Mal: la raiz lee todo el estado y cualquier campo invalida el arbol entero
@Composable
fun PerfilPantalla(vm: PerfilViewModel) {
    val estado by vm.container.stateFlow.collectAsStateWithLifecycle()
    Cabecera(estado)          // recibe el estado completo
    Muro(estado)              // tambien
    Filtros(estado)           // tambien
}

Hay dos correcciones y no son equivalentes. La primera y casi siempre suficiente consiste en pasar hacia abajo solo lo que cada hijo necesita, de modo que un cambio en el texto de búsqueda no altere los argumentos de la cabecera y esta pueda omitirse. Esta corrección tiene una consecuencia de diseño que conviene subrayar: es exactamente el mismo trabajo que la partición del estado en subestados cohesivos, visto desde el otro extremo del sistema. Un estado bien partido produce árboles de composición bien aislados casi sin esfuerzo adicional.

La segunda corrección, para el caso en el que un valor cambia con frecuencia altísima —la posición de un desplazamiento, el progreso de una animación, la coordenada de un gesto—, consiste en diferir la lectura pasando una función que devuelve el valor en lugar del valor mismo. Así la dependencia se establece en el punto exacto donde se usa, que suele ser la fase de dibujo, y ni siquiera se recompone: se vuelve a dibujar, que es entre uno y dos órdenes de magnitud más barato.

// Cada hijo recibe lo suyo, y el valor de altisima frecuencia se difiere
@Composable
fun PerfilPantalla(vm: PerfilViewModel) {
    val estado by vm.container.stateFlow.collectAsStateWithLifecycle()
    val listo = estado as? PerfilState.Listo ?: return
    Cabecera(listo.cabecera)
    Muro(listo.muro, desplazamiento = { scroll.value })
}

La segunda corrección tiene un requisito que la hace fácil de aplicar mal: solo funciona si la función diferida se consume dentro de un bloque que se ejecuta en una fase posterior. Pasar una función y llamarla inmediatamente en el cuerpo del componible no difiere nada, porque la lectura vuelve a ocurrir durante la composición y la dependencia se establece igual. La diferencia entre las dos versiones no está en la firma sino en dónde se invoca, lo que la convierte en una de las pocas optimizaciones cuyo efecto no se puede verificar leyendo solo la declaración.

flowchart TB
E[Cambia un campo del estado]
E --> R[La raiz leyo el estado completo]
R --> I[Se invalida la raiz entera]
I --> H1[Cabecera se recompone sin necesidad]
I --> H2[Muro se recompone sin necesidad]
E --> P[Cada hijo recibe solo lo suyo]
P --> O1[Cabecera se omite]
P --> O2[Muro se omite]
P --> O3[Filtros se recompone y es correcto]
style I fill:#f38ba8,color:#11111b
style P fill:#a6e3a1,color:#11111b

Estabilidad y lambdas

La segunda causa es la inestabilidad de tipos. Para omitir la ejecución de un componible, el compilador necesita poder comparar sus argumentos, y solo se atreve a hacerlo si puede demostrar que un valor igual implica un contenido igual que no cambiará por debajo. Los tipos que no ofrecen esa garantía se consideran inestables y bloquean la omisión. El caso que más sorprende es el de las colecciones de la biblioteca estándar: una List es una interfaz de solo lectura, no una garantía de inmutabilidad, y nada impide que la implementación concreta sea mutable, así que el compilador no puede darla por estable.

// El compilador no puede garantizar la estabilidad de una interfaz de solo lectura
data class MuroState(val posts: List<Post>)

// Alternativas: coleccion persistente o promesa explicita del autor
data class MuroOk(val posts: ImmutableList<Post>)

@Immutable
data class MuroPrometido(val posts: List<Post>)

La anotación de inmutabilidad es una promesa del programador, no una comprobación, y por tanto traslada la responsabilidad: si mientes, el compilador omite trabajo que debía hacer y la pantalla deja de reflejar los datos. Las colecciones persistentes, en cambio, garantizan por su tipo lo que la anotación solo declara. La otra fuente clásica de inestabilidad son las clases definidas en módulos que no pasan por el compilador de Compose, típicamente los modelos de dominio de un módulo puro, y ahí la salida limpia es un fichero de configuración de estabilidad en lugar de contaminar el dominio con anotaciones de interfaz.

El modo de omisión fuerte cambió el panorama sin cerrarlo, y conviene tener claro qué hizo exactamente. Hizo dos cosas: memoriza automáticamente las lambdas que se pasan a los componibles, con lo que la tercera causa —lambdas con identidad nueva en cada composición— dejó de ser el problema cotidiano que fue durante años; y permite omitir componibles con parámetros inestables comparándolos por identidad de instancia en lugar de por igualdad. Lo que no hizo fue volver irrelevante la estabilidad: la comparación por identidad solo salva el caso en el que la instancia es literalmente la misma, de modo que un objeto reconstruido con copy y contenido idéntico sigue provocando recomposición. Y sobre todo, no toca en absoluto la primera causa, que es la lectura demasiado alta.

Queda por tanto un residuo de casos donde las lambdas siguen importando, y conviene conocerlo para no dar el tema por cerrado. El más frecuente aparece dentro de listas: una lambda construida en cada elemento capturando el índice o el identificador de ese elemento tiene una identidad distinta por elemento y por composición, y la memorización automática no puede unificarla porque las capturas son genuinamente diferentes. La corrección clásica consiste en subir la lambda un nivel y pasar hacia abajo el identificador, de modo que el elemento reciba una función estable y el dato que la particulariza.

// La lambda se construye una vez y el identificador viaja como argumento
LazyColumn {
    items(posts, key = { it.id }) { post ->
        PostFila(post = post, onPulsar = alPulsarPost)
    }
}

Los falsos remedios

Hay tres correcciones populares que empeoran lo que pretenden arreglar. La primera es memorizar todo por sistema: cada memorización ocupa espacio en la composición y ejecuta comparaciones de claves, de modo que aplicada a valores baratos añade coste neto. Memorizar tiene sentido cuando el cálculo evitado cuesta más que la comparación, y para una concatenación de dos cadenas no lo cuesta.

La segunda es usar una clave para forzar la reconstrucción de una subárea. Funciona en el sentido de que elimina el estado obsoleto, y por eso parece resolver el problema, pero lo hace descartando y reconstruyendo toda la subcomposición junto con su estado recordado y sus animaciones en curso. Es la operación más cara del sistema, empleada como remedio contra el exceso de trabajo. La tercera es derivar un valor caro en cada recomposición en vez de derivarlo del estado con una derivación memorizada, que es el patrón concreto donde ordenar o filtrar una lista larga se repite decenas de veces por segundo sin que el resultado cambie.

// Se recalcula en cada recomposicion aunque la lista no haya cambiado
val visibles = posts.filter { it.publicado }.sortedByDescending { it.fecha }

// Solo se recalcula cuando cambia aquello de lo que depende
val visibles by remember(posts) {
    derivedStateOf { posts.filter { it.publicado }.sortedByDescending { it.fecha } }
}

Hay un cuarto falso remedio, más raro y más dañino que los tres anteriores, que consiste en mover la derivación al reductor para evitar el cálculo en la interfaz. Parece razonable y contradice la primera lección de este nivel: introduce estado derivado almacenado en el objeto de estado, con toda la carga de sincronización que eso implica, para ahorrar un cálculo que se podía memorizar en el sitio donde se usa. La regla que resuelve el conflicto aparente es simple: si la derivación depende solo de datos del estado, memorízala en la vista; si depende además de una regla de negocio que la vista no debería conocer, entonces sí pertenece al reductor, y en ese caso el campo resultante no es un derivado sino un hecho.