Рекомпозиция и производительность Compose

Compose следит, какие State прочитала каждая composable. Когда значение меняется, рантайм повторно вызывает только эти функции, а при вызове детей сравнивает параметры: если все стабильны и равны прошлым, ребёнок пропускается. Поэтому производительность упирается в стабильность и в то, где читается состояние. Я делаю UI-модели неизменяемыми data class с val, списки передаю как ImmutableList или помечаю обёртки @Immutable, не создаю новые объекты в теле на каждой рекомпозиции. Быстро меняющиеся значения вроде скролла и анимаций читаю в лямбдах Modifier.offset { } или graphicsLayer { }, тогда меняется только layout или отрисовка без рекомпозиции. Для значений, которые меняются реже источника, использую derivedStateOf, а в LazyColumn всегда задаю key. Ищу проблемы Layout Inspector со счётчиками рекомпозиций и отчётами компилятора, а меряю в release-сборке, потому что debug Compose заметно медленнее. Со Strong Skipping стало проще, но новые ссылки всё равно ломают пропуск.