Основы 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. (Перед этим, свернув приложение).

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

Фиксируем результат работы

В этот раз немного отвлечёмся от Android и поговорим про достижения 🙂

Весь прошлый год я плотно работал с ExoPlayer и решил написал статью про это.

Что внутри?
- Как ускорить процесс загрузки
- Как улучшить разрешение
- Как предотвратить ошибки воспроизведения
- Ловушки и уроки
- Производительность с Jetpack Compose
- Влияние улучшений на продуктовые метрики

Про фейлы на собеседованиях: отказ на behavioural интервью

В начале 2019 года я уже был в пассивном поиске нового места работы. За это время я +/- научился проходить технические собеседования, выполнять домашние задания и live coding, однако у меня не было полноценного behavioural interview (или интервью с hiring-менеджером).

Ну, и вот настало время. Я зааплаился в Revolut, прошёл все технические этапы, и мне назначили последний — behavioural, с одной оговоркой — собеседование будет проводить нейтив. С английским у меня в тот момент было чуть лучше, чем «никак», однако, я не унывал: рекрутер мне сказал, что не знает никого, кто бы не прошел этот этап, что в целом что-то внутри заставляло меня думать об этом лишь как о формальности: я даже решил провести этот этап, находясь в отпуске, с очень плохим интернетом, что не было особо здравым решением.

Мы встретились, всё прошло, как мне показалось, отлично.

На следующий день приходит обратная связь от рекрутера, и я такой в саркастичной манере думаю:
О Боже, что же это, наверное, это оффер, да?
Однако, это был отказ, связанный с уровнем английского языка и тем, что интервьюер не всегда меня понимал. Сказали, что я могу попробовать снова через полгода.
Что ж. Я начал заниматься английским примерно 3-4 раза в неделю, и в то же время стал проговаривать ответы на типичные вопросы с этой секции практически каждый день.
Если вы заранее распишите ответ на каждый вопрос по методу STAR с хорошей историей, вы будете более чем готовы. (Это занимает время, но Brag-doc очень помогает с этим)

Прошло 3 месяца, как мне показалось, я был вполне готов. Я не хотел ждать больше, поэтому решил просто написать рекрутеру, не особо ожидая реакции.
Но мне разрешили пройти последний этап раньше, и в этот раз всё было намного лучше: мне дали оффер.
Спустя полтора года я переехал в Лондон, а через два года снова начал активно собеседоваться и сменил работу.

Недавно я побывал в Нью-Йорке и выступил на Droidcon с докладом про перформанс ExoPlayer, где поделился результатами многих экспериментов и рассказал про внутреннюю кухню плеера.

Хайлайты:
- Создание инстанса ExoPlayer может занять ~100ms и более.
Использование кастомного пула плееров и инициализация на IO, при запуске приложения не только улучшили скорость рендеринга, но и сократили количество "frozen" фреймов (кастомная метрика: фреймы, рендеринг которых занимает более 700ms) на десятки процентов в некоторых странах
- Инициализация декодеров может занимать ~70ms и более
- SurfaceView, скорее всего, окажется тратой времени и не принесёт желаемых результатов

Видео