iOS cancelPeripheralConnection:(CBPeripheral *)peripheral 延时5S后才真正断开

最近在项目里面使用了蓝牙跟设备进行通讯，发现cancelPeripheralConnection这个方法不起效果，总是延时那么5秒才断开。APP端作为中心管理者连接外围设备。具体业务流程大概是这样的：

1.扫描外围设备。

2.连接指定的设备,如名称为“aaa”的设备。

3.查找服务、查找指定特征后发送数据，订阅一个通知（告诉APP这次的发送内容是否正确）。

4.didUpdateValueForCharacteristic:里面判断数据是否正确，以此显示给用户。之后调用cancelPeripheralConnection断开连接

多么痛的领悟的事情发生在调用cancelPeripheralConnection之后。

cancelPeripheralConnection调用完之后立刻回调didDisconnectPeripheral这个方法，表明此次已经“断开”连接。

但，事实是。。。。只是APP层面断开了连接，物理层并没有完全断开。这样，出现的现象是状态栏的蓝牙小图标不会立刻暗下来，而是过5秒后才会暗下来。（暗下来才是物理层的真正断开）

如果用户操作完第一次（以上四步骤），接着很快进行第二次（也需要进行以上四步骤），这样就会导致用户在扫描的时候浪费数秒（小于5秒）的时间，导致第二次以后的操作体验非常不好。因为第一次的连接在APP层是断开了，但是在物理层不没有断开的，此时第二次扫描、连接的时候必须等待第一次的物理层断开才可以正常进行。（安卓的立马就断开了，。。。。坑啊）

解决办法：设备端回码之后立刻断开连接！这样才能保证物理层的断开了。也就是说，想要蓝牙图标立刻变暗，需要设备端做断开。如果不需要这么高要求，那就等待5秒吧。

我是怎么发现的？

首先，cancelPeripheralConnection 为什么不是disConnectXXX呢？这个引起我的怀疑。

接着，我查了这个方法的官方注释：

/*!

*@method cancelPeripheralConnection:

*

*@param peripheralA CBPeripheral.

*

*@discussion Cancels an active or pending connection to peripheral. Note that this is non-blocking, and any CBPeripheral

*commands that are still pending to peripheral may or may not complete.

*

*@seecentralManager:didDisconnectPeripheral:error:

*

*/

- (void)cancelPeripheralConnection:(CBPeripheral*)peripheral;

说明此方法只是切断APP层的连接，may or may not complete ：不一定能切断物理层的连接。

思考：苹果为什么这样做？

这是蓝牙设备的调度管理锁导致的，因为一个蓝牙外设连接到APP，其实是连接到系统的蓝牙管理模块。但iphone上有很多APP都可能用到蓝牙的连接，怎么办？那就交给系统去分配吧！因为有可能有这种情况：APP1、APP2需要连接到同一个设备，但是他们用的是同一个设备的不同服务而已，假设现在两个APP都在后台连接这个设备（看起来有两个外设，其实对于系统来说只有一个在连接着），恰巧APP1需要跟设备（periphral）断开，而APP2一定不能断开，那怎么办？系统是要断开还是不断开呢。。。所以这种情况就需要对蓝牙设备进行管理了：APP1要断开，可以，你不用就可以了，对于系统来说你是断开的，这是虚拟的断开，你要连接就重新申请吧。

但是对于那个固定的5秒延时断开，我是没找到确切的证据了。。。

不知道说得对不对，求深入理解。。。。