⚙️ Rebound — бюджеты рекомпозиций для Compose Одна из моих любимых тем в Compose-разработке — отладка рекомпозиций. Layout Inspector, Rebugger, ComposeInvestigator — всё это хорошие инструменты, но у них общий слепой угол: они говорят сколько рекомпозиций, но не отвечают на вопрос нормально ли это для данного компонента. HomeScreen, который рекомпозируется 10 раз в секунду — это проблема. Анимация, которая делает то же самое — это норма. Число одинаковое, вывод противоположный. Библиотека работает на основе Kotlin compiler plugin, который классифицирует каждый @Composable по роли и назначает ему бюджет рекомпозиций: 1️⃣ Screen — 3/s. Если экранный компонент рекомпозируется чаще, state утекает вверх по дереву 2️⃣ Leaf — 5/s. Text, Icon, Image — дёшевы сами по себе, но не должны «молотить» 3️⃣ Animated — 120/s. Всё, что использует animate*, Transition, Animatable — пусть работает 4️⃣ Container — 10/s, Interactive — 30/s, List Item — 60/s При скролле бюджеты удваиваются, при анимации и вводе — умножаются на 1.5. Контекст учитывается. Когда что-то выходит за рамки, в логах появляется не просто число, а конкретика: BUDGET VIOLATION: ProfileHeader rate=11/s exceeds LEAF budget=5/s -> params: avatarUrl=CHANGED, displayName=CHANGED -> forced: 0 | param-driven: 11 | interaction: IDLE 🔨 Плюс IDE-плагин с live-деревом, таблицей горячих точек, timeline-хитмапой, и самое полезное — цветными иконками прямо в редакторе. Зелёный/жёлтый/красный кружок рядом с каждым @Composable. Никакого переключения контекста. Попробую на своих проектах (только не отправляй в прод) — идея с контекстными бюджетами кажется мне намного честнее, чем единый порог для всех компонентов. Решение пока не достигло версии 1.0 но это и некритично, так как не влияет на продакшен код. 🔗 Источник: adital.dev 🐱 Исходники на GitHub #Android #Compose #AndroidDev #Производительность