Use this skill when a Compose tree uses SubcomposeLayout, BoxWithConstraints, or Scaffold and the developer reports extra measure passes, slow first frame, or layout passes running content composition repeatedly. Covers why SubcomposeLayout composes its slots during the measure phase, why BoxWithConstraints forces a subcomposition for every new Constraints value, why nesting Scaffold or BoxWithConstraints multiplies the cost, when a custom Layout or Modifier.layout { } replaces SubcomposeLayout, and how to use SubcomposeLayoutState's slot reuse policy and precompose APIs when SubcomposeLayout is genuinely required. Use when the developer mentions BoxWithConstraints, SubcomposeLayout, Scaffold, "extra measure pass", "double measurement", "first frame slow", "subcompose", or notices that wrapping content in BoxWithConstraints regresses scroll perf inside a LazyColumn.
Installation
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Use this skill when a Compose tree uses SubcomposeLayout, BoxWithConstraints, or Scaffold and the developer reports extra measure passes, slow first frame, or layout passes running content composition repeatedly. Covers why SubcomposeLayout composes its slots during the measure phase, why BoxWithConstraints forces a subcomposition for every new Constraints value, why nesting Scaffold or BoxWithConstraints multiplies the cost, when a custom Layout or Modifier.layout { } replaces SubcomposeLayout, and how to use SubcomposeLayoutState's slot reuse policy and precompose APIs when SubcomposeLayout is genuinely required. Use when the developer mentions BoxWithConstraints, SubcomposeLayout, Scaffold, "extra measure pass", "double measurement", "first frame slow", "subcompose", or notices that wrapping content in BoxWithConstraints regresses scroll perf inside a LazyColumn.
license
Apache-2.0. See LICENSE for complete terms.
metadata
{"author":"Jaewoong Eum (skydoves)","keywords":["jetpack-compose","performance","subcomposelayout","boxwithconstraints","scaffold","layout-phase","measure-pass","subcomposition"]}
Avoiding Subcomposition Pitfalls — Keep Composition Out of the Measure Pass
SubcomposeLayout runs its content's composition during the measure pass, not during the
parent's composition pass. That trades extra layout cost for the ability to use measured constraints
inside the children's composition. BoxWithConstraints, material3.Scaffold, and the lazy layouts
are all built on top of it, so the cost is invisible until it nests or lands inside a hot path. This
skill teaches Claude how to detect the misuse, how to replace SubcomposeLayout with a cheaper
primitive when its power is not needed, and how to keep it efficient when it is.
When to use this skill
The developer wraps content in BoxWithConstraints purely to read maxWidth / maxHeight and
pick between a few composables, and the screen feels heavy at first frame or on configuration
change (rotation, IME show).
A BoxWithConstraints or Scaffold is nested inside another BoxWithConstraints or Scaffold,
multiplying subcomposition cost.
A BoxWithConstraints sits inside a LazyColumn/LazyRow item and the developer reports scroll
jank that did not exist before the wrap was added.
The developer manually authors a SubcomposeLayout block but only uses constraints to compute
final positions, never to drive child composition.
The Layout Inspector or a Perfetto trace shows Compose:applyChanges or measure-phase composition
counts that scale with parent constraint changes (rotation, drag-to-resize, animated container
size).
A custom SubcomposeLayout's measurePolicy block allocates a fresh composable lambda inside
subcompose(slotId) { … } on every measurement. AndroidX maintains an internal lint check named
ComposableLambdaInMeasurePolicy (in compose/lint/internal-lint-checks/) that flags exactly
this pattern on its own codebase; published APIs like BoxWithConstraints, material.Scaffold,
and material3.TabRow suppress that check because the trade-off is fundamental to their public
contract. App-side code that reproduces the pattern pays the same cost without the suppression
rationale.
When NOT to use this skill
The developer needs to compose a child whose content depends on another child's measured size —
that is the canonical SubcomposeLayout use case and there is no cheaper primitive. Keep
SubcomposeLayout; tune it (see Pattern: Tuning a justified SubcomposeLayout).
The slow path is inside a LazyColumn item but the cause is unstable parameters, not
subcomposition. Diagnose with ../../stability/diagnosing-compose-stability/SKILL.md first.
The state read driving repeated measurement is an animation value rather than a structural
constraint. That is ../deferring-state-reads/SKILL.md.
The user wants to optimize lazy list prefetch — that is
../../lists/configuring-lazy-prefetch/SKILL.md.
Prerequisites
Familiarity with Compose's three phases (Composition, Layout, Draw). If unsure, read
../deferring-state-reads/references/three-phases.md first.
A release build with R8 for any final measurement.
../../measurement/testing-compose-in-release-mode/SKILL.md covers why debug builds lie.
Layout Inspector or Perfetto trace tooling.
../../measurement/tracing-recompositions-at-runtime/SKILL.md covers wiring
androidx.compose.runtime:runtime-tracing so that measure-phase work shows up in system traces.
1. Identify every SubcomposeLayout user in the hot path. Grep the affected screen for
BoxWithConstraints, Scaffold, SubcomposeLayout, and any custom @Composable that delegates
to one. The material3.Scaffold and foundation.layout.BoxWithConstraints are both implemented
with SubcomposeLayout; their cost is identical.
2. For each user, decide whether the constraints are actually consumed during composition.
A BoxWithConstraints that reads maxWidth only to pass it to a child as a parameter is wasting
the subcomposition machinery. A BoxWithConstraints that picks between two completely different
@Composable trees based on maxWidth < 600.dp is using it correctly.
3. Replace unjustified BoxWithConstraints with a cheaper primitive. If the consumer only
needs the final size in pixels (e.g. to compute an offset, an alpha, a draw command), use
Modifier.layout { measurable, constraints -> … } or Modifier.onSizeChanged { … } instead. Both
run during the layout phase without spinning up a new composition.
4. Avoid nesting subcomposing layouts. Two Scaffolds nested, or a BoxWithConstraints
inside a Scaffold slot that itself contains another BoxWithConstraints, multiplies
measure-phase composition. Hoist the outer one to the screen root and use ordinary Box /
Column / Row for the inner branches.
5. Never wrap a LazyColumn/LazyRow item in BoxWithConstraints. Each item subcomposes
during measurement. If the item needs the available width, pass it down once from the parent (the
LazyColumn already knows its constraints) or use Modifier.fillMaxWidth().onSizeChanged { … }
for one-time sizing.
6. When SubcomposeLayout is justified,
configure SubcomposeLayoutState(SubcomposeSlotReusePolicy(n)). The state object retains up to
n previously-used slots so the next subcomposition reuses their slot table and node subtree
instead of paying for a fresh composition. The factory
SubcomposeSlotReusePolicy(maxSlotsToRetainForReuse: Int) ships in androidx.compose.ui.layout.
7. For predictable upcoming slots, call state.precompose(slotId, content) on a previous
frame. It returns a PrecomposedSlotHandle; the next subcompose(slotId, …) during measurement
skips the composition step. This is exactly how the lazy layouts spread item composition across
frames.
8. Verify in a Perfetto system trace. Add androidx.compose.runtime:runtime-tracing and
confirm that Compose:recompose and Compose:applyChanges no longer fire during scroll or resize
ticks at the rate of the parent's constraint changes. The measured screen should show
subcomposition only on actual structural change (e.g. rotation), not on every frame.
Patterns
Pattern: BoxWithConstraints used to read size — replace with Modifier.onSizeChanged
// WRONG@ComposablefunParallaxHeader(scrollOffset: () -> Float) {
BoxWithConstraints {
val widthPx = with(LocalDensity.current) { maxWidth.toPx() }
Image(
painter = painterResource(R.drawable.hero),
modifier = Modifier
.fillMaxWidth()
.height(220.dp)
.graphicsLayer {
translationX = scrollOffset() * widthPx * 0.2f
},
contentDescription = null,
)
}
}
// WRONG because: BoxWithConstraints subcomposes its content during the measure phase. Each// new constraint (rotation, IME show, animated parent size) re-runs that subcomposition just// to read maxWidth, when a Modifier.onSizeChanged would have given the same value with no// extra composition.
onSizeChanged runs in the layout phase (no subcomposition); the underlying onRemeasured is
invoked on every layout pass and forwards to the user callback when the measured size differs from
the previous size. The graphicsLayer block runs in Draw with the latest widthPx and the latest
scroll offset.
Pattern: BoxWithConstraints to pick a layout — keep it but hoist it
// WRONG@ComposablefunProductCard(product: Product) {
BoxWithConstraints {
if (maxWidth < 360.dp) {
CompactProductCard(product)
} else {
WideProductCard(product)
}
}
}
@ComposablefunProductGrid(products: List<Product>) {
LazyVerticalGrid(columns = GridCells.Fixed(2)) {
items(products) { ProductCard(it) }
}
}
// WRONG because: every grid cell wraps its content in BoxWithConstraints. Each cell pays// for a subcomposition during the grid's measure pass. With 200 cells visible across a long// scroll session, that is 200 redundant subcompositions on every measurement.
The single BoxWithConstraints at the grid root subcomposes once per parent constraint change. The
decision flows into every item as a plain Boolean, which is stable and skippable.
Pattern: Nested Scaffold — collapse to one
// WRONG@ComposablefunProfileScreen(...) {
Scaffold(topBar = { TopBar(...) }) { outer ->
Scaffold(
modifier = Modifier.padding(outer),
bottomBar = { ProfileTabBar(...) },
) { inner ->
ProfileContent(modifier = Modifier.padding(inner))
}
}
}
// WRONG because: each Scaffold is a SubcomposeLayout with its own measure-phase composition.// Nesting them doubles that cost on every frame whose constraints change (IME show, rotation,// nav bar inset change).
Scaffold already supports a top bar, bottom bar, snackbar host, and FAB in a single
subcomposition. Use the slots provided rather than nesting another Scaffold.
Pattern: Tuning a justified SubcomposeLayout
When a screen genuinely needs measure-time access to constraints (a tab strip whose tabs size by
their own content while sharing the row's max width, a lookahead-driven shared element container, a
custom popover that aligns to a measured anchor), keep SubcomposeLayout but tune the state.
@ComposablefunBadgeRow(badges: List<Badge>) {
val slotState = remember {
SubcomposeLayoutState(SubcomposeSlotReusePolicy(maxSlotsToRetainForReuse = 8))
}
SubcomposeLayout(state = slotState) { constraints ->
val measurables = subcompose(slotId = "badges") {
badges.fastForEach { Badge(it) }
}
val placeables = measurables.map { it.measure(constraints) }
val width = placeables.sumOf { it.width }
val height = placeables.maxOf { it.height }
layout(width, height) {
var x = 0
placeables.fastForEach { p ->
p.place(x, 0)
x += p.width
}
}
}
}
SubcomposeSlotReusePolicy(8) lets the layout retain up to eight previously-composed slots. When a
slot id reappears (e.g. a badge enters the screen again after exiting), the layout reuses the
existing slot table instead of rerunning composition. The lazy layouts use a similar mechanism with
their own policy implementation.
For predictable upcoming slots, call state.precompose(slotId, content) on an earlier frame and
dispose the returned PrecomposedSlotHandle if the slot is not needed after all. The next
subcompose(slotId, …) during measurement reuses the precomposed content with no composition step.
// WRONG
LazyColumn {
items(rows) { row ->
BoxWithConstraints {
val isWide = maxWidth > 600.dp
RowContent(row, isWide)
}
}
}
// WRONG because: each row item subcomposes during the LazyColumn's measure pass. Scroll the// list and every newly-visible item pays for a fresh subcomposition. On a 60Hz feed this is// the difference between smooth and dropped frames.
The single BoxWithConstraints at the feed root subcomposes only when the feed itself is
remeasured. The per-row item is a plain RowContent call with a stable Boolean parameter, which
strong skipping handles.
Mandatory rules
MUST NOT use BoxWithConstraints only to read maxWidth/maxHeight for a Modifier-level
effect. Use Modifier.onSizeChanged { … } or Modifier.layout { … } instead.
MUST NOT place a BoxWithConstraints inside a LazyColumn/LazyRow/LazyVerticalGrid item.
Hoist the constraint read to the lazy layout's parent and pass the resolved value down.
MUST NOT nest Scaffold inside another Scaffold. Use the slots (topBar, bottomBar,
snackbarHost, floatingActionButton) the outer Scaffold already exposes.
MUST keep a SubcomposeLayout when the children's composition genuinely depends on a measured
value (parent constraints, sibling size). The point is to use the right tool, not to ban
SubcomposeLayout.
MUST pass a SubcomposeSlotReusePolicy to SubcomposeLayoutState whenever slots come and go.
The default no-op policy disposes slots eagerly and pays full composition cost on every
reappearance.
PREFERRED: for predictable upcoming slots, call state.precompose(slotId, content) on a
previous frame and let the measure-pass subcompose reuse the result.
PREFERRED: measure once with Modifier.onSizeChanged { … } over reading maxWidth in a
BoxWithConstraints body when the value only feeds a graphicsLayer { }, drawBehind { }, or
other Layout/Draw-phase consumer.
Verification
A Perfetto system trace recorded with androidx.compose.runtime:runtime-tracing shows that
Compose:recompose and Compose:applyChanges no longer fire on every measurement of the affected
subtree. They should fire only on real structural change (rotation, navigation, list item insert).
Layout Inspector's recomposition count for any subtree wrapped by the prior
BoxWithConstraints does not increment per parent constraint change.
In any retained custom SubcomposeLayout, the subcompose(slotId) { … } content lambda is
hoisted into a remember-stable reference (or is cheap and intentional, with a one-line comment
explaining why a fresh lambda per measurement is safe here). This is the pattern AndroidX's
internal ComposableLambdaInMeasurePolicy lint enforces on the AndroidX codebase.
A grep over the migrated file finds zero BoxWithConstraints blocks inside LazyColumn/
LazyRow/LazyVerticalGrid items.
No Scaffold is nested inside another Scaffold in the migrated file.
For every retained SubcomposeLayout, a SubcomposeSlotReusePolicy is passed to
SubcomposeLayoutState, OR the comment explicitly notes that all slots are permanent and reuse is
unnecessary.
../deferring-state-reads/references/three-phases.md — three-phase model background that
motivates "do not run composition during measure".
../../lists/configuring-lazy-prefetch/SKILL.md — the lazy layouts use precompose and pausable
subcomposition; the same APIs are available to custom SubcomposeLayout users.
