Как разработчики WHOOP сократили количество сеансов со слишком долго работающими частичными запретами блокировки более чем на 90%

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

Ранее в этом году Google Play выпустил новый показатель в Android Vitals – "Слишком частые частичные запреты блокировки". Этот показатель отражает процент пользовательских сеансов, в которых совокупное время запрета блокировки без исключений превышает два часа за 24-часовой период. Этот показатель помогает выявлять и устранять возможные причины разряда батареи, что очень важно для удобства пользователей.

С 1 марта 2026 года приложения, которые не соответствуют порогу качества, могут быть исключены из разделов Google Play, предназначенных для поиска контента. На странице приложения в Google Play может появиться предупреждение о том, что оно может расходовать больше заряда батареи, чем ожидается.

По словам Маянка Саини (Mayank Saini), старшего инженера Android в WHOOP, это "дало команде возможность повысить эффективность приложения для Android". Android Vitals показал, что доля слишком долгой работы частичных запретов блокировки в приложении составляет 15 %, что превышает рекомендуемый порог в 5 %.

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

Как выявить проблему

Чтобы понять, с чего начать, команда сначала обратилась к Android Vitals, чтобы узнать, какие запреты блокировки влияют на показатель. Изучив панель управления Android Vitals с данными о чрезмерном количестве частичных запретов блокировки, разработчики выяснили, что основной причиной проблемы был один из воркеров WorkManager (на панели управления он обозначен как androidx.work.impl.background.systemjob.SystemJobService). Чтобы обеспечить постоянную работу WHOOP, приложение использует WorkManager для фоновых задач, таких как периодическая синхронизация и регулярная отправка обновлений на носимое устройство. 

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

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

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

У WHOOP уже была внутренняя инфраструктура для отслеживания показателей WorkManager. Они периодически проверяют:

1. Среднее время выполнения: сколько времени работает исполнитель?
2. Тайм-ауты. Как часто у исполнителя истекает время на выполнение задачи?
3. Повторные попытки. Как часто исполнитель повторяет попытку, если время ожидания истекло или произошел сбой?
4. Отмены. Как часто отменялись заказы?

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

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

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

Исследование: различия между вариантами рабочих процессов

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

Используя внутренние показатели, они смогли сузить поиск до конкретного воркера, но не могли определить, возникала ли ошибка, когда воркер был одноразовым, периодическим или и тем, и другим. Поэтому они выпустили обновление, в котором использовали метод setTraceTag из WorkManager, чтобы различать однократные и периодические варианты одного и того же Worker.

Эти дополнительные сведения позволят им точно определить, какой вариант воркера (периодический или однократный) больше всего способствовал сеансам с чрезмерными частичными запретами блокировки. Однако команда была удивлена, когда данные показали, что ни один из вариантов не вносит больший вклад, чем другой.

Манмит Тутеджа (Manmeet Tuteja), Android Engineer II в WHOOP, отметил: "Это разделение также помогло нам подтвердить, что проблема возникала в обоих вариантах. Это указывало на то, что проблема была не в конфигурации планирования, а в общей бизнес-логике внутри реализации Worker".

Анализ поведения работников и устранение основной причины

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

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

CoroutineWorker, который ожидает подключения к датчику WHOOP, прежде чем продолжить. 

Если работа началась без подключенного датчика, whoopSensorFlow (указывает, подключен ли датчик) было равно null.SensorWorker не рассматривал это как условие для раннего выхода и продолжал работать, фактически бесконечно ожидая подключения. В результате WorkManager удерживал частичный запрет блокировки до истечения времени ожидания, что приводило к частому использованию запрета блокировки в фоновом режиме и нежелательному переносу SensorWorker.

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

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

class SensorWorker(appContext: Context, params: WorkerParameters): CoroutineWorker(appContext, params) {
   override suspend fun doWork(): Result {
      ...
      // Check the sensor state and perform work or return failure
       return whoopSensorFlow.replayCache
            .firstOrNull()
            ?.let { cachedData ->
                processSensorData(cachedData)
                Result.success()
            } ?: run {
                Result.failure()
            }
}

Как сократить количество сеансов с чрезмерным числом частичных запретов блокировки на 90%

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

В результате доля частичных запретов блокировки снизилась с 15% до менее чем 1% всего за 30 дней после изменения Worker. 

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

Вот что команда WHOOP советует другим разработчикам, которые хотят повысить эффективность фоновых задач:

Начать

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