Какие плюсы и минусы derivedStateOf в Jetpack Compose?

Введение в derivedStateOf

derivedStateOf — это функция Jetpack Compose для деривации (вычисления) состояния на основе одного или нескольких других состояний (State объектов). Её основная цель — оптимизация: предотвращение избыточных рекомпозиций путём вычисления нового значения только при изменении реально значимых исходных состояний. Это аналог select или computed из других реактивных систем.

Ключевые принципы работы

Функция принимает лямбду-вычислитель и возвращает State<T>. Compose отслеживает чтение каких State/StateFlow/иных supported объектов происходит внутри лямбды и пересчитывает значение только при изменении любого из них.

val listState = rememberLazyListState()
val showButton by remember {
    derivedStateOf {
        listState.firstVisibleItemIndex > 0
    }
}
// showButton будет меняться только при изменении firstVisibleItemIndex,
// а не при каждом скролле (который меняет много других параметров)

Преимущества (derivedStateOf)

1. Оптимизация рекомпозиций

Основной плюс. derivedStateOf действует как мемоизация для состояния: если исходные стейты не изменились, то и производное значение остаётся прежним, и его чтение не запускает рекомпозицию. Это критично при работе с часто меняющимися источниками (скролл, анимация, поток событий).

2. Декларативная зависимость

Автоматическое отслеживание зависимостей внутри лямбды. Не нужно вручную указывать ключи, как в remember(key1, key2) { ... }. Соответствует философии Compose: опиши что, система решит когда.

3. Эффективная работа с коллекциями и сложной логикой

Позволяет "фильтровать" изменения. Например, вычислять, изменился ли первый видимый элемент, а не просто факт скролла.

val isFirstItemVisible by remember {
    derivedStateOf {
        listState.firstVisibleItemIndex == 0
    }
}
// Рекомпозиция только при переходе между 0 и не-0, а не на каждый пиксель скролла

4. Интеграция с другими API Compose

Хорошо сочетается с remember, SnapshotStateList/Map, Flow.collectAsState(). Может использоваться внутри и вне @Composable функций (если не требуется автоматическое отслеживание в UI, можно использовать derivedStateOf без remember).

Недостатки и подводные камни (derivedStateOf)

1. Риск избыточных перерасчётов при неправильном использовании

Если внутри лямбды читается изменяемый объект, не являющийся подписанным State (например, обычная переменная), derivedStateOf не сможет отследить изменение и значение устареет.

var counter = 0 // НЕ State!
val derived = derivedStateOf { counter * 2 } // НЕ БУДЕТ обновляться!

2. Не для всех видов вычислений

Предназначена для синхронных и быстрых вычислений. Длительные операции (сеть, дисковые чтения) блокируют UI-поток и должны выполняться в LaunchedEffect, rememberCoroutineScope или ViewModel.

3. Затраты на отслеживание зависимостей

Каждый вызов derivedStateOf создает объект, который подписывается на все прочитанные внутри стейты. Если стейтов много или они меняются очень часто, могут быть накладные расходы на управление подписками (обычно ничтожны, но в микро-оптимизациях стоит учитывать).

4. Требует аккуратного запоминания (remember)

Часто derivedStateOf нужно оборачивать в remember, иначе при каждой рекомпозиции будет создаваться новый экземпляр, теряя мемоизацию.

// ПРАВИЛЬНО:
val derived = remember { derivedStateOf { ... } }

// НЕПРАВИЛЬНО (теряется мемоизация):
val derived = derivedStateOf { ... }

5. Сложность отладки зависимостей

Иногда неочевидно, какой именно стейт вызывает перерасчёт, особенно при вложенных derivedStateOf или чтении свойств объектов. Может потребоваться профилирование рекомпозиций.

Практические рекомендации

• Используйте derivedStateOf, когда: нужно преобразовать или скомбинировать несколько стейтов, особенно если результат меняется реже, чем исходники (булевы флаги, индексы, агрегатные данные).
• Избегайте derivedStateOf, когда:

    *   вычисление тяжёлое или асинхронное.
    *   можно обойтись простым `remember(key)` с явными ключами.
    *   логика уже инкапсулирована во ViewModel или UseCase, и состояние приходит "готовым".

Альтернативы

• remember(key1, key2) — когда зависимости известны явно и их мало.
• Flow.combine или StateFlow в ViewModel — для более сложной бизнес-логики, которую нужно тестировать.
• Ручная мемоизация в ViewModel (например, через cachedIn для Flow).

Заключение

derivedStateOf — мощный инструмент для точной настройки реактивности в Compose. Его главный плюс — автоматическая оптимизация рекомпозиций за счёт интеллектуального отслеживания зависимостей. Главный минус — необходимость чёткого понимания, какие данные являются отслеживаемыми состояниями, и риск ошибок при неаккуратном использовании. Правильное применение требует анализа частоты изменения данных и здравого смысла: не стоит оборачивать в derivedStateOf каждое вычисление, но для преобразования часто меняющихся стейтов в стабильные флаги или значения — это часто оптимальное решение.