我们有一个订阅 ANCS 的 BLE 外设。它还托管我们的应用程序连接到的一些自定义服务。
由于 ANCS，必须在“设置”应用程序中连接到外围设备 (xxx)。因此，我们在应用程序中没有任何设施来启动 BLE 连接。这也使 UseEx 保持清洁，并减少“角落案例”。
这个想法是用户在设置应用程序中连接。然后，如果外围设备超出范围，iOS 将在返回范围后自动重新连接。
然而，客户发现，在说离开房间后，外围设备通常不会重新连接。
我们只能通过将 BLE 外围设备放在距离 iPhone 约 15 米的金属盒内来可靠地重现这一点。通过以适当的速度打开和关闭机箱，我们可以在 10 秒左右的时间内引发一系列失败的 ANCS 连接请求。
以下是一些设备控制台日志，显示了由于信号丢失而导致的第一次连接失败。
Mar 18 16:38:05 afes-iPhone BTLEServer[107] <Notice>: (Note ) Central "xxx" is now subscribed to characteristic "ANCS Data Source"
Mar 18 16:38:07 afes-iPhone BTServer[68] <Error>: Core Connection timed out to device "xxxxxxx"
Mar 18 16:38:07 afes-iPhone BTLEServer[107] <Notice>: (Note ) Peripheral "xxx" is now disconnected: Error Domain=CBErrorDomain Code=6 "The connection has timed out unexpectedly." UserInfo=0x14528470 {NSLocalizedDescription=The connection has timed out unexpectedly.}
Mar 18 16:38:07 afes-iPhone BTLEServer[107] <Notice>: (Note ) Connecting peripheral "xxx"...
Mar 18 16:38:07 afes-iPhone BTLEServer[107] <Notice>: (Note ) Central "xxx" is now unsubscribed from characteristic "ANCS Notification Source"
Mar 18 16:38:07 afes-iPhone BTLEServer[107] <Notice>: (Note ) Central "xxx" is now unsubscribed from characteristic "ANCS Data Source"
Mar 18 16:38:08 afes-iPhone BTLEServer[107] <Notice>: (Note ) Peripheral "xxx" is now connected
Mar 18 16:38:08 afes-iPhone Preferences[164] <Warning>: (Warn ) CoreBluetooth: API MISUSE: <CBPeripheral: 0x14da8170, identifier = xxxxxx, name = xxx, state = disconnected> can only accept commands while in the connected state
....
Mar 18 16:38:09 afes-iPhone BTServer[68] <Error>: Core Connection timed out to device "xxxxxxxxx"
Mar 18 16:38:09 afes-iPhone BTLEServer[107] <Notice>: (Note ) Peripheral "xxx" is now disconnected: Error Domain=CBErrorDomain Code=6 "The connection has timed out unexpectedly." UserInfo=0x1453daf0 {NSLocalizedDescription=The connection has timed out unexpectedly.}
Mar 18 16:38:09 afes-iPhone BTLEServer[107] <Notice>: (Note ) Connecting peripheral "xxx"...
Mar 18 16:38:09 afes-iPhone BTLEServer[107] <Notice>: (Note ) Peripheral "xxx" did not use any built-in service, strike #1
...
如果我们继续正确打开和关闭金属盒，我们可以连续三次执行相同的“API MISUSE”。
导致以下消息：
Mar 18 16:38:12 afes-iPhone BTLEServer[107] <Notice>: (Note ) Peripheral "xxx" did not use any built-in service, strike #2
...
Mar 18 16:38:16 afes-iPhone BTLEServer[107] <Notice>: (Note ) Peripheral "xxx" did not use any built-in service, strike #3
...
看起来这是一个“三击即出”的算法，然后将外围设备放入某种“灰名单”。时间必须在 11 秒左右的范围内。我们不能放慢我们的审讯速度，否则我们会遇到配对超时的 30 秒密钥交换。
此灰名单意味着 iOS 将不再允许将此外围设备重新连接到 ANCS，除非用户打开设置并手动连接到它。
这意味着 CBCentralManager - retrieveConnectedPeripheralsWithServices: 方法将不会检索外围设备，因为它不再连接。
我们必须添加一个变通方法，现在我们存储之前看到的任何外围设备的 UDID，然后在回调到 didDisconnectPeripheral 时，我们使用 -retrievePeripheralsWithIdentifiers 重新连接：
但是，为了保持 ANCS 连接的连续性，我们还必须在 Info.plist 中添加 bluetooth-central UIBackground 模式，以便在后台收到应用程序的 didDisconnectPeripheral 后重新连接。当然，如果应用程序在没有状态保存和恢复的情况下被卸载，ANCS 连接将再次断开。
为了更好地衡量，我们还在前台使用看门狗定时器来定期检查连接状态。
我们只能很难重现效果，我们的客户似乎可以经常看到它，当然BLE设备可能连接不可靠。
如果 ANCS 在 iOS 中得到更强大的处理，我们可以让我们的应用程序更节能，并以更少的工作量开发它。
使用的设备是 iOS 8.1 和 8.2 上的 iPhone 4S 和 iPhone 6。
问题是：有其他人在 ANCS 中看到过这种行为吗？