Android BLE蓝牙连接异常处理

蓝牙通信过程中异常很常见,大致有以下几种:

1,连接

2,发现服务

3,读写

4,通知

连接

连接失败可能是设备端原因,也可能是手机端原因。不同的手机来自不同的厂家,用的不同的芯片和蓝牙协议栈都会导致蓝牙功能的表现不一致,这都会导致各式各样的兼容性问题,可能有的手机连接成功率高,有的成功率低。设备端原因可能有些时候出现异常导致死机无响应,或某些参数设置得有问题。但对于Android应用层开发来说,能做的很有限,蓝牙通信是在系统服务进程中处理的,我们无法跨进程改变系统的行为,如果是在一个进程我们还可能通过Hook等手段来调整其内在逻辑。另外应用层的接口只是将请求封装传递给系统服务进程,并未做一些实质性的通信,所以应用层虽然是同一个进程的,但是Hook意义也不大。所以我们能做的仅仅是看怎样调整接口的调用,使得整体稳定性更好一点而已。

连接失败分两种,一种是超时,一种是提前返回失败。

关于超时,一般是设备不在周围,或设备断电未发广播,或设备当前被其他人连接。系统默认超时为30s,通常返回133,我们也可以自己设置更短的超时时间,超时则closeGatt,然后重新连接。

关于提前返回失败,一般是有明确的异常,可能是手机蓝牙的异常或者设备异常。

这两种情况建议closeGatt,延时500ms,然后重试。如果重试三次仍然失败,则可以考虑提示用户重启手机蓝牙,或者检查设备是否正常工作。

还有一种情况,连接成功后没过多久连接又断开了,这有可能是设备主动断开,连接成功后有的设备会等待鉴权,如果一定时间内手机端还未发起鉴权则设备端主动断开。也可能连接信道不够稳定导致断开的,此时closeGatt并重新连接即可。

当连接断开时,会收到onConnectionStateChanged回调,这个回调可能会有一定延时,甚至有5s以上。解决的办法是轮询,如每隔1s发起一次读请求,如果连接断了会立即返回失败。

如果蓝牙连接不稳定,可以考虑关掉WIFI,因为WIFI通常和蓝牙共用一个天线。

发现服务

有的手机上discoverService可能会回调不止一次onServiceDiscover,这个要注意防御。

当连接建立后,可以由设备端发起更改连接间隔,这样能加快后续发现服务以及数据读写的速度。有的手机discover service很慢,原因是connect interval太大了,有的手机会主动向设备发起更改connect interval,而有的手机却不会。这样的话connect interval相差就会很大,实践中发现有的手机是7ms,有的手机是默认的50ms,所以发现service都要8s,甚至20s的都很寻常,这对用户来说是无法忍受的。所以比较好的办法是设备主动发起更改connect interval,而Android系统是没有提供对应API的。

如果发现服务失败,通常来说不用closeGatt,重试一下就好了。如果重试三次还失败,建议清一下缓存,再closeGatt,重新连接。

读写

读写失败要看失败的原因是什么,如果是权限问题,则需要和设备端确认是否开放了相应的读写权限。也可能是要读写的character不存在,可能是设备端修改了固件,手机端需要刷新一下蓝牙缓存,closeGatt再重新连接。如果是其它未知错误,则重试三次,仍然失败则closeGatt。不过通常来说如果是因为连接出了问题导致读写失败的,会收到onConnectionStateChanged回调,此时就不用再无谓的重试了,直接closeGatt,重新连接。

通知

打开/关闭character的notify,必须等收到onDescriptorWrite回调之后才算结束,才能开始下一个任务。

如果打开notify失败,则可以改成周期性轮询的方式去查询character的值。

可参考该文章

Android-BLE-Issues

你可能感兴趣的:(Android BLE蓝牙连接异常处理)