Debugging Recompositions

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 87cfb886f00d · 16 Oct 2026Report an issue or request a re-scan

• Publisherskydoves GitHub userOwner of the repository this skill is read from
• Source folderskydoves/compose-performance-skills/recomposition/debugging-recompositionsThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict87cfb886f00dA new audit runs when the source changes
• Repository statusNot archivedLast push 121 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Use this skill to find which Jetpack Compose composables are recomposing and why, using Android Studio Layout Inspector recomposition counts and skip counts, the per-parameter Argument Change Reasons (Changed /…

---
name: debugging-recompositions
description: Use this skill to find which Jetpack Compose composables are recomposing and why, using Android Studio Layout Inspector recomposition counts and skip counts, the per-parameter Argument Change Reasons (Changed / Unchanged / Uncertain / Static / Unknown) introduced in Android Studio Hedgehog and later, and runtime `@TraceRecomposition` from `compose-stability-analyzer` for production-like measurement. Walks through enabling counts, mapping each Argument Change Reason to a fix, and confirming the result in a release build. Use when the developer says "this should be skipping but isn't", "I want to see recomposition counts", asks what "Uncertain" or "Unknown" means in the inspector, or needs to confirm a stability or strong-skipping fix actually worked end-to-end.
license: Apache-2.0. See LICENSE for complete terms.
metadata:
  author: Jaewoong Eum (skydoves)
  keywords:
  - jetpack-compose
  - performance
  - recomposition
  - layout-inspector
  - argument-change-reasons
  - trace-recomposition
  - android-studio-hedgehog
  - debugging
  - compose-stability-analyzer
---

# 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".

## When NOT to use this skill

- The composable is recomposing because of an unstable type — once this skill names the offender, the actual fix is in `../../stability/diagnosing-compose-stability/SKILL.md` and `../../stability/stabilizing-compose-types/SKILL.md`.
- The composable is recomposing because of a lambda capture or non-skippable scope — fix work lives in `../using-strong-skipping-correctly/SKILL.md`.
- The composable is recomposing because a state read happened in the wrong phase (Composition vs Layout vs Draw) — fix work lives in `../deferring-state-reads/SKILL.md`.
- The team needs a CI gate against future regressions — use `../../stability/enforcing-stability-in-ci/SKILL.md`.

## Prerequisites

- Android Studio **Hedgehog (2023.1.1)** or later for Argument Change Reasons. Earlier Studio versions have recomposition counts but not the per-parameter reason panel.
- A **debug** build for Layout Inspector (Layout Inspector requires debug). Read counts as **directional** signal only; debug builds run interpreted with Live Literals which inflate recomposition counts.
- `androidx.lifecycle:lifecycle-runtime-compose` available so `collectAsStateWithLifecycle` can replace plain `collectAsState` when a flow turns out to be the offender.
- For release-mode confirmation: the runtime tracing setup from `../../measurement/tracing-recompositions-at-runtime/SKILL.md` (the `compose-stability-analyzer` runtime + `ComposeStabilityAnalyzer.setEnabled(true)` in `Application.onCreate`).
- Familiarity with the Compose Compiler reports format (see `../../stability/diagnosing-compose-stability/SKILL.md`) — Layout Inspector classifications mirror the same stability vocabulary.

## Workflow

### 1. Enable recomposition counts in Layout Inspector

Run the app on a connected device or emulator in **debug**. Open Android Studio → **Tools** → **Layout Inspector**. In the Layout Inspector toolbar, toggle:

- **Show recomposition counts** — adds a "Recompositions" column to the component tree and overlays a count badge on the rendered tree.
- **Show recomposition skip counts** — adds a sibling column showing how many times the composable's skip guard fired (i.e. it was invoked but its body was skipped).

Both are off by default. With both on, the tree displays `<recompositions>/<skips>` per node, which is the primary signal.

The healthy ratio is "skips ≫ recompositions". A composable with `100/0` (one hundred recompositions, zero skips) is the smoking gun — every parent tick re-ran its body without any skip guard firing. A composable with `100/95` is doing fine — only five recompositions triggered actual work.

### 2. Reproduce the symptom while watching counts

Counts are cumulative. Reset them via the Layout Inspector "Reset" button before reproducing. Then perform the user action that the developer suspects is causing the jank — scroll, tap, animation tick — and watch which composables' counts climb.

The composable with the disproportionate count growth is the suspect. Note its name and parameter list before moving on.

### 3. Inspect Argument Change Reasons

Click the suspect composable in the Layout Inspector tree. The right-hand panel now shows a **"

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/skydoves/compose-performance-skills
git -C compose-performance-skills checkout 87cfb886f00d

Works in

1. 2026-10-16
   ✓SAFE B 89 / 100

   first audit · source 87cfb886f00d

Questions about Debugging Recompositions

• github.com/skydoves/compose-performance-skills/tree/main/recompo — the audited source at commit 87cfb886f00d and every finding aboveObserved · 16 Oct 2026

Spotted something wrong? Report a correction · Methodology