Как оптимизировать расход батареи приложения с помощью показателя запрета блокировки в Android Vitals

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

Чрезмерное использование частичных запретов блокировки в Android Vitals

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

Теперь в Android Vitals есть основной показатель "Слишком долгая работа частичных запретов блокировки". Он поможет повысить производительность и уменьшить расход батареи. Мы определили порог соответствия для слишком длительных запретов блокировки. С 1 марта 2026 года мы можем исключать из рекомендаций и других разделов, где пользователи ищут контент, фильмы и сериалы, которые не соответствуют этому порогу качества. В некоторых случаях мы можем показывать на странице приложения в Google Play предупреждение о том, что оно может быстро разряжать батарею.

Предупреждение о слишком частом использовании запрета блокировки на странице Обзор Android Vitals.

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

• Блокировка пробуждения удерживается не менее двух часов в течение 24 часов.
• Проблема затрагивает более 5% сеансов в приложении (в среднем за 28 дней).

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

Что такое запрет блокировки

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

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

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

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

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

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

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

Ответьте на четыре важных вопроса.

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

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

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

1. Нужно ли, чтобы экран был включен?
   • Да. Вместо этого ознакомьтесь с документацией по функции Не выключать экран.
2. Запущена ли в приложении активная служба?
   • Нет. Вам не нужно вручную получать блокировку пробуждения.
3. Влияет ли на удобство для пользователей переход устройства в спящий режим?
   • Нет. Например, чтобы обновить уведомление после того, как устройство выйдет из спящего режима, блокировка пробуждения не нужна.
   • Да. Если важно, чтобы устройство не переходило в спящий режим, например при обмене данными с внешним устройством, продолжайте.
4. Используется ли уже какой-либо API, чтобы устройство не переходило в спящий режим?
   • Чтобы определить, в каких случаях блокировки пробуждения создаются другими API, например LocationManager, ознакомьтесь с документацией Как определить блокировки пробуждения, созданные другими API.
   • Если API нет, перейдите к последнему вопросу.
5. Если вы ответили на все эти вопросы и пришли к выводу, что альтернативы нет, вам следует вручную получить блокировку пробуждения.

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

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

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

Снимок экрана инспектора фоновых задач, на котором показано, что работник WeatherSyncWorker часто повторяет попытки и терпит неудачу.

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

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

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

WorkManager getStopReason

Для отладки в полевых условиях рабочих процессов с чрезмерным количеством блокировок пробуждения используйте WorkInfo.getStopReason() в WorkManager 2.9.0+ или JobParameters.getStopReason() в JobScheduler (доступно в 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, для отладки рекомендуется использовать сбор трассировок системы.

Сбор данных отслеживания системы

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

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

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

Включите категорию Atrace power:PowerManagement в интерфейсе Perfetto на вкладке Android apps & svcs (Приложения и сервисы Android). 

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

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

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

Закрепите дорожки в разделе "Состояние устройства", например "Основное приложение", "Состояние экрана", "Длительные блокировки пробуждения" и "Задачи", чтобы визуально определить длительные блокировки пробуждения.

В каждом блоке указано название события, а также время его начала и окончания. В 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 – лишь небольшая часть нашей работы по поддержке разработчиков в вопросах снижения расхода батареи и повышения качества приложений. 

Правильное использование блокировок пробуждения позволяет значительно оптимизировать расход заряда батареи. Чтобы ваше приложение было успешным в Google Play, используйте альтернативные API, следуйте рекомендациям по работе с запретом блокировки и применяйте эффективные инструменты отладки, такие как инспектор фоновых задач, системные трассировки и ProfilingManager.