Otimizar o uso da localização para prolongar a duração da bateria

Siga estas etapas para melhorar o impacto do seu app na duração da bateria de um dispositivo ao usar os serviços de localização.

Remover atualizações de localização

Uma fonte comum de consumo desnecessário de bateria é a não remoção das atualizações de localização quando você não precisa mais delas.

Isso pode acontecer quando os métodos do ciclo de vida onStart() ou onResume() de uma atividade contêm uma chamada para requestlocationUpdates() sem uma chamada correspondente para removeLocationUpdates() nos métodos do ciclo de vida onPause() ou onStop().

Você pode usar componentes com reconhecimento de ciclo de vida para gerenciar melhor o ciclo de vida das atividades no seu app. Para mais informações, consulte Como gerenciar ciclos de vida com componentes que os reconhecem.

Definir limites de tempo

Para evitar consumo de bateria, defina um tempo limite razoável para a interrupção das atualizações de local. Esse tempo limite garante que as atualizações não continuem de forma indefinida, além de proteger o app em cenários onde as atualizações são solicitadas, mas não removidas (por exemplo, devido a um bug no código).

Para uma solicitação do provedor de localização combinada, adicione um tempo limite chamando setDurationMillis(), que recebe um parâmetro responsável por apresentar o tempo em milissegundos desde a última vez em que o método foi chamado. Também é possível usar o método para expressar o tempo de expiração em termos de duração.

Para adicionar um tempo limite a uma solicitação de localização da fronteira geográfica virtual, chame o método setExpirationDuration().

Solicitações em lote

Para todos os casos de uso que não sejam em primeiro plano, agrupe várias solicitações em lotes. Use o método setIntervalMillis() para especificar o intervalo em que você quer que a localização seja calculada. Em seguida, use o método setMaxUpdateDelayMillis() para definir o intervalo em que a localização será entregue ao app. Transmita um valor ao método setMaxUpdateDelayMillis() que seja um múltiplo do valor transmitido ao método setIntervalMillis(). Por exemplo, considere a solicitação de local a seguir:

Kotlin

val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)
.setMaxUpdateDelayMillis(60 * 60 * 1000)
.build()

Java

LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)
    .setMaxUpdateDelayMillis(60 * 60 * 1000)
    .build();

Nesse caso, o sistema calcula a localização aproximadamente a cada 10 minutos e entrega cerca de seis pontos de dados de localização em um lote a cada hora. Embora ainda receba atualizações de localização a cada 10 minutos, você economizará bateria porque seu dispositivo será ativado apenas a cada hora.

Usar atualizações de localização passivas

Nos casos de uso em segundo plano, é recomendável limitar as atualizações de localização. Os limites do Android 8.0 (nível 26 da API) impõem essa prática, mas os apps que são executados em dispositivos mais antigos precisam se esforçar para limitar ao máximo possível a localização em segundo plano.

É provável que, enquanto seu app esteja em segundo plano, outro app possa solicitar frequentemente atualizações de localização em primeiro plano. Os serviços de localização disponibilizam essas atualizações para seu app. Considere a seguinte solicitação de localização, que consome dados de localização de maneira oportuna:

Kotlin

val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)
.setMinUpdateIntervalMillis(2 * 60 * 1000)
.build()

Java

LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)
    .setMinUpdateIntervalMillis(2 * 60 * 1000)
    .build();

No exemplo anterior, a localização do app é calculada aproximadamente a cada 15 minutos. Se outros apps solicitarem a localização, o app vai receber os dados em um intervalo máximo de dois minutos.

Embora o consumo de localização de forma passiva não incorra em gasto de bateria, tome muito cuidado nos casos em que o recebimento de dados de local acione operações pesadas de CPU ou E/S. Para minimizar os custos de bateria, o intervalo especificado em setMinUpdateIntervalMillis() não pode ser muito pequeno.