Google с февраля 2027 года начнет проверять, насколько Android-приложения прожорливы по памяти, и это не косметическая правка в документации, а новая планка для публикации в Google Play. Для команд, которые давно откладывали оптимизацию памяти Android на потом, сигнал предельно понятный: лишние гигабайты больше не спишут на «железо у пользователей стало мощнее».
О новых требованиях сообщает The Register: Google вводит двухэтапную схему контроля качества приложений, где в первой фазе фокусируется на памяти и оптимизации кода, а во второй — на переносе учетных данных при миграции на новое устройство. Формально речь идет о стабильности Android-устройств, но по факту Google признает более неприятную вещь: память дорожает, пользователи чаще выбирают смартфоны с более скромной конфигурацией, а плохо написанное приложение легко портит жизнь всем остальным.
Первый этап стартует в феврале 2027 года. С этого момента для приложений в Google Play начнут действовать пороги «плохого поведения» и требования к оптимизации кода. Google будет смотреть на потребление памяти по метрике Anonymous Resident Set Size плюс Swap, на использование памяти под bitmap-объекты и на оптимизацию DEX-файлов. Если перевести с языка платформенной документации на язык мобильной разработки, смысл простой: приложение не должно раздуваться до таких размеров, чтобы система начала тормозить, выгружать фоновые процессы и лечить мультитаскинг топором.
Цифры Google уже обозначила. Для устройства с 8 ГБ оперативной памяти приложение может занимать не более 2,25 ГБ в активном режиме на переднем плане, до 1,5 ГБ в режиме user-perceived service и до 1,5 ГБ в фоне. Устройства с объемом памяти свыше 16 ГБ в основном выведены из-под этих ограничений, но рассчитывать на них как на массовый сценарий явно не стоит. Отдельно ограничивается память под bitmap: максимум 200 МБ для сервисов, заметных пользователю, и для фоновых процессов, а также 400 МБ для cached-сценариев на всех устройствах. Для игр условия отличаются, но общий вектор тот же: платформа больше не хочет быть страховкой для чужой неаккуратности.
Самый любопытный момент здесь даже не в самих лимитах, а в мотивации. Google прямо говорит о надвигающемся кризисе памяти на уровне всей экосистемы из-за роста стоимости RAM. Это редкий случай, когда платформодержатель не прикрывается только мантрой про пользовательский опыт, а увязывает требования к разработке с экономикой железа. И в этом есть неприятная для индустрии честность. Несколько лет мобильные команды жили в парадигме, где лишний слой абстракции, тяжелая библиотека, неубранные bitmap-ресурсы или вялотекущая утечка памяти воспринимались как технический шум. Теперь этот шум становится проблемой публикации и, вероятно, KPI для продуктовых и инженерных руководителей.
Контекст у решения тоже понятный. Еще в июне Google уже объявляла курс на повышение memory efficiency в Android, объясняя это борьбой с эффектом «одного плохого соседа», когда одно приложение ломает многозадачность и стабильность всего устройства. Нынешний шаг — это уже не просто рекомендация «пожалуйста, профилируйте приложение», а переход к формализованным порогам. На практике это означает, что командам придется внимательнее смотреть на жизненный цикл экранов, кеширование изображений, размер in-memory-данных, фоновую работу сервисов, поведение SDK от сторонних вендоров и сборку DEX. Особенно неприятные сюрпризы могут ждать проекты, где память ест не основная логика, а рекламные модули, аналитика или встроенные AI-функции. The Register отдельно замечает, что on-device AI вряд ли помогает ситуации, и с этим трудно спорить.
Для бизнеса это не только вопрос инженерной дисциплины, но и воронки. Если приложение вылетает, агрессивно выгружается из памяти или душит соседние процессы, страдает не абстрактная «стабильность платформы», а конкретные метрики удержания, конверсии и LTV. У Android-экосистемы огромный хвост устройств среднего и нижнего ценового сегмента, и именно там цена ошибок по памяти максимальна. Российским продуктовым командам это особенно знакомо: в массе своей аудитория не сидит на флагманах с 16 ГБ RAM, а значит оптимизация памяти Android быстро превращается из nice-to-have в условие нормальной конкуренции за пользователя.
Второй этап намечен на апрель 2027 года и касается уже не памяти, а миграции между устройствами. Google хочет, чтобы onboarding поддерживал zero-tap credential restoration — восстановление учетных данных без ручного ввода. Для этого разработчикам советуют использовать Android Restore Credentials API. Аргумент у компании прагматичный: ручной логин во время первичной настройки не просто ухудшает onboarding, но и повышает риск фишинга и кражи учетных данных. Иными словами, Play начинает одновременно давить на две больные точки мобильных продуктов: тяжелые приложения и длинный вход в сервис после смены смартфона.
Главный вопрос теперь не в том, сможет ли Google продавить новые правила через Google Play, а в том, сколько мобильных команд реально готовы к такой ревизии. Когда платформа впрямую связывает качество кода с дефицитом RAM, спорить уже поздно: следующая волна конкуренции в Android, похоже, пойдет не только за функции и AI-надстройки, но и за право занимать в памяти меньше соседа.