Effetto delle richieste HTTP sulla durata della batteria

Question

Ho un progetto in cui un'applicazione client, probabilmente su un dispositivo Android, richiederà alcuni file da un server. Un'implementazione consiste nel disporre di trasmissioni burst dal server al dispositivo in cui i file X vengono inviati insieme a un collegamento/puntatore al blocco successivo. L'altra implementazione è inviare un elenco di ID file e quindi effettuare una richiesta http per ciascuno degli ID e ottenere i singoli file. Ho sentito che questo fa davvero male alla durata della batteria. È vero?

Un altro problema è la larghezza di banda, il client potrebbe non volere/ha bisogno di tutti i file inviati in un burst, quindi il server è un po 'costringendo il client ad accettarli tutti insieme. Nella sottomissione individuale, il cliente può ottenere i file quando vuole, se li desidera.

L'effetto sulla durata della batteria è così grande che sarebbe un'opzione valida per oltrepassare la larghezza di banda? O ci sono alternative?

Answer 1

Ho sentito che questo fa davvero male la durata della batteria. È vero?

Non necessariamente. Sulla maggior parte dei dispositivi Android, sia HttpClient e HttpUrlConnection in grado di supportare Keep-Alive, quindi se il server HTTP è impostato correttamente e si effettuano le richieste in rapida successione, non mi aspetto una grande differenza.

Nella richiesta singola, il cliente può ottenere i file quando vuole, se li desidera.

Se vuoi dire che potrebbero essere loro chiedono per un periodo di tempo considerevole, questo non sarà in grado di sfruttare Keep-Alive. Tuttavia, potrebbe essere necessario richiedere un numero inferiore di file e consumare sostanzialmente meno larghezza di banda. È impossibile dirvi, in astratto, quale sarà meglio per il consumo della batteria.

L'effetto sulla durata della batteria è così grande che sarebbe un'opzione valida per oltrepassare la larghezza di banda?

Questo dipenderà da quanto si sta scaricando, la frequenza, ecc

Tuttavia, secondo me, si stanno concentrando sul problema sbagliato.

Se si sta consumando in modo larghezza di banda che si sono preoccupati per la durata della batteria, gli utenti saranno si attacca con forconi e picconi per costano così tanto denaro per il loro piano dati tassametro.

Quindi, vorrei utilizzare TrafficStats e provare vari scenari per vedere quanta larghezza di banda si utilizza realmente, e quindi se è necessario trovare modi per consumare meno larghezza di banda in generale (ad esempio, eseguire il polling meno frequentemente), quindi gli utenti non lo sono in bancarotta dalla tua app. Sospetto che i tuoi problemi di batteria si prenderanno cura di se stessi come un effetto collaterale.

Tuttavia, se nel vostro test, a trovare la vostra applicazione che mostra sul "schermo colpa batteria" in Impostazioni, quindi cominciare a preoccuparsi di consumo della batteria, sia da larghezza di banda o altre fonti (ad esempio, l'uso eccessivo di WakeLocks) .

Answer 2

Avere uno sguardo a queste diapositive da una sessione di Google IO sulla durata della pila:

http://dl.google.com/io/2009/pres/W_0300_CodingforLife-BatteryLifeThatIs.pdf

In particolare, AlarmManager che ha un metodo di setInexactRepeating(...). Il sistema può binare il tuo aggiornamento insieme ad altri che è più efficiente dal punto di vista energetico ed evita di svegliare il dispositivo dal sonno più del necessario.