Recomposition Is Not a Bug — You Are
Article Summary
If your Jetpack Compose UI is recomposing like crazy, the framework isn't broken—your code is fighting it instead of working with it.
Behzod Halil breaks down the five core performance rules from Google's official Compose documentation that most developers get wrong. This isn't theory—it's a practical guide to understanding how Compose's snapshot system and slot table actually work under the hood.
Key Takeaways
- Proper remember usage cuts calculation overhead by 60-80%
- derivedStateOf reduces unnecessary recompositions by 40-70%
- Lambda-based modifiers skip composition phase entirely for animations
- Lazy layout keys improve list scroll performance by 90%+
- Unstable parameters force defensive recomposition regardless of actual changes
Compose is fast by default—when it's slow, you're probably fighting the framework's design instead of leveraging its snapshot system and stability inference.
About This Article
Developers often pass mutable lists as keys to remember(), which breaks caching. Compose compares list contents using equals() rather than checking if they're the same object, so the cache gets invalidated and recalculations happen unnecessarily.
Behzod Halil points out that remember() needs fresh list instances to work correctly. Using remember(contacts, comparator) with stable key dependencies lets you cache expensive sorting operations. The cache only clears when the actual data changes.
Using remember() correctly with proper key management cuts calculation overhead by 60-80%. Adding derivedStateOf on top of that reduces unnecessary recompositions by another 40-70% when the output stays the same even though inputs changed.