Как задача по добавлению одной простой зависимости увеличила размер APK почти на 10%, но мы вовремя разобрались.

Сегодня расскажу одну интересную историю. Нужно было добавить небольшую зависимость в проект, я посмотрел описание и оценил задачку в пару SP. Прописать dependency в build.gradle - задачка с которой справится и стажер.

Но не тут то было. У нас есть мониторинг, который вычисляет разницу релизной APK до и после изменений. Оказалось, что после добавления этой библиотеки размер проекта увеличился почти на 10%. Как следствие pipeline на CI/CD упал с отчетом, что такое увеличение не допустимо. После тщательного изучения проблемы, оказалось, библиотека притащила агрессивные Proguard-правила, которые отключили оптимизацию для всего приложения.

⚠️Как работают Proguard-правила в Android-проекте:

1. Основные правила проекта – находятся в файле proguard-rules.
2. Правила из зависимостей (библиотек) – могут поставляться внутри AAR/JAR-файлов как proguard.txt.

Что происходит при сборке:
Если библиотека предоставляет свои Proguard-правила, они объединяются с правилами основного проекта.
Порядок применения зависит от порядка зависимостей, но обычно:
- Сначала применяются правила библиотек.
- Затем – правила основного проекта ( proguard-rules).

В моем кейсе были следующие проблемные правила:

1. -keepclassmembernames class  * { public protected <methods>; }
 - Действует на все классы приложения (из-за  *), отключая оптимизацию методов. В коде SDK нужно уточнить правило, чтобы оно затрагивало только классы SDK.

2. -keep public class  **.BuildConfig {  *; }
 - Сохраняет все BuildConfig в проекте, хотя нужно только свои.

3. -keep class ru.example. ** {  *; }
 - Полностью отключает оптимизацию всего SDK, хотя можно ограничиться только моделями (например, сериализуемыми классами).

Вывод:
Обязательно добавьте проверки на CI/CD, чтобы мониторить изменения в вашем приложении. Если вы разрабатываете SDK или библиотеку - обязательно проверяйте настройки proguard, чтобы не влиять на проекты, которые будут внедрять ваше решение. Свою обратную связь мы передали разработчикам и в следующей версии уже все поправили, так что все хорошо.
Правила должны быть:
📌 Конкретными (без дженериков, где возможно).
📌 Ограниченными только своим кодом (не затрагивать классы приложения).
📌 Проверки на CI/CD помогут вам оперативно выявить проблемы до релиза в прод.

А у вас есть проверки на CI/CD и как они вам помогают?

Посещение конференций как способ оценить обстановку на рынке труда.

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

И выводы неутешительные.

💃 Во-первых, заметил кратное уменьшение кол-ва HR-специалистов. Еще пару лет назад, приходилось буквально уворачиваться от цепких рук HR-специалистов, которые активно охотились на айтишников во время конференции. А если все-таки заполнил анкету на стенде - жди минимум нескольких десятков сообщений от разных HR-ов с предложениями о работе.

🛍️ Во-вторых, уменьшение стендов и каких-то интересных инициатив со стороны компаний. Раньше были хакатоны, стажировки и просто конкурсы в стиле: реши несколько задачек и выиграй iPhone 15 Pro Max. Компании ценят свое время и деньги и времена, когда после конфы можно было уйти с новенькой Playstation закончились. Высокая ключевая ставка готовит компании к оптимизации расходов.

🔹 Отмена конференций. Я готовился в том числе на конференцию AppsConf25, но, за несколько недель, пришла новость, что конфы не будет. Подробностей не знаю, но сам факт отмены конференций (не из-за ковида) вижу впервые.

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

На мой взгляд, тем у кого есть опыт в разработке от 5+ лет не стоит волноваться, но в то же время, уделять время на обучение и подготовку к собеседованию в данное время нужно как никогда.

Количество этапов сильно увеличилось, будьте готовы порешать задачки и пройти этап System Design Interview. Кстати именно этот этап, я считаю самым эффективным, который позволяет оценить опыт кандидата. В тоже время для мобильных разработчиков этот этап считается и самым тяжелым, так как материалов именно для мобильных разработчиков не так много. Планирую как раз раскрыть несколько важных тем по System Design для Android в следующих постах. А как вы оцениваете текущий рынок мобильной разработки?

Работа с метриками приложения: измеряем, анализируем, улучшаем производительноть приложения

Появилась запись моего доклада с конференции Merge 2025 в Иннополисе, где я поделился опытом внедрения метрик производительности в мобильное приложение Звук. В прошлом году мы уделили много времени именно качеству работы приложения и его производительности. В докладе рассказал, какие инструменты рассматривали для анализа, как в итоге разработали собственный Performance-tracer, и какие метрики получилось улучшить. Тут опишу основные тезисы:

📌Зачем собирать метрики производительности?
Стабильность – ловим баги до пользователей.
UX – ускоряем старт и рендеринг.
Ресурсы – экономим трафик и батарею.
Бизнес – рост конверсии и удержания.
Техдолг - проще анализировать и планировать работу

🛠 Из каких инструментов выбирали:
Firebase Crashlytics: Простота, детальные отчеты о сбоях
Firebase Performance: Удобные дашборды, автоматически собирается статистика о работе приложения. Но немного замедляет старт приложения и нет гибкой настройки.
Sentry: Мониторинг ошибок + перфоманс, из минусов дорого, сложная настройка self-hosted решения
OpenTelemetry: Гибкость, open-source. Но изначально это решение для backend-разработки, не нашел ни одного примера кто использовал бы в мобильных приложениях и нет документации для Android.
В итоге, мы как настоящие разработчики решили сделать свое кастомное решение на базе Redash + кастомные трейсы

📌 Какие метрики собирали?
Холодный/горячий старт
Отрисовка экранов
Скорость сетевых запросов
Парсинг JSON, инициализация DI
Бизнес-логика и воспроизведение контента

🚀 В итоге, используя все доступные инструменты для оптимизаций мы добились
Холодный старт: -20%
DI-инициализация: -15%
Inflate-методы: стали в 2-20 раз быстрее

Выводы:
1. Собирайте метрики до того как заметили проблемы в проде
2. Начинайте с бесплатных инструментов (Firebase, Profiler).
3. Дашборды – мощный аргумент для построения roadmap и инструмент тимлида для планирования работы с техдолгом.

​​🏕️ Выступил на ИТ-кэмпе Summer Merge 2025.
На прошлых выходных получилось совместить казалось бы абсолютно разные вещи: ИТ и отдых на природе. 2 насыщенных дня на берегу Волги на конференции Summer Merge пролетели незаметно. Утром: йога и сапсефринг, днем ИТ-доклады и полезный нетворкинг, а вечером кавер-группы и эндуро-покатушки на мотоциклах.

Мероприятие позиционировалось как антиконференция: палаточный городок, пляжный волейбол и вечерние дискотеки вперемешку с ИТ-докладами. Поэтому и требования к докладам соотвествующие: не сильно сложно, но в то же время интересно и практично. Я рассказал о том, как мобильному разработчику развивать свои Pet-проекты, почему это важно, а также поделился собственным опытом релиза нескольких своих мобильных приложений, как искал первых пользователей и внедрял монетизацию. Если интересно - накидайте огоньков, попробую как-нибудь рассказать здесь об этом.

Как итог, поездка оказалась насыщенной, увиделся со старыми друзьями, послушал несколько интересных выступлений, а самое главное - зарядился новыми идеями и немного отдохнул.

​​Список литературы на лето для Android-разработчика

Помните, как в школе задавали список книг для чтения на летние каникулы? Во взрослой жизни, к сожалению каникул уже нет, но учиться нужно не меньше. В этом, как и в прошлом году, поставил цель 30 книг за год. В данный момент читаю параллельно 3 книги и хочу поделиться с вами .

Карьера Software Engineering Manager. Эффективное управление командой разработчиков. Лидом я работаю уже давно, часть описанных идей для меня не были новыми, однако всегда полезно структурировать то, что уже есть и подметить известные решения с новой стороны. Очень понравилось, что повествование книги выстроено как в симуляторе. В каждой главе рассматривается какой-то отдельный аспект менеджера команды, описывается типичная ситуация и ты уже представляешь себя в этой ситуации и начинаешь думать как поступил бы. Считаю что обучение на каких-то типовых ситуациях приближенных к реальной жизни самое эффективное. Можно смело брать и читать. Будет полезно тем, кто хочет вырасти из senior в лида.

Карьера разработчика. Стафф — круче, чем senior Понятие Staff-разработчика довольно новое в ру-компаниях, поэтому хотелось структурировать уже имеющиеся знания и почерпнуть новое. Ожидания от книги были высокие, пока прочитал половину, и если честно, вода водой. Ни примеров из жизни, ни вдохновляющих историй роста в компании. Читается сложно, но надо осилить, возможно в конце книги будет что-то интересное, пока не рекомендую.

Kotlin в действии, 2-е изд. Ну тут думаю не стоит объяснять, самая полная и точная книга по Kotlin из всех доступных. Новое издание, считаю что у любого разработчика должна быть подобная книга.

Пару слов, о том, как я веду список. В Xmind я создал mindmap из списка книг, которые хотел бы прочитать. Для каждой книги создается отдельный план по главам. В процессе отмечаю какую главу прочитал и где остановился. Ставлю пометку Сделано напротив - это добавляет удовлетворения от выполнения небольшой задачки. Плюс всегда можно вспомнить на какой главе остановился. Легко и просто. А вы составили список книг на лето? Делитесь полезными книгами для разработчика

Наглядные примеры работы Kotlin Flow операторов

Кто работал с RxJava, возможно, помнит интерактивные Marble-диаграммы, для более наглядного понимания работы операторов.
Было бы круто что-то похожее увидеть и для Kotlin Flow для наглядности работы.

Нашел классную статью с крутыми анимациями с пиксельной графикой, которые автор создал для объяснения работы популярных операторов в Kotlin Flow. Ощущается, как будто играешь в какую-то игру на Nintendo.

​​LRU-кэш: Как сделать историю поиска за 3 строки кода (и пройти собеседование)

Мы в Звуке уже давно используем System Design для проверки знаний и умений кандидата. И часто, задача состоит в том, чтобы спроектировать 1-2 экрана похожих на те, что реализованы в приложении. Обычно это поиск + лента. И тут можно до бесконечности обсуждать способы реализации: пагинации списков, эффективного поиска, офлайн-кэширования и так далее. В этом и сложность этого этапа.

Так вот, один из таких вопросов это: "Как реализовать историю поиска и показывать пользователю последние запросы, а старые удалять?" Очень часто, кандидаты предлагают решение на базе HashMap. Предлагают хранить кол-во запросов/дату запроса и потом сортировать их от наиболее свежего до старого. Такой подход будет работать, но можно предложить более эффективное решение. Называется такой подход LRU-кэш.

LRU (Least Recently Used) — это алгоритм кэширования, который автоматически удаляет редко используемые данные, чтобы освободить место для новых.

Какие плюсы от LRU-кэша в данной задаче:

1. Автоматически удаляет старые элементы
Если пользователь искал много запросов, LRU удалит самые старые, оставив только последние (или N самых свежих).
Например, можно ограничить кэш 10 последними запросами.

2. Быстрый доступ к недавним элементам
LRU хранит элементы в порядке их использования, поэтому получить список недавних запросов можно за O(1).

3. Простота реализации
Во многих языках есть готовые реализации (например, LinkedHashMap в Java,

LinkedHashMap часто используется для реализации LRU-кэша, потому что эта структура данных сочетает в себе преимущества хеш-таблицы и связанного списка. Например с помощью accessOrder = true при любом обращении (вставка/чтение) элемент перемещается в конец. А метод removeEldestEntry() позволяет автоматически удалять самый старый элемент при превышении размера.

Вот так знание патерна LRU позволит вам не изобретать велосипед, а просто и эффективно решить такого рода задачу. Такие задачи - частый вопрос на собеседованиях (например, в Яндексе, Тинькофф, VK). И на практике, в android - проектах такие задачи постоянно встречаются. Например, библиотека Glide для кэширования ресурсов также использует LRU. Эти и другие эффективные подходы мы разбираем на курсе по System Design

​​Как получить +30% к зарплате к осени?
Анонс курса по подготовке к Mobile System Design.

Друзья, 5 августа стартует интенсивный тренинг по подготовке к мобильному System Design. Таким образом, к осени, когда компании начинают сезон найма вы будете уже готовы! Почему стоит пройти этот курс:

1️⃣ Максимально приближенные к реальным кейсы из BigTech. Разберем типовые кейсы, которые спрашивают в Avito, Yandex и т.д. А на Mock-собеседовании потренируемся.

2️⃣ Хватит рассказывать про Load Balancer и рисовать общие диаграммы с репозиториями! На курсе мы разберем ошибки, из-за которых вы не получаете хороший оффер.

3️⃣ Это хороший способ систематизировать уже имеющиеся знания, и начать расти в сторону архитектора. Мы разберем различные инструменты кэширования, backoff policy, обсудим плюсы/минусы разных форматов передачи данных - в общем те темы, которые часто нужны на более высоком грейде.

Цена пока довольно скромная, скоро повышение, поэтому рекомендую не откладывать тем, кто всерьез хочет прокачаться и уже к осени быть готовым к горячему сезону найма и performance review. Посмотреть отзывы и программу можно тут

Отзыв с Mock-собеседования по System Design.

Главная цель — не просто обучить участников навыкам, но и помочь им достичь поставленных целей. Это может быть систематизация знаний или получение оффера в крупную компанию. Именно второй цели достигла Юля. После Mock-интервью, собеседование по System Design в Яндекс она прошла без проблем, и уже работает в команде инфры.

Проходила мок-сосбес по System design. Понравилась атмосфера проведения, в процессе выписала для себя 3 страницы того, что нужно улучшить перед реальным собеседованием. После интервью получила развернутый фидбек. Что было хорошо, что нужно подтянуть. Причем фидбек был не абстрактный, а детализированный. Какие подходы/фреймворки стоит покопать, что стоит упоминать, и чего делать не надо. В общем, получила план развития, который, я уверена, приведет меня к моей цели!

А я напоминаю, что сегодня, последний день до повышения цены! Посмотреть отзывы и программу можно тут

​​Как спроектировать новостную ленту. Mobile System Design

Написал на хабре первую часть статьи-разбора как спроектировать мобильное приложение по типу новостной ленты. В первой части затронул такие важные этапы как сбор требований и проектирование коммуникации с Backend и проектирование API. Так мне в комментариях написали, что это не относится к мобильной разработке, ну что ж. Идея заключается в том, что чем сложнее и больше у вас проект, тем больше разработчик должен разбираться в смежных системах и инструментах.

Например мы в платформе когда делали свой инструмент для сбора performance-метрик задействовали Python для визуализации трейсов, Redash для бэкенда и еще сами писали SQL-запросы для Data-аналитиков. Так и на собеседовании по System Design, вас вряд ли спросят как сверстать кнопку. У меня как-то был кейс когда пришлось рассказывать про Message Queue на бэке и выбирать между Kafka и RabbitMQ.

А еще во многих компаниях (у нас в том числе) проходят так называемые защиты архитектуры той или иной фичи. И мобильные разработчики вправе выбрать и спроектировать такой API который будет удобен именно им и часто общаются с Backend-командой. Так что это тоже очень важный скил.

Закончился курс по System Design Interview

В августе я анонсировал курс по подготовке к System Design, и совсем недавно он завершился.

Курс был довольно интенсивным и насыщенным: вместе с участниками разобрали как теоретические аспекты построения систем в контексте мобильных приложений, так и потренировались на домашних заданиях и Mock-собеседованиях на реальных примерах из крупных компаний.

Я всегда собираю обратную связь в конце, и оценка NPS курса составила 9.33 (из 10) 🔥

Вот что говорили участники, когда пришли на курс:

Чувствую, что мне не хватает знаний по архитектуре, чтобы в современном подходе написать приложение с нуля.Планирую собеседоваться в крупные компании, где могут быть этапы по System Design, ранее только отдельные вопросы или небольшие блоки его касающиеся были на собеседованиях и я "плыла", в том, что сама не делала.

Последние несколько лет работаю в финтех проектах в фича-командах. Так как проекты большие и приходилось пилить только фичи по макетам из Figma, времени на погружение в цельную архитектуру не оставалось.
Твой проект androidschool давно знаю, классные статьи и темы там описываешь. От текущего курса ожидаю структурировать знания и попрактиковаться на mock-интервью.

Хотел бы структурировать знания по архитектуре мобильных приложений и приобрести навыки по прохождению system design собесов.

Судя по опросу, все цели курса были достигнуты.
Теперь ребята уверенно себя чувствуют в контексте System Design и смело выходят на непростой рынок ИТ.

✅ Могут спроектировать архитектуру сервиса,
✅ Подсветить edge-кейсы и выбрать наиболее подходящий стек,
✅ И самое главное — уложить это всё в 50 минут, которые обычно отводятся на system design собеседования.

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

Не успеваю написать пост, батарея садится или про анализ энергопотребления Android-приложений.

На днях занимался анализом энергопотребления приложения и скажу вам: отладка энергопотребления приложения — одна из самых неоднозначных задач. Нашел два хороших доклада, которые будут полезны многим Android-разработчикам, где расскажут как получить понимание, насколько сильно приложение нагружает устройства пользователей. Спешу поделиться с вами, будет чем заняться на выходных, так как в Москве выключили лето. Всех с пятницей и хороших выходных!

Анатомия энергопотребления
Анализ энергопотребления

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

🚗 Внедрили Звук в 2GIS - самый сложный проект этого года. Теперь вы можете слушать любимую музыку сразу в приложении 2GIS в режиме навигации. Вот где навыки System Design пригодились и прокачались. С точки зрения архитектуры и взаимодействия было очень интересно и нетривиально, необходимо было выделить в отдельный SDK логику для проигрывания, а также разделить дизайн-систему с минимум зависимостей так как у таких проектов обычно очень жесткие требования на размер и кол-во зависимостей. Кстати именно этот проект получил награду Релиз года от CEO.

⌚Разработали приложение для Huawei Watch GT 6 и 6 Pro - можно слушать музыку теперь и во время пробежек.

🚅 Множество рефакторингов и оптимизаций. Внедрили Baseline Profiles, а также распилили Shared Preferences на множество независимых DataSource-ов, в сумме ускорили старт приложения до 40%!

🦾 Одни из первых в команде внедрили AI-based code review в пайплайны (ну куда ж без AI), сократив время код-ревью, а также множество проверок для качества приложения: чекаем размер apk, делаем замеры энергопотребления.

И это только самые заметные проекты, не считая миллиона других важных задач. Год был продуктивным, поэтому на канал, к сожалению, было не так много времени, но я готовлю апдейты по System Design - так что не переключайтесь.

Считаю очень важным уметь видеть результаты своей работы. Да, возможно не всегда все сделано идеально и не с первой попытки. Но важно системно работать над своими целями и тогда рано или поздно все получится. Поэтому в следующем году желаю вам и себе исполнения намеченных целей, расширения горизонтов и новых возможностей, продвижения по карьере.

А вы подводите итоги работы в своей компании?