Почему Android задерживает уведомления и закрывает приложения: как работают Doze, оптимизация батареи и ограничения

Приложение в памяти и работающее приложение — не одно и то же

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

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

Отсюда следует важное различие. Удаление процесса из памяти само по себе не должно ломать push-уведомления, будильники или корректно запланированные фоновые задачи. Проблемы начинаются тогда, когда приложению требуется выполнить определенную работу, а выбранный разработчиком механизм сталкивается с ограничениями Android или дополнительной политикой производителя смартфона.

Почему Android вообще начал ограничивать фоновые процессы

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

Постепенно Android стал передавать контроль над такими операциями самой системе. Появились Doze, App Standby, JobScheduler, WorkManager, ограничения background services, foreground services и квоты на отдельные виды фоновой активности. Современное приложение должно сообщать Android не просто "я хочу работать", а что именно оно собирается делать и насколько эта задача срочная.

Именно поэтому советы времен Android 5 вроде "не закрывайте приложение и пусть его сервис постоянно висит в памяти" сегодня плохо описывают устройство системы.

Фото: 彭嘉傑

Что происходит после выключения экрана

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

При продолжительном бездействии смартфон может перейти в Doze. Согласно документации Android по Doze и App Standby, система в таком состоянии ограничивает обычный сетевой доступ приложений, откладывает задания JobScheduler и WorkManager, игнорирует обычные wake lock и переносит стандартные AlarmManager-события на периоды активности.

Телефон при этом не остается "мертвым" до следующей разблокировки. Android периодически открывает maintenance window — короткое окно, в котором приложения могут получить сеть и выполнить накопившуюся работу. Если устройство долго остается без движения и использования, интервалы между такими окнами способны увеличиваться. Поэтому обычная фоновая синхронизация не обязана срабатывать каждую минуту.

Doze нередко описывают как функцию, которая "убивает программы", но это неточно. Ее основная задача — ограничить доступ к ресурсам. Приложение вполне может оставаться в RAM и одновременно не иметь возможности произвольно выйти в сеть. Обратная ситуация тоже возможна: процесс удален из памяти вообще без участия Doze.

Для пользователя результат иногда выглядит одинаково: программа долго молчит, а после разблокировки сразу обновляется. Но попытка "закрепить ее в оперативной памяти" в таком случае не отменит сетевые ограничения Doze.

Почему мессенджер может получать сообщения, даже когда его процесса нет в памяти

Обычный push не требует, чтобы каждый мессенджер круглосуточно держал собственное соединение с сервером. На устройствах с Google Mobile Services эту задачу обычно берет на себя Firebase Cloud Messaging. Сервер приложения сообщает FCM о новом событии, системная инфраструктура доставляет его на устройство, а Android передает сообщение нужному приложению.

Такой подход экономнее, чем десятки независимых постоянных соединений. Google рекомендует использовать серверные события вместо частого фонового опроса в документации об оптимизации сетевой активности Android.

При этом не все push равнозначны. Обычное сообщение во время Doze может подождать и прийти позднее вместе с другими событиями. High priority предусмотрен для действительно срочной информации и способен временно разбудить приложение, но разработчик не может бесконечно объявлять срочной каждую рекламу или новость. Android следит за использованием высокого приоритета и может понизить его, если приложение злоупотребляет механизмом.

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

Почему ситуация меняется на смартфонах без Google-сервисов

FCM относится к инфраструктуре Google, а не к открытому Android как таковому. На Huawei без Google Mobile Services приложения могут использовать Huawei Push Kit, собственные каналы производителя либо другие схемы доставки. Некоторые разработчики поддерживают сразу несколько push-систем в зависимости от устройства.

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

Этим объясняется ситуация, когда два мессенджера на одном смартфоне ведут себя по-разному. Один использует корректную системную push-инфраструктуру, второй пытается поддерживать свое соединение и чаще сталкивается с энергосбережением.

Doze ограничивает устройство, App Standby — конкретное приложение

Эти механизмы часто смешивают, хотя они решают разные задачи. Doze прежде всего описывает состояние самого устройства. App Standby оценивает, насколько активно пользователь работает с конкретной программой.

В современных версиях Android для этого используются App Standby Buckets. Приложения распределяются по группам Active, Working Set, Frequent, Rare и Restricted. Часто используемая программа получает больше возможностей, чем утилита, которую не открывали несколько недель. По мере перехода к более жестким категориям сокращаются квоты на фоновые задания, сеть и некоторые другие операции.

Категория не назначается навсегда. Если человек снова начинает активно пользоваться приложением, система может ослабить ограничения. Поэтому характерный сценарий "открыл программу — несколько дней все нормально — потом уведомления снова начинают опаздывать" вполне укладывается в работу App Standby, особенно если производитель смартфона добавил поверх него собственный механизм сна приложений.

Optimized, Unrestricted и Restricted: что меняется на практике

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

Unrestricted снимает часть ограничений и дает приложению больше свободы. Это полезно, если его основная функция действительно требует надежной фоновой работы, но расплачиваться приходится потенциально повышенным энергопотреблением. Restricted действует в противоположную сторону: фоновая работа ограничивается настолько сильно, что отдельные функции приложения могут перестать работать корректно. На это прямо указывает Google в документации по фоновой оптимизации.

Названия пунктов зависят от оболочки. Где-то это "Без ограничений", где-то "Не оптимизировать", "Разрешить работу в фоне" или похожая формулировка. Поэтому инструкция, привязанная к одному конкретному пути меню, стареет быстрее, чем объяснение самой функции.

Переводить все установленные приложения в Unrestricted бессмысленно. Игре, магазину или сервису доставки обычно не нужна круглосуточная свобода. Исключение гораздо логичнее сделать для VPN, спортивного трекера, приложения автоматизации, клиента внешнего BLE-устройства или программы, для которой своевременная фоновая работа действительно является частью основной функции.

Уведомления могут быть отключены, даже если приложение прекрасно работает

После появления отдельного разрешения POST_NOTIFICATIONS в Android 13 отсутствие уведомления нельзя автоматически считать доказательством того, что программа "уснула". Пользователь мог запретить уведомления полностью либо отключить один из каналов: например, оставить сообщения и убрать служебные статусы.

Отдельно управляются звук, всплывающие окна и показ на экране блокировки. Поэтому диагностику разумно начинать именно здесь. Если событие было получено вовремя, но Android его не показал, искать проблему в Doze бесполезно. Если же уведомление появляется только после открытия самого приложения, вероятность проблемы с фоновой доставкой становится заметно выше.

Почему по Wi-Fi все работает, а через мобильную сеть — нет

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

Поэтому полезно отдельно проверить работу через Wi-Fi и мобильную сеть. Если задержки появляются только во втором случае, главным подозреваемым становится уже не Doze, а Data Saver, разрешение фоновой передачи данных, VPN, частный DNS или особенности сети оператора.

Контрольный тест через другую сеть вообще полезен чаще, чем кажется. Если одинаковая задержка одновременно возникает на Android и iPhone либо у нескольких людей, индивидуальная настройка батареи одного смартфона становится маловероятной причиной.

Почему замок в списке последних приложений не является универсальным решением

Некоторые оболочки позволяют "закрепить" приложение в Recents. Пользователь видит значок замка и вполне логично предполагает, что теперь система никогда не сможет закрыть программу. Обычно смысл функции намного уже.

Такой замок способен защитить карточку от команды "Закрыть все" или части фирменных механизмов очистки памяти. Но он не отменяет Doze, квоты JobScheduler, правила AlarmManager, фоновые сетевые ограничения и разрешения Android. Кроме того, производители реализуют эту функцию по-разному.

Использовать закрепление как дополнительную настройку на конкретной прошивке можно. Рассматривать его как аналог "не закрывать процесс никогда" — нет.

Почему регулярная очистка RAM скорее мешает

Android не нуждается в том, чтобы пользователь вручную освобождал всю оперативную память. Свободная RAM сама по себе не ускоряет смартфон. Если память сейчас не нужна, системе выгоднее оставить в ней недавно использованные процессы, чтобы не загружать их заново.

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

Большой объем RAM действительно помогает многозадачности: тяжелая игра реже будет выгружена после перехода в камеру или браузер. Но к Doze, App Standby, запрету фонового трафика и Sleeping apps Samsung это отношения не имеет. Смартфон с 16 ГБ памяти способен задерживать уведомления ровно по тем же причинам, что и модель с 6 ГБ.

По той же причине не спасает "расширение RAM". Memory Extension и похожие функции используют накопитель как дополнительную область для выгрузки данных, но не дают приложению новых системных прав. Включение еще "8 ГБ виртуальной памяти" не отменит Doze и не исправит неправильно работающий push.

Foreground service: почему навигация продолжает работать с выключенным экраном

Начиная с Android 8 обычная фоновая служба не может бесконечно работать после ухода приложения в фон. Если выполняется длительная заметная пользователю задача, Android предусматривает foreground service. Несмотря на название, программа при этом не обязана занимать экран — пользователь просто должен видеть постоянное системное уведомление о выполняющейся работе.

Именно такой механизм подходит для навигации, записи тренировки, воспроизведения музыки, VPN и других продолжительных операций. Если GPS-трекер пишет маршрут с погашенным экраном, постоянное уведомление об активной записи обычно является нормальным признаком правильно оформленного foreground service.

Разработчики, разумеется, быстро начали использовать foreground service как способ обходить ограничения. Поэтому Google постепенно ввела типы таких сервисов и дополнительные правила. Программа должна указать характер работы — location, media playback, connected device, data sync и другие предусмотренные категории.

Для части типов появились и временные лимиты. Например, приложения, ориентированные на Android 15 и выше, для foreground services типов dataSync и mediaProcessing получают суммарный лимит шесть часов за 24 часа, пока приложение находится в фоне. Открытие программы пользователем сбрасывает соответствующий счетчик. Это хорошо показывает, насколько далеко современный Android ушел от концепции "просто запустим сервис и оставим его навсегда".

Почему GPS-трекер может перестать писать маршрут

GPS-приложению нужны сразу несколько вещей: разрешение на местоположение, корректный foreground service типа location и в некоторых сценариях доступ к геопозиции в фоне. Даже при правильной реализации сверху остается политика производителя смартфона.

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

Для такого класса программ Unrestricted намного логичнее, чем для магазина или игры. Постоянная работа здесь не побочная прихоть программы, а ее основная функция.

Почему с будильниками все немного иначе

Android различает задачу, которую достаточно выполнить приблизительно вовремя, и событие, где ошибка даже в несколько минут нежелательна. Обновление погоды можно объединить с другими фоновыми операциями. Будильник на 07:00 требует другой модели.

Для таких случаев предназначены exact alarms. Начиная с Android 12 доступ к ним регулируется отдельными правилами, а начиная с Android 14 разрешение SCHEDULE_EXACT_ALARM по умолчанию не выдается большинству заново установленных приложений, ориентированных на Android 13 и выше. Для специализированных часов и календарей предусмотрены свои варианты в рамках системной политики.

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

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

Samsung: Sleeping apps и Deep sleeping apps

Galaxy добавляют к стандартной модели Android собственный слой управления фоном. Samsung использует Sleeping apps и Deep sleeping apps. Первый режим ограничивает фоновую активность, второй действует заметно жестче: приложения фактически не должны нормально выполнять фоновую работу, пока пользователь снова их не откроет.

Есть и список Never sleeping apps. В официальной документации Samsung компания указывает управление этими параметрами через Settings, Device care, Battery и Background usage limits, хотя названия и расположение могут отличаться между версиями One UI и регионами.

Из-за этого изменение только стандартного режима батареи иногда ничего не дает. Приложение может не находиться в Android Restricted, но одновременно числиться в фирменном Deep sleeping. Если на Galaxy уведомления начинают пропадать после нескольких дней редкого использования программы, этот список стоит проверить достаточно рано.

Добавлять туда весь софт не нужно. Для приложения, которому не требуется постоянная фоновая активность, стандартная оптимизация полезна и делает именно то, для чего предназначена.

Xiaomi и HyperOS: батарея и автозапуск — разные настройки

У Xiaomi поверх стандартных механизмов Android также работает собственное управление. Один из заметных элементов — Background autostart. Кроме него существуют индивидуальные настройки энергосбережения приложений, поэтому проверять приходится как минимум два разных направления: разрешена ли программе нормальная работа в фоне и сможет ли она автоматически восстановить необходимые компоненты без ручного запуска.

Названия меню меняются между MIUI, поколениями HyperOS, регионами и моделями. Поэтому старое руководство с точным маршрутом по настройкам может оказаться бесполезным на новом смартфоне. Быстрее воспользоваться поиском внутри настроек по словам "автозапуск", "батарея" или непосредственно по названию проблемного приложения.

Само слово "автозапуск" вводит в заблуждение тех, кто привык к Windows. На Android vendor-specific Autostart обычно означает не только запуск программы сразу после включения телефона. Он способен влиять на возможность компонентов приложения реагировать на системные события и восстанавливать предусмотренную фоновую работу. Отсюда характерный симптом: после перезагрузки уведомлений нет, но достаточно один раз открыть программу вручную — и все снова работает.

realme и OPPO: общий принцип важнее названия меню

realme UI и ColorOS используют дополнительные механизмы энергосбережения, названия которых менялись между поколениями оболочек. В разных версиях можно встретить управление фоновой активностью, автозапуском, оптимизированным использованием батареи и фирменной заморозкой редко используемых приложений.

Поэтому инструкция вида "на любом Android откройте Настройки → Батарея → ..." обречена быстро устареть. Android задает базовые правила, а производитель строит поверх них собственный интерфейс и иногда собственную политику.

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

Huawei и Honor лучше не считать одной и той же оболочкой

Huawei давно использует собственное управление App launch. В зависимости от версии EMUI можно отдельно контролировать автоматический запуск, запуск другими приложениями и работу в фоне. На устройствах без GMS дополнительное значение приобретает и конкретная push-инфраструктура приложения.

Honor после отделения развивает MagicOS самостоятельно, поэтому современный Honor не следует автоматически считать Huawei с другим логотипом. Пункты меню и поведение могут отличаться. Общая логика диагностики остается прежней: если данные появляются только после ручного открытия программы, нужно проверять не только стандартную батарею Android, но и фирменное управление запуском.

Почему свайп из Recents и Force Stop — совершенно разные действия

Карточка в меню последних приложений не является индикатором живого процесса. Android способен показывать сохраненный снимок Activity программы, процесс которой давно выгружен из памяти. Обратное тоже верно: приложение может отсутствовать на экране, а его корректно оформленный foreground service продолжит работу.

В стандартной модели Android свайп карточки из Recents убирает задачу из списка последних, но не означает вечного запрета на push. Некоторые производители исторически делали ручное закрытие более агрессивным, поэтому на отдельных оболочках поведение отличается. Если после каждого свайпа мессенджер молчит до следующего открытия, это сильнее похоже на специфику прошивки, чем на универсальное правило Android.

Force Stop — другое действие. Нажимая "Остановить" в карточке приложения, пользователь явно сообщает системе, что программа сейчас не должна работать. Это намного сильнее обычного удаления из Recents. Поэтому использовать Force Stop как способ "почистить память", а потом ждать от приложения обычных уведомлений не стоит.

Почему после перезагрузки все иногда ломается

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

Получается очень характерный сценарий: до перезагрузки все работало, после нее приложение замолчало, первое ручное открытие сразу исправило ситуацию. Такой симптом направляет диагностику в сторону автозапуска, состояния батареи и восстановления после BOOT_COMPLETED намного точнее, чем совет "переустановите приложение".

Перезагрузка поэтому полезна не как магическая очистка Android, а как диагностический эксперимент. Если проблема появляется именно после нее, круг возможных причин заметно сужается.

Почему проблема вообще может находиться не в Android

Push способен задержать сам сервер приложения. У сервиса может быть временный сбой, VPN — блокировать нужное соединение, частный DNS — отрезать домен, а корпоративный Wi-Fi — применять собственную сетевую политику. Наконец, ошибка может появиться в конкретной версии программы.

Есть простой способ не менять десяток настроек наугад. Сначала отправляем тестовое сообщение при активном экране. Затем блокируем смартфон и повторяем проверку через несколько минут. После этого оставляем устройство без использования на более длительный срок и тестируем снова.

Если задержки появляются только после продолжительного бездействия, подозрение сильнее падает на Doze или фирменный battery management. Если они одинаковы всегда, логичнее смотреть сеть, сервер и само приложение. Если проблема появляется только на мобильных данных — Data Saver и разрешение фонового трафика. Если только после перезагрузки — автозапуск и восстановление фоновой работы.

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

Почему тест через две минуты может ничего не показать

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

Для нестабильного приложения полезен хотя бы один продолжительный эксперимент: оставить телефон с выключенным экраном и без использования на 30–60 минут, затем отправить сообщение с другого устройства. Если проблема возникает именно ночью, лучший тест — воспроизвести ночные условия, а не проверять приложение сразу после настройки.

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

Условия движения тоже способны влиять на поведение энергосбережения. Сводить современный Android только к датчику движения было бы неправильно, но смартфон, несколько часов лежащий неподвижно, и тот же аппарат в кармане идущего человека находятся в разных условиях. Поэтому сравнивать такие тесты без контроля сети и питания не очень полезно.

VPN и Bluetooth требуют отдельного подхода

Постоянный VPN должен поддерживать сетевой туннель, для чего Android предоставляет VpnService и режим Always-on VPN. Если обычный VPN стабильно отключается после блокировки экрана, более свободный режим батареи для него выглядит оправданно. Здесь фоновая работа непосредственно является основной функцией приложения.

С Bluetooth ситуация зависит от типа устройства. Наушники способны продолжать воспроизведение без постоянной активности фирменного приложения, а специализированный BLE-датчик, автомобильный адаптер или фитнес-устройство могут зависеть от программного сервиса. Android предоставляет API для companion devices, connected device и Bluetooth-сценариев, но дополнительная политика производителя все равно иногда вмешивается.

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

Что проверять, если задерживаются уведомления мессенджера

Начать лучше с самого простого: разрешены ли уведомления вообще и включен ли нужный канал. Затем стоит сравнить Wi-Fi и мобильный интернет и проверить фоновую передачу данных. Только после этого имеет смысл смотреть режим батареи конкретного приложения.

Если установлен Restricted, разумно сначала вернуть Optimized. Если проблема сохраняется, можно временно протестировать Unrestricted. На Samsung параллельно проверяются Sleeping и Deep sleeping apps, на Xiaomi — Background autostart и индивидуальная политика батареи.

Менять лучше по одному параметру. Если одновременно разрешить автозапуск, отключить оптимизацию, снять Data Saver, закрепить программу в Recents и выключить Adaptive Battery, уведомления, возможно, действительно начнут приходить — но понять причину уже не получится.

Фото: JTanner (WMF)

Умный дом, навигация и будильник требуют разных решений

Приложение умного дома не обязательно должно жить в памяти. Если облачный сервер присылает обычный push, постоянный процесс ему может вообще не требоваться. Другое дело, если смартфон поддерживает прямое соединение с локальным устройством, работает через Bluetooth или сам выполняет роль шлюза. В таком случае требования к фоновой активности заметно выше.

Для GPS-трекера и автомобильного приложения главное — разрешения местоположения, корректный foreground service и режим батареи. Если запись маршрута является основной функцией, отключение части энергосбережения для конкретной программы часто оправданно.

Будильнику нужны уведомления и, если он использует точное срабатывание, специальный доступ к exact alarms. Проверить его стоит и после перезагрузки: приложение часов не должно требовать ежедневного ручного запуска для выполнения базовой функции.

Одного универсального переключателя здесь нет именно потому, что Android различает эти сценарии. Push, длительная GPS-запись, точный будильник и постоянный VPN — технически разные задачи.

Нужно ли полностью отключать Adaptive Battery и Battery Saver

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

Battery Saver тоже специально ужесточает поведение системы. Если приложение начинает опаздывать только при 20% заряда и включенном энергосбережении, это может быть ожидаемым следствием выбранного режима. Некоторые оболочки имеют еще более жесткий Ultra Power Saving, где нормально работают лишь выбранные приложения.

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

Когда Android действительно закрывает приложение из-за нехватки RAM

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

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

Смешивать это с задержкой push у Telegram не стоит. В первом случае система освобождает память. Во втором приложение может вообще отсутствовать в памяти и все равно корректно получать push через системную инфраструктуру.

Как понять, кто действительно расходует батарею

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

Один случайный замер мало что говорит. Полезнее смотреть повторяющийся паттерн за несколько циклов. Android дополнительно отслеживает чрезмерное использование wake lock — механизмов, которые временно удерживают процессор активным после выключения экрана.

Wake lock сам по себе необходим: приложению иногда действительно нужно закончить короткую операцию. Проблема начинается, когда программа удерживает его слишком долго или забывает освободить. Тогда экран уже выключен, но SoC не может нормально перейти в глубокий сон, и за ночь заряд падает заметно сильнее обычного.

С 1 марта 2026 года Google использует в Google Play дополнительную метрику excessive partial wake locks для оценки технического качества приложений. Это хорошо отражает общее направление Android: разработчикам все труднее бесконтрольно расходовать фоновые ресурсы, не объясняя системе и пользователю, зачем это необходимо.

Почему high-priority push нельзя использовать для всего подряд

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

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

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

Почему после разблокировки приходит сразу пачка сообщений

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

Если подобное происходит только с одной программой, в первую очередь нужно проверять ее настройки и архитектуру. Если одновременно "оживают" сразу несколько приложений, подозрение сильнее смещается к системному энергосбережению, сети или фирменной политике оболочки.

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

Как должна выглядеть нормальная фоновая работа современного Android-приложения

Хорошая программа не пытается сохранить собственный процесс любой ценой. Несрочную синхронизацию она передает JobScheduler или WorkManager, срочные события получает через подходящую push-инфраструктуру, длительную пользовательскую операцию оформляет foreground service, а точный будильник назначает через AlarmManager с необходимыми разрешениями.

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

Поэтому обновление приложения иногда действительно исправляет уведомления без каких-либо изменений со стороны пользователя. Разработчик мог перейти на другой target SDK, изменить работу push или переделать foreground service. Обратная ситуация тоже возможна: проблема появляется сразу после неудачного обновления конкретной программы.

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

Когда режим "Без ограничений" действительно имеет смысл

Хороший критерий довольно простой: фоновая работа должна быть частью основной функции приложения и реально требоваться пользователю. VPN должен поддерживать туннель. Спортивный трекер — продолжать маршрут. Приложение безопасности — получать события. Клиент BLE-устройства — сохранять связь. Для критичного мессенджера своевременная доставка сообщений тоже может быть важнее небольшой экономии батареи.

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

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

Как настроить проблемное приложение и не сломать энергосбережение всего смартфона

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

Для Samsung это Sleeping и Deep sleeping apps, для Xiaomi — Background autostart и индивидуальные настройки батареи, для других оболочек — аналогичные функции. Будильнику дополнительно требуется проверка exact alarms, GPS-приложению — местоположение и foreground service.

После каждого изменения нужен новый тест. Если проблема исчезла после разрешения фонового трафика, нет смысла отключать Adaptive Battery. Если помог выход из Deep sleeping, не требуется переводить десятки программ в Unrestricted.

Самый показательный тест можно провести дома

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

После этого оставьте аппарат неподвижным с выключенным экраном на 30–60 минут и отправьте еще одно сообщение. Если задержка проявилась только теперь, временно переведите именно это приложение из Optimized в Unrestricted и повторите эксперимент в тех же условиях.

Исчезновение задержки довольно уверенно укажет на связь с политикой фонового энергопотребления или взаимодействием приложения с ней. Если ничего не поменялось, снимать ограничения со всего остального софта бессмысленно. Следующими кандидатами становятся сеть, push-инфраструктура, автозапуск производителя и ошибка самой программы.

Почему фоновые ограничения становятся жестче, а не мягче

Общее направление Android за последние поколения не изменилось. Exact alarms получили отдельные разрешения, foreground services — типы и временные лимиты, редко используемые приложения — более жесткие квоты, а чрезмерные wake lock стали отдельным показателем технического качества.

В Android 17 ограничения продолжают развиваться, в том числе для отдельных сценариев фоновой активности из состояний, которые пользователь не видит. Причина вполне практическая: на смартфоне могут быть установлены сотни приложений, и система не может разрешить каждому из них считать собственную фоновую задачу самой важной.

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