Compose Performance Audit

Compose Performance Audit

Overview

Audit Jetpack Compose view performance end-to-end, from instrumentation and baselining to root-cause analysis and concrete remediation steps.

Workflow Decision Tree

• If the user provides code, start with "Code-First Review."
• If the user only describes symptoms, ask for minimal code/context, then do "Code-First Review."
• If code review is inconclusive, go to "Guide the User to Profile" and ask for Layout Inspector output or Perfetto traces.

1. Code-First Review

Collect:

• Target Composable code.
• Data flow: state, remember, derived state, ViewModel connections.
• Symptoms and reproduction steps.

Focus on:

• Recomposition storms from unstable parameters or broad state changes.
• Unstable keys in LazyColumn/LazyRow (key churn, missing keys).
• Heavy work in composition (formatting, sorting, filtering, object allocation).
• Unnecessary recompositions (missing remember, unstable classes, lambdas).
• Large images without proper sizing or async loading.
• Layout thrash (deep nesting, intrinsic measurements, SubcomposeLayout misuse).

Provide:

• Likely root causes with code references.
• Suggested fixes and refactors.
• If needed, a minimal repro or instrumentation suggestion.

2. Guide the User to Profile

Explain how to collect data:

• Use Layout Inspector in Android Studio to see recomposition counts.
• Enable Recomposition Highlights in Compose tooling.
• Use Perfetto or System Trace for frame timing analysis.
• Check Macrobenchmark results for startup/scroll metrics.

Ask for:

• Layout Inspector screenshot showing recomposition counts.
• Perfetto trace or System Trace export.
• Device/OS/build configuration (debug vs release).

Important: Ensure profiling is done on a release build with R8 enabled. Debug builds have significant overhead.

3. Analyze and Diagnose

Prioritize likely Compose culprits:

• Recomposition storms from unstable parameters or broad state changes.
• Unstable keys in lazy lists (key churn, index-based keys).
• Heavy work in composition (formatting, sorting, object allocation).
• Missing remember causing recreations on every recomposition.
• Large images without Modifier.size() constraints.
• Unnecessary state reads in wrong composition phases.

Summarize findings with evidence from traces/Layout Inspector.

4. Remediate

Apply targeted fixes:

• Stabilize parameters: Use @Stable or @Immutable annotations on data classes.
• Stabilize keys: Use stable, unique IDs for LazyColumn/LazyRow items.
• Defer state reads: Use derivedStateOf, lambda-based modifiers, or Modifier.drawBehind.
• Remember expensive computations: Wrap in remember { } or remember(key) { }.
• Skip recomposition: Extract stable composables, use key() to control identity.
• Async image loading: Use Coil/Glide with proper sizing constraints.
• Reduce layout complexity: Flatten hierarchies, avoid deep nesting.

Common Code Smells (and Fixes)

Unstable lambda captures

// BAD: New lambda instance every recompositionButton(onClick = { viewModel.doSomething(item) }) { ... }
// GOOD: Use remember or method referenceval onClick = remember(item) { { viewModel.doSomething(item) } }Button(onClick = onClick) { ... }

Expensive work in composition

// BAD: Sorting on every recomposition@Composablefun ItemList(items: List<Item>) {    val sorted = items.sortedBy { it.name } // Runs every recomposition    LazyColumn { items(sorted) { ... } }}
// GOOD: Use remember with key@Composablefun ItemList(items: List<Item>) {    val sorted = remember(items) { items.sortedBy { it.name } }    LazyColumn { items(sorted) { ... } }}

Missing keys in LazyColumn

// BAD: Index-based identity (causes recomposition on list changes)LazyColumn {    items(items) { item -> ItemRow(item) }}
// GOOD: Stable key-based identityLazyColumn {    items(items, key = { it.id }) { item -> ItemRow(item) }}

Unstable data classes

// BAD: Unstable (contains List, which is not stable)data class UiState(    val items: List<Item>,    val isLoading: Boolean)
// GOOD: Mark as Immutable if truly immutable@Immutabledata class UiState(    val items: ImmutableList<Item>, // kotlinx.collections.immutable    val isLoading: Boolean)

Reading state too early

// BAD: State read during composition (recomposes whole tree)@Composablefun AnimatedBox(scrollState: ScrollState) {    val offset = scrollState.value // Recomposes on every scroll    Box(modifier = Modifier.offset(y = offset.dp)) { ... }}
// GOOD: Defer state read to layout/draw phase@Composablefun AnimatedBox(scrollState: ScrollState) {    Box(modifier = Modifier.offset {        IntOffset(0, scrollState.value) // Read in layout phase    }) { ... }}

Object allocation in composition

// BAD: Creates new Modifier chain every recompositionBox(modifier = Modifier.padding(16.dp).background(Color.Red))
// GOOD for dynamic modifiers: Remember the modifierval modifier = remember { Modifier.padding(16.dp).background(Color.Red) }Box(modifier = modifier)

Stability Checklist

5. Verify

Ask the user to:

• Re-run Layout Inspector and compare recomposition counts.
• Run Macrobenchmark and compare frame timing.
• Test on a real device with release build.

Summarize the delta (recomposition count, frame drops, jank) if provided.

Outputs

Provide:

• A short metrics table (before/after if available).
• Top issues (ordered by impact).
• Proposed fixes with estimated effort.

References

• Jetpack Compose Performance
• Compose Stability Explained
• Debugging Recomposition
• Macrobenchmark