La creazione di un'app per Android per un dispositivo indossabile significa che il vero lavoro inizia quando lo schermo si spegne. WHOOP aiuta gli utenti a capire come il loro corpo risponde all'allenamento, al recupero, al sonno e allo stress e, per i molti utenti WHOOP su Android, la sincronizzazione e la connettività in background affidabili sono ciò che rende possibili queste informazioni.

All'inizio di quest'anno, Google Play ha rilasciato una nuova metrica in Android vitals: wakelock parziali eccessivi. Questa metrica misura la percentuale di sessioni utente in cui l'utilizzo cumulativo del wakelock non esente supera le 2 ore in un periodo di 24 ore. Lo scopo di questa metrica è aiutarti a identificare e risolvere le possibili cause del consumo eccessivo della batteria, il che è fondamentale per offrire un'esperienza utente ottimale.

A partire dal 1° marzo 2026, le app che continuano a non soddisfare la soglia di qualità potrebbero essere escluse dalle piattaforme di scoperta di Google Play. Potrebbe anche essere inserito un avviso nella scheda del Google Play Store, che indica che l'app potrebbe utilizzare più batteria del previsto.

Secondo Mayank Saini, ingegnere Android senior di WHOOP, "questo ha offerto al team l'opportunità di alzare l'asticella dell'efficienza di Android", dopo che Android vitals ha segnalato che la percentuale di wakelock parziali eccessivi dell'app era del 15%, superando la soglia consigliata del 5%.

Il team ha considerato la metrica Android vitals come un chiaro segnale che il lavoro in background manteneva la CPU attiva più a lungo del necessario. La risoluzione di questo problema consentirebbe di continuare a offrire un'esperienza utente ottimale, riducendo al contempo il tempo sprecato in background e mantenendo una connettività e una sincronizzazione Bluetooth affidabili e tempestive.

Identificare il problema

Per capire da dove iniziare, il team si è rivolto ad Android vitals per ottenere maggiori informazioni su quali wake lock influivano sulla metrica. Consultando la dashboard Android vitals per i wake lock parziali eccessivi, sono riusciti a identificare il principale responsabile dei wake lock parziali eccessivi in uno dei loro worker WorkManager (identificato nella dashboard come androidx.work.impl.background.systemjob.SystemJobService). Per supportare l'esperienza "always-on" di WHOOP, l'app utilizza WorkManager per attività in background come la sincronizzazione periodica e la distribuzione di aggiornamenti ricorrenti al dispositivo indossabile. 

Sebbene il team fosse consapevole che WorkManager acquisisce un wakelock durante l'esecuzione delle attività in background, in precedenza non aveva visibilità su come veniva distribuito tutto il lavoro in background (oltre a WorkManager) fino all'introduzione della metrica dei wakelock parziali eccessivi in Android vitals.

Poiché la dashboard ha identificato WorkManager come il principale responsabile, il team ha potuto concentrare i propri sforzi sull'identificazione di quale dei propri worker contribuiva maggiormente e lavorare per risolvere il problema.

Utilizzo di metriche e dati interni per restringere la causa

WHOOP aveva già configurato un'infrastruttura interna per monitorare le metriche di WorkManager. Monitorano periodicamente:

1. Runtime medio: per quanto tempo viene eseguito il worker?
2. Timeout: con quale frequenza il worker va in timeout anziché completare l'operazione?
3. Tentativi: con quale frequenza il worker riprova se il lavoro è scaduto o non è riuscito?
4. Annullamenti: con quale frequenza è stato annullato il lavoro?

Il monitoraggio di più di semplici successi e insuccessi dei lavoratori consente al team di avere visibilità sull'efficienza del proprio lavoro.

Le metriche interne hanno segnalato un tempo di esecuzione medio elevato per alcuni worker selezionati, consentendo di restringere ulteriormente l'indagine. 

Oltre alle metriche interne, il team ha utilizzato anche Background Task Inspector di Android Studio per esaminare ed eseguire il debug dei worker di interesse, con un'attenzione particolare ai wake lock associati, in modo da allinearsi alla metrica segnalata in Android vitals.

Indagine: distinguere tra le varianti dei lavoratori

WHOOP utilizza la pianificazione sia una tantum sia periodica per alcuni worker. Ciò consente all'app di riutilizzare la stessa logica di Worker per attività identiche con gli stessi criteri di successo, che differiscono solo per la tempistica.

L'utilizzo delle metriche interne ha consentito di restringere la ricerca a un lavoratore specifico, ma non è stato possibile stabilire se il bug si è verificato quando il lavoratore era una tantum, periodico o entrambi. Pertanto, hanno implementato un aggiornamento per utilizzare il metodo setTraceTag di WorkManager per distinguere tra le varianti una tantum e periodiche dello stesso Worker.

Questo dettaglio aggiuntivo consentirebbe di identificare in modo definitivo quale variante di Worker (periodica o una tantum) contribuisce maggiormente alle sessioni con wake lock parziali eccessivi. Tuttavia, il team è rimasto sorpreso quando i dati hanno rivelato che nessuna delle due varianti sembrava contribuire più dell'altra.

Manmeet Tuteja, ingegnere Android II di WHOOP, ha dichiarato che "la suddivisione ci ha anche aiutato a confermare che il problema si verificava in entrambe le varianti, il che ha escluso la configurazione della pianificazione e ha indicato un problema di logica aziendale condivisa all'interno dell'implementazione del worker".

Approfondimento del comportamento dei worker e risoluzione della causa principale

Sapendo di dover esaminare la logica all'interno del lavoratore,  il team ha riesaminato il comportamento dei lavoratori segnalati durante l'indagine. In particolare, cercavano istanze in cui il lavoro potrebbe essere bloccato e non completato.

Tutto ciò ha portato all'individuazione della causa principale dei wakelock eccessivi:

Un CoroutineWorker progettato per attendere una connessione al sensore WHOOP prima di procedere. 

Se il lavoro è iniziato senza che fosse collegato alcun sensore, whoopSensorFlow, che indica se il sensore è connesso, era null. SensorWorker non ha considerato questa situazione come una condizione di uscita anticipata e ha continuato a funzionare, attendendo indefinitamente una connessione. Di conseguenza, WorkManager ha mantenuto un wakelock parziale fino allo scadere del lavoro, il che ha comportato un elevato utilizzo del wakelock in background e una riprogrammazione frequente e indesiderata di SensorWorker.

Per risolvere il problema, il team di WHOOP ha aggiornato la logica del worker per controllare lo stato della connessione prima di tentare di eseguire la logica di business principale.

Se il sensore non è disponibile, il worker esce, evitando uno scenario di timeout e rilasciando il wakelock. Il seguente snippet di codice mostra la soluzione:

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

Riduzione del 90% delle sessioni con wakelock parziali eccessivi

Dopo aver implementato la correzione, il team ha continuato a monitorare la dashboard Android vitals per confermare l'impatto delle modifiche. 

Alla fine, WHOOP ha visto la percentuale di wake lock parziali eccessivi scendere dal 15% a meno dell'1% in soli 30 giorni dopo aver implementato le modifiche al proprio worker. 

A seguito delle modifiche, il team ha riscontrato un numero inferiore di casi di timeout del lavoro senza completamento, con conseguente riduzione dei tempi di esecuzione medi. 

Il consiglio del team di WHOOP per gli altri sviluppatori che vogliono migliorare l'efficienza del lavoro in background:

Inizia

Se ti interessa provare a ridurre i wakelock parziali eccessivi della tua app o a migliorare l'efficienza dei worker, visualizza la metrica relativa ai wakelock parziali eccessivi della tua app in Android vitals e consulta la documentazione sui wakelock per ulteriori best practice e strategie di debug.