tracing-recompositions-at-runtime
Tracing Recompositions at Runtime — @TraceRecomposition, logcat, and the live heatmap
Layout Inspector counts recompositions and surfaces Argument Change Reasons, but it works only in debug, where Live Literals and the interpreted Compose runtime inflate counts. @TraceRecomposition from skydoves/compose-stability-analyzer instruments a composable at compile time and emits per-recomposition diffs (which state changed, what value transition) to logcat under the Recomposition tag. The instrumentation works in any build the developer enables it for — including release-with-debug-symbols — and feeds the IntelliJ / Android Studio plugin's live recomposition heatmap.
This skill is the release-mode complement to ../../recomposition/debugging-recompositions/SKILL.md. Layout Inspector is debug-only, fast to set up, and good for the first triage. @TraceRecomposition is the ground-truth confirmation: instrument the suspect composable, ship a release+R8 build of the dev APK, run the user journey, and read the per-recomposition log lines.
When to use this skill
- A composable recomposes more than expected and Layout Inspector counts are inconclusive (the count differs between debug and release, or the suspect is an inline composable not covered by Layout Inspector).
- A stability or strong-skipping fix needs to be confirmed against a release-equivalent build before merging.
- A developer wants per-state-and-per-parameter change diffs printed inline rather than clicking through the Layout Inspector tree.
- A team wants to baseline a composable's recomposition count for an SLO ("PriceTicker recomposes ≤ once per price update; never per parent tick").
- The user mentions
@TraceRecomposition, "trace recomposition", "compose-stability-analyzer", "recomposition logcat", "recomposition heatmap", or "release-mode recomposition".