​​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

Онлайн-книга про алгоритмы

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

​​10 неизвестных инструментов для Android-разработки
#android

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

1️⃣ stackzy — приложение, которое позволяет посмотреть используемые зависимости и разрешения любого приложения. Помимо того, что оно красивое, так еще и написано на современном стеке и компонентах: Compose Desktop, MVVM, Coroutines & Flow.
💡Забавный факт: приложение использует Google Sheet в качестве backend.

2️⃣ v9 — некоторые должны помнить 9-patch файлы, которые динамически и автоматически изменяют размер растровых изображений в соответствии с тем, что внутри и размером экрана. Есть подобный инструмент для Path, который делает похожие штуки.

3️⃣ Glance — инструмент для просмотра содержимого базы данных вашего приложения. Выглядит как полезный инструмент для тестирования, а подключается по аналогии с LeakCanary, которым вдохновлялись при создании этой библиотеки.

4️⃣ adb-tools-mac — всплывающее меню для работы с Android-устройствами для MacOS. Может быть полезно вашим тестировщикам (разработчиков подобный плагин есть внутри Android Studio).

5️⃣ name-that-color-desktop — почти бесполезное, но забавное приложение, которое именует за вас цвета по отправленному hex-коду. Подобное есть ещё тут, так что приложение ставить не обязательно.

6️⃣ Gradle Task Tree — Gradle plugin, который построит дерево вызванных задач для конкретной команды. Полезная вещь для дебага времени билда приложения.

Статья о том, как не эксплуатируемый баг превратить в эксплуатируемый, да еще и 0 click. И не где-нибудь, а в великом и ужасном (если смотреть в исходный код) Telegram-е.

tl;dr обход Uri фильтра и использование недостатков ChooserTargetService

https://dphoeniixx.medium.com/chaining-telegram-bugs-to-steal-session-related-files-c90eac4749bd