Kotlin под капотом: нюансы использования аннотаций

Еще одна статья про внутрянку Kotlin, а именно про то, как применяются аннотации к полям класса.

Читать (Ru)

invalidate

Время идет. Уже все изучают Compose. А как работает старый добрый invalidate так многие и не знают.

Давайте расскажу кратко. А потом если тема пойдёт, то расскажу подробнее.

invalidate() - это метод View, который вызывает перерисовку (onDraw) вьюхи. Это примерно все знают. Но как это происходит? Когда? Если я вызову несколько раз подряд invalidate то перерисуется несколько раз?

Сейчас расскажу кратко путь от invalidate до реальной перерисовки вьюхи:
1. Вызываем invalidate у вьюхи
2. Вьюха вызывает у своего родителя invalidateChildInParent
3. И так invalidateChildInParent вызывается идя вверх по дереву пока не дойдем до ViewRootImpl - главного родителя нашей иерархии вьюх (она, кстати, сама вьюхой не является, а больше типо менеджера всего)
4. ViewRootImpl через класс Choreographer (мой любимчик) подписывается на следующий сигнал VSYNC. Или, простыми словами, подписывается на следующее событие отрисовки фрейма.
5. Не путайте - не просто кладет сообщение в мейн лупер, чтобы он выполнился как только сможет. А именно подписываемся на следующую отрисовку кадра.
6. Следующая отрисовка кадра произойдет как правило не позднее 16.6 мс с момента подписки.
7. Когда приходит VSYNC, то Choraographer вызывает метод doFrame и там по очереди обрабатывает запросы на: инпут, анимации, инсеты и, наконец, проход дерева и отрисовку.
8. И далее вниз по дереву спускается команда draw и вызывается наш колбек onDraw
9. Наша вьюха перерисовалась

Easy!

#android #view #ui #performance

#Docs #Blog #Modifier

Create custom modifiers

Ребята из Google выкатили новую документацию о том, как писать новые, а также мигрировать уже существующие кастомные модификаторы при помощи нового API Modifier.Node.

Продолжим тему секретных кодов. Я покажу один из возможных способов их извлечения через dumpsys. Тут придется немного погрепать или что-то заскриптовать чтобы выглядело красиво, но в базовом варианте команда будет выглядеть так: adb shell dumpsys package -f | grep -A 5 "android.provider.Telephony.SECRET_CODE". Далее можно или бездумно вводить каждый код, пытаясь понять почему же он не работает, или исследовать receiver который этот код слушает.

В самих же кодах нет никакой магии. Например код *#*#225#*#* отправленный из звонилки приведет к отправке intent-а с URI: android_secret_code://225, который и будет разбирать целевой receiver. А это значит, что можно отправить такой intent из своего приложения, и если в receiver-е нет проверки на action, то он будет обработан. Так можно проэксплуатировать какую-нибудь уязвимость в receiver-е.
#aht

Kotlin под капотом: inline функции

Ещё одна крутая статья из цикла Kotlin под капотом, про inline функции.

• Популярное заблуждение: inline функции экономят стек вызовов
• Популярное заблуждение: inline функции экономят количество методов
• В профит inline функций
• Измерение профита от inline функций
• Crossinline
• Reified

А вообще, у Макса все статьи крутые. Если пропустили, рекомендую почитать 👇

• Измеряя sequences
• Оптимизируя sequences
• Kotlin под капотом: нюансы использования аннотаций

Читать (Ru)

Kotlin Multiplatform в мобильной разработке. Рецепты общего кода для Android и iOS

Статья про Kotlin Multiplatform, с примером как можно выносить код в общий модуль.

👉 Общий модуль в KMP
👉 Логика экранов (ViewModel)
👉 Навигация между экранами
👉 Работа с сетью
👉 DI
👉 Хранение данных
👉 Строковые ресурсы
👉 Нативные инструменты (датчики, переход в другие приложения)
👉 Пример фичи (обработка push-уведомлений)

Читать (Ru)

Compose withAnimation

В SwiftUI есть очень классная фича withAnimation, позволяющая сделать анимацию вьюшки просто путем изменения состояния, а сама анимация произойдет как по волшебству.

@State private var showDetail = false

var body: some View {
    VStack {
        Button("Show details") {
            withAnimation {
                showDetail.toggle()
            }
        }

        if showDetail {
            Text("Details")
        }
    }
}

Не справедливо, что такого механизма нет из коробки в Compose, и инженер из Google решил исправить это недоразумение. Он сделал свой аналог withAnimation и реализовал это с помощью Snapshot API, про который мы говорили ранее.

Как это работает?

1. Создается пустой словарь состояний для анимации
2. Выполняется лямбда блок внутри Snapshot, в этой лямбде могут происходить изменения стейта
3. У Snapshot вызывается writeObserver при каждой записи в State и заполняется информация для анимации
4. Данные мапятся в другой тип, откуда достаются измененные значения
5. Уничтожается Snapshot, чтобы не допустить утечек памяти, при этом изменения не применяются глобально! «Все что произошло в снапшоте, остается в снапшоте»©
6. Анимируются значения

internal suspend fun withAnimation(
    adapterRegistry: StateObjectAdapterRegistry,
    animationSpec: AnimationSpec<Any?>,
    block: () -> Unit
) {
    val statesToAnimate = mutableMapOf<Any, StateObjectAdapter>() // 1
    val snapshot = Snapshot.takeMutableSnapshot(
        writeObserver = { changedState ->
            statesToAnimate[changedState] = checkNotNull(adapterRegistry.getAdapterFor(changedState)) // 3
        }
    )
    val targetValues = snapshot.enter {
        block() // 2
        buildTargetValues(statesToAnimate) // 4
    }
    snapshot.dispose() // 5

    animateValues(targetValues, animationSpec) // 6
}

Если у вас есть еще идеи как можно применить снапшоты, делитесь своими мыслями в комментариях👇

#Compose #Snapshots #Animations

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

FlexibleBottomSheet на GitHub: https://github.com/skydoves/FlexibleBottomSheet
Платформа: Android
⭐️: 194

Простота. Наглядность. Красота.

📚 Реальные задачи на System Design собеседовании для мобильного разработчика

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

Итак, какого типа задачи ожидать на System Design интервью для мобильного разработчика? Это реальные задачи которые я видел:

📌 Спроектировать приложение прогноз погоды.
📌 Спроектировать банковское приложение для отслеживания котировок акций.
📌 Спроектировать приложение для отслеживания заказа.
📌 Спроектировать приложение редактор картинок

Таким образом, на позиции мобильного разработчика от вас никто не ждет что вы сможете спроектировать высоконагруженный бэкенд, однако иметь представление о сетевом слое все-таки необходимо. Вы должны уметь рассказать о плюсах и минусах например REST API vs GraphQL и доказать почему именно REST подойдет вашему приложению которое вы проектируете.

О чем еще неплохо порассуждать и показать что вы знаете о чем говорите:

📌 Реляционные БД vs No-SQL решения
📌 Server-Driven UI
📌 Способы тестирования и плюсы минусы тех или иных подходов
📌 MVP vs MVVM vs MVI.

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

Ну и напоследок, самое главное что от вас ожидают на System Design интервью - это способность задать уточняющие вопросы, предложить идеи. Не начинайте рисовать диаграммы пока не спросите 5-10 вопросов. Если молча начать проектировать архитектуру - это красный флаг.

Вообще тема System Design большая и я планирую в ближайшее время большую статью об этом, а пока вот вам немного полезных ресурсов если хотите подготовиться.

- Набор примеров задач для System Design Interview
- System Design. Подготовка к сложному интервью. Автор:Алекс Сюй
- System Design Template
- System Design CheatSheet

📺 Enhancing Jetpack Compose app performance (28 мин) - большое видео с советами про оптимизацию скорости работы Compose UI

#performance @compose_broadcast

Feature freeze для JDK 22 выглядит прямо прикольно. Много интересных приятных изменений. Прямо разворошили этот улей за последние несколько лет.

#java #jdk

⚙️ Взламываем System Design интервью для мобильного разработчика.

Как и обещал, написал детальную статью по System Design интервью для мобильных разработчиков. Тут кратко расскажу про этапы и рекомендации, а на хабре более подробно с примерами и диаграммами. https://habr.com/ru/articles/781404/

В зависимости от процессов найма в компании на System Design у вас будет скорее всего около 1 часа. Это супер мало, поэтому четко планируйте время и старайтесь придерживаться следующего тайминга:

1️⃣ Понять условие задачи и собрать требования (5-10 минут). На этом этапе важно собрать как можно больше требований и досконально понять проблему какую вам нужно решить. Иногда вам могут дать уже какую-то заготовку, например скриншот какого-то приложения и спросить как спроектировать функционал показанный на этом скриншоте. На данном этапе приветствуется задавать вопросы. В первую очередь запишите что именно будут делать пользователи, опишите возможные сценарии использования.

2️⃣ Построение общей архитектуры верхнего уровня. (10-15 минут).

На этом этапе вы уже можете брать виртуальный маркер и начать рисовать верхнеуровневую диаграмму. Вам необходимо нарисовать блоки с ключевыми компонентами системы. Если говорить про Android-разработку, то нужно упомянуть принципы Clean Architecture и разделение по слоям. Комментируйте вслух почему вы решили использовать тот или иной компонент, какая у него будет ответственность. Например: DataSource будет отвечать за кэширование данных, потому что мы будем использовать offline-first подход.

3️⃣ Детальное описание каждого компонента вашей архитектуры и выбор решения. (20 минут).

На данном шаге вы согласовали требования и спроектировали примерную архитектуру. Теперь необходимо углубиться в каждый из компонентов и описать как бы вы реализовывали тот или иной компонент. Имея список компонентов (в реальном интервью он у вас на схеме перед глазами) вам необходимо пройтись по каждому и рассказать плюсы минусы альтернативных решений и почему вы выбрали именно это. Например реализация кэширования через Room vs Realm, использование сокетов или Rest API и т.д.

4️⃣ Подведение итогов и ответы на вопросы. (10 минут).

На этом этапе вам могут задать вопросы о каких-то отдельных аспектах или попросить рассказать о проблемных местах и потенциальных улучшениях. Кроме этого будет хорошо, если вы успеете затронуть и эксплуатационные вопросы

Рекомендации

🗣️ Не стесняйтесь задавать вопросы и уточнять требования.Общайтесь с интервьюером как будто это ваш тимлид или коллега с которым вы вместе проектируете решение, но в то же время показывайте что вы автономны и можете быть самостоятельной единицей.

⏰ Следите за временем. Интервьюер может вас отвлекать - ваша задача максимально полно представить решение за короткий срок. Заранее ознакомьтесь со средой в которой будете рисовать. Это может быть Draw.io, Excalidraw.

🤝 Попробуйте мок интервью. Попросите ваших коллег или поищите наставника, которые могут послушать вас и провести тестовое собеседование еще до того как вы упустите оффер своей мечты

С большим опозданием, но все же опубликовал исходный код с доклада.

Там самые разные компиляторные плагины, такие как:
- подсветка рекомпозиций
- логирование причин рекомпозиций
- удаление вызовов функции sourceInformation
- генерация/удаление/отображение testTag
- анализ стабильности параметров composable функций

Все компиляторные плагины подключаются к проекту как gradle plugin. Можно все по отдельности, а можно вместе - так удобнее настраивать.

В проверках стабильности параметров поддержаны самые последние обновления Compose Compiler, а именно возможность задавать в файле классы, которые надо пропустить в проверках. Подробнее писали тут.

Кроме этого есть ещё idea plugin. Правда в виде jar, так как получил отказ при попытке публикации в JetBrains Marketplace.
Он умеет отображать какие testTag будут сгенерированы компиляторным плагином, а так же проверять стабильность параметров функций и отображать ошибку в редакторе кода. Конечно, не на 100%, как это в компиляторном плагине сделано, но, думаю, в большинстве случаев правильно.

Ну и получил несколько просьб по поводу detekt правила для проверки параметров функций. Его тоже добавил. И там же есть возможность исключать классы, которые не нужно проверять.

Если будут проблемы или вопросы - пишите. Попробуем решить)

github.com/VKCOM/vkompose