Compose at Scale: Stop Unnecessary Recomposition
summary
Claims that tiny code changes can create big CPU bottlenecks by breaking Compose’s skip logic, with common culprits being unstable parameter types, captured lambdas, mutable domain models and misused annotations. Shows using Compose 1.9 recomposition callbacks plus layout inspector and profile traces to pinpoint which value change caused each recomposition, and describes fixes: enable strong skipping flag, mark types @Stable/@Immutable or register them, prefer deferring reads and passing state as lambdas, use remember and read-only composable; measurements and linters validate that these changes actually cut wasted recomposition.
AI-written summary · about
chapters (13)
- 0:00Compose adoption at scale
- 1:10Recomposition triggers
- 3:57Recomposition scopes
- 6:09Optimizing with stability flags
- 8:38Collections and state pitfalls
- 10:49LazyList and effects misuse
- 11:12Detecting recomposition issues
- 13:18Compose tracing tools
- 14:21Minimizing recomposition
- 17:48Lambda impact on recomposition
- 20:25Compose annotations best practices
- 22:35Large-scale Compose recommendations
- 25:11Q&A
related talks
36mUnderstanding Recomposition Performance Pitfalls
34mCompose Performance: Hunting for unnecessary recompositions
55mWhat does Recomposition mean to your app
49mWhat does Recomposition mean to your app?
45mMastering Recomposition: Optimizing State Changes for Efficient UI
38mWhat does Recomposition mean to your app?
38mJetPack Compose Performance Tips & Tricks
37mPerformance in Compose:Lessons learned from Lazy layouts