在iOS后台监控状态下,如何在一个UUID中获取主要编号和次要编号?

在iOS后台监控状态下,如何在一个UUID中获取主要编号和次要编号?,ios,background,ibeacon,Ios,Background,Ibeacon,我们使用一个UUID,以及不同操作的主要和次要组合。 我们需要知道iOS后台监控中的主要和次要数字 测距可以得到主要和次要号码,但这需要发射延迟和电池消耗。所以这对我们来说不是一个合适的解决方案,因为我们需要即时检测和低电池消耗 因此,我们希望在iOS后台监控状态下获得相同UUID中的主要和次要编号。 这种机制是必要的,因为我们制作的iOS应用程序不适用于典型用途。 有可能吗?您无法使用监视API读取单个信标标识符。您所能做的就是访问用于启动监视的CLBeaconRegion标识符。在您的例子中

我们使用一个UUID,以及不同操作的主要和次要组合。 我们需要知道iOS后台监控中的主要和次要数字

测距可以得到主要和次要号码,但这需要发射延迟和电池消耗。所以这对我们来说不是一个合适的解决方案,因为我们需要即时检测和低电池消耗

因此,我们希望在iOS后台监控状态下获得相同UUID中的主要和次要编号。 这种机制是必要的,因为我们制作的iOS应用程序不适用于典型用途。
有可能吗?

您无法使用监视API读取单个信标标识符。您所能做的就是访问用于启动监视的CLBeaconRegion标识符。在您的例子中,这可能只是带有零大调和小调的proximityuid

另一种方法是将测距与背景监测相结合。每当你收到didEnterRegion事件时,你也会收到10秒左右的范围回调,即使你的应用程序在后台。您可以使用此回调读取所有标识符


虽然前台测距确实比监控使用的电池多得多,但后台测距实际上非常电池友好。考虑每次进入或退出一个区域时,你只需要10秒的时间。即使测距仍处于打开状态,操作系统在后台10秒后会自动停止测距。除非您希望用户不断地进入/退出区域,否则在如此短的背景范围内,电池不应成为问题。

还有一个问题,设备是否可能在背景区域事件中发送信标信号?不幸的是,没有。请参见此处: