avoiding-subcomposition-pitfalls

BoxWithConstraints is built on SubcomposeLayout, which composes its content during the measure phase rather than the parent's composition pass. Every new Constraints value, such as rotation or IME changes, re-runs that subcomposition.

Use Modifier.onSizeChanged to receive the measured size in the layout phase, or Modifier.layout for custom measurement. Both avoid spinning up a subcomposition just to read maxWidth or maxHeight.

No. Each item subcomposes during the lazy list's measure pass, causing scroll jank. Hoist a single BoxWithConstraints to the list root and pass the resolved value down as a stable parameter.

Keep it when child composition genuinely depends on measured values like parent constraints or sibling sizes, such as tab strips or anchor-aligned popovers. Tune it with SubcomposeSlotReusePolicy and precompose instead of removing it.

Yes. Each Scaffold is a SubcomposeLayout with its own measure-phase composition, so nesting multiplies that cost on every constraint change. Use the topBar, bottomBar, snackbarHost, and FAB slots of a single Scaffold instead.

Record a Perfetto system trace with androidx.compose.runtime:runtime-tracing and confirm Compose:recompose and Compose:applyChanges no longer fire on every measurement. Layout Inspector recomposition counts should stay flat across constraint changes.