以下是LocationRequest API
的官方指南site的当前引用在这两个极端之间是一个非常常见的用例，其中 应用程序肯定希望在指定的接收更新 间隔，并且可以在可用时更快地接收它们，但仍然需要 低功率影响。这些应用应该考虑 PRIORITY_BALANCED_POWER_ACCURACY结合更快 setFastestInterval（long）（例如1分钟）和一个较慢的 setInterval（long）（例如60分钟）。他们只会被分配 由setInterval（long）设置的间隔的权力责备，但仍然可以 接收由其他应用程序触发的位置，速率最高为 setFastestInterval（长）。这种请求方式适合 许多位置感知应用程序，包括后台使用。是的 如果你执行，小心也要限制setFastestInterval（long） 收到更新后的重量级工作 - 例如使用 网络
我关心的是这些方法
LocationRequest setFastestInterval(long millis)
明确设置位置更新的最快间隔，以毫秒为单位。
LocationRequest setInterval(long millis)
设置活动位置更新的所需间隔，以毫秒为单位。
让我们说数字...... 如果我设置interval = 30s和speed = 8s，那么在t = 8，t = 16，t = 24（8的倍数）我从其他应用程序获得更新？如果没有正在运行的位置感知应用程序怎么办？ 在30秒，我可以看到一个新的更新？该更新是否计入我的应用程序的耗电量？怎么估计？
因此，如果这是正确的，那么这两个参数之间的良好关系是什么，以获得实时更新而不消耗大量电力？例如，间隔= 6 x最快？
我会尝试自己，但我不能重复指南所描述的情景，我也无法区分哪些更新是权力责任。
答案 0 :(得分：1)
如果您的应用可以持续跟踪位置，则需要定期获取设备的位置。虽然您可以使用getLastLocation()获取设备的位置，但更直接的方法是请求融合位置提供商定期更新。作为回应，API会根据当前可用的位置提供商（如WiFi和GPS），使用最佳可用位置定期更新您的应用。
在请求位置更新之前，您的应用必须连接到位置服务并发出位置请求。位置请求到位后，您可以致电requestLocationUpdates()开始定期更新。在Google API客户端提供的onConnected()回调中执行此操作，该回调在客户端准备就绪时调用。
尝试阅读Location Strategies，本指南中描述的策略适用于android.location中的平台位置API。另外，请显示for `obtaining user location and defining a Model for the Best Performance'