Привет, Хабр! Jetpack Compose в 2026 году стал стандартом разработки UI на Android, но в проектах регулярно повторяется одна и та же история: на экране со списком в пару сотен элементов прокрутка идёт рывками, профайлер показывает скачки кадров до 200 миллисекунд, а команда чешет голову и предлагает откатиться обратно на RecyclerView.
Проблема почти всегда не в Compose, а в том, как написан UI: recomposition спроектирован как дешёвая операция, но эта дешевизна работает только при соблюдении ряда правил, которые в документации описаны рассыпанно и часто игнорируются.
Разберём пять ошибок, из-за которых производительность Compose-экранов проседает заметно для глаза, и покажем, как их находить и чинить.
Лямбды без remember пересоздаются на каждой рекомпозиции
Часто встречающийся код, который выглядит логично:
@Composable
fun UserList(users: List<User>, onUserClick: (User) -> Unit) {
LazyColumn {
items(users) { user ->
UserCard(
user = user,
onClick = { onUserClick(user) }
)
}
}
}
В каждой рекомпозиции UserList лямбда { onUserClick(user) } создаётся заново, и Compose видит её как новый объект. Если UserCard принимает onClick: () -> Unit без remember, Compose считает, что параметры изменились, и рекомпозит карточку, даже когда сам user остался прежним.
Решение, которое разработчики применяют чаще всего, выглядит так:
items(users, key = { it.id }) { user ->
val onClick = remember(user) { { onUserClick(user) } }
UserCard(user = user, onClick = onClick)
}remember(user) кэширует лямбду, пересоздавая её только при смене пользователя. Это работает, но загромождает код. Более чистая альтернатива: внутри UserCard принимать не () -> Unit, а (User) -> Unit и сам объект пользователя, тогда лямбда верхнего уровня стабильна сама по себе и не требует remember.
Compose Compiler с включёнными compiler reports подсвечивает такие места: в выводе появляются строки про unstable parameters, и можно сразу видеть, где Compose не может пропустить recomposition. Включается флагом composeCompiler { reportsDestination = ... } в build.gradle, и через десять минут анализа из отчёта вытаскивается список проблемных точек.
Нестабильные типы заставляют Compose не доверять параметрам
Compose делит типы на stable и unstable.
Stable типы (Int, String, enum, data class с immutable полями стабильных типов) Compose сравнивает по equals и пропускает рекомпозицию, если параметр не изменился. Unstable типы (List, Map, Set, обычные классы с var-полями) Compose не считает безопасными для пропуска: даже если содержимое не менялось, рекомпозиция случится.
Пример:
data class ProductFilters(
val categories: List<String>,
val priceRange: IntRange,
val brands: List<Brand>
)
@Composable
fun FilterPanel(filters: ProductFilters) {
// Этот composable будет рекомпозиться при любой рекомпозиции родителя
}List<String> это интерфейс, под которым может скрываться mutable-реализация. Compose не знает, что внутри ArrayList, который теоретически могут изменить снаружи, поэтому помечает весь ProductFilters как unstable.
Решений два.
Первое: использовать kotlinx.collections.immutable, который даёт ImmutableList, PersistentList и аналоги. Эти типы помечены как stable аннотацией внутри библиотеки, и Compose их пропускает корректно.
data class ProductFilters(
val categories: ImmutableList<String>,
val priceRange: IntRange,
val brands: ImmutableList<Brand>
)Второе: пометить класс аннотацией @Immutable или @Stable, если есть уверенность, что после создания объект не меняется.
@Immutable
data class ProductFilters(
val categories: List<String>,
val priceRange: IntRange,
val brands: List<Brand>
)@Immutable это контракт: разработчик гарантирует Compose, что объект и всё, на что он ссылается, не изменится после создания. Если контракт нарушен (где-то в коде мутируется список внутри), Compose будет показывать устаревшие данные. Поэтому @Immutable ставится осознанно на типы, у которых физически нет mutable-поверхности.
Чтение state в верхнем composable рекомпозит всё дерево
Состояние в Compose читается через .value или через делегат by. Любой composable, который читает state, попадает в зону отслеживания: при изменении state именно этот composable будет рекомпозиться, и все его дочерние, если параметры до них дойдут изменёнными.
Антипаттерн:
@Composable
fun ScreenContent(viewModel: ScreenViewModel) {
val state by viewModel.state.collectAsState()
Column {
Header(title = state.title)
UserSection(user = state.user)
ContentList(items = state.items)
Footer()
}
}При любом изменении любого поля в state рекомпозится весь ScreenContent, потому что чтение состояния происходит наверху. Compose попытается пропустить дочерние composables, у которых параметры не изменились (skippable), но это работает только если их параметры стабильные. Для state.items с типом List<Item> пропуска не произойдёт.
Решение: переместить чтение state как можно ниже по дереву, ближе к месту использования.
@Composable
fun ScreenContent(viewModel: ScreenViewModel) {
Column {
Header(viewModel = viewModel)
UserSection(viewModel = viewModel)
ContentList(viewModel = viewModel)
Footer()
}
}
@Composable
private fun Header(viewModel: ScreenViewModel) {
val title by viewModel.state.map { it.title }.collectAsState(initial = "")
Text(title)
}Каждый composable читает только своё подмножество state, и при изменении одного поля рекомпозится только тот composable, который этим полем пользуется. Альтернатива через lambda-параметры:
@Composable
fun ScreenContent(viewModel: ScreenViewModel) {
Column {
Header(titleProvider = { viewModel.state.value.title })
// ...
}
}
@Composable
private fun Header(titleProvider: () -> String) {
Text(titleProvider())
}Lambda как параметр откладывает чтение state до момента вызова, что даёт похожий эффект: рекомпозиция Header произойдёт только при изменении title.
Вычисления без derivedStateOf приводят к лишним рекомпозициям
Сценарий с кнопкой «Наверх» в длинном списке:
@Composable
fun ScrollableList(items: List<Item>) {
val listState = rememberLazyListState()
val showScrollToTop = listState.firstVisibleItemIndex > 5
Box {
LazyColumn(state = listState) {
items(items) { item -> ItemRow(item) }
}
if (showScrollToTop) {
ScrollToTopButton(onClick = { /* ... */ })
}
}
}firstVisibleItemIndex обновляется на каждый кадр прокрутки, и значение меняется десятки раз в секунду. Compose видит, что showScrollToTop зависит от меняющегося state, и рекомпозит окружающий composable на каждое изменение, даже если булево значение остаётся true.
derivedStateOf решает эту проблему: он отслеживает зависимости и рекомпозит только когда финальное значение изменилось.
val showScrollToTop by remember {
derivedStateOf { listState.firstVisibleItemIndex > 5 }
}Теперь рекомпозиция произойдёт только в моменты пересечения порога (с 5 на 6 и обратно), а не на каждом изменении индекса. Для счётчика прокрутки в большом списке это разница между десятками рекомпозиций в секунду и парой за всю сессию.
derivedStateOf уместен, когда промежуточный state меняется чаще, чем финальный, и читателей у финального значения больше, чем у промежуточного. Если зависимость один к одному, derivedStateOf даёт только накладные расходы без выгоды.
Modifier создаётся внутри composable вместо хранения снаружи
Часто пишут так:
@Composable
fun ProductCard(product: Product) {
Column(
modifier = Modifier
.fillMaxWidth()
.padding(16.dp)
.background(Color.White)
.clip(RoundedCornerShape(8.dp))
) {
Text(product.name)
Text(product.price)
}
}Цепочка Modifier создаётся при каждой рекомпозиции заново. Сами модификаторы стабильны (Compose Compiler знает про них), но создание длинной цепочки в каждом кадре даёт измеримый оверхед, особенно в LazyColumn с большим количеством элементов.
Оптимизация для случаев, когда modifier не зависит от состояния:
private val CardModifier = Modifier
.fillMaxWidth()
.padding(16.dp)
.background(Color.White)
.clip(RoundedCornerShape(8.dp))
@Composable
fun ProductCard(product: Product) {
Column(modifier = CardModifier) {
Text(product.name)
Text(product.price)
}
}Modifier теперь создаётся один раз при загрузке класса, а не на каждую рекомпозицию. Для модификаторов, которые зависят от темы или composition-local значений, помогает remember:
@Composable
fun ProductCard(product: Product) {
val cardModifier = remember {
Modifier
.fillMaxWidth()
.padding(16.dp)
.clip(RoundedCornerShape(8.dp))
}
val themedModifier = cardModifier.background(MaterialTheme.colorScheme.surface)
Column(modifier = themedModifier) {
Text(product.name)
Text(product.price)
}
}Базовая часть кэшируется через remember, тема-зависимая часть навешивается поверх. На малых списках разница неощутима, но в реальных приложениях с десятками сложных композаблов на экран суммарно набегает заметная экономия.
Как искать эти проблемы у себя
Compose Compiler Reports включается флагом в build.gradle.kts:
composeCompiler {
reportsDestination = layout.buildDirectory.dir("compose_compiler")
metricsDestination = layout.buildDirectory.dir("compose_compiler")
}После сборки в указанной директории появляются файлы с разбором каждого composable: какие параметры stable, какие нет, какие composables skippable, какие нет, где лямбды не запоминаются. Это первый и самый информативный источник информации.
Layout Inspector в Android Studio показывает recomposition counts: над каждым composable выводится счётчик пересборок, и видно, какие из них перерисовываются чаще, чем должны. На экране со списком счётчики у элементов вне видимости должны оставаться нулевыми, у видимых, не зависящих от прокрутки, тоже.
Macrobenchmark с включённым BaselineProfile даёт измеримые цифры по фреймрейту реальных сценариев. Это последний рубеж проверки, ведь если профилирование показывает плавную прокрутку, остальное вторично.
Пять перечисленных ошибок встречаются практически в любом Compose-проекте: лямбды без remember в параметрах, нестабильные коллекции вместо immutable, чтение state наверху дерева, отсутствие derivedStateOf для производных значений, создание модификаторов в каждой рекомпозиции. По отдельности каждая даёт небольшой оверхед, в сумме на экране со списком в пару сотен элементов получается заметное падение фреймрейта.
Фикс всегда один: включить Compose Compiler Reports, посмотреть, где Compose помечает параметры как unstable, исправить причины, прогнать macrobenchmark до и после. Обычно после первой итерации очистки кадры на критичных экранах перестают проваливаться, и дальше остаётся точечная работа над сложными сценариями анимаций и тяжёлых вычислений в composables.
Когда экран начинает тормозить из-за лишних рекомпозиций, становится понятно, что знание синтаксиса Compose — только начало. На специализации по Android-разработке отдельное внимание уделяется архитектуре приложений, работе с состоянием, производительности интерфейсов и инструментам, которые помогают находить такие проблемы до релиза. Именно этот уровень понимания обычно и отделяет работающий экран от действительно качественного мобильного приложения.