本节介绍了一些典型的位置信息收集场景，以及有关如何最佳使用地理围栏和融合位置信息提供程序 API 的建议。
对用户可见或在前台进行的更新
示例：某个地图应用需要频繁、准确且延迟非常低的位置信息更新。所有更新都在前台进行：用户开始一项活动，使用位置数据，然后在短时间后停止该活动。
将 setPriority() 方法与 PRIORITY_HIGH_ACCURACY 或 PRIORITY_BALANCED_POWER_ACCURACY 值一起使用。
在 setInterval() 方法中指定的间隔取决于用例：对于实时场景，将值设置为几秒钟；否则，限制为几分钟（建议大约两分钟或更长时间，以最大程度地减少电池使用）。
了解设备的位置信息
示例：某个天气应用想知道设备的当前位置。
使用 getLastLocation() 方法，该方法返回最近可用的位置信息（在极少数情况下可能为 null）。此方法提供了一种直接获取位置信息的方法，并且不会产生与主动请求位置更新相关的开销。结合使用 isLocationAvailable() 方法，当 getLastLocation() 返回的位置信息相对最新时，该方法会返回 true。
当用户位于特定位置时启动更新
示例：当用户距离工作地点、家庭或其他位置在一定距离内时请求更新。
结合融合位置信息提供程序更新使用地理围栏。当应用收到地理围栏进入触发器时请求更新，当应用收到地理围栏退出触发器时移除更新。这可确保应用仅当用户进入已定义区域时才获取更精细的位置更新。
此场景的典型工作流可能包括在地理围栏进入转换时显示通知，并启动一个活动，其中包含在用户点按通知时请求更新的代码。
根据用户的活动状态启动更新
示例：仅当用户正在开车或骑自行车时请求更新。
结合融合位置信息提供程序更新使用活动识别 API。当检测到目标活动时请求更新，当用户停止执行该活动时移除更新。
此用例的典型工作流可能包括为检测到的活动显示通知，并启动一个活动，其中包含在用户点按通知时请求更新的代码。
与地理区域相关的长期后台位置更新
示例：用户希望在设备接近某个零售商时收到通知。
这是一个非常适合使用地理围栏的用例。由于该用例几乎肯定涉及后台位置信息，因此请使用 addGeofences(GeofencingRequest, PendingIntent) 方法。
您应该设置以下配置选项
如果您正在跟踪驻留转换，请使用
setLoiteringDelay()方法，并传入大约五分钟或更小的值。使用
setNotificationResponsiveness()，并传入大约五分钟的值。但是，如果您的应用能够处理额外的响应延迟，可以考虑使用大约十分钟的值。
一个应用一次最多只能注册 100 个地理围栏。在一个应用希望跟踪大量零售商选项的用例中，应用可能希望注册一个大型地理围栏（城市级别），并动态注册较小的地理围栏（城市内的位置），用于大型地理围栏内的商店。当用户进入大型地理围栏时，添加较小的地理围栏；当用户退出大型地理围栏时，移除较小的地理围栏并为新区域重新注册地理围栏。
没有可见应用组件的长期后台位置更新
示例：一个被动跟踪位置信息的应用
如果可能，使用带有 PRIORITY_NO_POWER 选项的 setPriority() 方法，因为它几乎不消耗电池电量。如果无法使用 PRIORITY_NO_POWER，请使用 PRIORITY_BALANCED_POWER_ACCURACY 或 PRIORITY_LOW_POWER，但避免在长时间后台工作中使用 PRIORITY_HIGH_ACCURACY，因为此选项会大幅消耗电池电量。
如果您需要更多位置数据，通过调用 setFastestInterval() 方法并传入小于 setInterval() 的值来使用被动位置。当与 PRIORITY_NO_POWER 选项结合使用时，被动位置可以机会性地提供由其他应用计算的位置信息，而无需额外开销。
通过使用 setMaxWaitTime() 方法增加一些延迟来降低频率。例如，如果您使用值为大约 10 分钟的 setinterval() 方法，则应考虑使用 30 到 60 分钟的值调用 setMaxWaitTime()。使用这些选项，您的应用大约每 10 分钟计算一次位置，但应用只会在每 30 到 60 分钟唤醒一次，并批量提供一些位置数据。这种方法以延迟换取更多可用数据和更好的电池性能。
用户与其他应用交互时进行频繁的高精度更新
示例：导航或健身应用在用户关闭屏幕或打开其他应用时仍继续工作。
使用前台服务。如果您的应用可能代表用户执行耗时的工作，建议的最佳实践是让用户感知到该工作。前台服务需要一个持久通知。有关更多信息，请参阅通知概览。