Improving LazyColumn performance
summary
Measures run in release with R8 and baseline profiles because debuggable builds and missing precompilation each cost about 2x; tests use a very low-end device (~10x slower than Pixel 7). Misused derived state causes huge overhead—reading two derived states per lazy item can consume ~60% of measure time; coalescing to one read or mapping to simple comparables fixes it. Replacing composed modifiers with modifier node cuts clickable composition from ~1ms to ~0.5ms, yields 20–30% faster creates, and ~50% fewer allocations, enabling view and node reuse.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:48LazyColumn performance focus
- 3:53Benchmarking best practices
- 7:01Optimization strategies in Compose
- 8:48Avoiding unnecessary recomposition
- 13:20Invalidation scope in Compose
- 14:02Derived state pitfalls
- 17:52State access cost in Compose
- 21:01Modifier node performance
- 26:56Lazy layout reuse techniques
- 30:23Key takeaways and future work
related talks
37mPerformance in Compose:Lessons learned from Lazy layouts
37mUsing Performance Management Tools: Firebase Performance Monitoring and Macrobenchm…
36mOptimizing Render Performance of Jetpack Compose
32mFrom Debugging to Real-World Tuning: A Practical Guide to Compose Performance
54mOptimizing Render Performance of Jetpack Compose
40mBoosting Compose UI from Sluggish to Snappy
21mPerformance best practices for Jetpack Compose
35mEnhancing Jetpack Compose App Performance:Tools, Strategies and Optimizations