SubcomposeLayout y BoxWithConstraints: componer según el espacio

Queda un problema que ni la medida ordinaria ni los intrínsecos resuelven: el caso en que el espacio disponible no determina el tamaño de los composables sino cuáles existen. Una tarjeta que en una ventana estrecha muestra un resumen y en una ancha añade una columna lateral; un indicador que debe situarse bajo la pestaña seleccionada y necesita conocer la posición de todas. Aquí no hay ninguna consulta previa que sirva, porque el árbol todavía no está decidido. La respuesta de Compose es tan drástica como coherente: si la composición debe depender de los Constraints, entonces la composición tiene que ocurrir después de recibirlos, es decir, dentro de la fase de layout. Eso es SubcomposeLayout, y todo lo que cuesta se deduce de esa inversión de orden.

Componer dentro de la medida

En el orden normal, la composición decide qué nodos existen y solo después el layout los mide. La subcomposición invierte ese orden para una parte del árbol: la primitiva recibe una lambda que se ejecuta durante la medida, con los Constraints ya disponibles, y dentro de ella se invoca una función que compone un bloque de contenido y devuelve la lista de medibles resultante. A partir de ahí todo vuelve a ser el protocolo de siempre: se miden, se decide el tamaño y se colocan.

Conviene notar que la inversión es parcial y deliberadamente acotada. No se aplaza la composición de todo el árbol, solo la de las ranuras que declares dentro de ese nodo; el resto de la pantalla sigue componiéndose antes y midiéndose después, como siempre. Esa acotación es la que permite que el mecanismo conviva con el modelo general sin contaminarlo, y también la que hace que el coste sea proporcional al tamaño de lo que metas dentro y no al de la pantalla.

Cada bloque compuesto se identifica con una clave de ranura. Esa clave es lo que permite al sistema saber, entre dos pasadas, que el contenido que estás componiendo ahora es la continuación del que compusiste antes y no algo nuevo, de modo que su estado se conserve. Componer dos veces la misma clave dentro de una misma pasada es un error; usar claves distintas para contenidos que conceptualmente son el mismo produce estado que se pierde en cada medida.

// Medir la cabecera primero y componer el cuerpo sabiendo cuanto queda
SubcomposeLayout(modifier) { constraints ->
    val cabecera = subcompose("cabecera") { Cabecera() }
        .map { it.measure(constraints) }
    val altoCabecera = cabecera.maxOfOrNull { it.height } ?: 0

    val restante = constraints.copy(
        minHeight = 0,
        maxHeight = (constraints.maxHeight - altoCabecera).coerceAtLeast(0),
    )
    val cuerpo = subcompose("cuerpo") { Cuerpo(altoDisponible = restante.maxHeight) }
        .map { it.measure(restante) }

    layout(constraints.maxWidth, constraints.maxHeight) {
        cabecera.forEach { it.placeRelative(0, 0) }
        cuerpo.forEach { it.placeRelative(0, altoCabecera) }
    }
}

Hay una segunda familia de usos que no tiene que ver con el espacio disponible sino con el orden: componer una parte del contenido después de haber medido otra, para poder pasarle como parámetro algo que solo se conoce tras esa medida. Una barra de pestañas que necesita las posiciones y anchuras de todas las pestañas para componer el indicador que se sitúa bajo la seleccionada es el ejemplo canónico, y no tiene solución con la medida ordinaria porque el indicador no es un tamaño distinto: es un composable cuyos parámetros dependen de un resultado de medida.

Sobre este mecanismo está construida buena parte de la biblioteca. Las listas perezosas lo usan para componer únicamente los elementos que caben en la ventana visible, que es su razón de ser: no hay forma de saber cuántos elementos componer sin conocer antes la altura disponible. Ese uso incorpora además la pieza que hace viable el desplazamiento fluido: una política de reutilización de ranuras que, en lugar de descartar la composición de un elemento que sale de pantalla, la guarda desactivada y la reutiliza para el que entra, conservando los nodos y evitando recomponer desde cero.

flowchart TD
A[Fase de composicion normal] --> B[Fase de layout]
B --> C[El nodo con subcomposicion recibe constraints]
C --> D[Compone la ranura aqui dentro, ya en layout]
D --> E[Mide los medibles recien compuestos]
E --> F[Decide tamano y coloca]
F --> G[Fase de dibujo]
style D fill:#f38ba8,color:#11111b
style E fill:#a6e3a1,color:#11111b

BoxWithConstraints es una fachada

El contenedor que expone los Constraints recibidos a su contenido no es una primitiva distinta: es una subcomposición de una sola ranura con un ámbito que traduce los cuatro enteros a unidades independientes de densidad. Todo lo que se diga del mecanismo se aplica íntegro a él, incluida la imposibilidad de responder a consultas intrínsecas que se anticipó en la lección anterior. Que su uso quepa en tres líneas no cambia lo que ocurre por debajo.

BoxWithConstraints {
    // Este cuerpo se compone durante la fase de layout
    if (maxWidth < 480.dp) ColumnaUnica(datos) else DosPaneles(datos)
}

La consecuencia práctica más importante es que el cuerpo se vuelve a componer cada vez que los Constraints cambian. En una pantalla estática eso ocurre una vez y no importa; dentro de algo cuyo tamaño se anima, o dentro del elemento de una lista que se remide al desplazarse, ocurre por fotograma. Y como esa composición sucede dentro de la medida, no se beneficia de las mismas oportunidades de omisión que una composición ordinaria: el trabajo está atrapado en la fase equivocada.

Hay además un efecto sobre la legibilidad que se subestima. Un cuerpo que decide su estructura en función del ancho disponible mezcla en un mismo punto dos decisiones de naturaleza distinta —qué contenido existe y cómo se dispone— y hace que la respuesta a la pregunta qué se ve en esta pantalla dependa de ejecutar el layout. Cuando esa decisión es realmente de producto, es mejor tomarla arriba y una sola vez.

Lo que cuesta de verdad

Conviene desglosar la factura en partidas, porque el resumen habitual de que es caro no ayuda a decidir nada.

Ninguna de esas partidas es prohibitiva por separado, y ese es justamente el motivo de que el abuso pase desapercibido. El patrón que degrada una pantalla no es una subcomposición grande sino muchas pequeñas en un camino caliente: un contenedor que expone Constraints en la raíz de cada elemento de una lista, para tomar una decisión que era idéntica en los cincuenta elementos y que podría haberse tomado una sola vez fuera.

Hay además una consecuencia sobre la observabilidad que complica el diagnóstico. Las herramientas de conteo de recomposiciones atribuyen el trabajo al nodo que lo dispara, y en una subcomposición ese nodo es el contenedor, no el punto del árbol donde alguien escribió una decisión discutible. El resultado es que las cifras señalan al mensajero. Cuando una pantalla con varias subcomposiciones va lenta, el camino corto suele ser desactivarlas una a una y observar, en lugar de intentar leer la atribución.

Merece la pena señalar el contraste con las listas perezosas, que son el uso ejemplar del mecanismo. Ahí la subcomposición no es un atajo sino el núcleo del algoritmo, se hace una vez por contenedor y no una por elemento, y la política de reutilización de ranuras amortiza el coste a lo largo del desplazamiento. La lección no es que la subcomposición sea mala, sino que su precio se justifica cuando compra algo que no se puede comprar de otra forma.

Las alternativas, en orden de preferencia

Antes de recurrir a la subcomposición merece la pena recorrer el catálogo, porque la mayoría de los casos reales caen en alguno de los escalones anteriores.

// Peldano bajo: la decision de producto se toma una vez, cerca de la raiz,
// y baja como un parametro ordinario que cualquiera puede leer.
@Composable
fun Pantalla(clase: WindowWidthSizeClass, datos: Datos) {
    when (clase) {
        WindowWidthSizeClass.COMPACT -> ColumnaUnica(datos)
        else -> DosPaneles(datos)
    }
}

Si la decisión es de estructura de pantalla —una columna o dos paneles, navegación inferior o lateral—, pertenece a la adaptación por clase de tamaño de ventana, que se calcula una vez cerca de la raíz y se propaga como un parámetro corriente. Es una decisión de producto y se lee como tal en el código, sin que ningún nodo tenga que componerse durante la medida.

Si lo que cambia con el espacio disponible no es qué composables existen sino cómo se miden o dónde se colocan, el instrumento correcto es un contenedor propio como el de la tercera lección. Un contenedor de flujo, una rejilla de columnas variables o una disposición que reordena a sus hijos según el ancho no necesitan recomponer nada: los composables son siempre los mismos y solo cambia la política. Esta es, con diferencia, la sustitución que más subcomposiciones innecesarias elimina.

Hay un caso intermedio que merece nombre propio porque se resuelve mal muy a menudo: el de una decisión que sí depende del espacio pero que no cambia en cada fotograma, como elegir cuántas columnas caben en una rejilla. Ahí no hace falta recomponer el contenido en cada medida; basta con que el contenedor propio calcule el número de columnas dentro de su política y coloque en consecuencia a los hijos que ya existen. La diferencia entre las dos soluciones es que una compone contenido nuevo cada vez que el ancho cambia un píxel y la otra solo cambia aritmética.

Si la dependencia es entre hermanos y el subárbol es pequeño, una consulta intrínseca cuesta menos que una subcomposición, aunque solo sirva cuando los hijos ya están decididos. Y si lo que necesitas es reaccionar a un tamaño para animar o para ajustar una posición, hay dos vías que no obligan a componer durante la medida: leer el tamaño dentro del bloque de colocación mediante un modificador con lambda, que recoloca sin remedir, o usar el ámbito de previsualización de layout que permite conocer el tamaño de destino antes de llegar a él y animar hacia ese valor.