Оптимизируйте расход заряда батареи вашего приложения с помощью метрики блокировки пробуждения Android Vitals.

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

Чрезмерное использование частичной блокировки пробуждения в Android Vitals

Теперь Play Console отслеживает разряд батареи, уделяя особое внимание чрезмерному использованию частичной блокировки пробуждения , как ключевому показателю производительности.

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

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

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

Шлюзы, удерживаемые в течение 24 часов, должны оставаться в силе не менее двух часов.
В среднем за 28 дней это затрагивает более 5% сессий вашего приложения.

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

Понимание блокировки пробуждения

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

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

Существует два метода получения частичной блокировки пробуждения:

Приложение вручную получает и снимает блокировку пробуждения, используя API PowerManager для конкретного сценария использования; часто это происходит совместно с фоновой службой — API жизненного цикла платформы, предназначенным для работы, воспринимаемой пользователем.
В качестве альтернативы, блокировка пробуждения может быть получена с помощью другого API и отнесена к приложению в связи с использованием этого API; подробнее об этом в разделе «Рекомендации по использованию».

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

Рекомендации по использованию блокировки пробуждения (Wake Lock).

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

Рассмотрите эти четыре важных вопроса.

1. Рассматривали ли вы альтернативные варианты блокировки пробуждения?

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

Блок-схема для принятия решения о том, когда следует вручную получить блокировку сигнала пробуждения.

Экран должен оставаться включенным?
- Да: Вместо этого обратитесь к документации по функции « Оставить экран включенным».
Приложение запускает службу переднего плана?
- Нет: вам не нужно вручную получать блокировку пробуждения.
Вредит ли переход устройства в спящий режим для удобства пользователя?
- Нет: Например, для обновления уведомления после пробуждения устройства блокировка пробуждения не требуется.
- Да: Если предотвращение приостановки работы устройства крайне важно, например, для поддержания связи с внешним устройством, продолжайте.
Существует ли уже API, который поддерживает устройство в активном состоянии от вашего имени?
- Вы можете использовать документацию «Идентификация блокировок пробуждения, созданных другими API» , чтобы определить сценарии, в которых блокировки пробуждения создаются другими API, например, LocationManager.
- Если API отсутствуют, переходите к последнему вопросу.
Если вы ответили на все эти вопросы и пришли к выводу, что альтернативы не существует, вам следует приступить к ручному получению блокировки пробуждения.

2. Правильно ли вы называете блокировку пробуждения?

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

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

3. Всегда ли снимается полученная блокировка пробуждения?

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

Например, если во время обработки события processingWork() возникает необработанное исключение, вызов release() может никогда не произойти. Вместо этого можно использовать блок try-finally, чтобы гарантировать снятие блокировки пробуждения, даже если возникнет исключение.

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

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. Можно ли уменьшить частоту пробуждений?

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

WorkManager: Увеличьте периодический интервал в PeriodicWorkRequest .
SensorManager: Используйте пакетную обработку, указав maxReportLatencyMs при регистрации слушателя.
Объединенный поставщик местоположения:
- Сократите частоту получения данных о местоположении, используя функцию getLastLocation для получения самого последнего сохраненного в кэше местоположения.
- Используйте setPriority(PRIORITY_PASSIVE ) для более экономичного с точки зрения энергопотребления метода обновления.
- Кроме того, вы можете использовать механизм пакетной обработки данных о местоположении, установив минимальный интервал обновления с помощью параметра setMinUpdateIntervalMillis .

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

Отладка чрезмерного использования блокировки пробуждения

Даже при самых благих намерениях может происходить чрезмерное использование блокировки пробуждения. Если ваше приложение отмечено в Play Console, вот как это исправить:

Первоначальная идентификация с помощью Play Console

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

На панели мониторинга Android Vitals, посвященной чрезмерной частичной блокировке пробуждения, прокрутите вниз до раздела "Разборчивая информация", чтобы просмотреть теги, относящиеся к чрезмерной блокировке пробуждения.

Отладка чрезмерного количества блокировок пробуждения, удерживаемых рабочими процессами/заданиями.

Идентифицировать блокировки пробуждения, удерживаемые работником, можно по имени этой блокировки пробуждения:

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

Полный список вариантов имен блокировок пробуждения, удерживаемых рабочим процессом, доступен в документации . Для отладки этих блокировок пробуждения можно использовать Background Task Inspector для локальной отладки или getStopReason для отладки проблем в полевых условиях.

Инспектор фоновых задач Android Studio

Скриншот инспектора фоновых задач, где видно, что он смог идентифицировать рабочий процесс «WeatherSyncWorker», который часто повторял попытки и терпел неудачу.

Для локальной отладки проблем WorkManager используйте этот инструмент на эмуляторе или подключенном устройстве (уровень API 26+). Он отображает список рабочих процессов и их статусы (завершены, выполняются, поставлены в очередь), что позволяет изучить детали и понять цепочки рабочих процессов.

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

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

WorkManager getStopReason

Для отладки рабочих процессов с чрезмерным количеством блокировок пробуждения в полевых условиях используйте WorkInfo.getStopReason() в WorkManager 2.9.0+ или JobScheduler JobParameters.getStopReason() доступный в SDK 31+.

Этот API помогает регистрировать причину остановки рабочего процесса (например, STOP_REASON_TIMEOUT , STOP_REASON_QUOTA ), выявляя такие проблемы, как частые таймауты из-за исчерпания времени выполнения.

backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

Дополнительные сведения см. в разделе «Оптимизация использования батареи для API планирования задач» .

Отладка других типов чрезмерных блокировок пробуждения.

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

Сбор системных трассировок

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

Для получения трассировки системы можно использовать несколько методов:

Использование инструмента командной строки трассировки системы.
Использование профилировщика ЦП в Android Studio
Использование пользовательского интерфейса Perfetto
Запись трассировки вручную на устройстве непосредственно из параметров разработчика .

Включите категорию трассировки "power:PowerManagement" в пользовательском интерфейсе Perfetto на вкладке "Приложения и службы Android".

Независимо от выбранного метода, крайне важно убедиться, что вы собираете данные категории Atrace "power:PowerManagement" , чтобы иметь возможность просматривать треки состояния устройства.

Проверка пользовательского интерфейса Perfetto и анализ SQL-запросов

Системные трассировки можно открыть и просмотреть в пользовательском интерфейсе Perfetto . При открытии трассировки вы увидите визуализацию различных процессов на временной шкале. В этом руководстве мы сосредоточимся на трассировках, относящихся к разделу «Состояние устройства».

Закрепите треки в разделе «Состояние устройства», такие как «Лучшее приложение», «Состояние экрана», «Длительные блокировки пробуждения» и «Задания», чтобы визуально идентифицировать длительные периоды блокировки пробуждения.

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

Для масштабируемого анализа множества трассировок можно использовать SQL-анализ Perfetto . SQL-запрос может найти все блокировки пробуждения, отсортированные по длительности, что поможет выявить основные источники чрезмерного использования ресурсов.

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

SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

Используйте ProfilingManager для сбора данных трассировки непосредственно в полевых условиях.

Для решения трудновоспроизводимых проблем используется ProfilingManager (добавленный в SDK 35) — программный API, позволяющий разработчикам собирать системные трассировки в полевых условиях с помощью начальных и конечных триггеров. Он обеспечивает больший контроль над точками начала и окончания сбора профилирования и применяет ограничение скорости на системном уровне для предотвращения снижения производительности устройства.

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

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

Заключение

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

Понимание и правильная реализация блокировок пробуждения могут значительно оптимизировать энергопотребление вашего приложения. Использование альтернативных API, соблюдение лучших практик использования блокировок пробуждения и применение мощных инструментов отладки, таких как Background Task Inspector, системная трассировка и ProfilingManager, являются ключом к успеху вашего приложения в Google Play.

Автор:

Alice Yuan
Инженер по связям с разработчиками
read_more Просмотреть профиль

Продолжить чтение

21 апреля 2026 г.
21 апреля 2026 г.
Новости о продуктах
Улучшите свои навыки разработки с помощью режима планирования и прогнозирования следующего изменения в Android Studio Panda 4.
arrow_forward
Android Studio Panda 4 теперь стабильна и готова к использованию в продакшене. В этом релизе появились режим планирования, прогнозирование следующего изменения и многое другое, что делает создание высококачественных Android-приложений проще, чем когда-либо.
Matt Dyor • 5 мин чтения
17 апреля 2026 г.
17 апреля 2026 г.
Новости о продуктах
Экспериментальный гибридный вывод и новые модели Gemini для Android
arrow_forward
Если вы — разработчик Android-приложений, стремящийся внедрить в них инновационные функции искусственного интеллекта, то недавно мы выпустили новые мощные обновления.
Thomas Ezan • 3 мин чтения
16 апреля 2026 г.
16 апреля 2026 г.
Новости о продуктах
Четвертая бета-версия Android 17
arrow_forward
Android 17 достиг четвертой бета-версии, последней запланированной бета-версии этого цикла релизов, что является критически важным этапом для обеспечения совместимости приложений и стабильности платформы.
Daniel Galpin • 4 мин чтения