debugging-recompositions
Debugging Recompositions — make the invisible visible, then map status to action
Recomposition is invisible by default. A composable that re-runs sixty times a second to redraw an animation looks identical in source to one that should re-run zero times when its parent ticks. Three layers of instrumentation make it visible: Layout Inspector recomposition counts and skip counts (Android Studio, debug build), Layout Inspector Argument Change Reasons (Hedgehog and later, per-parameter Changed / Unchanged / Uncertain / Static / Unknown classifications), and runtime @TraceRecomposition from compose-stability-analyzer for release / R8 / real-device measurement.
This skill is the diagnostic layer. It does not fix recompositions; it tells the developer which composable is recomposing and which parameter is responsible. Once the param is named, the fix lives in a sibling skill — stability for unstable types, strong skipping for lambda capture, or phase deferral for state reads in the wrong phase.
When to use this skill
- The developer says "this should be skipping but it's not" or "this re-runs every time the parent ticks".
- The developer wants to count recompositions of a specific composable to confirm a fix worked.
- The developer asks what "Uncertain", "Unknown", "Static", or "Unchanged" means in the Layout Inspector recomposition reasons panel.
- A PR claims a stability or strong-skipping fix; the reviewer needs to confirm the recomposition actually went away in release.
- The user mentions "recomposition count", "Layout Inspector", "Argument Change Reasons", "Hedgehog", "@TraceRecomposition", or "why is this recomposing".