Cómo WHOOP disminuyó las sesiones de bloqueo de activación parcial excesivo en más de un 90%

Cuando se compila una app para Android para un wearable, el verdadero trabajo comienza cuando se apaga la pantalla. WHOOP ayuda a los miembros a comprender cómo responde su cuerpo al entrenamiento, la recuperación, el sueño y el estrés, y para los muchos miembros de WHOOP que usan Android, la sincronización y la conectividad en segundo plano confiables son lo que hace posible esa información.

A principios de este año, Google Play lanzó una nueva métrica en Android vitals: Bloqueos de activación parciales excesivos. Esta métrica mide el porcentaje de sesiones de usuario en las que el uso acumulado de bloqueos de activación no exentos supera las 2 horas en un período de 24 horas. El objetivo de esta métrica es ayudarte a identificar y abordar las posibles fuentes de agotamiento de la batería, lo que es fundamental para brindar una excelente experiencia del usuario.

A partir del 1 de marzo de 2026, es posible que las apps que sigan sin cumplir con el umbral de calidad se excluyan de las plataformas de descubrimiento de Google Play. También es posible que se coloque una advertencia en la ficha de Google Play Store para indicar que la app podría usar más batería de lo esperado.

Según Mayank Saini, ingeniero sénior de Android en WHOOP, esto “le dio al equipo la oportunidad de mejorar la eficiencia en Android”, después de que Android vitals marcó el porcentaje de bloqueos de activación parciales excesivos de la app como un 15%, lo que superaba el umbral recomendado del 5%.

El equipo consideró la métrica de Android vitals como un indicador claro de que su trabajo en segundo plano mantenía la CPU activa durante más tiempo del necesario. Resolver este problema les permitiría seguir ofreciendo una excelente experiencia del usuario y, al mismo tiempo, disminuir el tiempo de inactividad en segundo plano y mantener una conectividad y sincronización de Bluetooth confiables y oportunas.

Identifica el problema

Para saber por dónde empezar, el equipo primero recurrió a Android vitals para obtener más información sobre qué bloqueos de activación afectaban la métrica. Consultando el panel de bloqueos de activación parciales excesivos de Android vitals, pudieron identificar que el mayor contribuyente a los bloqueos de activación parciales excesivos era uno de sus trabajadores de WorkManager (identificado en el panel como androidx.work.impl.background.systemjob.SystemJobService). Para respaldar la “experiencia siempre activa” de WHOOP, la app usa WorkManager para tareas en segundo plano, como la sincronización periódica y la entrega de actualizaciones recurrentes al wearable. 

Si bien el equipo sabía que WorkManager adquiere un bloqueo de activación mientras ejecuta tareas en segundo plano, antes no tenía visibilidad de cómo se distribuía todo su trabajo en segundo plano (más allá de WorkManager) hasta que se introdujo la métrica de bloqueos de activación parciales excesivos en Android vitals.

Con el panel que identificaba a WorkManager como el principal contribuyente, el equipo pudo enfocar sus esfuerzos en identificar cuál de sus trabajadores contribuía más y trabajar para resolver el problema.

Aprovechar las métricas y los datos internos para determinar mejor la causa

WHOOP ya tenía configurada una infraestructura interna para supervisar las métricas de WorkManager. Supervisan periódicamente lo siguiente:

1. Tiempo de ejecución promedio: ¿Durante cuánto tiempo se ejecuta el trabajador?
2. Tiempos de espera: ¿Con qué frecuencia se agota el tiempo de espera del trabajador en lugar de completarse?
3. Reintentos: ¿Con qué frecuencia el trabajador reintenta si se agota el tiempo de espera o falla el trabajo?
4. Cancelaciones: ¿Con qué frecuencia se canceló el trabajo?

Hacer un seguimiento de más que solo los éxitos y fracasos de los trabajadores le da al equipo visibilidad sobre la eficiencia de su trabajo.

Las métricas internas marcaron un tiempo de ejecución promedio alto para unos pocos trabajadores seleccionados, lo que les permitió acotar aún más la investigación. 

Además de sus métricas internas, el equipo también usó el Inspector de tareas en segundo plano de Android Studio para inspeccionar y depurar los trabajadores de interés, con un enfoque específico en los bloqueos de activación asociados, para alinearse con la métrica marcada en Android vitals.

Investigación: Distingue entre las variantes de trabajadores

WHOOP usa la programación única y periódica para algunos trabajadores. Esto permite que la app reutilice la misma lógica de Worker para tareas idénticas con los mismos criterios de éxito, que solo difieren en el tiempo.

Con sus métricas internas, pudieron limitar la búsqueda a un trabajador específico, pero no pudieron determinar si el error se produjo cuando el trabajador era único, periódico o ambos. Por lo tanto, lanzaron una actualización para usar el método setTraceTag de WorkManager para distinguir entre las variantes únicas y periódicas del mismo Worker.

Este detalle adicional les permitiría identificar de forma definitiva qué variante de Worker (periódica o única) contribuyó más a las sesiones con bloqueos de activación parciales excesivos. Sin embargo, el equipo se sorprendió cuando los datos revelaron que ninguna de las variantes parecía contribuir más que la otra.

Manmeet Tuteja, ingeniero de Android II en WHOOP, dijo: “Esa división también nos ayudó a confirmar que el problema se producía en ambas variantes, lo que nos alejó de la configuración de programación y nos llevó a un problema de lógica empresarial compartido dentro de la implementación del trabajador”.

Profundiza en el comportamiento de los trabajadores y corrige la causa raíz

Sabiendo que debían analizar la lógica dentro del trabajador,  el equipo volvió a examinar el comportamiento de los trabajadores que se habían marcado durante la investigación. Específicamente, buscaban instancias en las que el trabajo podría haberse quedado atascado y no se completaba.

Todo esto culminó en la búsqueda de la causa raíz de los bloqueos de activación excesivos:

Un CoroutineWorker que se diseñó para esperar una conexión con el sensor de WHOOP antes de continuar 

Si el trabajo comenzó sin ningún sensor conectado, whoopSensorFlow, que indica si el sensor está conectado, era null. El SensorWorker no trató esto como una condición de salida anticipada y siguió ejecutándose, esperando indefinidamente una conexión. Como resultado, WorkManager mantuvo un bloqueo de activación parcial hasta que se agotó el tiempo de espera del trabajo, lo que generó un alto uso del bloqueo de activación en segundo plano y una reprogramación frecuente y no deseada del SensorWorker.

Para solucionar este problema, el equipo de WHOOP actualizó la lógica del trabajador para que verifique el estado de la conexión antes de intentar ejecutar la lógica empresarial principal.

Si el sensor no está disponible, el trabajador se cierra, lo que evita una situación de tiempo de espera y libera el bloqueo de activación. En el siguiente fragmento de código, se muestra la solución:

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()
            }
}

Cómo lograr una disminución del 90% en las sesiones con bloqueos de activación parciales excesivos

Después de implementar la corrección, el equipo siguió supervisando el panel de Android vitals para confirmar el impacto de los cambios. 

En última instancia, WHOOP vio que su porcentaje de bloqueos de activación parciales excesivos disminuyó del 15% a menos del 1% solo 30 días después de implementar los cambios en su Worker. 

Como resultado de los cambios, el equipo observó menos instancias de tiempo de espera de trabajo sin completar, lo que generó tiempos de ejecución promedio más bajos. 

Este es el consejo del equipo de WHOOP para otros desarrolladores que quieran mejorar la eficiencia de su trabajo en segundo plano:

Comenzar ahora

Si te interesa intentar reducir los bloqueos de activación parciales excesivos de tu app o mejorar la eficiencia de los trabajadores, consulta la métrica de bloqueos de activación parciales excesivos de tu app en Android vitals y revisa la documentación sobre bloqueos de activación para obtener más prácticas recomendadas y estrategias de depuración.