当前位置:   article > 正文

经典蓝牙与BLE的扫描_手机可以同时连接经典蓝牙和ble蓝牙吗

手机可以同时连接经典蓝牙和ble蓝牙吗

一、蓝牙能做些什么

  1. 近距离通信:收发数据,指令控制

    蓝牙设备通常是穿戴式,便携式,室内或车内等,正是因为蓝牙适用于近距离通信的特点。如果要做远距离通信,则可借助于Wifi,用手机或网关做中转。

  2. 广播消息、通知

    蓝牙可以以一定的周期发送广播,手机端接收到广播后,解析广播包,可做设备识别、配对,事件通知以及指令控制等。

  3. 精度定位

    根据设备的信号强度,可以估算出大概方位和距离。

二、Android平台的蓝牙

Android 4.3才开始支持低功耗蓝牙,提供的API很简陋,只有扫描和连接。

(一) 蓝牙扫描

  1. 蓝牙扫描分为经典蓝牙扫描和低功耗蓝牙扫描,官方文档里提到这两种蓝牙不能同时扫描,如下
  2. [https://developer.android.com/intl/es/guide/topics/connectivity/bluetooth-le.html](https://developer.android.com/intl/es/guide/topics/connectivity/bluetooth-le.html)

这里写图片描述

然而实验发现 BluetoothAdapter.startDiscovery是可以同时发现经典蓝牙和ble的

在stackoverflow上查看解释:

http://stackoverflow.com/questions/25065810/android-bluetooth-scan-for-classic-and-btle-devices

http://stackoverflow.com/questions/27169468/android-bluetooth-device-scan-discovery-for-classic-and-low-energy-devices-seque

这个帖子说某些手机上startDiscovery不能扫ble 
http://stackoverflow.com/questions/21809946/bluetoothadapter-startscan-vs-bluetoothadapter-startlescan/22524528#22524528

总结一下:

BluetoothAdapter.startDiscovery在大多数手机上是可以同时发现经典蓝牙和Ble的,但是startDiscovery的回调无法返回Ble的广播,所以无法通过广播识别设备,且startDiscovery扫描Ble的效率比StartLeScan低很多。所以在实际应用中,还是StartDiscovery和StartLeScan分开扫,前者扫传统蓝牙,后者扫低功耗蓝牙。考虑到BLE设备较多,所以先扫BLE 10s,再扫传统蓝牙10s。

另外需要提一下的是: 
在 startLeScan() 的时候,在onLeScan() 中不能做太多事情,特别是周围的BLE设备多的时候,非常容易导致出现如下错误: 
E/GKI LINUX(17741): ##### ERROR : GKI exception: GKI exception(): Task State Table E/GKI LINUX(17741): ##### 
E/GKI LINUX(17741): ##### ERROR : GKI exception: TASK ID [0] task name [BTU] state [1] 
E/GKI 
LINUX(17741): ##### 
LINUX(17741): ##### ERROR : GKI 
exception: TASK ID [1] task name [BTIF] state [1] 
LINUX(17741): ##### 
E/GKI LINUX(17741): ##### ERROR : GKI exception: TASK ID [2] task name [A2DP-MEDIA] state [1] 
E/GKI 
LINUX(17741): ##### 
LINUX(17741): ##### ERROR : GKI exception: GKI exception 65524 getbuf: out of buffers##### 
E/GKI LINUX(17741): ##### ERROR : GKI exception: 
E/GKI_LINUX(17741): * * * * * * * * * * * * * * * * * * * * * * 
开发建议:在 onLeScan() 回调中只做尽量少的工作,可以把扫描到的设备,扔到另外一个线程中去处理,让 onLeScan() 尽快返回。 参考帖子

(二)设备识别

蓝牙设备识别方式多种多样,有通过mac地址特征识别的,有通过设备名称识别的,有通过广播识别的。通过mac地址识别最简单,不过不太靠谱,同一个厂家不同批次生产的产品可能mac特征都不一样,所以客户端需要不停地兼容。通过设备名称识别的也不靠谱,首先重复率太高,其次获取设备名称涉及到跨进程通信,如果在UI线程可能导致ANR,所以得放在子线程,增加了复杂度。最好的办法是通过广播,广播中可以约定一套协议,并将设备类型ID放入广播,当收到符合该协议的广播时,读取出设备类型ID,到后台一查,就能获取到该类型设备的所有参数,这样灵活性最高。不过有的设备识别比较坑,需要先建立连接,并查看是否存在某个Service,对于这种稍复杂的设备,可以建立mac地址到设备类型的缓存,就免去了每次都要连接的麻烦。

(三)设备配对 
这里说的配对指的是BLE设备的配对。配对的作用在于和设备做相互确认,一方面是确定要操作的设备,另一方面是考虑到安全因素。假如家里买了两盏灯,蓝牙扫描时都扫出来了,但是怎么区分这两盏灯呢?比较好的办法是按一下某台灯的电源键,然后灯会发广播,手机就会收到了。如果隔壁有人也搜到这盏灯了,由于他无法配对,所以就无法操控这盏灯了。

配对的过程和扫描过程类似,都是打开蓝牙扫描,然而稍有区别,配对时只扫Ble,且扫描的策略不同,原因是实践中发现某些蓝牙芯片在一次扫描中只回一次response,假如这次手机没有收到,那就算扫一天也收不到。针对这种情况,解决的办法是多扫几次,每次时间可以短一点,这样扫到的概率就会大大提高。可参考如下帖子 
http://stackoverflow.com/questions/19502853/android-4-3-ble-filtering-behaviour-of-startlescan 
http://stackoverflow.com/questions/17870189/android-4-3-bluetooth-low-energy-unstable

我们不用每次操作设备的时候都要配对,那样过于繁琐了。配对只在第一次使用设备时进行,或设备正在被他人占用,你要抢过来用时才需要配对。如果曾经使用过设备是不需要配对的,下次直接连接即可。

(四)设备连接 
要操作设备通常要与设备建立连接,从设备读或向设备写数据,数据包括控制指令和一些参数等。连接建立成功后,还要进行授权,即从设备读出Service Token,和手机本地的Service Token对比,只有两个吻合才能操作设备,否则表示设备正被他人占用或本地Service Token已过期,需要重新配对以确认身份的合法性。如果是刚配对过,则手机端会生成Token并写入设备,以后操作设备都用这个token即可,并且该token可以分享给他人。

Android中蓝牙BLE设备连接有不少坑要注意的,不然很多时候会出一些莫名其妙的问题。我大概总结了一下,大概有十来条。如果大家觉得自己一条条去解决太麻烦,可以参考这个开源框架:

https://github.com/dingjikerbo/BluetoothKit

一、对蓝牙设备的操作不能并行,只能串行,并且每次都要在收到上一个操作的回调后才能继续下一个操作。有时候蓝牙协议栈出现异常可能收不到回调,所以我们要对每个操作做超时检查,否则后面的所有操作都被阻塞了。对于这些超时的任务或者失败的任务,通常是连接出了问题,我的做法是直接给gatt关掉,下次重新连接的时候重开一个gatt。除超时处理之外,对每个任务最好支持失败重试机制,尤其是连接。

要注意,断开连接是不用放到队列中等待的,而是直接closeGatt,并给当前正在进行的任务直接退出回调Cancel。

二、同一个设备的所有操作最好都放在同一个线程串行执行,最好不要放在UI线程,虽然这些操作都是异步的,理论上来说不会耗时,但是由于涉及到跨进程,有可能出现ANR。另外不建议每个设备都开一个线程,设备多了会费内存也会降低性能。较好的做法是开一个线程,所有设备的操作都在该线程中发起,虽然占用同一个线程,但是每个设备各自维护自己的任务队列。

三、设备的gatt在不用时要及时关闭,不然会造成连接泄露,而系统支持的连接设备数是有限的,当达到上限后有可能其它设备连不了。

四、当设备断开连接时,最好closeGatt,而不是diconnect。不要下次复用之前的gatt来reconnect,因为有的手机上重连可能会存在问题,比如重连后死活发现不了service。这种情况下,最好只要断开连接就close gatt,下次连接时打开全新的gatt,这样就可以发现service了。

五、service不要缓存,虽然uuid什么的都没变,但是这些service都会和gatt关联的,如果gatt变了,那service就报废了,对这些service和character做任何读写操作都会出错。所以建议每次连接上时都去discover service,不要缓存。

六、有的手机discover service很慢,原因是connect interval太大了,有的手机会主动向设备发起更改connect interval,而有的手机却不会。这样的话connect interval相差就会很大,实践中发现有的手机是7ms,有的手机是默认的50ms,所以发现service都要8s,甚至20s的都很寻常,这对用户来说是无法忍受的。所以比较好的办法是设备主动发起更改connect interval,这个可以参考google搜索 ble spec update connection parameter, 
https://devzone.nordicsemi.com/question/12545/update-connection-parameter-programmatically/

七、前面提到蓝牙的所有操作都要放到同一个线程里执行,但是回调通常都会在binder线程里执行,因为这是跨进程回调回来的。一定要注意到这一点,否则会出现一些奇怪的问题。比如writeCharacter在线程A中,但是onCharacterWrite是在binder线程中,回调里如果涉及到任务队列的调度一定要post回线程A中,不然任务调度会出问题。

八、当设备固件升级后,character可能发生了变化,而系统是不知道的,下次discover service的时候还是返回的旧的缓存,这样读写character可能会失败。解决办法是固件升级后,断开连接再重开一个gatt,并马上刷新一下该设备的缓存。当然,重启蓝牙也会刷新缓存,不过会影响到所有设备。另外有时候discoverService服务发现的不全,或者根本发现不了服务,也可以考虑清除一下缓存。 
关于蓝牙缓存的清除可以参考 http://stackoverflow.com/questions/22596951/how-to-programmatically-force-bluetooth-low-energy-service-discovery-on-android

九、尽量维护设备的连接,因为连接是有成本的,慢的时候可能要等几秒钟,对于操作频次较高的设备用户是无法忍受的。这种情况可以考虑在退出设备操作页面时,继续为该设备保持连接一段时间再断开,如果这段时间内用户又重新点进设备操作页就能很快。

十、固件升级通常是写设备,为加快写速度,可以在write character时指定no response标志,实践发现速度可以提升2~3倍。不过要注意的是即便带了no response标志,也不代表这种写操作是没有回调的,我们仍然要遵循收到上一次写回调后才能进行下一次写操作。

十一、打开/关闭character的notify,如下:

  1. private boolean setCharacteristicNotification(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic, boolean flag) {
  2. boolean result = gatt.setCharacteristicNotification(characteristic, flag);
  3. if (result) {
  4. BluetoothGattDescriptor descriptor = characteristic
  5. .getDescriptor(UUID.fromString(BluetoothConstants.CLIENT_CHARACTERISTIC_CONFIG));
  6. if (descriptor != null) {
  7. descriptor.setValue(flag ? BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE
  8. : BluetoothGattDescriptor.DISABLE_NOTIFICATION_VALUE);
  9. }
  10. result = mBluetoothGatt.writeDescriptor(descriptor);
  11. }
  12. return result;
  13. }
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

这里有两步操作,别漏掉设置descriptor,并且要注意必须等收到onDescriptorWrite回调之后再继续执行下一个任务。

最后可以参考这个链接,关于BLE各种不稳定的问题和兼容的办法的讨论: 
http://stackoverflow.com/questions/17870189/android-4-3-bluetooth-low-energy-unstable

(五)蓝牙安全 
蓝牙最主要的两个安全问题就是:加密和防重放。加密的包括token,控制指令,数据等。 token相当于控制设备的钥匙,每当要操作设备时,都需要核实token,token在手机和设备之间传递时是通过秘钥加密过的,所以就算别人截获了,如果不知道秘钥和加密算法也无法破解。另一个是防重放,总体来说,都是数据中带有一个序号,这个序号有一个有效窗口,在这个有效窗口内的请求被认为是有效的,否则认为是无效的。序号通常有三种:

  1. 时间戳 ,下次请求的时间戳必须和上次请求有一个时间差,比如大于5s,否则认为是重放。这个窗口不能设置的太小了,太小了防重放就没有作用,太大了会导致正常的网络请求被屏蔽。

  2. 递增序列,每次操作都递增序列号,如果收到的序列号没有递增,则丢弃。比如手机遥控电视,手机每发出一次指令,序列号就加一,电视会保存这个序列号,但是遥控器不能每次发指令都保存序列号,因为要省电,并且flash的写次数是有限制的,所以要隔一个周期写入,比如满100写入一次。如果中途设备断电导致序列号丢失了,则下次上电时需要加上一个周期。

  3. 随机数,每次都生成一个随机数,服务端会将最近一段时间收到的序列号保存下来,如果发现收到的序列号已经存在了就认为是重放,因为是随机数,所以碰撞的概率极小。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小蓝xlanll/article/detail/192458
推荐阅读
相关标签
  

闽ICP备14008679号