Android Good Reads

Боремся с лишними рекомпозициями в 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

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

Альфа Room 3.0 Alpha

Обновление одной из флагманских библиотек. Я всегда стараюсь использовать что-то по меньше и шустрее, типа sqldelight, но знаю, что этого монстра многие используют! А чо внутри то?

👉 KMP и WASM
👉 Чтобы избежать конфликтов с Room 2.x, androidx.room теперь стал androidx.room3
👉 Отказ от SupportSQLite: Библиотека теперь полностью работает на драйверах androidx.sqlite. Для постепенного перехода предусмотрен артефакт room3-sqlite-wrapper
👉 Только Kotlin и KSP: Генерация Java-кода, а также поддержка Java Annotation Processing (AP) и KAPT полностью прекращены
👉 Coroutines First: Из-за требований веб-платформ все API стали асинхронными. Блокирующие функции в DAO больше не поддерживаются — они должны быть либо suspend, либо Flow. Наканец-та!
👉 Кастомные типы возвращаемых значений: Добавлена аннотация @DaoReturnTypeConverter. Она позволяет разработчикам создавать собственные интеграции (например, для RxJava, Paging, LiveData)
👉 Текущее поколение Room 2.x переходит в maintenance mode. Новые фичи добавляться не будут, планируются только исправления ошибок и обновления зависимостей до релиза стабильной Room 3.0

Исследуем CompositionLocal API

С этим API вы уже знакомы

val LocalUser = compositionLocalOf { "GoodReads" }

@Composable
fun App() {
    CompositionLocalProvider(LocalUser provides "AndroidGoodReads") {
        UserProfile()
    }
}

@Composable
fun UserProfile() {
    val name = LocalUser.current
    Text("Hello, $name")
}

Внутри статьи рассказывают:

👉 Разбор внутреннего устройства: как связаны CompositionLocal, ProvidableCompositionLocal и их различные вариации
👉 Что на самом деле создают функции compositionLocalOf, staticCompositionLocalOf и compositionLocalWithComputedDefaultOf, и в чем разница между результатами их работы
👉 Механика работы CompositionLocalProvider и свойства .current. Как правильно передавать локальные данные между различными композициями
👉 Внутренняя кухня Compose: работа с Value Holders, использование Persistent Maps и интеграция на уровне Composer
👉 Рекомендации по оптимизации производительности и разбор типичных ошибок, которых следует избегать при использовании CompositionLocal

Google Play раскатывает это обновление!

Внутри разбирают популярные сценарии и что с ними делать

👉 Некоторые подключаемые библиотеки могут влиять на это, увы, с этим, вы ничего не сделаете, но сможете отследить в Android Vitals
👉 Загрузка или выгрузка файлов
👉 Одноразовые или периодические операции в фоне
👉 Bluetooth соединение
👉 Location трекинг
👉 Частое снятие показаний с сенсоров (всякие гироскопы и прочее)
👉 Remote messaging не через гугловский FCM. Да-да, если у вас собственная реализация слушания ивентов - увы и ах

Внутри статьи рекомендации по тому как избежать проблем

Android LLM leaderboard!

Бенчмарк для моделей с уклоном в андроид разработку

Ссылка на Android Bench: https://developer.android.com/bench

Немного про то как за год vibecoding перешел от гэмблинга к части моего рабочего процесса

https://t.me/androidraft/93

Новый Experimental Styles API в Jetpack Compose

Устали от простыней кода с InteractionSource и animate*AsState просто чтобы поменять цвет кнопки при нажатии? В Compose завозят решение!

👉 Всё в одном блоке: Больше не нужно жонглировать модификаторами и стейтами. Вы создаете единый блок Style, где описываете базовый вид и реакции на различные состояния (hovered, pressed, focused)
👉 Автоматические анимации: Достаточно обернуть изменения в блок animate { ... } (можно передать свой AnimationSpec), и система сама плавно заанимирует переходы
👉 Умная инвалидация под капотом: Свойства стилей хранятся с использованием битовых масок. Если при нажатии меняется только цвет (свойства отрисовки), Compose инвалидирует только фазу draw, полностью пропуская рекомпозицию и layout
👉 Доступ к темам: StyleScope имеет доступ к CompositionLocal, так что можно легко брать цвета из темы прямо внутри стиля, и они будут обновляться при ее смене

ClickableStyleableBox(
    onClick = onClick,
    style = {
        background(Color.Green)
        size(150.dp)
        hovered { 
            animate { background(Color.Yellow) } 
        }
        pressed { 
            animate(tween(100)) { background(Color.Red) } 
        }
    }
)

Большое исследование мобильных разработчиков

Ребята из DevCrowd запустили новое большое исследование мобильных разработчиков (а они проводят их уже много лет). И вот в 2026 году его результаты, кажется, будут действительно неожиданными – разработка за последний год поменялась очень сильно, и эта волна точно затронула и Android.

В опросе будем разбираться с тем, что происходит на рынке по грейдам и зарплатам, выживает ли кроссплатформа, как мобильщики используют AI в работе, куда расти, и как искать работу. Результаты выложим где-то в апреле!

👉Пройти опрос

Goodbye ViewModel. Hello retain!

Потенциальная замена для viewModel из коробки. Основная проблема которой, это отдельная поддержка viewModel из каждого DI. retain же работает как Composable и не нуждается в отдельном @HiltViewModel

Переписывать на retain в ближайшие пару лет никто, конечно же, не будет, но знать про это все-таки стоит

@Inject
class AuthPresenter(...) {
  val state: StateFlow<UiState>
  fun login(creds: Credentials) { .. }
  fun logout() { .. }
}

interface AuthScreenProviders {
  @IntoSet
  @Provides
  fun provideRoute(presenter: Provider<AuthPresenter>): RouteEntryProviderScope = {
    entry<Route.Auth> { AuthScreen(presenter = retain { presenter() }) }
  }
}

Петиция KeepAndroidOpen

В августе 2025 года Google объявила, что начиная с сентября 2026 года разрабатывать приложения для платформы Android будет невозможно без предварительной централизованной регистрации в Google. Эта регистрация будет включать:

👉 Оплату сбора Google
👉 Согласие с условиями использования Google
👉 Предоставление удостоверения личности государственного образца
👉 Загрузку доказательств владения приватным ключом подписи разработчика
👉 Указание всех текущих и будущих идентификаторов приложений

Если вкратце - распространять приложения станет сильно сложнее. На странице петиции описаны (на разных языках) последствия которые нас ждут после вступления правил в силу

И еще разок Dependency Injection vs Service Locator

Вместо того чтобы просто сравнивать либы, автор делит их на две категории:

Истинный Dependency Injection (Dagger, Hilt, Anvil, kotlin-inject, Metro)

👉 Строятся на Inversion of Control (IoC)
➕ Строгая валидация графа на этапе компиляции (если собралось — в проде из-за DI не упадет). Разрешение зависимостей за O(1) в рантайме. Идеально для тестов и больших команд
➖ Требуют больше явного кода от разработчика, замедляют сборку

Service Locators (Koin, Kodein, Spring DI, Compose CompositionLocals)

👉 Фокус на Developer Experience и скорости написания кода.
➕ Почти нулевой оверхед на сборку (все происходит в рантайме), минимум бойлерплейта
➖ Разрешение зависимостей за O(n), ошибки вылезают только при выполнении, а значит вылезает еще 1 категория багов на проде

Как kotlinx.serialization генерирует код

​В этой статье разбирается внутреннее устройство compile плагина kotlinx.serialization: от стратегии двухпроходной генерации IR (промежуточного представления) до оптимизации «золотой маски» для проверки обязательных полей. Плагин превращает обычные аннотации @Serializable в эффективные и типобезопасные сериализаторы, полностью обходясь без рефлексии или генерации кода во время выполнения

​А зачем это знать?
​Можно успешно использовать библиотеку, и не зная этих нюансов. Однако понимание внутренних механизмов поможет вам решать редкие связанные баги и принимать оптимальные по производительности решения

Кажется, это было трендом еще в 2016 году, но давайте освежим. Модуляризация в Android для больших команд
И сразу же часть 2 с примером

От себя скажу, что на эту статью лучше посмотреть как на чужой опыт и не перенимать один в один. Прежде чем приступать к такого рода изменениям - попробуйте и обкатайте их на отдельном проекте и проверьте как это будет работать

LeakCanary теперь встроен в профайлер внутри Android Studio, начиная с Panda 1

В чем особенность? Компьют перенесли с мобильного девайса на ваш лаптоп. Теперь поиск в дампе будет быстрее

Итак, вопрос с собеседования! Чем отличается Dispatchers.Main от Dispatchers.Main.immediate

Внутри разбирают с картинками:
👉 А что если продьюсить на Main, а консьюмить на immediate. И вообще перебрать всевозможные комбинации?
👉 А зачем выбирать immediate?
👉 Почему AndroidX команда выбрала immediate стандартным диспатчером для lifecycleScope и viewModelScope?

Ладно, я немного преувеличил и думаю, что такого рода вопросы скоро, все-таки, пропадут с собеседований...

Shared Internals: кросс-модульная видимость

Разбираем KEEP-0451, предлагающий ввести shared internal, как еще один скоуп видимости внутри модуля и некоторых зависящих модулей

Кратко весь сехматоз описывают так

A ──shares──▶️ B ──shares──▶️ C

C имеет доступ к A shared internals

Сценарий простой и вы с ним сталкивались в многомодульном приложении: модуль с тестами хочет иметь доступ к internal функциям основного модуля.

Как по мне, это извращенная friends декларация из плюсов. Плохо ли?

Оригинальный KEEP-0451 почитать тут

Android Studio Panda 1 | 2025.3.1 Canary 5

Обрастает фичами. Хотелось бы верить что по клику на Update all libraries with AI агент сходит, посмотрит релиз ноутсы, сопоставит зависимости, подскажет или сам поправит минорные изменения, но нет

Это градловая таска, которую он запихивает в агента, чтобы там уже править ошибки. Спасибо 😡

Навыки, которые мы теряем, пока AI делает скучную работу

Чот я всё хвалю и хвалю AI, надо и поругать в сегодняшней статье. Автор проводит параллель с пилотами, которые теряют навыки ручного управления из-за надежды на автопилот, и утверждает, что то же самое происходит сейчас с разработчиками

👉 Скука — это тренировка. Написание тестов, документации и бойлерплейта — это не просто рутина. Это «повторения», которые формируют интуицию и помогают предугадывать баги и граничные сценарии
👉 Невидимая атрофия. Потеря навыка происходит незаметно. Вы по-прежнему закрываете тикеты, метрики выглядят хорошо, но способность глубоко понимать систему и находить сложные баги (которые AI пропускает) исчезает
👉 Иллюзия продуктивности. Ссылаясь на исследования (включая отчет GitClear 2025), автор отмечает, что с приходом AI количество рефакторинга упало, а копипасты — выросло. Опытные инженеры могут даже замедляться, используя AI, не замечая этого

Отказываться от AI глупо, но важно не превратиться в оператора, который не может работать без инструмента. Решение — периодически писать код и тесты самому, чтобы поддерживать форму