¿Qué dispara realmente una recomposición en Jetpack Compose, y cómo evitás las innecesarias?

#Qué es realmente una "recomposición"

Jetpack Compose no vuelve a renderizar todo el árbol de UI cada vez que cambia un estado, como sugiere un modelo mental ingenuo. La unidad de trabajo en Compose es la función composable, y recomponer significa que Compose vuelve a invocar las funciones composable cuyos parámetros ya no puede demostrar que siguen iguales, salteando cualquier función cuyos parámetros comparan como iguales respecto de la llamada anterior. Por eso se dice que Compose hace recomposición "inteligente" o "granular": un cambio de estado tres niveles adentro del árbol puede, en principio, volver a ejecutar solo el composable hoja que lo lee, sin tocar a sus padres, hermanos ni hijos.

El plugin del compilador de Compose es lo que hace esto posible. Reescribe cada función @Composable para que reciba parámetros extra y ocultos — un Composer y una máscara de bits de "cambios" — e inserta lógica de comparación alrededor de cada punto de llamada. Cuando un composable está por ser invocado de nuevo, el runtime chequea si cada uno de sus parámetros es igual al valor que tenía en la llamada anterior. Si todos son iguales y el composable está marcado como "saltable" (algo que depende de la estabilidad, ver más abajo), Compose directamente no llama a la función y reutiliza la UI que ya había emitido.

#Los tres disparadores reales

Dejá de lado por un momento la idea vaga de "cuando cambia el estado" y nombrá los disparadores exactos:

1. Un State<T> que leíste durante la composición cambia. Este es el sistema de Snapshots: mutableStateOf, derivedStateOf, collectAsState y compañía producen todos un State<T>, y leer su .value dentro del cuerpo de un composable lo registra como suscriptor. Cuando el snapshot commitea un valor nuevo, se agenda la recomposición de cada suscriptor.
2. Su padre recompone y lo llama con argumentos distintos — y su función no es saltable para esos argumentos, así que Compose no puede probar que nada cambió.
3. Un CompositionLocal que lee cambia de valor.

Eso es toda la lista. Un detalle clave: que "el padre haya recompuesto" no es, por sí solo, motivo para que un hijo recomponga — si el padre pasa exactamente los mismos valores que la vez anterior, y el hijo es saltable, Compose lo saltea por completo. Este es el detalle que más ingenieros se equivocan, y es exactamente donde viven los bugs de "recomposición innecesaria".

#La estabilidad es lo que hace confiable a un parámetro

Para que Compose pueda saltear una llamada, tiene que confiar en que "igual" realmente significa "igual" para cada tipo de parámetro. El compilador clasifica cada tipo como estable o inestable:

• Estable: todos los tipos primitivos, String, los tipos función (lambdas, sujetos a las reglas de memoización de abajo), y cualquier clase donde todas las propiedades sean val estables — inferido automáticamente para clases de tu propio módulo, o declarado explícitamente con @Stable / @Immutable.
• Inestable: List, Set y Map de Kotlin puro (el compilador no puede probar que una referencia de tipo List no sea en realidad una MutableList mutada desde otro lado, así que nunca confía en las interfaces de colección), cualquier tipo interface (el compilador no tiene idea de qué estabilidad real tiene la implementación concreta, salvo que la afirmes con @Stable), y cualquier clase que exponga una propiedad var.

Un parámetro inestable vuelve no saltable al composable para ese parámetro: Compose se rinde al intentar compararlo y directamente vuelve a llamar a la función. Ese único hecho es la causa número uno de los bugs de "por qué esto recompone todo el tiempo" en código real.

#Un antes / después concreto

// ANTES — recompone mucho más de lo necesario.
@Composable
fun ScreenContainer(viewModel: ItemsViewModel) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

    // Se asigna una List completamente nueva en CADA recomposición de
    // ScreenContainer, aunque los ítems visibles no hayan cambiado en realidad.
    ItemList(
        items = uiState.items.filter { it.isVisible },
        onItemClick = { item -> viewModel.select(item) },
    )
}

@Composable
fun ItemList(items: List<Item>, onItemClick: (Item) -> Unit) {
    // List<Item> es un tipo inestable para el compilador, así que toda esta
    // función es no saltable — recompone cada vez que lo hace su padre,
    // sin importar si `items` es estructuralmente la misma lista.
    LazyColumn {
        items(items, key = { it.id }) { item ->
            ItemRow(item = item, onClick = { onItemClick(item) })
        }
    }
}

data class Item(val id: String, val label: String, val isVisible: Boolean)

Ajustar líneas largas
// DESPUÉS — entradas estables, y el filtro solo se recalcula cuando cambia la lista fuente.
@Immutable
data class Item(val id: String, val label: String, val isVisible: Boolean)

@Composable
fun ScreenContainer(viewModel: ItemsViewModel) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

    // derivedStateOf recalcula en cada cambio de uiState.items, pero quien
    // lo lee más abajo solo recompone cuando el resultado FILTRADO difiere.
    val visibleItems by remember(uiState.items) {
        derivedStateOf { uiState.items.filter { it.isVisible }.toImmutableList() }
    }

    ItemList(items = visibleItems, onItemClick = { item -> viewModel.select(item) })
}

@Composable
fun ItemList(items: ImmutableList<Item>, onItemClick: (Item) -> Unit) {
    // ImmutableList es estable, Item es @Immutable, y la lambda tiene una
    // captura estable — este composable ahora sí es genuinamente saltable.
    LazyColumn {
        items(items, key = { it.id }) { item ->
            ItemRow(item = item, onClick = { onItemClick(item) })
        }
    }
}

#Tabla: qué recompone, y por qué

#El "strong skipping mode" cambia la ecuación

Desde que el compilador de Compose se distribuye junto con Kotlin 2.0, el strong skipping mode viene activado por defecto. Hace que incluso los parámetros de tipo inestable sean saltables, cayendo en una comparación de instancia/equals() en tiempo de ejecución en lugar de negarse directamente a compararlos, y envuelve automáticamente cada parámetro lambda en remember para que ya no tengas que escribirlo a mano. Esto cierra buena parte del consejo histórico de "envolvelo vos mismo en remember" para lambdas — pero no arregla que una List se vuelva a crear con contenido igual pero instancia distinta en cada llamada: la igualdad de instancia sigue diciendo "distinto", así que el costo de una lista genuinamente nueva en cada recomposición sigue siendo real.

#La decisión que toma Compose en cada llamada

🧠 Check your understanding
0/3 · 0/3 answered
1. Un composable recibe un parámetro List<String>. El contenido de la lista nunca cambia, pero el padre asigna una nueva instancia de List con los mismos elementos en cada recomposición. ¿Qué pasa?
Se saltea el composable porque los elementos son igualesCompose lanza una excepción en tiempo de ejecuciónEl composable recompone siempre, porque List se trata como inestableDepende únicamente de si la lista está vacía
2. ¿Qué agrega el 'strong skipping mode' sobre las reglas clásicas de estabilidad?
Hace saltables a los parámetros de tipo inestable mediante un chequeo de igualdad en runtime, y memoiza automáticamente las lambdasDesactiva la recomposición por completo en builds de releaseReemplaza el sistema de Snapshots por un algoritmo de diffingProhíbe usar tipos inestables dentro de composables
3. ¿Cuál de estas NO es una de las tres cosas que disparan la recomposición de un composable?
Su padre recompone y le pasa argumentos distintosCambia un CompositionLocal que leeCambia un State<T> que leeEl usuario hace scroll en la pantalla