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

一、蓝牙能做些什么

1. 近距离通信：收发数据，指令控制

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

2. 广播消息、通知

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

3. 低精度定位

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

二、Android平台的蓝牙

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

（一） 蓝牙扫描

 蓝牙扫描分为经典蓝牙扫描和低功耗蓝牙扫描，官方文档里提到这两种蓝牙不能同时扫描，如下
 [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，如下：

private boolean setCharacteristicNotification(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic, boolean flag) {
    boolean result = gatt.setCharacteristicNotification(characteristic, flag);
 
    if (result) {
        BluetoothGattDescriptor descriptor = characteristic
         .getDescriptor(UUID.fromString(BluetoothConstants.CLIENT_CHARACTERISTIC_CONFIG));
 
        if (descriptor != null) {
            descriptor.setValue(flag ? BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE
                            : BluetoothGattDescriptor.DISABLE_NOTIFICATION_VALUE);
        }
        result = mBluetoothGatt.writeDescriptor(descriptor);
    }
    return result;
}
 
 
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. 随机数，每次都生成一个随机数，服务端会将最近一段时间收到的序列号保存下来，如果发现收到的序列号已经存在了就认为是重放，因为是随机数，所以碰撞的概率极小。