What does Recomposition mean to your app
summary
Explains what “recompose” actually does: compiler/runtime use a slot table, composer and change list so functions rerun only when tracked inputs change; shows concrete costs of full recomposition and the surprising metric that an example app has 76 restartable and 64 skippable composables (12 that always restart). Demonstrates practical tools—compose compiler metrics, recompose highlighter, a logging modifier and Layout Inspector (Electric Eel)—and provides code patterns (keys, defer state reads, derivedStateOf) and whether each approach reduces wasted work.
AI-written summary · about
chapters (19)
- 0:00Start
- 2:26Jetpack Compose paradigm
- 11:32Android Lifecycle & Compose
- 12:28State Snapshot System
- 25:43Recomposition in SlotTable: example 1
- 29:19Stable type contract rules
- 29:47Stable property types
- 30:59Inferring Class stability
- 31:21Exceptions
- 32:39Compose Compiler Metrics
- 34:42Recompose Highlighter
- 36:23Logging Modifier
- 37:30Recomposition counter in Android Studio EE
- 38:52Break down composable functions
- 39:48Use the key composable
- 41:11Read the state value at the lowest composable function
- 42:27Use modifier lambdas
- 44:31Tips worth repeating
- 47:20Resources
related talks
49mWhat does Recomposition mean to your app?
38mWhat does Recomposition mean to your app?
36mUnderstanding Recomposition Performance Pitfalls
28mCompose at Scale: Stop Unnecessary Recomposition
45mMastering Recomposition: Optimizing State Changes for Efficient UI
41mDeep Dive into the Compose Compiler
34mCompose Performance: Hunting for unnecessary recompositions
41mDemystifying the Compose Runtime & Compiler
