优化位置信息使用情况以延长电池续航时间
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
请采取以下措施,以减少应用对设备电池续航时间的影响,在使用位置信息服务时。
移除位置信息更新
造成不必要的电池电量消耗的一个常见原因是,当不再需要位置信息更新时,没有移除它们。
例如,当某个 activity 的 onStart()
或 onResume()
生命周期方法中包含 requestlocationUpdates()
调用,但在 onPause()
或 onStop()
生命周期方法中却没有相应的 removeLocationUpdates()
调用时,就会发生这种情况。
您可使用生命周期感知型组件更好地管理应用中的 Activity 的生命周期。如需了解详情,请参阅使用生命周期感知型组件处理生命周期。
设置超时
为了防止电池电量消耗,应设置一个停止位置信息更新的合理超时。通过设置超时,可确保更新不会无限期地继续,并在请求更新后未移除更新的情况下(例如由于代码错误),对应用起到保护作用。
对于一体化位置信息提供程序请求,可通过调用 setDurationMillis()
(将接收一个表示自该方法上一次被调用后的时长 [以毫秒计] 的参数)添加超时。您还可以使用此方法以时长来表示到期时间。
如需为地理围栏位置信息请求添加超时,请调用 setExpirationDuration()
方法。
批处理请求
对于所有非前台用例,将多个请求一起进行批处理。使用 setIntervalMillis()
方法指定计算位置的时间间隔。然后,使用 setMaxUpdateDelayMillis()
方法设置将位置信息传递给应用的时间间隔。向 setMaxUpdateDelayMillis()
方法传递的值应是传递给 setIntervalMillis()
方法的值的倍数。例如,请考虑以下位置请求:
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();
在这种情况下,系统大约每 10 分钟计算一次位置,并且大约每小时批量传递六个左右位置数据点。虽然您仍然每十分钟左右就会获得位置信息更新,但您节省了电池用量,因为您的设备大约每小时才会被唤醒一次。
使用被动位置信息更新
在后台用例中,限制位置信息更新是一个好方法。Android 8.0(API 级别 26)中的后台位置信息限制将强制执行此做法,但在较低版本设备上运行的应用也应尽量限制后台位置信息更新。
可能当您的应用在后台运行时,另一个应用会频繁地在前台请求位置信息更新。位置信息服务会向您的应用提供这些更新。请考虑以下位置信息请求,它会适时地使用位置数据:
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();
在上一个例子中,应用的位置大约每 15 分钟计算一次。如果其他应用请求位置信息,该应用可在最多两分钟后获得这些信息。
虽然被动地使用位置信息不会导致电池电量消耗,但当接收位置数据会触发昂贵的 CPU 或 I/O 操作时,应格外小心。为了最大限度地降低电池电量消耗,setMinUpdateIntervalMillis()
中指定的时间间隔不应过小。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[null,null,["最后更新时间 (UTC):2025-07-27。"],[],[],null,["# Optimize location use for battery life\n\nTake the following actions to [improve your app's\nimpact on a device's battery life](/develop/sensors-and-location/location/battery) when using location services.\n\nRemove location updates\n-----------------------\n\nA common source of unnecessary battery drain is the failure to remove location\nupdates when they are no longer needed.\n\nThis can happen when an activity's [`onStart()`](/reference/android/app/Activity#onStart()) or [`onResume()`](/reference/android/app/Activity#onResume())\nlifecycle methods contain a call to [`requestlocationUpdates()`](https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderClient#requestLocationUpdates(com.google.android.gms.location.LocationRequest,%20android.app.PendingIntent)) without a\ncorresponding call to [`removeLocationUpdates()`](https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderClient.html#removeLocationUpdates(com.google.android.gms.location.LocationCallback)) in the [`onPause()`](/reference/android/app/Activity#onPause()) or\n[`onStop()`](/reference/android/app/Activity#onStop()) lifecycle methods.\n\nYou can use lifecycle-aware components to better manage the lifecycle of the\nactivities in your app. For more information, see [Handling Lifecycles with\nLifecycle-Aware Components](/topic/libraries/architecture/lifecycle).\n\nSet timeouts\n------------\n\nTo guard against battery drain, set a reasonable timeout when location updates\nshould stop. The timeout ensures that updates don't continue indefinitely, and\nit protects the app in scenarios where updates are requested but not removed\n(for example, because of a bug in the code).\n\nFor a fused location provider request, add a timeout by calling\n[`setDurationMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#setDurationMillis(long)), which receives a parameter that represents the\ntime in milliseconds since the method was last called. You can also use the\nmethod to express the expiration time in terms of duration.\n\nTo add a timeout to a geofence location request, call the\n[`setExpirationDuration()`](https://developers.google.com/android/reference/com/google/android/gms/location/Geofence.Builder.html#setExpirationDuration(long)) method.\n\nBatch requests\n--------------\n\nFor all non-foreground use cases, batch multiple requests together. Use the\n[`setIntervalMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#setIntervalMillis(long)) method to specify the interval at which you would like\nlocation to be computed. Then, use the [`setMaxUpdateDelayMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#setMaxUpdateDelayMillis(long)) method to set\nthe interval at which location is *delivered* to your app. Pass a value to the\n`setMaxUpdateDelayMillis()` method that is a multiple of the value passed to the\n`setIntervalMillis()` method. For example, consider the following location request: \n\n### Kotlin\n\n val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)\n .setMaxUpdateDelayMillis(60 * 60 * 1000)\n .build()\n\n### Java\n\n LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)\n .setMaxUpdateDelayMillis(60 * 60 * 1000)\n .build();\n\nIn this case, the system computes location roughly every ten minutes and\ndelivers approximately six location data points in a batch approximately every\nhour. While you still get location updates every ten minutes or so, you conserve\nbattery because your device wakes up only every hour or so.\n\nUse passive location updates\n----------------------------\n\nIn background use cases, it is a good idea to throttle location updates. Android\n8.0 (API level 26) limits enforce this practice, but apps running on lower\ndevices should strive to limit background location as much as possible.\n\nIt is likely that while your app is in the background, another app may be\nfrequently requesting location updates in the foreground. Location services\nmakes these updates available to your app. Consider the following location\nrequest, which opportunistically consumes location data: \n\n### Kotlin\n\n val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)\n .setMinUpdateIntervalMillis(2 * 60 * 1000)\n .build()\n\n### Java\n\n LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)\n .setMinUpdateIntervalMillis(2 * 60 * 1000)\n .build();\n\nIn the previous example, the app's location computes roughly every 15 minutes.\nIf other apps request location, the app receives the data at a maximum interval\nof two minutes.\n\nWhile consuming location passively incurs no battery drain, take extra care in\ncases where the receipt of location data triggers expensive CPU or I/O\noperations. To minimize battery costs, the interval specified in\n[`setMinUpdateIntervalMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#public-locationrequest.builder-setmaxupdateagemillis-long-maxupdateagemillis(long)) shouldn't be too small."]]