С Android 9 оптимизация батареи получила дальнейшее развитие, и приложения классифицируются по резервным корзинам в зависимости от того, как часто пользователь недавно взаимодействовал с приложением (см. Документация Android ).Система ограничивает ресурсы устройства, доступные для каждого приложения, в зависимости от того, в какой корзине находится приложение.
Как я могу хранить свое приложение в корзине "рабочего набора", даже если пользователь не взаимодействует с ним?(Я не нахожу никаких разрешений или аналогичных, позволяющих переопределить эту функцию управления питанием.)
В частности, у меня есть PeriodicWorkRequest
, который должен запускаться каждые 30 минут с гибкостью 10 минут.Однако, если я понимаю таблицу наложенных ограничений мощности , такой рабочий запрос может быть отложен до 24 часов, если мое приложение помещено в «редкую» корзину.(Внутренняя библиотека Work использует планировщик заданий.)
Дополнительные сведения о сценарии
Приложение критически важно для безопасности и не предназначено для публичного использования, но толькозначимым для ограниченного круга пользователей.Тем не менее, если кто-то еще использует это приложение, ничего плохого не произойдет, но приложение не имеет для него никакой цели.
Точнее, приложение подключено к центральной станции пожарной сигнализации определенного здания.Всех сотрудников просят установить приложение на свой смартфон.Если центральная станция пожарной сигнализации этого здания обнаруживает событие, она отправляет push-уведомление (через FCM) на все зарегистрированные смартфоны, и приложение воспроизводит сигнал тревоги.Это означает, что ничего не происходит (надеюсь) долгое время, и пользователь не намерен каким-либо образом взаимодействовать с приложением.Само приложение не обеспечивает никакого взаимодействия, оно только иллюстрирует текущее состояние (которое является либо зеленым знаком «ОК», либо красным знаком «ТРЕВОГА») и ожидает в фоновом режиме остальное время.
Поскольку приложение является критически важным для безопасности, должно быть обнаружено условие сбоя, когда приложение теряет соединение с сервером.С этой целью сервер фактически периодически отправляет сообщения в фоновом режиме, т.е. последовательность idle
, idle
, idle
, idle
, alarm
, alarm
, alarm
, alarm
, idle
, idle
, idle
, ... Обычно сообщения передаются с низким приоритетом FCM каждые 5 минут.Если состояние изменяется, сразу же отправляется дополнительное сообщение с высоким приоритетом FCM (см. Полужирные буквы).
Приложение реализует сторожевой таймер, используя PeriodicWorkRequest
, как упомянуто в вопросе выше.Этот сторожевой таймер выполняет две функции: разбудите устройство и заставьте устройство получать все (низкоприоритетные) FCM-сообщения, которые были отложены, а затем проверьте, не было ли самое последнее сообщение старше 1,5 * 5 минут.Если это не удается, приложение пытается перерегистрировать себя на сервере и ожидает повторного появления сообщений о состоянии.Если это тоже не удается, приложение выдает предупреждение пользователю.
Пока все работает нормально.Единственная проблема - это новый тип оптимизации батареи, который в какой-то момент замедляет работу сторожевого таймера.Конечно, я мог бы выдать постоянный регламент, который заставляет всех сотрудников время от времени открывать приложение и просто смотреть на него, но это немного глупо.
Я мог бы перефразироватьвопрос выше: Я полностью понимаю, почему Android подталкивает оптимизацию батареи к краю.Есть много (безумных) приложений, которые неправильно использовали периодические задачи для целей, которые должны были быть решены по-другому.И в Интернете все еще полно «идиотских» советов по программированию, таких как проверка конкретной веб-страницы на предмет изменений каждые 5 секунд.Тем не менее, как я должен писать критически важные для безопасности приложения, которые требуют сторожевого режима для законных целей, если оптимизация батареи становится все более и более препятствием.Правило Google, гласящее: «если пользователь не использует ваше приложение, оно явно для него / нее неважно» здесь не применимо.