Help us improve
Share bugs, ideas, or general feedback.
From chrisbanes-skills
Analyzes Jetpack Compose parameter stability, compiler reports, skippability, and Kotlin 2.0+ strong skipping to diagnose unnecessary recompositions.
npx claudepluginhub chrisbanes/skills --plugin chrisbanes-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/chrisbanes-skills:compose-stability-diagnosticsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Compose performance problems from parameters are about **whether inputs compare cheaply and predictably across recompositions**. With Kotlin 2.0.20+ strong skipping is enabled by default, so unstable parameters no longer automatically make restartable composables non-skippable. That does not make stability irrelevant: unstable parameters are compared by instance identity (`===`), stable paramet...
Routes Jetpack Compose recomposition investigations to focused skills for stability, deferred reads, or back-writing.
Guides building Android UIs with Jetpack Compose: project setup, MVVM state management with ViewModels/StateFlow, navigation, performance optimization, Material 3.
Provides Jetpack Compose patterns for state hoisting, remember variants, slot APIs, modifiers, side effects, theming, animations, and performance in Android UI development.
Share bugs, ideas, or general feedback.
Compose performance problems from parameters are about whether inputs compare cheaply and predictably across recompositions. With Kotlin 2.0.20+ strong skipping is enabled by default, so unstable parameters no longer automatically make restartable composables non-skippable. That does not make stability irrelevant: unstable parameters are compared by instance identity (===), stable parameters by equality (equals), and churny instances can still defeat skipping.
First identify the compiler mode you are on, then read reports in that context.
List, Set, Map, ranges, Java time/money types, or third-party types.composables.txt / classes.txt shows unstable parameters or non-skippable composables.On Kotlin 2.0.20+, strong skipping is enabled by default. In that mode:
equals.===).That means the question changes from "is this composable skippable at all?" to "will these parameters compare the way I expect, and are callers creating new unstable instances every frame?"
For older compiler setups or strong skipping disabled, the legacy rule still matters: a restartable composable with unstable parameters may be restartable but not skippable.
With Kotlin 2.0+ the Compose Compiler is configured through the Kotlin Gradle plugin:
plugins {
alias(libs.plugins.android.application) // or android.library / jvm
alias(libs.plugins.kotlin.android) // or kotlin.multiplatform / kotlin.jvm
alias(libs.plugins.compose.compiler)
}
if (providers.gradleProperty("composeReports").orNull == "true") {
composeCompiler {
reportsDestination = layout.buildDirectory.dir("compose_compiler")
metricsDestination = layout.buildDirectory.dir("compose_compiler")
}
}
Then build the variant whose compiler configuration you care about, for example:
./gradlew :app:assembleRelease -PcomposeReports=true
Use release/non-debuggable builds for runtime profiling. Compiler reports are build-time outputs, so the important thing is matching the variant and compiler flags you ship.
Key files:
| File | What it tells you |
|---|---|
<module>-classes.txt | Stability of classes and properties |
<module>-composables.txt | Restartable/skippable status and parameter stability |
<module>-composables.csv | Same data in sortable form |
<module>-module.json | Aggregate metrics |
Pick the lightest fix that makes the type's immutability or equality semantics true.
kotlin.collections.List is an interface; Compose cannot know the runtime implementation is immutable. Prefer kotlinx.collections.immutable at UI-state boundaries:
// Before: unstable collection interfaces
data class UiState(val items: List<Item>, val tags: Set<String>)
// After: immutable collection contracts
import kotlinx.collections.immutable.ImmutableList
import kotlinx.collections.immutable.ImmutableSet
data class UiState(val items: ImmutableList<Item>, val tags: ImmutableSet<String>)
Producers convert once at the boundary with .toImmutableList() / .toImmutableSet().
@Immutable / @Stable@Immutable when every property is effectively immutable and equality describes all observable state.@Stable for types whose mutable state is observable by Compose, typically via MutableState.Do not annotate to silence a report. A false stability promise can produce stale UI.
For types you cannot annotate, use stabilityConfigurationFiles:
composeCompiler {
stabilityConfigurationFiles.add(
rootProject.layout.projectDirectory.file("compose_stability.conf"),
)
}
java.math.BigDecimal
java.math.BigInteger
java.time.*
kotlinx.datetime.*
Only list types you are willing to promise are immutable. Do not list mutable types such as java.util.Date.
Lazy list items recompose when their lambda inputs change identity, even if the visible data is unchanged.
Hoist and remember per-item inputs that are stable for the item's lifetime:
// ❌ BAD — new lambda instances when parent recomposes
items(list, key = { it.id }) { item ->
RowCard(
onClick = { onItemClick(item.id) },
isHighlighted = { item.id == selectedId },
)
}
// ✅ GOOD — stable captures for this item instance
items(list, key = { it.id }) { item ->
val onClick = remember(item.id) { { onItemClick(item.id) } }
val isHighlighted = remember(item.id, selectedId) { item.id == selectedId }
RowCard(onClick = onClick, isHighlighted = isHighlighted)
}
Also hoist row position metadata (isFirst, isLast, corner radii) with remember(index) { … } when the value depends only on index — but do not expect this alone to fix back-writing or cross-row measurement bugs.
Verify focus moves and insertions with recomposition-count assertions after hoisting.
| Symptom | Diagnosis | Fix |
|---|---|---|
| Kotlin 2.0.20+ but old docs say unstable means non-skippable | Strong skipping changed the default | Check comparison semantics and instance churn instead |
unstable val items: List<Item> | Interface collection | Use ImmutableList<Item> or another true immutable wrapper |
unstable val price: BigDecimal | External immutable type | Add to stability config |
@Immutable on a type with mutable internals | False promise | Fix the model or remove the annotation |
| Composable skips poorly despite strong skipping | New unstable instance each recomposition | Remember, hoist, or make the type stable/equality-based |
| Lazy items recompose on parent recompose despite unchanged data | New lambda or derived-value instance per parent recompose (§4) | Hoist per-item with remember(item.id) { … } |
| Reports not generated | Compose compiler plugin missing or flag not set | Apply org.jetbrains.kotlin.plugin.compose and enable destinations |
compose-state-deferred-reads.State read in composition, such as scroll or animation. Use compose-state-deferred-reads.compose-state-deferred-reads - frame-rate state should often be read in layout/draw rather than composition.compose-recomposition-performance - entry point when you are not sure which recomposition axis is involved.