Qual è l'approccio più efficiente della batteria dell'utilizzo di LocationClient per ottenere periodicamente aggiornamenti?

Question

Sto pensando di avere due allarmi separati per raccogliere i dati di posizione di un utente ogni ora, uno che si spegne ogni 59 minuti per "connettere" il client e un secondo per ottenere effettivamente la posizione e successivamente disconnettere il client.

In termini di durata della batteria, c'è qualcos'altro che dovrei prendere in considerazione se ottenere la posizione dell'utente sarà il principale svuotamento dell'app? Oppure esiste un approccio diverso all'utilizzo di due allarmi? Inizialmente avevo solo un singolo allarme, ma l'esecuzione di un controllo (! MLocationClient.isConnected) e la connessione non danno al client abbastanza tempo per connettersi.

Grazie per la vostra comprensione.

I due allarmi sarebbe andato fuori qualcosa di simile a questo:

private int PERIODIC_UPDATE = 60000*60; //gets location and disconnects every hour 
private int PERIODIC_RECONNECTION_UPDATE = 60000*59; //connects 1 minute before getLocation call 

    Timer toReconnect = new Timer(); 
    toReconnect.schedule(new TimerTask() { 

     @Override 
     public void run() { 
      mLocationClient.connect(); 
     } 
    }, 5000, PERIODIC_RECONNECTION_UPDATE); 

    Timer theTimer = new Timer(); 
    theTimer.schedule(new TimerTask(){ 
     @Override 
     public void run() { 
      try { 
       if(!mLocationClient.isConnected()) { 
        mLocationClient.connect(); 
        //This will not have much affect because cannot so quickly, will remove. 
       } 

       Location theLocation = mLocationClient.getLastLocation(); 
       if(theLocation!=null) { 
        checkPostLocation(theLocation); 

        mLocationClient.disconnect(); 
       } 
      } catch (Exception e) { 
       e.printStackTrace(); 
      } 
     }}, 5000, PERIODIC_UPDATE); 

Answer 1

Avete veramente bisogno di tracciare l'utente?

Se si tratta solo dell'interfaccia utente, utilizzare getLastKnownLocation (PASSIVE_PROVIDER) e si dovrebbe ottenere qualcosa di semi-accurato assumendo che abbiano utilizzato i servizi di localizzazione sul proprio telefono da qualche altra parte.

Se è necessario triangolare effettivamente l'utente, rendersi conto che i diversi provider utilizzano batterie diverse. Passivo < Rete < GPS.

Più localizzi l'utente, più batteria con GPS consuma più batteria e più tempo.

Avviare il servizio in base a un programma, 1 ora o qualsiasi altra cosa, solo un servizio necessario. Vivi solo per un massimo di 1 minuto (o meno), ascolta su tutti i provider di posizione. Dopo che il minuto o la precisione sono sufficienti, si salva il risultato e si arresta il servizio.

Answer 2

Vedere la sezione "Ricezione di localizzazione degli aggiornamenti" alla documentazione per gli sviluppatori Android per una discussione dettagliata di questo argomento con il nuovo Fused LocationProvider:

http://developer.android.com/training/location/receive-location-updates.html

Questo vi dà la possibilità di registrare un Intent con un LocationListener al LocationProvider fuso che viene attivato automaticamente dal framework dei servizi di Google interni quando viene considerato "efficiente". Confido che questo framework abbia un potenziale molto più grande per ottimizzare l'utilizzo di energia, dal momento che ha una maggiore conoscenza di cos'altro sta succedendo nel sistema rispetto a un timer registrato nell'app.

Qui ci sono le opzioni per la registrazione di un ascoltatore con diversi livelli di priorità di potenza, che si tradurrà in diversi livelli di consumo della batteria, come indicato nella documentazione di cui sopra:

• PRIORITY_BALANCED_POWER_ACCURACY - Utilizzato con setPriority (int) per richiedere la precisione del livello "blocco". La precisione a livello di blocco è considerata di circa 100 metri di precisione. L'utilizzo di una precisione grossolana come questa spesso consuma meno energia.
• PRIORITY_HIGH_ACCURACY - Utilizzato con setPriority (int) per richiedere le posizioni più precise disponibili. Ciò restituirà la migliore posizione disponibile (e il massimo potenziale per il drenaggio di energia).
• PRIORITY_NO_POWER - Utilizzato con setPriority (int) per richiedere la migliore precisione possibile con zero consumo di energia aggiuntivo. Nessuna posizione verrà restituita a meno che un diverso client abbia richiesto aggiornamenti di posizione, nel qual caso questa richiesta fungerà da listener passivo per tali posizioni.