iOS 在后台监控/测距信标会消耗大量电池答案

【问题标题】：iOS monitoring/ranging beacons in background consumes a lot of batteryiOS 在后台监控/测距信标会消耗大量电池
【发布时间】：2014-12-10 10:46:19
【问题描述】：

在 iOS 中，我们在后台实现了对 ibeacon 的监控和测距。当设备进入一个区域时，我们开始在后台对 ibeacons 进行测距。当设备退出某个区域时，我们会停止在后台对 ibeacons 进行测距。

当我们在启动应用程序时发出以下语句时，这非常有效： locationManager.startUpdatingLocation()

并且我们可以在我们在该区域内的整个时间里在后台保持信标的范围。

当我们不发出此声明时，后台 iBeacons 的测距会在启动几秒钟后停止。这对于我们的应用程序来说还不够好，因为我们需要在一个区域内时保持对信标的测距。我们还看到，以这种方式在后台监控和测距信标会消耗大量电池电量。

有人有这方面的经验吗？后台的电池消耗是由 startUpdatingLocation() 引起的吗（它还会为 didUpdateLocations() 生成回调，其中包含我们不需要的纬度和经度）？还有其他方法可以避免在后台几秒钟后停止信标的测距吗？

我看到了另一个条目Beacon Ranging in Background on iOS，但仅测距 180 秒也不是我们真正想要的。条目说：为了解决第二个问题，在转换后只能获得 10 秒的测距时间，您可以请求额外的时间来保持测距。 iOS 允许您在后台继续测距长达 180 秒。这不需要后台模式，也不需要 AppStore 的特殊许可。

【问题讨论】：

标签： ios background ibeacon

【解决方案1】：

我写了一篇关于您在这里的各种选择的博客文章：

http://developer.radiusnetworks.com/2014/11/13/extending-background-ranging-on-ios.html

基本选项是：

使用位置背景模式在后台持续进行范围 - 这与您提到的设置locationManager.startUpdatingLocation() 本质上是相同的技术。缺点是你必须说服 Apple 你有一个定位应用才能获得 AppStore 的批准。
请求额外的后台运行时间。博文链接中提到了详细信息，但这只需要 180 秒。
通过设置信标影响您进入和退出区域的方式，让系统获得多个 180 秒的周期。
使用 10 秒背景测距默认设置。

无论您选择什么选项，信标测距比监控更耗电。如果您不断地进行续航，预计几小时内电池就会耗尽。

【讨论】：

非常好的选项概述。我们可能会从中做出选择。
你知道为什么测距信标使用这么大的功率吗？我会认为测距仍然必须依赖于每 x 毫秒从信标接收数据包？由于它只是接收，它不会“感觉”它应该使用太多的能量。我似乎找不到任何关于“测距”实际上是什么的细节，或者为什么 API 无法从它用于监视/检测的同一个数据包中指出范围。如果有人可以提供有关“测距”实际发生的任何信息，我很想知道。抄送：@罗伯特N
Ranging 基本上会持续进行蓝牙 LE 扫描，并让 CPU 处理它检测到的任何数据包。

【解决方案2】：

信标的测距设计为低功耗，但仅在前台使用。当应用程序关闭或后台运行时，它仅用于处理 didEnterRegion 和 didExitRegion。测距本身并不太耗电，所以我想说你的罪魁祸首是 locationManager.startUpdatingLocation。即使您没有使用它，它也会启动 GPS 硬件并不断获取您的位置。

您的用例与您链接到的帖子的用例相似吗？

【讨论】：

我们的用例与其他帖子有共同之处。在我们的例子中，我们希望在用户在几座建筑物内外行走时跟踪设备的位置。有多个重叠区域，每个区域都有多个信标。用户只会偶尔将应用程序置于前台。
您不仅可以监控 UDID，还可以监控主要和次要更改。这样，您将收到多个 didEnter 和 didExit 通知，使您能够看到用户所在的建筑物/房间。
你是对的。我们将对此进行研究。