Composition: esencia, construcción del árbol de UI en Compose

Qué es Composition en Jetpack Compose

Composition es el proceso de ejecución de funciones Composable, que da como resultado una representación interna de la interfaz de usuario como un árbol de nodos. Cada nodo de este árbol corresponde a un componente integrado (Text, Button, Image) o a una llamada a una función Composable definida por el usuario. Composition no crea directamente objetos View de Android — construye una descripción abstracta que luego es procesada por las fases de Layout y Drawing.

La característica clave de Composition es su reiniciabilidad. Cada función Composable dentro de la composición puede reiniciarse en cualquier momento si sus parámetros de entrada o los objetos de estado que lee han cambiado. El sistema no reinicia todo el árbol — solo aquellas funciones que realmente dependen de los datos modificados.

Técnicamente, Composition se gestiona a través de Composer — un motor interno que el compilador Kotlin incorpora en cada función Composable. Composer escribe información sobre qué funciones fueron llamadas, con qué parámetros y en qué orden en slots (grupos de posición). En llamadas posteriores, Composer compara los nuevos datos con los almacenados y decide si reiniciar.

Cómo se construye el árbol de UI durante Composition

El proceso de construcción del árbol de UI comienza con la llamada al método setContent dentro de una Activity o Fragment. Este método crea la Composition inicial y comienza a ejecutar la función Composable raíz. Luego, cada función Composable anidada añade sus nodos al árbol, formando una jerarquía: Row contiene Text y Button, Column contiene Image y Card, y así sucesivamente.

Cada nodo del árbol recibe una clave de posición única, basada en su posición en el código fuente. Esta clave se utiliza para identificar el nodo durante ejecuciones posteriores. La clave de posición es la razón por la que el orden de llamada de las funciones Composable no debe depender de condiciones: si en una ejecución se llama A -> B, y en la siguiente B -> A, Compose no podrá coincidir los nodos antiguos con los nuevos.

@Composable
fun AppScreen() {
    Column {                     // Nodo Column (posición 1)
        HeaderSection()            // Nodo HeaderSection (posición 2)
        ContentSection()           // Nodo ContentSection (posición 3)
        FooterSection()            // Nodo FooterSection (posición 4)
    }
}

@Composable
fun HeaderSection() {
    Row {                       // Nodo Row (posición 2.1)
        Text("Título")         // Nodo Text (posición 2.2)
        Icon(...)                // Nodo Icon (posición 2.3)
    }
}

En este ejemplo, cada llamada recibe una posición basada en el orden en el código. Column (posición 1) contiene tres nodos hijos (posiciones 2, 3, 4). HeaderSection añade dos nodos hijos más (2.1, 2.2, 2.3). Si en la siguiente recomposición ContentSection se llama antes que HeaderSection, Composer no podrá coincidir correctamente los nodos — de ahí la regla: el orden de las llamadas a funciones Composable debe ser estable.

Gestión del estado en Composition

El estado en Composition se gestiona a través de objetos de tipo State<T>. Cuando una función Composable lee un valor de State mediante una propiedad delegada (by), registra una dependencia de ese State. Cuando el valor cambia, todas las funciones que leyeron este State se marcan para reinicio en la siguiente fase de composición.

El mecanismo de registro de dependencias se llama sistema de snapshots. Cada vez que State cambia, un snapshot registra todos los cambios y notifica a Composer qué funciones dependen de ese State. Es importante entender: leer State dentro de código no Composable (por ejemplo, en una lambda onClick) no registra una dependencia — solo la lectura dentro de una función Composable o en lambdas ejecutadas en el contexto de composición.

El sistema de snapshots funciona transaccionalmente: múltiples cambios de State dentro de un mismo evento se combinan en una transacción, evitando múltiples recomposiciones. Esto es especialmente importante al manejar gestos: un movimiento cambia varios objetos State, pero Compose realiza solo una recomposición.

@Composable
fun StateExample() {
    var text by remember { mutableStateOf("Hello") }
    var isVisible by remember { mutableStateOf(true) }

    Column {
        Text(text)  // registra dependencia de text

        if (isVisible) {  // registra dependencia de isVisible
            TextField(value = text, onValueChange = { text = it })
        }

        Button(onClick = { isVisible = !isVisible }) {
            Text(if (isVisible) "Ocultar" else "Mostrar")
        }
    }
}

Cambiar text provoca la recomposición solo de Column, Text y TextField. Column, Button y la condición isVisible permanecen sin cambios. Este aislamiento de la recomposición es una ventaja clave de Compose sobre los sistemas que redibujan toda la pantalla. Cada función Composable rastrea solo aquellos objetos State que lee directamente.

Composition vs Recomposition: diferencias clave

Composition y Recomposition son dos modos diferentes de ejecutar funciones Composable. Composition ocurre una vez cuando se crea la pantalla: el sistema ejecuta todas las funciones Composable con valores iniciales y construye el árbol de UI inicial. Recomposition ocurre múltiples veces cuando los datos cambian: el sistema reinicia solo aquellas funciones que dependen del estado modificado.

Modo Composition activa todos los nodos del árbol, asigna slots para cada función y registra todos los descendientes. Recomposition funciona de forma selectiva: Compose compara los valores nuevos y antiguos de los parámetros de cada función, y si no han cambiado — la función no se ejecuta (skipping).

Composition y Recomposition difieren en costo. La primera Composition es más cara porque requiere la construcción completa del árbol y la asignación de slots. Recomposition es más barata, especialmente si la mayoría de las funciones son estables — sus parámetros se comparan con equals, y Compose omite su invocación. Para máximo rendimiento, se debe buscar que la mayoría de las recomposiciones afecten al menor número posible de funciones.

CompositionLocal: paso de datos a través del árbol

CompositionLocal es un mecanismo para pasar datos implícitamente a través del árbol de composición. Resuelve el problema cuando un parámetro debe pasarse a través de docenas de funciones Composable anidadas que no lo usan directamente. En lugar de una cadena explícita de parámetros, los datos se establecen en el nivel superior y se leen en cualquier función anidada a través de CompositionLocal.current.

MaterialTheme es el ejemplo más conocido de CompositionLocal. Todos los componentes de Compose leen colores, tipografía y formas a través de MaterialTheme.colorScheme, MaterialTheme.typography, MaterialTheme.shapes, sin recibirlos a través de parámetros. Los desarrolladores pueden crear sus propios CompositionLocal para datos como el usuario actual, configuraciones de localización o configuración de pantalla.

Una limitación importante: CompositionLocal no debe usarse para datos que cambian con frecuencia (posición de desplazamiento, texto en un campo de entrada). Un componente que lee CompositionLocal se reinicia cada vez que el valor cambia, por lo que para datos dinámicos es mejor usar parámetros explícitos o State. CompositionLocal es óptimo para datos de configuración que cambian raramente o nunca.

val LocalUser = compositionLocalOf<User?> { null }

@Composable
fun AppRoot(user: User, content: @Composable () -> Unit) {
    CompositionLocalProvider(LocalUser.provides(user)) {
        content()
    }
}

@Composable
fun UserAvatar() {
    val user = LocalUser.current  // lectura sin parámetro explícito
    AsyncImage(model = user?.avatarUrl, contentDescription = "Avatar")
}

CompositionLocalProvider crea un ámbito dentro del cual LocalUser.current devuelve el valor especificado. UserAvatar lee el usuario sin pasar explícitamente el parámetro a través de funciones intermedias. Esto es especialmente valioso en jerarquías profundas donde los datos solo se necesitan en unos pocos nodos hoja.