L'utilizzo della radio wireless per trasferire i dati è potenzialmente una delle fonti più significative di consumo della batteria dell'app. Per ridurre al minimo il consumo della batteria associato all'attività di rete, è fondamentale capire in che modo il modello di connettività influisce sull'hardware radio di base.
Questa sezione presenta la macchina a stati radio wireless e spiega in che modo interagisce il modello di connettività dell'app. Offre quindi diverse tecniche che, se seguite, ti aiuteranno a ridurre al minimo l'effetto del consumo di dati dell'app sulla batteria.
La macchina a stati della radio
La radio wireless sul dispositivo dell'utente ha funzionalità di risparmio energetico integrate che contribuiscono a ridurre al minimo il consumo di batteria. Quando è completamente attiva, la radio wireless consuma molta energia, ma quando è inattiva o in standby consuma pochissima energia.
Un fattore importante da ricordare è che la radio non può passare dallo stato di standby a quello di piena attività istantaneamente. Esiste un periodo di latenza associato all'"accensione" della radio. Pertanto, la batteria passa lentamente da stati energetici più elevati a stati energetici più bassi per risparmiare energia quando non è in uso, tentando al contempo di ridurre al minimo la latenza associata all'accensione della radio.
La macchina a stati di una radio di rete 3G tipica è composta da tre stati di energia:
- Massima potenza: viene utilizzata quando è attiva una connessione, che consente al dispositivo di trasferire i dati alla massima velocità possibile.
- Consumo ridotto: uno stato intermedio che riduce il consumo di energia della batteria di circa il 50%.
- Standby: lo stato di consumo minimo durante il quale non è attiva alcuna connessione di rete.
Sebbene gli stati basso e di attesa consumino molto meno batteria, introducono anche una latenza significativa nelle richieste di rete. Il ritorno alla potenza massima dallo stato basso richiede circa 1,5 secondi, mentre il passaggio dalla modalità standby alla potenza massima può richiedere più di 2 secondi.
Per ridurre al minimo la latenza, la macchina a stati utilizza un ritardo per posticipare la transizione a stati a energia inferiore. La Figura 1 utilizza i tempi di AT&T per una radio 3G standard.
Figura 1. Macchina a stati radio wireless 3G tipica.
La macchina a stati radio su ogni dispositivo, in particolare il ritardo di transizione associato ("tempo di coda") e la latenza di avvio, variano in base alla tecnologia radio wireless impiegata (3G, LTE, 5G e così via) e sono definiti e configurati dalla rete dell'operatore su cui opera il dispositivo.
In questa pagina viene descritta una macchina a stato rappresentativa per una tipica radio wireless 3G, in base ai 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 sul web mobile, in quanto previene la latenza sgradevole durante la navigazione sul web da parte degli utenti. Il tempo di coda relativamente basso fa sì che, al termine di una sessione di navigazione, la radio possa passare a uno stato di energia inferiore.
Purtroppo, questo approccio può portare ad app inefficienti sui sistemi operativi degli smartphone moderni come Android, in cui le app vengono eseguite sia in primo piano (dove la latenza è importante) sia in background (dove la priorità deve essere data alla durata della batteria).
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 potenza massima. Nel caso della tipica macchina a stati radio 3G descritta in precedenza, rimarrà a piena potenza per la durata del trasferimento, più altri 5 secondi di tempo di coda, seguiti da 12 secondi in stato di basso consumo. Pertanto, per un tipico dispositivo 3G, ogni sessione di trasferimento dati fa 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 costantemente attiva, riportandola di nuovo alla potenza elevata proprio quando entra in modalità standby.
Figura 2. Utilizzo relativo della potenza radio wireless per un trasferimento di un secondo eseguito
tre volte ogni minuto. La figura esclude la latenza di "accensione" tra le esecuzioni.
In confronto, se la stessa app raggruppa i trasferimenti di dati, eseguendo un singolo trasferimento di tre secondi ogni minuto, la radio rimarrà in stato di alta potenza per un totale di soli 20 secondi ogni minuto. In questo modo, la radio può essere in modalità standby per 40 secondi ogni minuto, con una significativa riduzione del consumo della batteria.
Figura 3. Utilizzo relativo della potenza radio wireless per trasferimenti di tre secondi eseguiti una volta ogni minuto.
Tecniche di ottimizzazione
Ora che sai in che modo l'accesso alla rete influisce sulla durata della batteria, vediamo alcune cose che puoi fare per contribuire a ridurre il consumo della batteria, offrendo al contempo un'esperienza utente rapida e fluida.
Trasferimenti di dati 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.
Ovviamente, non è sempre possibile farlo se la tua app deve ricevere o inviare immediatamente dati in risposta a un'azione dell'utente. Puoi mitigare questo problema anticipando e precaricando i dati. Altri scenari, come l'invio di log o dati di analisi a un server e altri trasferimenti di dati non urgenti avviati dall'app, si prestano molto bene al raggruppamento e al raggruppamento. Consulta Ottimizzare le attività avviate dall'app per suggerimenti su come pianificare i trasferimenti di rete in background.
Precaricare i dati
Il pre-caricamento dei dati è un altro modo efficace per ridurre il numero di sessioni di trasferimento di dati indipendenti eseguite dalla tua app. Con il pre-caricamento, quando l'utente esegue un'azione nella tua app, l'app anticipa quali dati molto probabilmente serviranno per la serie successiva di azioni utente e li recupera in un singolo incremento, su una singola connessione, a piena capacità.
Se esegui il front-loading dei trasferimenti, riduci il numero di attivazioni radio necessarie per scaricare i dati. Di conseguenza, non solo risparmi la batteria, ma migliori anche la latenza, riduci la larghezza di banda richiesta e i tempi di download.
Il pre-caricamento 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 proprio mentre scorrono per visualizzarle.
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. Non solo, il passaggio costante tra stati di energia genera una latenza significativa quando si cambiano categorie o si leggono articoli.
Un approccio migliore è prelevare una quantità ragionevole di dati all'avvio, iniziando con il primo insieme di titoli e miniature delle notizie, per garantire un tempo di avvio a bassa latenza, e continuando con i titoli e le miniature rimanenti, nonché con il testo di ogni articolo disponibile almeno nell'elenco dei titoli principali.
Un'altra alternativa è prelevare ogni titolo, miniatura, testo dell'articolo e persino le immagini complete dell'articolo, in genere in background secondo una programmazione predeterminata. Questo approccio rischia di consumare una notevole larghezza di banda e la batteria per scaricare contenuti che non vengono mai utilizzati, pertanto deve essere implementato con cautela.
Considerazioni aggiuntive
Sebbene il pre-caricamento dei dati offra molti vantaggi, se utilizzato in modo troppo aggressivo, il pre-caricamento introduce anche il rischio di aumentare il consumo della batteria e l'utilizzo della larghezza di banda, nonché la quota di download, scaricando dati che non vengono utilizzati. È inoltre importante assicurarsi che il precaricamento non ritarda l'avvio dell'applicazione mentre quest'ultima attende il completamento del precaricamento. In termini pratici, ciò potrebbe significare elaborare i dati progressivamente o avviare trasferimenti consecutivi con priorità in modo che i dati necessari per l'avvio dell'applicazione vengano scaricati ed elaborati per primi.
L'entità del pre-caricamento dei 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 una probabilità del 50% di essere utilizzati all'interno della sessione utente corrente, in genere puoi eseguire il pre-caricamento per circa 6 secondi (circa 1-2 megabyte) prima che il potenziale costo del download dei dati inutilizzati corrisponda al potenziale risparmio del mancato download di questi dati.
In generale, è buona norma eseguire il pre-caricamento dei dati in modo da dover avviare un altro download ogni 2-5 minuti e nell'ordine di 1-5 megabyte.
In base a questo principio, i download di grandi dimensioni, ad esempio i file video, dovrebbero essere scaricati in blocchi a intervalli regolari (ogni 2-5 minuti), precaricando in modo efficace solo i dati video che potrebbero essere visualizzati nei prossimi minuti.
Una soluzione è programmare il download completo solo quando il dispositivo è connesso al Wi-Fi e, eventualmente, solo quando è in carica. L'API WorkManager supporta esattamente questo caso d'uso, consentendoti di limitare il lavoro in background fino a quando il dispositivo non soddisfa i criteri specificati dallo sviluppatore, ad esempio la ricarica e la connessione alla rete 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 dall'utente è controllare prima la presenza di una connessione utilizzando ConnectivityManager, come mostrato in Monitorare lo stato della connettività e la misurazione della connessione.
Se non c'è rete, l'app può risparmiare batteria non forzando la ricerca sulla 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 raggruppamento e al pre-caricamento, un'altra strategia che può essere utile è riunire le connessioni di rete dell'app.
In genere è più efficiente riutilizzare le connessioni di rete esistenti piuttosto che avviarne di nuove. Inoltre, il riutilizzo delle connessioni consente alla rete di reagire in modo più intelligente alla congestione e ai relativi problemi di dati di rete.
HttpURLConnection e la maggior parte dei client HTTP, come OkHttp, attivano per impostazione predefinita il pooling delle connessioni e il riutilizzo della stessa connessione per più richieste.
Riepilogo e prospettive future
In questa sezione hai appreso molto sulla radio wireless e su alcune strategie che puoi applicare in modo ampio per offrire un'esperienza utente rapida e reattiva, riducendo al contempo il consumo della batteria.
Nella sezione successiva, esamineremo in dettaglio tre tipi distinti di interazioni con la rete comuni alla maggior parte delle app. Scoprirai i fattori che influenzano ciascuno di questi tipi, nonché tecniche e API moderne per gestire queste interazioni in modo efficiente.