Это перевод моей собственной статьи, опубликованной ранее в ProAndroidDev.
Сотня рекомпозиций в секунду при скролле — это приговор. Приговор батарее устройства, плавности анимаций и вашей репутации как инженера. Мы привыкли мыслить высокоуровневыми абстракциями: закинуть LazyColumn, добавить пару Modifier.padding и отправить в продакшен. Но что делать, когда стандартные компоненты начинают "захлебываться", а Layout Inspector горит красным от избыточных отрисовок?
Давайте снимем розовые очки абстракций. Если убрать всю "магию" компонентов Compose, останутся только Layout и Modifier. Даже Text под капотом — это BasicText, который опирается на фундамент Layout.
Сегодня мы разберем хардкорный кейс из моего проекта MicroMod: создание бесконечной сетки элементов, расположенных по спирали, с абсолютно нулевым показателем рекомпозиций при активном скролле. Никакой ерунды в духе "просто добавь @Stable". Только глубокая работа с фазами рендеринга, кастомный LazyLayout и умное управление состоянием.
Прежде чем перейти к практике, нужно закрепить внутреннюю механику фазы Layout. Процесс компоновки состоит из трех шагов: Constraints (Ограничения), Measurement (Измерение) и Placement (Размещение). Вечный спор о том, передается ли управление "сверху вниз" или "снизу вверх", не имеет однозначного ответа, так как эти этапы взаимосвязаны:
Constraints передаются от родителя к детям (сверху вниз).
Measurement (расчет размеров) идет в обратном порядке (снизу вверх).
Placement (позиционирование) финализируется снова сверху вниз.
Анатомия рендеринга: почему Compose лагает
Отрисовка каждого элемента в Compose проходит через три строго регламентированных этапа:
Composition: Что мы показываем? Compose строит дерево UI.
Layout: Где это находится? Включает шаги Measurement (снизу вверх) и Placement (сверху вниз).
Drawing: Как это выглядит? Отрисовка пикселей на экране.
Большинство проблем с производительностью (те самые лаги при скролле) возникают, когда мы заставляем Compose возвращаться на фазу Composition при изменении каждого пикселя. Даже механизмы вроде Donut-hole skipping (пропуск рекомпозиции внутри функции, если параметры не изменились) или новый Strong Skipping Mode не спасут, если вы читаете состояние скролла напрямую в теле @Composable функции.
Лямбда-модификаторы и спуск до Canvas
Классический пример делегирования вычислений: вместо Modifier.offset(x = scrollState.value), грамотный инженер напишет Modifier.offset { IntOffset(x = scrollState.value, 0) }. Лямбда откладывает чтение состояния до фазы Layout (а именно — Placement). Фаза Composition при этом остается нетронутой.
А когда стоит опускаться до Canvas? Если ваш UI — это график или система частиц без сложного внутреннего стейта и интерактивных дочерних элементов. В Canvas мы работаем напрямую в фазе Drawing. Но если нам нужны полноценные ноды Compose (карточки, кнопки, изображения), наше оружие — низкоуровневый LazyLayout.
Практика: Бесконечная спираль на LazyLayout
Задача: Расположить элементы не списком и не сеткой, а по бесконечной спирали.
Математика размещения (расчет координат X и Y по индексу n) выглядит так:
private fun getSpiralCoordinates(n: Int): Pair<Int, Int> { if (n == 0) return Pair(0, 0) val k = ceil((sqrt(n.toDouble() + 1) - 1) / 2).toInt() val t = 2 * k val m = (2 * k + 1) * (2 * k + 1) return when { n >= m - t -> Pair(k - (m - n), -k) n >= m - 2 * t -> Pair(-k, -k + (m - t - n)) n >= m - 3 * t -> Pair(-k + (m - 2 * t - n), k) else -> Pair(k, k - (m - 3 * t - n)) } }
Чтобы реализовать ленивую загрузку множества элементов с порогом видимости, нам понадобится кастомный провайдер.
Шаг 1: Подготовка State и Provider
Интерфейс LazyLayoutItemProvider требует от нас знания количества элементов и функции для их отрисовки. Но мы пойдем дальше — нам нужно точно знать, какие элементы попадают в Viewport.
typealias ComposableItemContent = @Composable (ListItem) -> Unit data class LazyLayoutItemContent( val item: ListItem, val itemContent: ComposableItemContent ) class ItemProvider( private val itemsState: State<List<LazyLayoutItemContent>> ) : LazyLayoutItemProvider { override val itemCount get() = itemsState.value.size @Composable override fun Item(index: Int, key: Any) { val item = itemsState.value.getOrNull(index) item?.itemContent?.invoke(item.item) } fun getItemIndexesInRange(boundaries: ViewBoundaries, stepX: Int, stepY: Int): List<Int> { val result = mutableListOf<Int>() itemsState.value.forEachIndexed { index, itemContent -> val item = itemContent.item val realX = item.coordinates.x * stepX val realY = item.coordinates.y * stepY if (realX in boundaries.fromX..boundaries.toX && realY in boundaries.fromY..boundaries.toY ) result.add(index) } return result } fun getItem(index: Int): ListItem? = itemsState.value.getOrNull(index)?.item }
Шаг 2: Оптимизация через derivedStateOf и rememberUpdatedState
Чтобы наш ItemProvider реагировал на изменения DSL, но не вызывал лишних рекомпозиций всей обертки, используем хирургически точное управление состоянием:
@Composable fun rememberItemProvider(customLazyListScope: CustomLazyListScope.() -> Unit): ItemProvider { val customLazyListScopeState = rememberUpdatedState(customLazyListScope) return remember { ItemProvider( itemsState = derivedStateOf { val layoutScope = CustomLazyListScopeImpl().apply(customLazyListScopeState.value) layoutScope.items } ) } }
Здесь derivedStateOf — наш лучший друг. Он кэширует результат вычислений DSL. Если входные данные не изменились, Compose даже не посмотрит в эту сторону на следующем цикле.
Шаг 3: Управление скроллом без рекомпозиции
В кастомном Layout мы сами обрабатываем жесты. Создадим LazyLayoutState, который хранит оффсет:
@Stable class LazyLayoutState(initialOffset: IntOffset = IntOffset.Zero) { private val _offsetState = mutableStateOf(initialOffset) val offsetState: State<IntOffset> get() = _offsetState fun onDrag(offset: IntOffset) { val x = _offsetState.value.x - offset.x val y = _offsetState.value.y - offset.y _offsetState.value = IntOffset(x, y) } // ... расчет границ видимости }
Шаг 4: Placement — там, где происходит магия "нуля"
Самая ответственная часть: мы вызываем measure только для видимых индексов, а расчет размещения (placement) делаем "на лету".
fun Placeable.PlacementScope.placeItem( state: LazyLayoutState, listItem: ListItem, placeables: List<Placeable>, gridStepX: Int, gridStepY: Int ) { val xPosition = (listItem.coordinates.x * gridStepX) - state.offsetState.value.x val yPosition = (listItem.coordinates.y * gridStepY) - state.offsetState.value.y placeables.forEach { placeable -> placeable.placeRelative(xPosition, yPosition) } }
Почему это дает 0 рекомпозиций? Мы читаем state.offsetState.value внутри лямбды размещения функции layout(). Когда оффсет меняется (пользователь скроллит), Compose инвалидирует только фазу Placement. Ему не нужно заново пересчитывать размеры дочерних элементов (Measurement), и уж тем более перестраивать дерево UI (Composition).
Бенчмарк: Layout Inspector не врет
Запускаем Layout Inspector и начинаем агрессивно скроллить спираль.
Результат:
Layout Inspector:
Recomposition Count: 0.
Skipped Count: Максимальный для всех нод.
Вынос логики вычислений за пределы фазы композиции и грамотное использование возможностей SubcomposeLayoutState (на котором базируется LazyLayout) позволяют добиться идеального фреймрейта даже на слабых устройствах.
Заключение
Мы собрали высокопроизводительный кастомный компонент. Да, в отличие от использования готового LazyColumn, нам пришлось вручную считать границы, обрабатывать жесты и дирижировать фазами Measure и Place. Но именно это отличает обычного пользователя фреймворка от инженера, который понимает его внутренности.
Баланс между чистым кодом и производительностью всегда хрупок. Если вам нужен стандартный список — используйте стандартные компоненты. Но если ваша задача, как и в проекте MicroMod (построенном на микромодульной архитектуре с Navigation3), требует бескомпромиссной скорости от нестандартного UI — спускайтесь на уровень LazyLayout. Контроль над фазами рендеринга — это ваша суперсила. Используйте её с умом.
Полную реализацию смотрите на Git
