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 recomposition Button(onClick = { viewModel.doSomething(item) }) { ... }

// GOOD: Use remember or method reference val onClick = remember(item) { { viewModel.doSomething(item) } } Button(onClick = onClick) { ... }

Expensive work in composition

// BAD: Sorting on every recomposition @Composable fun ItemList(items: List<Item>) { val sorted = items.sortedBy { it.name } // Runs every recomposition LazyColumn { items(sorted) { ... } } }

// GOOD: Use remember with key @Composable fun 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 identity LazyColumn { 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 @Immutable data class UiState( val items: ImmutableList<Item>, // kotlinx.collections.immutable val isLoading: Boolean )

Reading state too early

// BAD: State read during composition (recomposes whole tree) @Composable fun 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 @Composable fun 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 recomposition Box(modifier = Modifier.padding(16.dp).background(Color.Red))

// GOOD for dynamic modifiers: Remember the modifier val modifier = remember { Modifier.padding(16.dp).background(Color.Red) } Box(modifier = modifier)

Stability Checklist

Type Stable by Default? Fix

Primitives (Int , String , Boolean ) Yes N/A

data class with stable fields Yes* Ensure all fields are stable

List , Map , Set

No Use ImmutableList from kotlinx

Classes with var properties No Use @Stable if externally stable

Lambdas No Use remember { }

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