L'utilizzo della radio wireless per trasferire dati è potenzialmente una delle fonti di maggiore consumo della batteria della tua app. Per ridurre al minimo il consumo eccessivo della batteria con l'attività di rete, è fondamentale comprendere il modo in cui influirà sull'hardware radio sottostante.
Questa sezione presenta la macchina a stato radio wireless e spiega come le il modello di connettività dell'app vi interagisce. Offre quindi diverse tecniche che, se seguiti, ti aiuteranno a ridurre al minimo l'effetto dei dati dell'app. il consumo eccessivo della batteria.
La macchina a stati della radio
La radio wireless sul dispositivo dell'utente ha funzionalità di risparmio energetico integrate che per ridurre al minimo il consumo di batteria. Quando la funzionalità è completamente attiva, la radio wireless consuma molta energia, ma quando non è attiva o in standby, consuma pochissimo.
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 per una tipica rete radio 3G è composta da tre stati di energia:
- Potenza massima: viene utilizzata quando è attiva una connessione, consentendo al dispositivo di trasferire i dati alla massima velocità possibile.
- Basso consumo: uno stato intermedio che riduce il consumo della batteria del circa il 50%.
- Standby: lo stato di consumo minimo dell'alimentazione durante il quale non è attiva alcuna connessione di rete.
Sebbene lo stato basso e in standby consumino molto meno batteria, introducono una latenza significativa per le 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 stato utilizza un ritardo per posticipare la transizione a stati di energia più bassi. 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 dello stato radio su ciascun dispositivo, in particolare la transizione associata il ritardo ("tail time") e la latenza di avvio variano in base alla radio wireless la tecnologia utilizzata (3G, LTE, 5G e così via) ed è definita e configurata La rete dell'operatore su cui è operativo il dispositivo.
Questa pagina descrive una macchina a stati rappresentativa per una radio wireless 3G tipica, 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, previene latenze indesiderate mentre gli utenti navigano sul web. Il tempo di coda relativamente basso garantisce inoltre che, al termine di una sessione di navigazione, la radio possa passare a uno stato di energia inferiore.
Purtroppo, questo approccio può portare alla creazione di app inefficienti sugli smartphone moderni sistemi operativi come Android, dove le app vengono eseguite sia in primo piano (dove latenza è importante) e in background (dove la durata della batteria dovrebbe essere prioritarie).
In che modo le app influiscono sulla macchina a stati della radio
Ogni volta che crei una nuova connessione di rete, la radio passa a a piena potenza. 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 bassa energia. Di conseguenza, per un tipico dispositivo 3G, ogni sessione di trasferimento di dati comporterà per assorbire energia per almeno 18 secondi.
In pratica, questo significa che un'app che effettua un trasferimento di dati di un secondo tre volte al minuto, la radio wireless rimarrà attiva per sempre, spostandola alla potenza elevata proprio quando si entra in modalità standby.
Figura 2. Consumo relativo di potenza radio wireless per un trasferimento di 1 secondo in esecuzione
tre volte al minuto. Il dato esclude la latenza di "accensione" tra le esecuzioni.
In confronto, se la stessa app raggruppava i propri trasferimenti di dati, eseguendo di tre secondi al minuto, in questo modo la radio manterrebbe per un totale di soli 20 secondi al minuto. In questo modo la radio rimanere in standby per 40 secondi al minuto, comportando di riduzione del consumo della batteria.
e
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.
Trasferimento dei dati di gruppo
Come indicato nella sezione precedente, raggruppando i trasferimenti di dati in modo da trasferire più dati con minore frequenza è uno dei modi migliori per migliorare la durata della batteria efficienza operativa.
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 anticipare e precaricare i dati. Altri scenari, ad esempio invio di log o analisi a un server e altri dati non urgenti avviati dall'app i trasferimenti di dati, si prestano molto bene al raggruppamento e al raggruppamento. Consulta la sezione Ottimizzazione avviato dall'app Google Cloud 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 e le sessioni di Data Transfer 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 recupera questi dati in un singolo incremento, su una singola connessione, a piena capacità.
Caricando in anticipo i tuoi trasferimenti, riduci il numero di attivazioni radio necessari per scaricare i dati. Di conseguenza, non solo si preserva la durata della batteria, ma migliorano anche la latenza, riducono la larghezza di banda necessaria e riducono i download volte.
Il precaricamento fornisce inoltre una migliore esperienza utente, riducendo al minimo le visualizzazioni in-app latenza causata dall'attesa del completamento dei download prima di eseguire un'azione o la visualizzazione di 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 aver selezionato una categoria, gli articoli completi solo quando l'utente vuole leggerli e le miniature non appena 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. E non solo: il costante passaggio da uno stato di energia all'altro si traduce in una latenza significativa quando si cambia categoria o si legge 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 in base a 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 precaricamento dei dati offra molti vantaggi, viene utilizzato in modo troppo aggressivo il precaricamento introduce anche il rischio di un aumento del consumo eccessivo della batteria e della larghezza di banda oltre alla quota di download, scaricando i dati non utilizzati. È inoltre possibile è importante assicurarsi che il precaricamento non ritarda l'avvio dell'applicazione mentre l'app 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. A titolo indicativo, in base ai macchina a stato descritta in precedenza, per i dati che hanno una probabilità del 50% di essere nella sessione utente corrente, in genere puoi eseguire il precaricamento per circa 6 secondi (circa 1-2 MB) prima del potenziale costo del download il potenziale risparmio se non scarichi quei dati, tanto per cominciare.
In generale, è buona norma precaricare i dati in modo da avviare un altro download ogni 2-5 minuti e nell'ordine 5 MB.
Secondo questo principio, i download di grandi dimensioni, ad esempio i file video, devono scaricati in blocchi a intervalli regolari (ogni 2-5 minuti), eseguendo il precaricamento solo dei dati video che potrebbero essere visualizzati nei prossimi minuti.
Una soluzione è pianificare il download completo in modo che venga eseguito solo quando è connesso Wi-Fi ed eventualmente solo quando il dispositivo è in carica. La 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, come la ricarica e 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 è verificare innanzitutto la presenza di
una connessione tramite
ConnectivityManager, come mostrato in
Monitorare lo stato della connettività e la connessione
misurazione.
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 rispetto a 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 correlati.
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 prospettiva
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.