Хватит использовать 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
- Влияние улучшений на продуктовые метрики

Про фейлы на собеседованиях: 5 минут

Весна 2017 года. На тот момент, я работал чуть меньше полугода в аутсорсе, в котором почти ни один мой проект не дошёл до продакшена. В то время, рынок был в неплохом пике и рекрутеры уже писали сами в LinkedIn даже с таким опытом.

После общения с ректутёром в одну из небольших компаний, тех интервью началось с рассказа о себе: про проекты за проектами, про попытки работать с RxJava/Dagger2/Moxy/ButterKnife и прочими героями того времени.

Однако, я зафейлил абсолютно всю добрую классику — на вопросы «расскажи про equals/hashCode», «volatile & synchronized» и т.д. — мне особо нечего было ответить.

Собес закончился за 5 минут, со словами

может быть вы прекрасно знаете как работает подкопотная магия Dagger 

(лол

,

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

, но то, что я вас спросил, мы активно используем.

Это был мой первый тех собес в жизни (на позицию Junior на первой работе меня взяли после просмотра GitHub и behavioral интервью. Такая роскошь иногда проскакивала на везение в 2016, что сейчас кажется нереальным)

Позже, я не так позорно завалил ещё 4 собеса в ряд в другие компании, но уже с другими пробелами, на этот раз больше с AndroidSdk и алгоритмами.

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

Вывод — не бойтесь заваливать интервью. Да, это неприятно, да, это бьёт по самолюбию, но в конечном итоге именно этот опыт повышает ваши шансы в будущем 🙂

Продолжение следует.

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

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

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

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

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

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

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

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

Видео

Если вы используете старую версию Media/ExoPlayer, сейчас самое время обновиться.

После обновления до версии 1.5.1, мы увидели улучшение TTFF (Time to first frame) на 14%.

Кроме того, 1.6.0 и более новые версии улучшают настройки LoadControl для shorts. Если у вас они не кастомизированны, ExoPlayer будет грузить на 60% меньше данных для старта видео!

Последние полтора года я также тесно работал с ExoPlayer и недавно опубликовал вторую статью об улучшении Android видео перформанса в Reddit

Одна из «прелестей» работы в видео команде это вот такие вот баги.

Практически всегда когда я вижу что-то подобное, непонятно, как пройдёт день и удастся ли нормально поспать. Но в то же время, наверное у нас у всех есть уже принятие, что «борьба с системой» уже норма, что Android не был бы Android-ом без таких проблем.

Если у вас в продукте есть видео, вот тут детали фикса.

Так же, мой первый PR в androidx.media с воркэраундом был вмержен & будет доступен в 1.8.

Недавно произошло то, к чему я шёл последние несколько лет: меня повысили до Staff Engineer в Reddit!

Получилось с 3-го раза. Первая попытка была ещё в далёком 2022 году, когда я работал в Revolut, вторая в 2024 году, и третья уже в этом.

Одно из осознаний: вся эта история с повышениями немного напоминает прохождение интервью, что в целом отдельный скилл, который часто слабо связан с повседневной работой.
И там, и там вас оценивают и решают, идёте ли вы дальше. В обоих случаях задействован результат вашей работы (в случае а интервью, раунда), соответствие требованиям и обратная связь.

После 2х фейлов я стал относиться к этому как к некой подготовке к «интервью». Самое основное, до того как начать, это полностью разобраться, как оно всё устроено: от требований в career ladder (в бигтехе они всегда формализированы), до того, как работают перформанс комитеты, кто в них и на что смотрят.

Следующий шаг, когда уже понятно, как всё работает, понять, где ты сейчас и какие есть пробелы. Я взял каждое требование из career ladder к Staff и стал под подкреплять каждое из них данными в цифрах. Если данных нет или они слабые, значит это пробел, и его надо закрыть.

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

Ты бы поддержал мой промоушен до Staff? Если да, почему. Если нет, почему.

Это так же помогает избежать недопонимания и сюрпризов. В моём случае я выяснял, что многие люди просто не знали, чем я занимаюсь и какие у меня результаты, поэтому не поддеражали бы промоушен. Brag doc, про который я упоминал в прошлых постах, здесь сильно помог.

Делать все эти шаги я начал за полгода до официального цикла.
Если снова вернуться к аналогии с интервью, многое из того, о чём я написал, по сути представляет собой «мок интервью», где есть обратная связь и шаги, что делать дальше 🙂