Выявление и оптимизация сценариев использования блокировки пробуждения

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

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

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

AlarmManager

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

Названия замков пробуждения

AlarmManager создает блокировки пробуждения с именем *alarm* . (Звездочки являются частью имени блокировки пробуждения и не представляют собой подстановочные символы.)

Рекомендация

Для оптимизации работы системы оповещения мы рекомендуем следующие методы:

  • Чтобы выбрать точный или неточный тип оповещения, воспользуйтесь функцией выбора типа оповещения . Если точность не требуется, используйте неточные оповещения, чтобы обеспечить системе большую гибкость в планировании, что может увеличить срок службы батареи.
  • Учитывайте установленные системой квоты на срабатывание оповещений и разрабатывайте приложение таким образом, чтобы оно их соблюдало.
  • Избегайте выполнения длительной работы в методе onReceive() и планируйте выполнение обработчиков, если после срабатывания сигнала тревоги требуется дополнительная обработка.

Аудио и медиа

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

Названия замков пробуждения

API для работы с медиафайлами получают блокировки пробуждения с различными именами, начинающимися с Audio :

  • AudioBitPerfect : Используется для воспроизведения аудио без потерь качества через USB.
  • AudioDirectOut : Используется для воспроизведения звука без потерь качества на телевизоре или специальном устройстве.
  • AudioDup : Используется для воспроизведения уведомлений при подключении через Bluetooth или USB.
  • AudioIn : Используется для захвата звука в режиме видеокамеры при активном микрофоне.
  • AudioMix : Используется для воспроизведения звука на распространенном устройстве.
  • AudioOffload : Используется для длительного воспроизведения только музыки в приложениях, поддерживающих этот режим.
  • AudioSpatial : Используется для воспроизведения многоканального звука фильмов или музыки на устройствах, поддерживающих пространственное звучание.
  • AudioUnknown : Используется, когда другие ситуации не применимы.
  • MmapCapture : Используется для захвата звука с низкой задержкой.
  • MmapPlayback : Используется для воспроизведения с низкой задержкой, например, в играх или в профессиональных аудиоприложениях.

Рекомендация

Мы рекомендуем следующие методы:

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

Bluetooth

API Bluetooth платформы в основном удерживают блокировки пробуждения ядра во время выполнения действий Bluetooth, которые не связаны с приложением.

Рекомендация

  • Используйте функцию сопряжения дополнительных устройств для подключения устройств Bluetooth, чтобы избежать ручной блокировки экрана во время сопряжения Bluetooth.
  • Для получения информации о том, как осуществлять фоновую связь по Bluetooth, обратитесь к руководству по настройке связи в фоновом режиме .
  • Использование WorkManager часто бывает достаточным, если задержка связи не оказывает влияния на пользователя. Если необходима ручная блокировка пробуждения, удерживайте ее только во время активности Bluetooth или обработки данных об активности.

Датчики устройства

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

В операционной системе Wear OS используйте Wear Health Services для получения данных с устройства, таких как высота над уровнем моря, частота сердечных сокращений и пройденное расстояние.

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

Для таких сценариев, как отслеживание изменения количества шагов или пройденного расстояния, вы можете использовать API записи на мобильных устройствах в сочетании с WorkManager для периодического получения данных. Для доступа к историческим данным о шагах (например, к общему количеству шагов за день или количеству шагов за последние 6 часов) Health Connect также поддерживает отслеживание шагов на устройстве под управлением Android 14 или выше.

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

Рекомендация

Использование датчиков для записи с высокой частотой дискретизации может значительно разряжать батарею. Вот рекомендации по снижению расхода заряда батареи и использованию блокировки пробуждения:

  • При отслеживании количества шагов или пройденного расстояния используйте API записи для экономичной зарядки. Для устройств под управлением Android 14 и выше рассмотрите Health Connect для доступа к истории использования устройства и сводным данным о количестве шагов.
  • Для пассивного отслеживания местоположения с помощью датчиков на Wear OS используйте Wear Health Services для оптимизации расхода заряда батареи.
  • При регистрации датчика в SensorManager задайте значение maxReportLatencyUs более 30 секунд, чтобы использовать логику пакетной обработки данных с датчиков и уменьшить количество прерываний, получаемых приложением. Когда устройство впоследствии будет активировано другим триггером, таким как взаимодействие с пользователем, определение местоположения или запланированное задание, система немедленно отправит кэшированные данные датчика.
  • Если вашему приложению требуются как данные о местоположении, так и данные с датчиков, синхронизируйте получение и обработку событий, связанных с ними. Объединяя показания датчиков в рамках кратковременной блокировки пробуждения, которую система удерживает для обновления местоположения, вы избегаете необходимости в дополнительной блокировке пробуждения для поддержания активности процессора. Используйте рабочий процесс или кратковременную блокировку пробуждения для обработки загрузки и обработки этих объединенных данных.

Firebase Cloud Message (FCM)

Блокировка пробуждения устанавливается во время отправки широковещательного сообщения Firebase Cloud Message (FCM) в приложение. Блокировка пробуждения снимается после завершения выполнения метода onMessageReceived() широковещательного сообщения FCM.

Названия замков пробуждения

Когда устройство получает сообщение FCM, устанавливается кратковременная блокировка пробуждения с именем GOOGLE_C2DM ; в Android 16 и более поздних версиях имя блокировки пробуждения — GCM_MESSAGE .

Рекомендация

Для оптимизации работы FCM мы рекомендуем следующие методы:

  • Оптимизировать частоту подачи FCM.
  • Не используйте FCM с высоким приоритетом, если сообщение не требует немедленной доставки.
  • Выполните метод onMessageReceived() как можно быстрее или запланируйте продолжение задачи для отдельного обработчика, если требуется дополнительная обработка. Дополнительную информацию см. в руководстве Firebase .

JobScheduler

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

Названия замков пробуждения

Имена блокировок пробуждения, получаемые JobScheduler, зависят от версии операционной системы Android, на которой они работают, и от назначения задания.

Элементы, заключенные в угловые скобки, являются переменными. Например, "<package_name>" — это имя пакета вашего приложения, а не буквальный текст <package name> . Однако *job* — это последовательность символов *job* со звездочками; звездочки не используются в качестве подстановочных символов.

Android 15 и ниже

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

*job*u/@<name_space>@/<package_name>/<classname>

В других профессиях используется подобная схема:

*job*/@<name_space>@/<package_name>/<classname>
Android 16.1 и выше

Задания, инициированные пользователем, создают блокировки пробуждения с именами, соответствующими следующему шаблону:

*job*u/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

Для срочных заказов используется следующий шаблон:

*job*e/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

В обычных рабочих местах используется следующая схема:

*job*r/@<name_space>@/#<trace_tag>#/<package_name>/<classname>
Пример

Предположим, существует ускоренное задание с пространством имен backup и started тегом трассировки. Имя пакета — com.example.app , а класс, создавший задание, — com.backup.BackupFileService .

На устройствах под управлением Android 15 или более ранних версий функция блокировки пробуждения будет называться следующим образом:

*job*/@backup@/com.example.app/com.backup.BackupFileService

На устройствах под управлением Android 16.1 и выше функция блокировки пробуждения будет называться следующим образом:

*job*e/@backup@/#started#/com.example.app/com.backup.BackupFileService

Рекомендация

  • Не следует вручную устанавливать блокировку пробуждения для сценариев загрузки/выгрузки, инициированных пользователем. Вместо этого используйте API для передачи данных, инициированной пользователем (UIDT) . Это предназначенный путь для длительных задач передачи данных, инициированных пользователем.
  • Если вы обнаружили блокировки пробуждения, создаваемые JobScheduler, с высокой частотой их использования, это может быть связано с неправильной настройкой задания, из-за которой оно не завершается в определенных сценариях. Рассмотрите возможность анализа причин остановки задания, особенно если вы наблюдаете частое появление ошибки STOP_REASON_TIMEOUT .
  • Проведите аудит использования задач JobScheduler. В частности, следуйте нашим рекомендациям по оптимизации расхода заряда батареи при использовании API планирования задач .

Расположение

LocationManager и FusedLocationProviderClient используют блокировки пробуждения для получения и передачи местоположения устройства. Блокировки пробуждения назначаются приложению, которое вызвало эти API.

Названия замков пробуждения

Службы определения местоположения используют следующие названия:

  • CollectionLib-SigCollector
  • NetworkLocationLocator
  • NetworkLocationScanner
  • NlpCollectorWakeLock
  • NlpWakeLock
  • *location*

Рекомендация

  • Ознакомьтесь с нашими рекомендациями по оптимизации использования данных о местоположении . Рассмотрите возможность внедрения тайм-аутов, использования пакетной обработки запросов на определение местоположения или пассивного обновления данных о местоположении.
  • Избегайте использования отдельной, непрерывной блокировки пробуждения для кэширования данных о местоположении, поскольку это избыточно и должно быть удалено. При запросе обновлений местоположения с использованием API FusedLocationProvider или LocationManager система автоматически запускает пробуждение устройства во время обратного вызова события местоположения. Вместо этого сохраняйте события местоположения в памяти или хранилище и периодически обрабатывайте их с помощью WorkManager .

Удалённый обмен сообщениями

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

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

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

Рекомендация

  • Если сетевые события могут обрабатываться на стороне сервера, используйте FCM для получения информации на стороне клиента. При необходимости дополнительной обработки данных FCM можно запланировать выполнение задачи в ускоренном режиме .
  • Если обработка событий должна осуществляться на стороне клиента с использованием сокетного соединения, блокировка пробуждения для прослушивания прерываний событий не требуется. Когда пакеты данных поступают в сеть Wi-Fi или сотовую сеть, радиооборудование инициирует прерывание в виде блокировки пробуждения ядра. Затем вы можете запланировать выполнение рабочего процесса или получить блокировку пробуждения для обработки данных.
  • Например, если вы используете ktor-network для прослушивания пакетов данных на сетевом сокете, вам следует получать блокировку пробуждения только тогда, когда пакеты доставлены клиенту.

Менеджер работ

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

Названия замков пробуждения

Названия блокировок пробуждения, получаемые WorkManager, зависят от версии операционной системы Android, на которой они работают.

Android 15 и ниже

Задачи WorkManager создают блокировки пробуждения с именами, соответствующими следующему шаблону:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
Android 16.1 и выше

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

*job*e/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

Обычные задачи выполняются по следующей схеме: 

*job*r/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

По умолчанию <trace_tag> — это имя рабочего процесса.

Пример

Предположим, существует ускоренный обработчик с именем BackupFileWorker . Имя пакета — com.example.app .

На устройствах под управлением Android 15 или более ранних версий функция блокировки пробуждения будет называться следующим образом: 

*job*/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

На устройствах под управлением Android 16 или выше, использующих WorkManager 2.10.0+ , блокировка пробуждения будет называться следующим образом: 

*job*e/#BackupFileWorker#/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Рекомендация

  • Чтобы сделать сообщения о блокировке экрана более подробными на Android 16.1 и выше, обновите версию WorkManager до последней стабильной.
  • Проведите аудит использования рабочих процессов WorkManager. В частности, убедитесь, что оно соответствует нашим рекомендациям по оптимизации использования батареи для API планирования задач . Чтобы сделать теги блокировки пробуждения более подробными на Android 16.1 и выше, используйте метод setTraceTag в рабочем процессе для добавления дополнительной отладочной информации, например, о том, какой класс запланировал рабочий процесс.
  • Если вы обнаружили блокировки пробуждения, создаваемые WorkManager, с высокой частотой их использования, это может быть связано с неправильной настройкой вашего воркера, который не завершает работу в определенных сценариях. Рекомендуется проанализировать причины остановки воркера , особенно если вы наблюдаете частое появление ошибки STOP_REASON_TIMEOUT .
  • Помимо регистрации причин остановки рабочих процессов, ознакомьтесь с нашей документацией по отладке рабочих процессов . Также рекомендуется собирать и анализировать системные трассировки , чтобы понять, когда захватываются и снимаются блокировки пробуждения.

_НЕИЗВЕСТНЫЙ

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

Рекомендация

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