Cómo WHOOP disminuyó las sesiones de bloqueos de activación parciales excesivos en más de un 90%

Cuando se compila una app para Android para un dispositivo wearable, el trabajo real 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. Para los muchos miembros de WHOOP en Android, la conectividad y la sincronización confiables en segundo plano son lo que hace posible esas estadísticas.

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 usuarios en las que el uso acumulativo y no exento de bloqueos de activación supera las 2 horas en un período de 24 horas. El objetivo de esta métrica es ayudarte a identificar y abordar 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, las apps que no cumplan con el umbral de calidad podrían excluirse de las plataformas de descubrimiento de Google Play. También se puede colocar una advertencia en la ficha de Google Play Store, que indique 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 elevar el estándar de eficiencia de Android”, después de que Android vitals marcara el porcentaje de bloqueos de activación parciales excesivos de la app como 15%, lo que superaba el umbral recomendado del 5%.

El equipo consideró que la métrica de Android vitals era una señal clara de que su trabajo en segundo plano mantenía la CPU activa más tiempo del necesario. Resolver esto les permitiría seguir brindando una excelente experiencia del usuario y, al mismo tiempo, disminuir el tiempo perdido en segundo plano y mantener la conectividad y la 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. Al consultar 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 admitir 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 dispositivo wearable. 

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

Como el panel identificó 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.

Usa métricas y datos internos para acotar mejor la causa

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

1. Tiempo de ejecución promedio: ¿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 vuelve a intentarlo si se agotó el tiempo de espera o falló?
4. Cancelaciones: ¿Con qué frecuencia se canceló el trabajo?

El seguimiento de más que solo los éxitos y las fallas de los trabajadores le da al equipo visibilidad de la eficiencia de su trabajo.

Las métricas internas marcaron un tiempo de ejecución promedio alto para algunos 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 a 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.

El uso de sus métricas internas permitió acotar 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 manera definitiva qué variante de Worker (periódica o única) contribuía 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 que “esa división también nos ayudó a confirmar que el problema ocurría en ambas variantes, lo que indicaba que no se trataba de un problema de configuración de programación, sino de un problema de lógica empresarial compartida dentro de la implementación del trabajador”.

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

Con el conocimiento de que necesitaban 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. En particular, buscaban instancias en las que el trabajo podría haberse quedado atascado y no completarse.

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

Un CoroutineWorker diseñado para esperar una conexión al sensor WHOOP antes de continuar. 

Si el trabajo comenzaba sin un 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 provocó un uso elevado 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 verificar el estado de la conexión antes de intentar ejecutar la lógica empresarial principal.

Si el sensor no está disponible, el trabajador sale, 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()
            }
}

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

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

En última instancia, WHOOP observó 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 agotado sin completarse, lo que generó tiempos de ejecución promedio más bajos. 

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

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 de bloqueos de activación para obtener más prácticas recomendadas y estrategias de depuración.