位置提供商真的很耗电吗？
我需要实现基于位置的服务。我不需要精确的位置，所以不需要 GPS。
最简单的方法是在应用程序启动时开始侦听位置更新，并将其保留为打开状态：
mLocationMgr.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 10000, 100, mPendingIntent);
由于我不需要太多精确度，因此我将最大更新频率设置为 10 秒和 100m，而不是默认的 0、0。
当我们考虑位置时，我们认为电池耗尽，但我想这是一个捷径，只有 GPS 真正耗尽电池。我认为这样使用网络提供商不会耗尽电池。有什么想法吗？
I need to implement location-based service. I don't need fine location, so no GPS is needed.
Easiest would be to start listening for locations updates at app start, and leave it ON:
mLocationMgr.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 10000, 100, mPendingIntent);
Since I don't need much accuracy, I set max frequency of updates, to 10s, and 100m instead of default 0, 0.
When we think location, we think battery drain, but I guess this is a shortcut and that only GPS really drains the battery. I think that such a use of network provider wouldn't drain the battery. Any thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从电池消耗的角度来看，您的 100m 距离过滤器对您几乎没有帮助。这只会控制您的
PendingIntent由于修复而被执行的次数。操作系统可能会使用您的 10 秒时间值来控制电源使用，但不能保证。而且，由于价值如此之低，它似乎不太可能被使用。也许每小时一次，但不是每 10 秒一次。
更重要的是，您需要始终保持 CPU 通电。而且，由于您使用的是
requestLocationUpdates()的PendingIntent风格，我猜测您计划收集很长一段时间的数据。如果您只有 COARSE 权限，Android 希望能够避开 WiFi 热点接近检测，这将节省一些电量。
总体而言，网络提供商比 GPS 提供商消耗更少的电量。 “少”与“少”相差甚远。在 Nexus 级 Android 设备上，GPS + CPU 可为我提供几个小时的电池续航时间（通过使用 Google 导航确定）。我希望网络提供商 + CPU 能够多持续几个小时，但仅此而已，因为 CPU 本身就是相当大的电池消耗。
我更关心的是：
这听起来好像您实际上并不打算删除位置更新。对于任何类型的提供者（除了也许被动提供者）来说，这都是一个非常糟糕的主意。请在注册和删除更新时制定更具体的计划。特别是，请确保用户能够控制何时消耗电池到这种程度。
Your 100m distance filter will do little for you from a battery drain standpoint. That will only control how many times your
PendingIntentgets executed due to fixes.Your 10 second time value might be used by the OS to control power usage, but there is no guarantee. And, with that low of a value, it seems highly unlikely that it would be used. Every hour, maybe, but not every 10 seconds.
The bigger thing is that you will be needing to keep the CPU powered on all the time. And, since you're using the
PendingIntentflavor ofrequestLocationUpdates(), I am guessing that you plan on collecting data for a long time.If you only have
COARSEpermission, Android hopefully eschews the WiFi hotspot proximity detection, which will save a bit of power.On the whole, the network provider will consume less power than will the GPS provider. "Less" is a far cry from "little". On a Nexus-class Android device, GPS + CPU gives me a few hours battery life (as determined by using Google Navigation). I would expect network provider + CPU to last a few hours longer, but that's about it, because the CPU is a fairly significant battery drain in its own right.
My bigger concern is:
This sounds like you aren't actually planning on removing your location updates. This is a really bad idea, with any sort of provider (except maybe the passive provider). Please have a more concrete plan for when you are registering and removing the updates. In particular, make sure the user has the ability to control when you are consuming battery to this degree.
Android 开发者指南。我建议您查看页面上的代码示例。
这就是他们提到的关于节省电池和各种参数的内容。
基本上，请考虑减少您请求更新的频率或请求更新的时间长度。这就像高尔夫一样，你要求的地点越少越好。考虑以下用例：
在该示例中，应用程序等待，直到用户执行需要位置的操作，然后停止一旦不再需要位置数据就进行轮询。
虽然不断轮询将允许应用程序立即准备好位置，但它根本不值得浪费资源，为了减轻请求位置时的延迟，您可以使用
getLastKnownLocation（字符串提供程序）。编辑：
有一种方法可以确定各种 LocationProvider 的电量使用情况！
调用
getPowerRequirement ()将返回三个常量之一。为了使您的代码更具可读性，请考虑使用 在任何布尔检查中
满足Criteria（条件标准），使您的代码更具可读性。我将使用它来确定您的应用程序应使用哪种方法来实现最低的电力成本，此外，您还可以受益于支持对提供商有不同电力要求的设备。
There is a topic about this included in the Android Developers Guide. I would recommend that you take a look at the code examples on the page.
This is what they mention regarding conserving battery and various parameters.
Basically, consider reducing the frequency of the updates you request or the length of time you request them. This is like golf, the less locations you request the better. Consider the following use case:
In the example the application waits until the user performs an action that needs a location and then stops polling once the location data is no longer needed.
While polling constantly would allow the application to have a location ready at an instant notice its simply not worth the wasted resources, to mitigate the delay when requesting a location you can use
getLastKnownLocation (String provider).Edit:
There is a way to determine power usage for the various LocationProviders!
Calling
getPowerRequirement ()on a LocationProvider will return one of three constants.To make your code more readable look into using
meetsCriteria (Criteria criteria)in any boolean checks to make your code more readable.I would use this to determine what method your application should use for the lowest power cost, Also you have the benefit of supporting devices that have different power requirements for providers.