La creazione di un'app 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 numerosi utenti WHOOP su Android, la sincronizzazione e la connettività in background affidabili sono ciò che rende possibili questi approfondimenti.

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 di wakelock non esenti supera le 2 ore in un periodo di 24 ore. Lo scopo di questa metrica è aiutarti a identificare e risolvere le possibili fonti di 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 superfici di scoperta di Google Play. Nella scheda del Google Play Store potrebbe essere visualizzato anche un avviso che indica che l'app potrebbe utilizzare più batteria del previsto.

Secondo Mayank Saini, Senior Android Engineer di WHOOP, questa metrica "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 segnale chiaro che il lavoro in background manteneva la CPU attiva più a lungo del necessario. La risoluzione di questo problema avrebbe consentito di continuare a offrire un'esperienza utente ottimale, riducendo al contempo il tempo di background sprecato e mantenendo una sincronizzazione e una connettività Bluetooth affidabili e tempestive.

Identificare il problema

Per capire da dove iniziare, il team ha prima consultato Android vitals per ottenere maggiori informazioni su quali wakelock influivano sulla metrica. Consultando la dashboard Wakelock parziali eccessivi di Android vitals, è stato possibile identificare il principale fattore che contribuiva ai wakelock parziali eccessivi in uno dei worker di WorkManager (identificato nella dashboard come androidx.work.impl.background.systemjob.SystemJobService). Per supportare l'"esperienza sempre attiva" di WHOOP, l'app utilizza WorkManager per le 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 Wakelock parziali eccessivi in Android vitals.

Dopo che la dashboard ha identificato WorkManager come il principale fattore che contribuiva al problema, il team ha potuto concentrare i propri sforzi sull'identificazione del worker che contribuiva maggiormente e lavorare per risolvere il problema.

Utilizzare metriche e dati interni per restringere ulteriormente la causa

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

1. Durata media: per quanto tempo viene eseguito il worker?
2. Timeout: con quale frequenza il worker va in timeout anziché completare l'attività?
3. Tentativi: con quale frequenza il worker riprova se l'attività va in timeout o non riesce?
4. Annullamenti: con quale frequenza l'attività è stata annullata?

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

Le metriche interne hanno segnalato una durata media elevata per alcuni worker selezionati, consentendo di restringere ulteriormente l'indagine. 

Oltre alle metriche interne, il team ha utilizzato anche lo strumento di ispezione delle attività in background di Android Studio per ispezionare ed eseguire il debug dei worker di interesse, con un'attenzione particolare ai wakelock associati, in modo da allinearsi alla metrica segnalata in Android vitals.

Indagine: distinguere tra le varianti dei worker

WHOOP utilizza la pianificazione una tantum e periodica per alcuni worker. In questo modo, l'app può riutilizzare la stessa logica del 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 worker specifico, ma non è stato possibile stabilire se il bug si verificava quando il worker era una tantum, periodico o entrambi. Pertanto, è stato 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 avrebbe consentito di identificare in modo definitivo quale variante del worker (periodica o una tantum) contribuiva maggiormente alle sessioni con wakelock parziali eccessivi. Tuttavia, il team è rimasto sorpreso quando i dati hanno rivelato che nessuna delle due varianti sembrava contribuire più dell'altra.

Manmeet Tuteja, Android Engineer II di WHOOP, ha dichiarato che "questa 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 di business condivisa all'interno dell'implementazione del worker".

Approfondire il comportamento dei worker e correggere la causa principale

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

Tutto ciò ha portato alla scoperta della causa principale dei wakelock eccessivi:

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

Se l'attività è iniziata senza che fosse collegato alcun sensore, whoopSensorFlow, che indica se il sensore è collegato, era null. SensorWorker non ha trattato questa condizione come una condizione di uscita anticipata e ha continuato a essere eseguito, attendendo indefinitamente una connessione. Di conseguenza, WorkManager ha mantenuto un wakelock parziale fino al timeout dell'attività, con conseguente elevato utilizzo di wakelock in background e riprogrammazione frequente e indesiderata di SensorWorker.

Per risolvere il problema, il team WHOOP ha aggiornato la logica del worker in modo da 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()
            }
}

Ottenere una 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 verificare l'impatto delle modifiche. 

In definitiva, WHOOP ha registrato un calo della percentuale di wakelock parziali eccessivi dal 15% a meno dell'1% solo 30 giorni dopo l'implementazione delle modifiche al worker. 

Grazie alle modifiche, il team ha riscontrato un minor numero di casi di timeout delle attività senza completamento, con conseguente riduzione della durata media di esecuzione. 

Il consiglio del team WHOOP ad altri sviluppatori che vogliono migliorare l'efficienza del proprio 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 Wakelock parziali eccessivi della tua app in Android vitals e consulta la documentazione sui wakelock per ulteriori best practice e strategie di debug.