最近在进行低功耗蓝牙SDK的开发，为了方便快捷，使用了BabyBluetooth库，整个开发都比较顺利，但是在测试的时候发现一个很奇怪的问题。App在被用户主动杀掉的时候，设备会断开ble的连接，但是如果是app crash的时候，app已经断开了ble的连接了，但是设置里面还是显示连接着外设，这样就导致了一个问题，因为ble外设作为边缘设备一次只能被一个设备连接上，而且在连接上时其他手机是扫描不到这款ble外设的，所以在那种场景下，其他的手机扫描不到外设，必须要将连接ble的手机断开了，或者打开crash的app，手动杀掉才能正常断开外设的连接。
这个问题很尴尬，很多人会说，app既然上线了，就要保证基本不crash吧，总不能把这种case作为一种正常的测试用例。理论上是这样的，但是没办法保证100%不crash，而且我很奇怪，究竟是什么原因导致了这个问题。为了搞清楚这个问题，我先咨询了固件开发，发现crash了他们没有任何办法去监测到，所以想要固件去主动断开连接是不可能的，问题还是出在app端。我去网上下了一个BabyBluetooth的官方demo，用这个demo去连接外设，发现也是会出现上面所说的问题的，我这个时候才有点开始怀疑是不是BabyBluetooth库有问题，因为这个库使用很方便，不需要考虑CBCentralManager等，库里都实现好了，一般用起来也没什么问题。正当我准备去搞一个使用CoreBluetooth的demo时，我想着是不是CBCentralManager的初始化做了什么，然后我就去看了源码，一看我才恍然大悟。
我们在开发Ble的时候，外面都设置Background mode，如图1所示。
图1
图2
在CBCentralManager初始化时，会判断图1是否勾选上，加上一个CBCentralManagerOptionRestoreIdentifierKey的初始化。这个key是给中心管理者提供一个字符串作为“恢复标识”，在系统重启app时恢复你的中心或周边角色，这个key在这里不做讨论，但是就是因为设置了这个key，导致了crash之后，设置里不会断开ble的连接。这个key在之前的项目中都用过，但是没有意识到会导致这个问题。
很多时候都是一个细节引发了一个百思不得其解的问题，所以还是要理解透彻才能一目了然问题的原因。
网友评论