#Article #Blog

movableContentOf and movableContentWithReceiverOf

Не так давно Jorge Castillo (автор книги Jetpack Compose Internals) создал блог “Effective Android”, в котором он публикует различные полезные материалы по Android разработке (естественно большая часть посвящена Compose).
В одной из таких статей разбираются функции movableContentOf и movableContentWithReceiverOf, которые позволяют нам сохранять состояние UI-контента и передавать его в последующие вызовы.

▫️P.S. В одном из предыдущих постов мы уже частично разбирали movableContentOf , может помочь для лучшего понимания
▫️P.S.S. В своем недавнем докладе я также уделял внимание этому механизму (ссылка с таймкодом)

Интерактивный гайд по работе со стейтом с помощью Flow

Страница со статьей собрана на Compose for Web. Благодаря этому, можно не только смотреть на примеры кода, но и на ходу играть со стейтом и смотреть, как обрабатываются его изменения. Автор разбирает:
- Как реализовать UDF с помощью Flows
- Как прокидывать действия пользователя до стейта
- Как мерджить изменения в стейте
- Как решать конфликты при изменениях

​​UDF с Kotlin Flow
#kotlin

Классный пример визуализации поведения Kotlin Flow в Android.

Автор рассмотрел основные кейсы работы Flow в контексте состояний, пользовательских действий и различных типов.
Получилась крутая визуализация, что будет полезно, если вы хотите лучше разобраться с Flow 🤓

Вообще мы у себя давно так делаем, оно появилось как-то само собой, чисто интуитивно, но оказывается у этого подхода есть умное название: Stacked PRs. Вкратце: не выкатываешь всю фичу разом на ревью, а отправляешь небольшими порциями в виде зависимых PRов. С github это всё довольно хорошо работает, но всё ещё приходится кое-что делать ручками. И вот тут в статье автор описывает, что хочется уметь делать минимальными усилиями, и какие тулы в этом могут помочь.

#git #tool

Android Developer Options that you probably forgot

Полезная статья с обзором возможностей Developer Options.

От себя наиболее полезные опции выделяю: Strict Mode, Вытеснение активити, Debug GPU overdraw, Show view updates.

Иногда кстати, на собесах спрашивают например про отладку списков и в этом вопросе так же ожидают услышать про Developer Options, отрисовку кадров, перерисовку и вот это вот всё.

Читать (En)

Strings, Please! Eliminating Data Leaks Caused by Kotlin Assertions

В статье рассказывает про то как Kotlin генерит доп вызовы для выбрасывания исключений в Runtime, когда вы нарушаете Null Safety в Kotlin. Проблема в том что туда вставляются имена вызываемого кода, а при обфускации так и остаются оригинальными строками, что дает злоумышленникам проще разобраться в вашем коде.

Чтобы избавиться от этих проверок, используйте код на скриншотах, но только в релизных сборках. Для дебага проверки нужны.

Я уже давно предлагал и лаже описал способ как их выкосить с помощью конфига ProGuard/R8 (читайте здесь)

Keynote доклад с прошедшего Droidcon Berlin 2022, посвященный современным подходам в Android разработке. Данный доклад можно охарактеризовать как набор базовых рекомендаций от Google, который разработчик может брать за основу при написании нового проекта:

👉 в качестве основного ЯП использовать Kotlin (Google активно переписывает актуальные библиотеки, повсеместно использует корутины и Flow, внедряет KSP на замену KAPT)

👉 для построения UI использовать Jetpack Compose (авторы предлагают делать выбор между Views&Compose и Compose: использовать старый подход только в случае невозможности реализации или отсутствия подходящего механизма на компоузе, при этом желательно проверять роадмап и создавать соответствующие issues)

👉 для построения архитектуры приложения использовать принципы, изложенные в Guide to app architecture (Clean Architecture + UDF)

👉 при измерении производительности приложения и ускорении запуска использовать соответствующие инструменты: Benchmark your app и Baseline Profiles

👉 для ускорения сборки проекта использовать доступный функционал Gradle (incremental builds, build cache, configuration cache, lazy APIs)

Посмотреть на реализацию данных рекомендаций на практике можно в тестовом приложении Now in Android.

Как CompositionLocal может помочь с аналитикой

CompositionLocal – это API в Compose, который позволяет получить доступ к каким-то данным из любого Composable без необходимости передачи их вручную через параметры функции. Пример использования – работа с темами.

CompositionLocal удобен и для того, чтобы настроить аналитику – ведь ее инициализация находится где-то в точке общей конфигурации приложения, а непосредственное логивание событий – в листьях дерева нод.

очень жизненно

В данном докладе автор рассказывает о частых ошибках, которые допускают разработчики при работе с корутинами.

Можно выделить следующие типы ошибок:

👉 последовательный вызов suspend функций, когда в этом нет необходимости (если результат вызова одной suspend функции не зависит от вызова другой, то данные действия можно выполнять параллельно, используя async в связке с await() или awaitAll())

👉 не предусматривать возможность отмены suspend функции (когда оборачиваем некоторое апи на коллбеках, не забывать об использовании suspendCancellableCoroutine вместо suspendCoroutine)

👉 не делать suspend функции безопасными для главного потока (в случае необходимости не забывать переключать контекст выполнения на другой поток с помощью withContext(Dispatchers.IO))

👉 не обрабатывать CancellationException (быть аккуратным при использовании блока try...catch, перехватывая только необходимые исключения или явно проверяя прилетевшее исключение на CancellationException с возможностью пробросить его дальше)

👉 выставлять наружу suspend функции из вьюмодели (при таком подходе могут возникнуть ошибки в случае использования неправильного внешнего CoroutineScope, автор рекомендует использовать viewModelScope, либо любой другой, созданный внутри вьюмодели)

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

#Article #Blog #Animation

Velocity Based Animation with Compose

Неплохая статья, в которой разбирается такая техника, как Velocity Based Animation (проще говоря “Анимация, основанная на скорости”), которая позоляет отслеживать скорость прокрутки списка и при помощи этого кастомизировать длительность применяемой анимации.

​​Chrome Inspect
#android

Совсем недавно узнал о таком инструменте Chrome как chrome://inspect. Возможно, вы, как и я, услышите о нём впервые.

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

💡Пользоваться им очень просто:

1️⃣ Включаем режим разработчика на смартфоне (кажется, что вы все это сделали).
2️⃣ Ввводим в строку браузера chrome://inspect и подключаемся к телефону.
3️⃣ В целом, на этом всё: мы можем анализировать код, который приходит в нашу WebView, ставить callbacks и анализировать логи.

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

Clean Android multi-module offline-first scalable app in 2022

Крутая статейка с примером проекта, который включает в себя наверное самые актуальные технологии на данный момент. В избранное ✅

👉 Multi-module
👉 Jetpack Compose
👉 MVI
👉 Kotlin Сoroutines
👉 Kotlin Flow
👉 Kotlin serialization
👉 Hilt
👉 Room

Код на GitHub → Android Kotlin starter project - 2022

Читать (En)

Может ли приложение быть запущено в нескольких процессах?

Короткий ответ – Да.

Но для начала давайте разберемся чем процесс отличается от потока.

Процесс – это сущность на уровне ОС. Каждая программа может быть запущена в одном или нескольких процессах.

Поток – это сущность на уровне Runtime Environment.

Программа может выполняться в нескольких процессах. В каждом из процессов может быть создано несколько потоков (Java Threads).

Вернемся к андроиду. В предыдущем посте мы рассмотрели базовые компоненты и узнали, что каждый из компонентов может быть точкой входа в приложение. По умолчанию компоненты приложения работают в дефолтном процессе, но каждый из компонентов <activity>, <service>, <receiver>, <provider> может иметь поле android:process="<name>" в андроид манифесте. Кастомное значение этого поля явно говорит системе в каком процессе будет работать компонент.

Важно: При старте нового процесса создается инстанс приложения и снова вызывается Application.onCreate(). Если в этом методе вы инициализируете модули или библиотеки, которые используются только в главном процессе, то не забывайте проверять, в каком процессе вы находитесь в момент инициализации.

Подробнее про процессы и треды читайте в документации.

#System

5 ways to improve your android build productivity

Авторы дают рекомендации как можно ускорить сборку Android Gradle проекта и упростить его дальнейшую поддержку.

1️⃣ Обновлять инструменты и библиотеки, используемые в проекте, как можно чаще.

👉 чем чаще обновляем, тем проще сам процесс обновления
👉 чем раньше обновить зависимости, тем больше останется времени на непредвиденные изменения
👉 не использовать динамические версии зависимостей в проекте
👉 не использовать api там, где можно обойтись implementation
👉 новые обновления зачастую приносят новые фичи и улучшения, позволяющие ускорить сборку проекта

Примером такого улучшения может являться Gradle Configuration Cache, который на современной версии можно включить следующим образом:

// in gradle properties
org.gradle.unsafe.configuration-cache=true

2️⃣ Использовать Version Catalog для управления зависимостями (позволяет определить все зависимости в едином месте с возможностью включения по всему проекту).

3️⃣ По возможности избегать выполнение лишней работы.

👉 удалять неиспользуемые gradle репозитории для ускорения поиска зависимостей
👉 для тестирования сборок создавать отдельные flavors, в которых оставлять только минимальный набор необходимых ресурсов: resConfigs("en", "xxhdpi")
👉 отключить Jetifier (в Android Studio можно запустить Jetifier Check для проверки отсутствия зависимостей от старых support библиотек):

// in gradle.properties
android.enableJetifier = false

👉 отключить генерацию BuildConfig (особенно актуально в случае многомодульного приложения, так как на каждый модуль генерируется свой конфиг):

android {
buildFeatures {
buildConfig = false
}
}

👉 не смешивать Java и Kotlin (происходит генерация дополнительного кода для поддержки совместимости между языками)

4️⃣ Использовать многомодульный подход организации проекта.

👉 incremental build
👉 build cache
👉 parallel build

5️⃣ Использовать Composite Builds.

Создавать в проекте отдельный Convention Plugin, в который выносить общую логику для сборки однотипных модулей. Затем использовать данный плагин в необходимых модулях, тем самым уменьшая повторяющийся код в файлах build.gradle.

Kevlar – библиотека с набором проверок безопасности

- Пакет antipiracy проверяет, нет ли на устройстве пользователя пиратского софта
- Пакет rooting определяет наличие root-доступа или других аномалий, связанных с системой
- Пакет integrity проверяет, не модифицировано ли как-то само приложение

​​Important Performance Metrics
#android

Попалась статья, в которой описываются ключевые метрики Android приложений. Особенно полезно изучить её прежде чем начинать оптимизировать своё приложение: как минимум, вы будете понимать, на что стоит потратить свои усилия. 😉

1️⃣ Фазы запуска приложения — важная метрика, которая видна пользователю приложения как только он открывает его. В целом, есть следующие этапы запуска приложения:

➡️ cold start — открытие приложения сразу после его установки, полного закрытия, перезапуска системы и т.д. Как раз тут и вызывается Application.onCreate(). По мнению автора, время холодного запуска должно быть меньше 500 миллисекунд, большее время заметно пользователям и может вызвать раздражение.
➡️ warm start — измеряется, начиная с Activity.onCreate() перед созданием дерева View. Его можно получить, если сделать поворот экрана, во время которого пересоздаётся Activity, ну или когда система вытесняет ваше приложение из памяти, если оно находится в фоне.
➡️ hot start — измеряется, начиная с Activity.onStart(). Его вы получаете, когда переключаетесь между приложениями.

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

2️⃣ Time to Initial Display — это время до отрисовки первого кадра вашего приложения, можно проверить при помощи ActivityTaskManager с тэгом Displayed.

3️⃣ Time to Full Display — время, когда было отрисовано всё необходимое для работы с экраном. Любопытно, что эту метруку можно не только проверить, но и настраивать при помощи reportFullyDrawn() метода Activity.

4️⃣ Frame rates — важная характеристика, которая показывает, насколько плавно работает ваше приложение. Тут есть прямая зависимость от частоты обновления экрана, и автор рекомендует взять за эталон 90 fps: следовательно, у нас есть максимум 1/90 или 11.1 миллисекунд для отрисовки одного кадра.

Больше деталей можно посмотреть в самой статье