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à influirà sull'hardware radio sottostante.
Questa sezione presenta la macchina a stati della radio wireless e spiega come interagisce con il modello di connettività della tua app. Quindi, offre diverse tecniche che, se seguite, aiuteranno 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 batteria consumata. Quando è completamente attiva, la radio wireless consuma molta energia, ma quando è inattiva o in standby, il consumo è minimo.
Un fattore importante da ricordare è che la radio non può passare istantaneamente dalla modalità standby a quella completamente attiva. 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 al contempo di ridurre al minimo la latenza associata all'accensione della radio.
La macchina a stati per una tipica radio di rete 3G è composta da tre stati energetici:
- Potenza massima: utilizzata quando una connessione è attiva, consente al dispositivo di trasferire i dati alla massima velocità possibile.
- Basso consumo: uno stato intermedio che riduce il consumo della 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 di standby consumino molta meno batteria, introducono anche una latenza significativa alle richieste di rete. Il ritorno alla piena potenza dallo stato basso richiede circa 1,5 secondi, mentre il passaggio dallo 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 a stati energetici inferiori. La Figura 1 utilizza le tempistiche di AT&T per una tipica radio 3G.
Figura 1. Tipica macchina a stati 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 radio wireless.
Questo approccio è particolarmente efficace per la tipica navigazione web mobile, in quanto impedisce una latenza indesiderata durante la navigazione web degli utenti. Il tempo di coda relativamente basso garantisce inoltre che, al termine di una sessione di navigazione, la radio possa passare a uno stato di consumo energetico inferiore.
Purtroppo, questo approccio può portare ad app inefficienti 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 avere la 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 tipica macchina a stati della radio 3G descritta in precedenza, rimarrà alla massima potenza per la durata del trasferimento, più altri 5 secondi di tempo di coda, seguiti da 12 secondi nello stato a basso consumo energetico. Quindi, per un tipico dispositivo 3G, ogni sessione di trasferimento di dati farà sì che la radio consumi energia per almeno 18 secondi.
In pratica, ciò significa che un'app che effettua un trasferimento di dati di un secondo, tre volte al minuto, manterrà la radio wireless costantemente attiva, riportandola alla modalità ad alta potenza proprio mentre sta entrando in modalità standby.
Figura 2. Consumo di energia della radio wireless relativo per un trasferimento di un secondo eseguito tre volte al minuto. La cifra esclude la latenza di "accensione" tra le esecuzioni.
In confronto, se la stessa app raggruppasse i trasferimenti di dati, eseguendo un singolo trasferimento di tre secondi ogni minuto, la radio rimarrebbe nello stato ad alta potenza per un totale di soli 20 secondi al minuto. In questo modo, la radio potrebbe rimanere in standby per 40 secondi ogni minuto, con una significativa riduzione 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 in che modo l'accesso alla rete influisce sulla durata della batteria, parliamo un po' di alcune cose che puoi fare per ridurre il consumo eccessivo della batteria, offrendo 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, questo non è sempre possibile se l'app deve ricevere o inviare dati immediatamente in risposta a un'azione dell'utente. Puoi mitigare questo problema anticipando e eseguendo il precaricamento dei dati. Altri scenari, come l'invio di log o analisi a un server e altri trasferimenti di dati non urgenti avviati dall'app, si prestano molto bene al raggruppamento e al raggruppamento. Consulta Ottimizza le attività avviate dall'app per suggerimenti sulla pianificazione dei trasferimenti di rete in background.
Precarica i dati
Il precaricamento dei dati è un altro modo efficace per ridurre il numero di sessioni di trasferimento di dati indipendenti eseguite dalla tua app. Con il precaricamento, quando l'utente esegue un'azione nella tua app, quest'ultima anticipa quali dati saranno probabilmente necessari per la serie successiva di azioni dell'utente e li recupera in un'unica operazione, su una singola connessione, a piena capacità.
Se esegui i trasferimenti in anticipo, riduci il numero di attivazioni della radio necessarie per scaricare i dati. In questo modo, non solo risparmi la batteria, ma migliori anche la latenza, riduci la larghezza di banda richiesta e i tempi di download.
Il precaricamento offre anche un'esperienza utente migliore 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 vengono visualizzate.
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 tra gli stati energetici comporta una latenza significativa quando si cambia categoria o si leggono articoli.
Un approccio migliore consiste nel precaricare una quantità ragionevole di dati all'avvio, iniziando con il primo insieme di titoli e miniature delle notizie, garantendo un tempo di avvio a bassa latenza, e continuando con i titoli e le miniature rimanenti, nonché il testo di ogni articolo disponibile almeno nell'elenco dei titoli principali.
Un'altra alternativa è eseguire il precaricamento di ogni titolo, miniatura, testo dell'articolo e possibilmente anche delle immagini dell'articolo completo, in genere in background in base a una pianificazione predeterminata. Questo approccio rischia di consumare una quantità significativa di larghezza di banda e di batteria per scaricare 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 comporta 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. È anche importante assicurarsi che il precaricamento non ritardi l'avvio dell'applicazione mentre l'app attende il completamento del precaricamento. In termini pratici, ciò potrebbe significare l'elaborazione progressiva dei dati o l'avvio di trasferimenti consecutivi con priorità in modo che i dati richiesti per l'avvio dell'applicazione vengano scaricati ed elaborati per primi.
L'aggressività con cui esegui il precaricamento 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 il 50% di probabilità di essere utilizzati nella sessione utente corrente, in genere puoi eseguire il precaricamento per circa 6 secondi (circa 1-2 megabyte) prima che il costo potenziale del download dei dati inutilizzati corrisponda al risparmio potenziale di non scaricare questi dati, per cominciare.
In generale, è buona norma eseguire il precaricamento dei 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 in modo efficace solo i dati video che probabilmente verranno visualizzati nei minuti successivi.
Una soluzione è pianificare il download completo solo quando il dispositivo è connesso alla rete Wi-Fi ed eventualmente 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 di rete mobile è una delle operazioni che consumano più energia su un dispositivo mobile. Una best practice per le richieste avviate dall'utente è verificare prima la presenza di una connessione utilizzando ConnectivityManager, come mostrato in Monitora 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
Un'altra strategia che può essere utile oltre al raggruppamento in batch e al precaricamento è il raggruppamento delle connessioni di rete dell'app.
In genere, è più efficiente riutilizzare le connessioni di rete esistenti piuttosto che avviarne di nuove. 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, abilitano il pooling delle 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 rapida e reattiva, riducendo al contempo il consumo della batteria.
Nella prossima sezione, esamineremo in dettaglio tre tipi distinti di interazioni di rete comuni alla maggior parte delle app. Scoprirai i fattori trainanti di ciascuno di questi tipi, nonché le tecniche e le API moderne per gestire queste interazioni in modo efficiente.