Question

我们与ESTIMOTE BEACONS的目标：我们计划在高尔夫球场设置Estimote信标。我们的场景是每当玩家到达洞口时，游戏的节奏是什么，它应该由信标和＆amp;通过我们的iPhone应用程序响应服务器。在这种情况下，用户不需要打开应用程序，因为移动设备在他的口袋里。他在玩。

我们做了什么：

只有当应用程序处于活动状态时，范围才有效。（目标尚未实现）。
为了实现这个目标，我们正在使用Monitoring，但问题是监视委托（didDetermineState状态：for region :)有时会调用某些时候（称为：instant，someDelay＆amp; never）。换句话说，信标并不总是通过监控来检测iOS。（目标尚未实现）。
如果我们正在测试具有相同iOS版本10的两个或更多iPhone 6s，那么每个手机都有不同的结果，有些检测到＆amp;别人没有。为了进行测试，我们使用了flip to sleep＆amp;在不同地点设置信标，以进入/退出事件发射＆amp;最低广告时间间隔。
在estimote beacon上实现了edystone，当应用程序在后台时它们无法正常工作。（目标尚未实现）。

我们尝试了在互联网或estimote信标论坛上发现的以下解决方案。

2013年11月的文章Ibeacon monitoring但在2016年12月似乎没什么区别。
我们还尝试通过CoreLocationManager.startUpdatingLocation进行背景测距： Here和Here
我们试图说Estimote，但他们的答案是暧昧的，“我们痛苦地意识到iBeacon监控有时候有点挑剔。我们讨厌它，就像开发人员尝试构建信标驱动的应用程序一样，但是当它来到iBeacon，我们非常无助，因为Apple在锁定时有API - 除了内置的API之外，没有办法在iOS上检测iBeacon数据包，因为它会出现这些问题。“ 似乎有些可能。

这就是我正在注册的信标数组，目前我们有3到6个信标。

func loadBeacons() { // Load beacons 
     self.beacons = getAllbeacons()
     self.beaconManager = ESTBeaconManager()
     self.beaconManager.delegate = self
     self.beaconManager.requestAlwaysAuthorization()
  if self.beaconManager.isAuthorizedForMonitoring() == true {
     self.rangingBeaconsSetup()
  } else {
    self.beaconManager.requestAlwaysAuthorization()
  }
 }


func rangingBeaconsSetup() { // SET UP Ranging beacons
   for beacon in self.beacons {
 if let beaconRegion = self.beaconRegionFromItem(beacon) {
     beaconRegion.notifyEntryStateOnDisplay = true
     self.beaconManager.startMonitoring(for: beaconRegion)
     self.beaconManager.startRangingBeacons(in: beaconRegion)
   }
  }
 }

func beaconRegionFrom(_ beacon: Beacon) -> CLBeaconRegion? { // GET VALID REGION
    let val = 1 << 16
    if let uuid = NSUUID(uuidString: beacon.uuid), beacon.major < val &&      beacon.minor < val {
 return CLBeaconRegion(proximityUUID: uuid as UUID, major:    CLBeaconMajorValue(beacon.major), minor: CLBeaconMinorValue(beacon.minor),   identifier: beacon.deviceName)
   }
  return nil
 }

  func beaconManager(_ manager: Any, didDetermineState state:   CLRegionState, for region: CLBeaconRegion) { // Monitoring delegate.
   if state == .inside {
   let notification = UILocalNotification()
   notification.alertBody = "By tapping you will be able to check-in"
   notification.alertAction = "OK"
   notification.fireDate = Date()
   application.scheduleLocalNotification(notification)
   }
  }

当我们使用相同的IOS设备（OS 10）时，我们会收到以下响应，这两种设备都有不一致的行为。

相关问题：

我们对信标准确度的期望是否很高？
如果信标正在向所有电话广播数据，那么每个设备必须表现相同，因为我们拥有相同的IOS版本，相同的Iphone和相同的代码。我们怎样才能得到一致的结果我们的经验是，检测变化“从几秒钟到15分钟，有些时候根本没有检测到”
我们可以做些什么来获得一致且可靠的结果？

Answer 1

从您的问题描述中，您遇到的核心问题是后台监控回调中的行为不一致。

理论上，您应该能够获得一个监视回调，在后台唤醒您的应用程序并让它在后台范围内持续10秒（如果您使用this technique，则每次可扩展到3分钟）首先在监视区域中检测信标，或者每次在监视区域中停止检测所有信标。这会触发didEnterRegion或didExitRegion回调。

正如您所看到的，有时这些回调在预期时不会出现。这有两个主要原因：

由于区域状态未发生变化，您无法获得进入或退出回调。当iOS认为它始终位于CLBeacon区域内时，通常会发生这种情况，而应用程序测试人员会短暂地从信标附近移除iOS设备（通过移动电话或关闭信标）然后将其返回到该区域。在这种情况下无法获得退出/进入序列通常是由于没有给iOS足够的时间来检测它已退出该区域。在后台，这可能需要15分钟。 大部分时间这纯粹是一个测试问题而不是您的实际用户将面临的问题 - 测试人员面临着完成测试的时间压力，因此他们通常不会等待很长时间在这些测试案例中足够了。添加日志，通知或其他有关区域退出的信息可以帮助您的测试人员确保他们等待足够长的时间。
您没有快速获得条目回调，因为所有硬件加速插槽都已填满。为了检测信号并在一两秒内发送didEnterRegion个回调，当检测到感兴趣的信标时，iOS依靠蓝牙硬件过滤器来唤醒操作系统。问题是这些硬件过滤器是一种稀缺资源，如果它们被手机上安装的其他应用程序耗尽，那么您的应用程序将无法访问它们，这意味着检测时间将回落到软件扫描可能需要15分钟。无法知道您的应用程序是否已被授予对这些硬件过滤器的访问权限，甚至在手机上卸载和重新安装应用程序可能会改变这是否属实，从而导致不一致的结果。可用过滤器的数量未记录，但some evidence suggests的数量为30，这意味着只有手机上监控的前30 CLBeaconRegions才能获得优先权。

为了解决测试中的问题＃2，卸载您认为可能正在监控信标的任何其他应用，然后重新安装您的应用。然后您应该获得更一致的结果。

当然，您无法让真实用户卸载其他信标应用，因此他们仍可能遇到这些问题。但好消息是，大多数普通用户手机上都没有很多信标应用，所以真实用户发生这种情况的可能性要小于通常拥有大量信标应用的开发人员或测试人员。他们的手机。

Estimote信标不按预期在Iphone上工作

1 个答案: