Боремся с лишними рекомпозициями в Compose

Если вы хоть раз пытались понять, какого черта ваш экран перерисовывается 10 раз при скролле или вводе текста, то это для вас. Подъехали сразу две годные тулзы, которые подходят к проблеме перфоманса с абсолютно разных сторон:

👉 DejaVu
Мощная библиотека, которая превращает проверки рекомпозиций в полноценные тесты

Под капотом: Это test-only решение, то есть в прод не улетит ни строчки лишнего кода. Подключается максимально просто: инициализируете правило createRecompositionTrackingRule<>() в тестовом классе, вешаете стандартный Modifier.testTag() на нужный Composable и пишете ассерты на количество перерисовок

В чем фишка: Идеально для CI. Библиотека отслеживает счетчики для каждого инстанса отдельно и выдает аналитику. Если кто-то из команды или AI-ассистент сломает стейт, тест упадет и покажет таймлайн проблемы с диффом параметров, из-за которых случилась рекомпозиция

Github (55 ⭐️): https://github.com/himattm/dejavu

👉 Compose Rebound
Инструмент для мониторинга "бюджета рекомпозиций" прямо во время работы приложения

Под капотом: Работает на базе Kotlin Compiler Plugin. Во время компиляции плагин автоматически резолвит имена Composable-функций и назначает им лимиты в зависимости от роли (например, 3 рекомпозиции в секунду для экрана, 30/с для кнопок, 120/с для анимаций)

В чем фишка: У Rebound есть шикарный плагин для IDE. Он не просто считает перерисовки, а отделяет вынужденные рекомпозиции (из-за родителя) от тех, что вызваны изменением параметров самого компонента. Помогает находить реальные спайки и аномалии, а не просто пугать вас большими цифрами в Layout Inspector

Github (37 ⭐️): https://github.com/aldefy/compose-rebound

Такое мы внедряем!