Compose Performance: Hunting for unnecessary recompositions
summary
Unnecessary recompositions cause real jank on weaker devices and can be hunted down with concrete fixes and tools: use Layout Inspector to see actual vs skipped recompositions, and generate compose compiler reports (composables.txt, classes.txt) in release builds to find unstable inputs. Practical fixes shown include caching boolean results with derivedStateOf, switching modifier updates to lambda-based graphicsLayer or remember, replacing mutable Lists with kotlinx immutable collections or marking small models @Stable; after these changes skipped counts disappear and recompositions drop to only the meaningful ones.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 0:58Compose phases and recomposition
- 3:37Checking for recompositions
- 6:11Example one: State read
- 8:18Example two: Modifier usage
- 11:53Restartable and skippable concepts
- 15:23Example three: Stabilize unstable part one
- 20:21Compose compiler matrix explained
- 23:33Fixing unstable parameters
- 30:12Example four: Stabilize unstable part two
- 32:43Final advice and conclusion
related talks
28mCompose at Scale: Stop Unnecessary Recomposition
36mUnderstanding Recomposition Performance Pitfalls
38mJetPack Compose Performance Tips & Tricks
49mWhat does Recomposition mean to your app?
45mMastering Recomposition: Optimizing State Changes for Efficient UI
55mWhat does Recomposition mean to your app
21mMore performance tips for Jetpack Compose
37mPerformance in Compose:Lessons learned from Lazy layouts