ios - Estimote 信标无法按预期在 Iphone 上运行

Question

我们使用 ESTIMOTE 信标的目标:我们计划在高尔夫球场设置 Estimote 信标。我们的场景是每当玩家到达洞口时，比赛的节奏是什么，信标应该检测到它并通过我们的 iPhone 应用程序响应服务器。在这种情况下，用户不需要打开应用程序，因为手机在他的口袋里，他正在玩。

到目前为止我们做了什么:

1. 测距仅在应用处于事件状态时有效。 (目标未实现)。
2. 为了实现这个目标，我们正在使用 Monitoring，但问题是监控委托(delegate)(didDetermineState state:for region:)有时调用有时不调用(调用:instantly，someDelay & never)。换句话说，信标并不总是被 iOS 通过监控检测到。 (目标未实现)。
3. 如果我们在两部或多部装有相同 iOS 版本 10 的 iPhone 6s 上进行测试，每部手机都会有不同的结果，有些检测到，有些则没有。为了进行测试，我们使用翻盖 sleep 并在不同位置设置信标以触发进入/退出事件和最低广告间隔。
4. 在 estimote 信标上实现了 edystone，当应用程序处于后台时它们不工作。 (目标未实现)。

我们尝试了以下在互联网或 estimote beacons 论坛上找到的解决方案。

1. 2013 年 11 月的文章 Ibeacon monitoring但在 2016 年 12 月似乎没有什么不同。

2. 我们还尝试通过 CoreLocationManager.startUpdatingLocation 进行背景测距: Here和 Here

3. 我们尝试与 Estimote 交谈，但他们的回答模棱两可，“我们痛苦地意识到 iBeacon 监控有时可能有点挑剔。我们和试图构建信标驱动应用程序的开发人员一样讨厌它，但当它谈到 iBeacon，我们很无助，因为 Apple 锁定了 API——除了通过内置 API 之外，没有其他方法可以检测 iOS 上的 iBeacon 数据包，这会出现这些问题。”这似乎有些可能。

4. 这就是我注册信标阵列的方式，目前我们有 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)
      }
     }
   

5. 以下是我们在相同的 IOS 设备 (OS 10) 上都具有不一致行为时收到的响应。

相关问题:

1. 我们对信标准确性的期望是否很高？

2. 如果信标向所有手机广播数据，那么每台设备的行为都必须相同，因为我们拥有相同的 IOS 版本、相同的 Iphone 和相同的代码。我们怎样才能得到一致的结果我们的经验是，检测“从几秒到 15 分钟不等，有时根本检测不到”

3. 我们如何才能获得一致且可靠的结果？

Answer 1

从你的问题描述来看，你的核心问题是后台监控回调行为不一致。

理论上，您应该能够获得一个监控回调，在后台唤醒您的应用程序，并让它在后台范围内持续 10 秒(如果您使用 this technique 可延长至 3 分钟)每次信标首次在受监控区域中检测到或每次在受监控区域中停止检测到所有信标时。这将触发 didEnterRegion 或 didExitRegion 回调。

如您所见，有时这些回调不会按预期出现。这有两个主要原因:

1. 您不会收到进入或退出回调，因为区域状态未更改。当 iOS 认为它始终位于 CLBeacon 区域内时，通常会发生这种情况，而应用程序测试人员会短暂地将 iOS 设备从信标附近移除(通过移动手机或关闭信标)，然后将其放回该区域。在这种情况下无法获得退出/进入序列通常是由于没有给 iOS 足够的时间来检测它已经退出该区域。在后台，这最多可能需要 15 分钟。 大多数时候，这纯粹是一个测试问题，而不是您的实际用户将面临的问题——测试人员在完成测试方面面临时间压力，因此他们通常不会等待足够长的时间这些测试用例。添加日志记录、通知或其他关于何时发生区域退出的洞察力可以帮助您的测试人员确保他们等待足够长的时间。

2. 您无法快速获得入口回调，因为所有硬件加速槽都已满。为了检测信标并在一秒或一秒内发送 didEnterRegion 回调第二，当检测到感兴趣的信标时，iOS 依靠蓝牙硬件过滤器来唤醒操作系统。问题是这些硬件过滤器是一种稀缺资源，如果它们被首先安装在手机上的其他应用程序耗尽，那么您的应用程序将无法访问它们，这意味着检测时间将回退到软件扫描最多可能需要 15 分钟。没有办法知道您的应用程序是否已被授予访问这些硬件过滤器的权限，甚至在您的手机上卸载并重新安装应用程序也会改变这是否属实，从而导致不一致的结果。可用过滤器的数量未记录，但 some evidence suggests数字是 30，这意味着只有手机上监控的前 30 个 CLBeaconRegions 获得优先访问权。

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

当然，你不能让真正的用户卸载其他的信标应用，所以他们可能仍然会面临这些问题。但好消息是，大多数普通用户的手机上不会有很多信标应用程序，因此这种情况发生在真实用户身上的可能性远小于手机上经常有很多信标应用程序的开发人员或测试人员.