📉 Ваш List убивает перформанс Compose. Разбираемся со Stability Написали красивый экран на Compose. Данные не меняются, но Layout Inspector показывает, что ваш Composable со списком перерисовывается каждый чих. Почему? Потому что вы передали туда обычный List. @Composable fun UsersList(users: List<User>) { // ❌ Компилятор вам не верит // ... } В чем проблема? Compose опирается на концепцию Stability (стабильности), чтобы понимать, можно ли «скипнуть» (пропустить) рекомпозицию узла, если параметры не изменились. Но в Kotlin List это просто интерфейс (read-only). Под капотом туда легко может прилететь MutableList или ArrayList. Compose не может гарантировать, что этот список кто-то не изменит из другого потока без ведома фреймворка. Поэтому компилятор помечает List как Unstable. А если параметр Unstable - Compose всегда будет вызывать рекомпозицию этой функции, если перерисовался родитель. Как это лечить? Есть три пути. 1. Официальный (и самый чистый): kotlinx.collections.immutable Используем библиотеку от JetBrains. Там лежат настоящие неизменяемые коллекции. @Composable fun UsersList(users: ImmutableList<User>) { // ✅ Stable! // ... } Компилятор Compose обучен доверять ImmutableList и PersistentList. Рекомпозиция будет скипаться. Минус: Приходится маппить .toImmutableList() на слое ViewModel, что создает аллокации (хоть и оптимизированные). 2. Суровый (через врапперы) Если вы не хотите тащить новую либу в проект, можно обернуть список в класс и зафорсить стабильность аннотацией: @Immutable @JvmInline value class UsersState(val items: List<User>) @Composable fun UsersList(state: UsersState) { // ✅ Stable! // ... } Мы берем ответственность на себя. Мы клянемся компилятору (через @Immutable), что не будем мутировать этот List под капотом. 3. Современный (Strong Skipping Mode) Начиная с Compose Compiler 2.0, JetBrains включили Strong Skipping Mode по умолчанию. Это меняет правила игры! Теперь Compose умеет скипать функции даже с Unstable параметрами (например, обычным List). Как? Он просто сравнивает инстансы по ссылке (===). Если вы передали тот же самый объект списка, что и в прошлый раз - рекомпозиции не будет. Но если ваша ViewModel при каждом обновлении делает uiState.copy(users = users.toList()) - инстанс меняется, и рекомпозиция всё равно ударит по UI. Вывод: Strong Skipping Mode сильно спасает легаси-код от тормозов. Но архитектурно правильно - использовать ImmutableList. Это делает контракт вашей UI-модели железобетонным: "эти данные не мутируют". А что в вашем проекте? Тащите kotlinx.collections.immutable, пишите врапперы или просто надеетесь на Strong Skipping? 👇 ✍️ @kotlin_lib