Для Android-приложения один плохой релиз может стоить не только нервов команды, но и места в выдаче Google Play. Android-команда Иви рассказала, как выводила долю ANR в активном режиме ниже порога 0,47% и зачем после собственного сбоя пришлось ужесточать quality gate. Для русскоязычных мобильных команд это полезный сигнал: борьба за производительность давно стала не внутренней гигиеной, а фактором дистрибуции.
В интервью, о котором сообщает Habr / Карьера, технический менеджер Android-платформы Катя Супрун описала устройство core-команды Иви. Она отвечает за Android Mobile и Android TV, а ее зона ответственности лежит не столько в продуктовых фичах, сколько в менее заметной, но куда более капризной инженерии: производительность, загрузки, рефакторинг, оптимизация, релизы в магазины приложений и работа над дизайн-системой. Стек при этом вполне ожидаемый для зрелой Android-разработки: Kotlin, Coroutines, Compose и Kotlin Flow. То есть без экзотики, зато с акцентом на системную работу там, где у многих компаний обычно заканчивается терпение и начинается очередной «быстрый фикс».
Самый конкретный тезис из интервью касается Android Vitals — метрик Google, по которым Play Store оценивает качество приложения. В Иви отдельно выделяют долю ANR в активном режиме, тот самый случай, когда пользователь видит зависшее приложение и знакомый выбор: подождать или закрыть. Для команды это была не просто неприятная цифра в консоли разработчика. По словам Супрун, если показатель не укладывается в доверенный порог ниже 0,47%, приложение может реже показываться в выдаче магазина. Проще говоря, стабильность влияет не только на пользовательский опыт, но и на видимость продукта. Это уже не вопрос эстетики кода и не абстрактный DevEx, а прямая связь между инженерным качеством и трафиком.
Интересно и то, как именно Android-команда Иви к этому шла. Готового рецепта не было: команда проверяла гипотезы от релиза к релизу, часть решений помогала, часть не давала эффекта, а некоторые изменения, по признанию самой команды, делали ситуацию хуже. Одни ANR удавалось закрыть относительно просто, другие требовали более тяжелой работы: рефакторинга, оптимизации старта приложения и разбирательства с тем, как косвенные узкие места влияют на зависания. В итоге Иви не просто попал в порог, а, по словам Супрун, показал результат лучше медианы по рынку в кабинете разработчика Google Play. Цифр сравнения компания не раскрывает, и это правильно: без скриншотов из консоли лучше не устраивать чемпионат по процентикам. Но сам акцент показателен. Для зрелой мобильной команды метрика становится не приложением к релизу, а центральной осью работы.
Когда инцидент прилетает от своих же
На этом месте обычно хочется написать что-то бодрое про «успешный успех», но у Иви в интервью есть деталь куда полезнее. Команда прямо рассказывает о недавнем факапе: одна продуктовая доработка спровоцировала ANR у пользователей, раскатку пришлось срочно останавливать и выпускать хотфикс. Даже быстрая реакция не спасла метрики от скачка. И в этом, пожалуй, главный практический смысл всей истории. Неудачный релиз ударил не только по пользователям, но и по той самой статистике, которую команда долго выправляла. После инцидента в Иви пересмотрели процесс дежурства на проде, собрали отдельный сценарий реагирования на сбои и сделали quality gate строже. То есть речь не про мораль в духе «ошибки нас учат», а про вполне земную операционную донастройку: кто собирается, кто фиксит, кто тестирует, кто выкладывает исправление и по каким правилам новая версия вообще проходит в бой.
Для мобильного рынка здесь нет сенсации, но есть важное подтверждение тренда. Чем сложнее приложение и чем плотнее связаны кодовые потоки, тем слабее работает разделение на «продуктовую» и «техническую» команду как на два отдельных мира. В Иви прямо говорят, что core-команда много взаимодействует с аналитиками, UX, биллингом, подписочной моделью, видео и партнерствами, в том числе по предустановкам. Причина проста: репозиторий один, а последствия любой доработки часто общие. Когда продуктовая фича ухудшает технические метрики, это уже не локальная проблема одной команды, а риск для всей воронки использования приложения. Для CTO и мобильных лидов это довольно прямое напоминание: если метрики здоровья живут отдельно от продуктового планирования, расплачиваться потом придется всей организации.
AI, фичи-тогглы и найм без романтики
Вторая часть интервью показывает, как Android-команда Иви пытается не только тушить пожары, но и ускорять рутину. В компании уже используются LLM-инструменты для «нейроревью» и «нейрорезюме». Первый сценарий — это AI-проверка кода, причем пока неблокирующая: разработчик может не согласиться с замечаниями, потому что модель иногда ошибается. Подход трезвый, без магии и без поклонения слову «автоматизация». Но команда признает, что такие проверки уже несколько раз подсвечивали критичные моменты. Второй сценарий еще интереснее с точки зрения процесса: когда задача уходит в тестирование, модель анализирует изменения и инженерным языком описывает фичу, затронутые экраны и функциональность. Для тестировщиков это экономит время на вход в контекст, а для менеджмента выглядит как вполне практичное применение AI без презентаций о светлом будущем.
При этом инициативы внутри команды не принимаются на веру. Если кто-то хочет новую библиотеку или подход, ему предлагают принести proof of concept: показать, как это внедряется, что дает по производительности и где риски. Такой фильтр особенно логичен для core-команды, где любое улучшение на бумаге может превратиться в регрессию на проде. Дополнительную страховку дают фичи-тогглы: по словам Супрун, новые функциональности в Иви раскатываются именно так, чтобы эксперименты можно было включать и выключать без клиентских релизов. Для Android-разработки это уже почти стандарт, но интервью ценно тем, что показывает связку инструментов в реальной эксплуатации: метрики, toggles, quality gate, инцидентный контур и AI как помощник, а не как начальник.
Наконец, из текста довольно ясно читается и профиль найма. Иви ищет не просто Android-разработчиков, а людей, которым одинаково не чужды багфиксы, проектирование рефакторинга и продуктовые задачи. Это типичный запрос не на «узкого бойца по экранчикам», а на инженера, готового держать в голове систему целиком. На фоне рынка, где многие компании продолжают делить вакансии на красиво упакованные специализации, такой запрос звучит честно: core-команде нужны люди, которые умеют входить в сложный контекст и не пугаются тем оптимизаций, где быстрых побед почти не бывает. Вопрос здесь открытый, но важный: сколько российских продуктовых команд готовы так же открыто признать, что главная конкуренция в мобильной разработке идет уже не за список фич, а за дисциплину вокруг качества, релизов и технических метрик.