以下是来自官方站点的关于LocationRequest API的当前引用
在这两个极端之间是一个非常常见的用例，其中应用程序肯定希望在指定的时间点接收更新间隔，并且可以在可用时更快地接收它们，但仍然需要一个低功率冲击。这些应用程序应该考虑PRIORITY_BALANCED_POWER_ACCURACY与一个更快的setfaststinterval(长)(如1分钟)或更慢setInterval(长)(如60分钟)。他们只会被分配功率怪为setInterval设置的间隔(长)，但仍然可以接收由其他应用程序触发的位置，速率高达setFastestInterval(长)。这种请求方式适合于许多位置感知应用程序，包括后台使用。做的是如果执行，也要注意调节setfaststinterval(长)接收到更新后的繁重工作-例如使用网络。
我关心的是这些方法
LocationRequest setFastestInterval(long millis)
显式设置位置更新的最快间隔，单位为毫秒。
LocationRequest setInterval(long millis)
设置活动位置更新所需的时间间隔，单位为毫秒。
我们说数字…如果我设置间隔=30秒，最快=8秒，那么在t=8, t=16, t=24(8的倍数)，我从其他应用程序获得更新?如果没有正在运行的位置感知应用程序怎么办?在30秒，我能看到新的更新吗?这个更新算不算我的应用的能耗?它是如何估计的?
那么，如果这是正确的，那么这两个参数之间的良好关系是什么，以获得实时更新而不消耗大量功率?例如interval=6 x最快?
我本想自己试一试，但我无法重复指南中描述的场景，我也无法区分哪些更新是电源问题
如果你的应用程序可以持续跟踪位置，它需要定期获得设备的位置。虽然可以使用getLastLocation()获取设备的位置，但更直接的方法是从融合的位置提供程序请求定期更新。作为回应，API会根据当前可用的位置提供商(如WiFi和GPS)，定期更新您的应用程序的最佳可用位置。
在请求位置更新之前，您的应用程序必须连接到位置服务并发出位置请求。一旦位置请求到位，您就可以通过调用requestLocationUpdates()来启动常规更新。在Google API Client提供的onConnected()回调中执行此操作，该回调将在客户端准备就绪时调用。
试着阅读Location Strategies，本指南中描述的策略适用于android.location中的平台定位API。此外，还显示了for '获取用户位置并定义最佳性能模型'