L'utilizzo della radio wireless per trasferire dati è potenzialmente una delle fonti più significative di consumo della batteria della tua app. Per ridurre al minimo il consumo della batteria associato all'attività di rete, è fondamentale comprendere in che modo il modello di connettività influenzerà l'hardware radio sottostante.
Questa sezione introduce la macchina a stati della radio wireless e spiega come interagisce con essa il modello di connettività della tua app. Offre poi diverse tecniche che, se seguite, contribuiranno a ridurre al minimo l'effetto del consumo di dati della tua app sulla batteria.
La macchina a stati della radio
La radio wireless sul dispositivo dell'utente dispone di funzionalità di risparmio energetico integrate che contribuiscono a ridurre al minimo la quantità di energia della batteria che consuma. Quando è completamente attivo, il modulo radio wireless consuma molta energia, ma quando è inattivo o in standby, il modulo radio consuma pochissima energia.
Un fattore importante da ricordare è che la radio non può passare dalla modalità standby a completamente attiva istantaneamente. Esiste un periodo di latenza associato all'accensione della radio. Pertanto, la batteria passa lentamente da stati di energia più elevati a stati di energia più bassi per risparmiare energia quando non è in uso, cercando di ridurre al minimo la latenza associata all'"accensione" della radio.
La macchina a stati per una tipica radio di rete 3G è costituita da tre stati di energia:
- Piena potenza: utilizzata quando una connessione è attiva, consentendo al dispositivo di trasferire i dati alla massima velocità possibile.
- Risparmio energetico: uno stato intermedio che riduce il consumo di batteria di circa il 50%.
- Standby: lo stato di consumo energetico minimo durante il quale non è attiva alcuna connessione di rete.
Sebbene gli stati di basso consumo e standby consumino molta meno batteria, introducono anche una latenza significativa nelle richieste di rete. Il ritorno alla piena potenza dallo stato di batteria scarica richiede circa 1,5 secondi, mentre il passaggio dalla modalità standby alla piena potenza può richiedere più di 2 secondi.
Per ridurre al minimo la latenza, la macchina a stati utilizza un ritardo per posticipare la transizione agli stati di consumo energetico inferiore. La Figura 1 utilizza i tempi di AT&T per una tipica radio 3G.
Figura 1. Macchina a stati tipica della radio wireless 3G.
La macchina a stati della radio su ogni dispositivo, in particolare il ritardo di transizione associato ("tempo di coda") e la latenza di avvio, varia in base alla tecnologia radio wireless utilizzata (3G, LTE, 5G e così via) ed è definita e configurata dalla rete dell'operatore su cui opera il dispositivo.
Questa pagina descrive una macchina a stati rappresentativa per una tipica radio wireless 3G, basata sui dati forniti da AT&T. Tuttavia, i principi generali e le best practice risultanti sono applicabili a tutte le implementazioni di radio wireless.
Questo approccio è particolarmente efficace per la tipica navigazione web mobile, in quanto previene la latenza indesiderata durante la navigazione web degli utenti. Il tempo di coda relativamente basso garantisce inoltre che, una volta terminata una sessione di navigazione, la radio possa passare a uno stato di consumo energetico inferiore.
Purtroppo, questo approccio può portare a inefficienze nelle app sui moderni sistemi operativi per smartphone come Android, in cui le app vengono eseguite sia in primo piano (dove la latenza è importante) sia in background (dove la durata della batteria deve essere una priorità).
In che modo le app influiscono sulla macchina a stati della radio
Ogni volta che crei una nuova connessione di rete, la radio passa allo stato di piena potenza. Nel caso della macchina a stati della radio 3G tipica descritta in precedenza, rimarrà a piena potenza per la durata del trasferimento, più 5 secondi aggiuntivi di tempo di coda, seguiti da 12 secondi nello stato di basso consumo energetico. Pertanto, per un tipico dispositivo 3G, ogni sessione di trasferimento dei dati farà sì che la radio assorba energia per almeno 18 secondi.
In pratica, ciò significa che un'app che esegue un trasferimento di dati di un secondo, tre volte al minuto, manterrà la radio wireless perennemente attiva, riportandola alla potenza elevata proprio mentre entra in modalità standby.
Figura 2. Utilizzo relativo della potenza della radio wireless per il trasferimento di un secondo in esecuzione
tre volte al minuto. La cifra esclude la latenza di "accensione" tra le corse.
Al contrario, se la stessa app raggruppasse i trasferimenti di dati, eseguendo un singolo trasferimento di tre secondi ogni minuto, la radio rimarrebbe nello stato di alta potenza per un totale di soli 20 secondi al minuto. In questo modo, la radio rimane in standby per 40 secondi al minuto, con una conseguente riduzione significativa del consumo della batteria.
Figura 3. Utilizzo relativo della potenza della radio wireless per trasferimenti di tre secondi
eseguiti una volta al minuto.
Tecniche di ottimizzazione
Ora che hai capito come l'accesso alla rete influisce sulla durata della batteria, parliamo di alcune cose che puoi fare per ridurre il consumo della batteria, garantendo al contempo un'esperienza utente rapida e fluida.
Trasferimenti di dati in bundle
Come indicato nella sezione precedente, raggruppare i trasferimenti di dati in modo da trasferire più dati meno spesso è uno dei modi migliori per migliorare l'efficienza della batteria.
Naturalmente, non è sempre possibile farlo se la tua app deve ricevere o inviare dati immediatamente in risposta a un'azione dell'utente. Puoi mitigare questo problema anticipando e precaricando i dati. Altri scenari, come l'invio di log o analisi a un server e altri trasferimenti di dati avviati da app non urgenti, si prestano molto bene al raggruppamento e al bundling. Consulta la sezione Ottimizzazione delle attività avviate dalle app per suggerimenti sulla pianificazione dei trasferimenti di rete in background.
Precaricare i dati
Il precaricamento dei dati è un altro modo efficace per ridurre il numero di sessioni di trasferimento dei dati indipendenti eseguite dall'app. Con il recupero anticipato, quando l'utente esegue un'azione nella tua app, l'app prevede quali dati saranno probabilmente necessari per la successiva serie di azioni dell'utente e li recupera in un'unica sessione, tramite un'unica connessione, alla massima capacità.
Anticipando i trasferimenti, riduci il numero di attivazioni della radio necessarie per scaricare i dati. Di conseguenza, non solo risparmi batteria, ma migliori anche la latenza, riduci la larghezza di banda richiesta e i tempi di download.
Il precaricamento offre anche un'esperienza utente migliorata riducendo al minimo la latenza in-app causata dall'attesa del completamento dei download prima di eseguire un'azione o visualizzare i dati.
Ecco un esempio pratico.
Un lettore di notizie
Molte app di notizie tentano di ridurre la larghezza di banda scaricando i titoli solo dopo che è stata selezionata una categoria, gli articoli completi solo quando l'utente vuole leggerli e le miniature solo quando scorrono nella visualizzazione.
Con questo approccio, la radio è costretta a rimanere attiva per la maggior parte della sessione di lettura delle notizie degli utenti mentre scorrono i titoli, cambiano categoria e leggono gli articoli. Inoltre, il passaggio costante da uno stato di energia all'altro comporta una latenza significativa quando si cambiano categorie o si leggono articoli.
Un approccio migliore è precaricare una quantità ragionevole di dati all'avvio, a partire dal primo insieme di titoli e miniature delle notizie, garantendo un tempo di avvio a bassa latenza, e continuare con i titoli e le miniature rimanenti, nonché con il testo di ogni articolo disponibile almeno nell'elenco dei titoli principali.
Un'altra alternativa è il precaricamento di tutti i titoli, le miniature, il testo degli articoli e possibilmente anche le immagini degli articoli completi, in genere in background secondo una pianificazione predeterminata. Questo approccio rischia di consumare una quantità significativa di larghezza di banda e durata della batteria scaricando contenuti che non vengono mai utilizzati, pertanto deve essere implementato con cautela.
Considerazioni aggiuntive
Sebbene il precaricamento dei dati offra molti vantaggi, se utilizzato in modo troppo aggressivo introduce anche il rischio di aumentare il consumo di batteria e di larghezza di banda e la quota di download, scaricando dati che non vengono utilizzati. È anche importante assicurarsi che il recupero anticipato non ritardi l'avvio dell'applicazione mentre l'app attende il completamento del recupero anticipato. In termini pratici, ciò potrebbe significare elaborare i dati in modo progressivo o avviare trasferimenti consecutivi con priorità in modo che i dati necessari per l'avvio dell'applicazione vengano scaricati ed elaborati per primi.
L'aggressività con cui vengono precaricati i dati dipende dalle dimensioni dei dati scaricati e dalla probabilità che vengano utilizzati. Come guida approssimativa, in base alla macchina a stati descritta in precedenza, per i dati che hanno il 50% di probabilità di essere utilizzati all'interno della sessione utente corrente, in genere puoi eseguire il prefetch per circa 6 secondi (circa 1-2 megabyte) prima che il potenziale costo del download di dati non utilizzati corrisponda al potenziale risparmio di non scaricare questi dati.
In generale, è buona norma precaricare i dati in modo da dover avviare un altro download solo ogni 2-5 minuti e nell'ordine di 1-5 megabyte.
Seguendo questo principio, i download di grandi dimensioni, come i file video, devono essere scaricati in blocchi a intervalli regolari (ogni 2-5 minuti), precaricando solo i dati video che probabilmente verranno visualizzati nei minuti successivi.
Una soluzione è programmare il download completo in modo che avvenga solo quando il dispositivo è connesso alla rete Wi-Fi e, possibilmente, solo quando è in carica. L'API WorkManager supporta esattamente questo caso d'uso, consentendoti di limitare il lavoro in background finché il dispositivo non soddisfa i criteri specificati dallo sviluppatore, ad esempio la ricarica e la connessione al Wi-Fi.
Verifica la connettività prima di effettuare richieste
La ricerca di un segnale cellulare è una delle operazioni che consumano più energia su un
dispositivo mobile. Una best practice per le richieste avviate dagli utenti è verificare prima
una connessione utilizzando
ConnectivityManager, come mostrato in
Monitorare lo stato della connettività e la misurazione
della connessione.
Se non è presente una rete, l'app può risparmiare batteria non forzando la ricerca della radio mobile. La richiesta può quindi essere pianificata ed eseguita in batch con altre
richieste quando viene stabilita una connessione.
Connessioni del pool
Oltre al batching e al prefetching, un'altra strategia che può essere utile è il raggruppamento delle connessioni di rete della tua app.
In genere è più efficiente riutilizzare le connessioni di rete esistenti che avviare nuove connessioni. Il riutilizzo delle connessioni consente inoltre alla rete di reagire in modo più intelligente alla congestione e ai problemi relativi ai dati di rete.
HttpURLConnection e la maggior parte dei client HTTP, come OkHttp, attivano il pool di connessioni per impostazione predefinita e riutilizzano la stessa connessione per più richieste.
Riepilogo e prospettive future
In questa sezione hai imparato molto sulla radio wireless e su alcune strategie che puoi applicare in generale per offrire un'esperienza utente veloce e reattiva, riducendo al contempo il consumo della batteria.
Nella sezione successiva, esamineremo nel dettaglio tre diversi tipi di interazioni di rete comuni alla maggior parte delle app. Scoprirai i fattori che determinano ciascuno di questi tipi, nonché le tecniche e le API moderne per gestire queste interazioni in modo efficiente.