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 миллисекунд для отрисовки одного кадра.

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

​​#Article #Blog #Performance

6 Jetpack Compose Guidelines to Optimize Your App Performance

Статья с большим количеством советов (разбитых на 6 правил) о том, как можно значительно улучшить производительность вашего приложения на Compose. Авторы затрагивают такие темы как стабильность классов (о которой был предыдущий пост), правильный вынос state-ов (State hoisting), и много чего ещё. Рекомендую к прочтению.

🔥 Touchlab сделал мобильное приложение для Droidcon NYC на Android и iOS, использую Compose для каждой из платформ 😮

Это первый production на Compose iOS, который сделали еще даже до появления dev preview Compose iOS

iPhone у меня нет чтобы оценить приложения, но может вы сможете когда оно опубликуется (на момент выхода поста проходит ревью)

👉 Исходники приложения на GitHub

Lessons Learned Migrating the Maps SDK to Compose

Автор рассказывает об уроках, полученных в процессе создания полноценной библиотеки android-maps-compose вокруг Google Maps SDK для Jetpack Compose.

Изначальный подход добавления Google Maps SDK в проект на Jetpack Compose предполагал использование @Composable функции AndroidView совместно с LifecycleEventObserver и DisposableEffect . В простых сценариях, когда необходимо отобразить статически несколько точек на карте, данный подход применим и по сей день. В более сложных задачах, когда необходимо постоянно динамически пересчитывать отображаемые точки на карте, данному подходу не хватает гибкости из-за нехватки механизмов эффективного подсчёта разницы между получаемыми списками точек. Именно поэтому авторы пришли к написанию отдельного решения, позволяющего оптимизировать работу карты в Compose мире.

Полученные уроки, можно выделить в следующий набор правил:

1️⃣ Решать задачи декларативно при работе с Compose

Основные элементы, отображаемые на карте, такие как Marker, Circle, Polygon, Polyline были реализованы на основе ComposeNode.

2️⃣ Переиспользовать компоненты как можно больше

Управление камерой было вынесено в отдельное состояние rememberCameraPositionState(), с помощью которого можно осуществлять как изменение позиции камеры, так и добавление анимаций передвижения.

3️⃣ Использовать особенности Kotlin

Автор отдельно отметил использование корутин: удалось избавиться от большинства коллбеков и упростить работу с последовательностями анимаций.

4️⃣ Не забывать о правилах написания кода при работе с Compose

5️⃣ Не забывать адаптировать API под типы Compose

Установку сдвига для маркера на карте можно сделать с помощью Offset, а его установку цвета - на основе Color.

6️⃣ Предоставить возможность "аварийного выхода"

На данный момент реализованная библиотека включает в себя не весь функционал, доступный в Google Maps SDK Utility Library. Для возможности использования остального функционала был придуман MapEffect, позволяющий обратиться напрямую к объекту карты:

MapEffect(items) { map ->
if (clusterManager == null) {
clusterManager = ClusterManager<MyItem>(context, map)
}
clusterManager?.addItems(items)
}

Исходя из названия доклада, перед его просмотром в первую очередь ожидаешь увидеть какие-то специфичные советы, актуальные при работе с картами в Compose и влияющие на оптимизацию и скорость работы. К сожалению, автор практически не предоставляет таких советов, зачастую скатываясь к пересказу базовых вещей из документации, актуальных при написании кода на Compose.

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

Wolfia – сервис, который позволяет пошарить эмулятор с запущенным приложением

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

Рубрика «Почему бы и нет»: краткий туториал по превращению Android-устройства в веб-сервер.

Читать

MVI for Compose

Еще одна серия статей про организацию MVI для Compose. Разбираются некоторые особенности MVVM, чем отличаюется MVI от MVVM, ну и примеры кода и best practices.

👉 Part 1 – Problems and benefits of MVVM
👉 Part 2 – Custom MVI
👉 Part 3 – Practical examples, continued implementation
👉 Part 4 – Automating / Reducing boilerplate
👉 Part 5 – Best practices and conclusions