Зачем этот канал?

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

При этом, далеко не всегда эти мысли вмещаются в одном твите.
В то же время, они не дотягивают до формата полноценной статьи.
Все эти мысли — навсегда теряются в недрах памяти.
Этим каналом я хочу закрыть эту дыру.

Что вам это даст?

Вы точно сможете узнать что-то новое.

Даже если нет — этот канал однозначно будет согревать вашу душу холодными зимними вечерами одним своим названием в вашем списке чатов

Ограничиваем время выполнения Unit-тестов

Несколько раз замечал, что сборки PR-ов на

TeamCity

падают по таймауту самой джобы. (У нас это 1h30m)

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

Решение

Ограничить время выполнения каждого теста.
Круто, что

JUnit5

позволяет сделать это централизованно через

systemProperty

Сколько весит приложение ?

После полного перехода на AppBundle, стало намного сложнее понять финальный размер приложения в Google Play.

Всэ зависит от ABI, плотности экрана (от котороой зависит выбранные ресурсы) и даже локалей, поддерживаемых на устройстве.
Все они представленны в виде отдельных apk, запакованных в bundle, с использованием bundletool под капотом.


Как узнать размер приложения?

bundletool отвечает не только за упаковку, но и за обратную распаковку, которая используется в Google Play.

За пару команд, мы можем раздробить bundle на все apk-шки и узнать вес, в зависимости от ABI, ресурсов или локалей, как показано на картинке.

По статистике, максимальный размер у arm64-v8a с xxxhdpi

Ускоряем Android Studio

С ростом количества кода и остальных файлов в проекте, скорость работы нашей любимой IDE оставляет желать лучшего.
В Android Studio можно отключить индексацию

apt

,

kapt

и

.gradle

файлов.

Довольно старый, но всё ещё актуальный пост на эту тему

Gradle Enterprise & AAB Tests

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

Решил описать, как это можно делать с помощью Gradle Enterprise

Основы Gradle

Как правило, Gradle, это то, что многие предпочитают избегать. (Не считая добавления зависимостей)

Собственные таски/плагины могут сильно помочь автоматизировать рутину, особенно в больших проектах.

Нашёл довольно неплохой плейлист из 17 коротких видео, который поможет вам разобраться с основами

Не одним ViewModel и Jetpack едины

Вчера выложили в open-source фреймворк Kompot, с помощью которого мы ведём разработку во всех продуктах в Revolut.

Unidirectional data flow со строгими контрактами (Input + Output), Screens, Flows, Navigation — всё это позволяет забыть даже про fragments с activity, и держать фокус на главном — разработка фичи

Немного про Manifest & Android 12

Большую часть пятницы убил на то, чтобы исправить проблемы со сборкой при обновлении на targetSdk=32

Написал небольшой пост про это

Gradle Catalog: Bundles

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

Хватит использовать ResourceProvider во ViewModel

Написал небольшой пост про то, какие проблемы и альтернативы есть у использования класса-обёртки над appplicationContext в Presenter/ViewModel, для работы со строками

Gradle открыл регистрацию на серию бесплатных тренингов на январь.

Лично посещал тренинги по Build Cache и Dependency Management, весьма хорошее погружение с неплохой практикой

Недавно выступал на Londroid, где рассказывал про все типы кеша в Gradle и практики, которые позволяют улучшить и держать build time в тонусе.

Презентация
Видео

Наконец появилось время на полноценное написание постов.

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

Первая часть: Про приключения с алгоритмами и LeetСode

Прошло довольно много времени с тех пор, как я последний раз создавал кастомную вью. (Да что говорить, за 7 лет я написал всего несколько, чтобы прям по серьёзке, onMeasure/onLayout/onDraw и всё такое)

В прошлые выходные, я снова засел за изучение Jetpack Compose и попробовал сделать DonutChart (кстати, его можно вполне легко конвертировать в PieChart, поменяв useCenter на true и style на Fill у drawArc).

В старом способе создании вью, имплементация скорее всего выглядела бы так же, т.к. математические расчёты (самая сложная часть процесса для меня) — не меняются.

ViewPool для AndroidView в Jetpack Compose

Последнюю неделю оптимизирую скролл во всех списках с видео.
В данный момент, ExoPlayer не поддерживает рендеринг видео напрямую в Jetpack Compose, что решается оборачиванием TextureView в AndroidView.

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

Я уже стал реализовывать ViewPool для подобных кейсов сам, но обнаружил, что в Jetpack Compose 1.4 его поддержали (хоть и экспериментально). Работает это дело аналогично с RecyclerViewPool.

Несмотря на то, что результат радует и удалось избавиться от ~20% пропуска кадров, в RecyclerView это всё работало бы из коробки и проблем бы не было.

В прочем, Jetpack Compose без сомнений ещё нагонит своё со временем 🙂

Gradle и аббревиатуры

Недавно обнаружил, что Gradle позволяет использовать сокращённые названия тасок. Может быть даже одна буква, при отсутствии конфликтов.

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

Вероятно, самый простой способ измерить производительность скролла?

При улучшении перформанса, важно понимать, что оптимизации работают. Gfxinfo (работает с API 23+) позволяет получить всю необходимую информацию по потерянным кадрам одной командой, с помощью adb. Можно даже построить красивую гистограмму по времени, основываясь на output-е.

Данная утилита также используется в Macrobenchmark под капотом, которая позволяет автоматизировать этот процесс.

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

Автоматизация рутины

Почти всегда мне лень включать GPU/HWUI rendering вручную.

Несколько adb команд и небольшой bash-скрипт, который можно добавить в ~/.bash_profile или ~/.zshrc, решают эту проблему. Теперь все, что нужно сделать, это набрать «profiling» в консоли. (Настройка займет пару минут)

К сожалению, это всё не особо задокументировано. Параметры для команды удалось найти вот тут

Разбираемся с кешированием в Gradle

В прошлом году мне часто приходилось работать с Gradle.

Как мне кажется, кеширование — одна из самых сложных и интересных тем. В то же время, это самое импактное, что можно сделать для улучшения времени сборки.

Написал статью, в которой детально и с иллюстрациями затрагиваются все уровни кеширования и как они работают.

Убийство процесса

Всегда проверяйте, как ваши экраны ведут себя при восстановлении процесса. Особенно, когда дело касается главного экрана.

Недавно ковырял баг с тем, что соотношение initial http запросов не коррелирует с метриками просмотра экрана.

Оказалось, что проблема воспроизводится только при смерти и восстановлении процесса: до 10% пользователей систематично оставляют приложение в overview menu, и это только главный экран.

Проверить данное поведение относительно просто: можно через Android studio, нажав на красную кнопку в logcat. (Перед этим, свернув приложение).

Но в последнее время, мне всё больше и больше нравится использовать командную строку для подобного.