Android BLE开发详解和FastBle源码解析

项目中有用到了蓝牙相关的功能，所以之前也断断续续地针对蓝牙通信尤其是BLE通信进行了一番探索，整理出了一个开源框架FastBle与各位分享经验。
源码地址：

https://github.com/Jasonchenlijian/FastBle

随着对FastBle框架关注的人越来越多，与我讨论问题的小伙伴也多起来，所以整理了一篇文章，详细介绍一下框架的用法，一些坑，还有我对Android BLE开发实践方面的理解。

文章分为3个部分：

  • FastBle的使用
  • BLE开发实践方面的理解
  • FastBle源码解析

1. FastBle的使用

1.1 声明权限

<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
  • android.permission.BLUETOOTH : 这个权限允许程序连接到已配对的蓝牙设备, 请求连接/接收连接/传输数据需要改权限, 主要用于对配对后进行操作;
  • android.permission.BLUETOOTH_ADMIN : 这个权限允许程序发现和配对蓝牙设备, 该权限用来管理蓝牙设备, 有了这个权限, 应用才能使用本机的蓝牙设备, 主要用于对配对前的操作;
  • android.permission.ACCESS_COARSE_LOCATION和android.permission.ACCESS_FINE_LOCATION：Android 6.0以后，这两个权限是必须的，蓝牙扫描周围的设备需要获取模糊的位置信息。这两个权限属于同一组危险权限，在清单文件中声明之后，还需要再运行时动态获取。

1.2. 初始化及配置

@Override
protected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);BleManager.getInstance().init(getApplication());BleManager.getInstance().enableLog(true).setReConnectCount(1, 5000).setOperateTimeout(5000);
}

在使用之前，需要事先调用初始化init(Application app)方法。此外，可以进行一些自定义的配置，比如是否显示框架内部日志，重连次数和重连时间间隔，以及操作超时时间。

1.3. 扫描外围设备

APP作为中心设备，想要与外围硬件设备建立蓝牙通信的前提是首先得到设备对象，途径是扫描。在调用扫描方法之前，你首先应该先处理下面的准备工作。

  • 判断当前Android设备是否支持BLE。
    Android 4.3以后系统中加入了蓝牙BLE的功能。

     BleManager.getInstance().isSupportBle();

  • 判断当前Android设备的蓝牙是否已经打开。
    可以直接调用下面的判断方法来判断本机是否已经打开了蓝牙，如果没有，向用户抛出提示。

    BleManager.getInstance().isBlueEnable();

  • 主动打开蓝牙。
    除了判断蓝牙是否打开给以用户提示之外，我们也可以通过程序直接帮助用户打开蓝牙开关，打开方式有这几种：
    方法1：通过蓝牙适配器直接打开蓝牙。

    BleManager.getInstance().enableBluetooth();

    方法2：通过startActivityForResult引导界面引导用户打开蓝牙。

    Intent intent = new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);
startActivityForResult(intent, 0x01);

    需要注意的是，第一种方法是异步的，打开蓝牙需要一段时间，调用此方法后，蓝牙不会立刻就处于开启状态。如果使用此方法后紧接者就需要进行扫描，建议维护一个阻塞线程，内部每隔一段时间查询蓝牙是否处于开启状态，外部显示等待UI引导用户等待，直至开启成功。使用第二种方法，会通过系统弹出框的形式引导用户开启，最终通过onActivityResult的形式回调通知是否开启成功。

  • 6.0及以上机型动态获取位置权限。
    蓝牙打开之后，进行扫描之前，需要判断下当前设备是否是6.0及以上，如果是，需要动态获取之前在Manifest中声明的位置权限。

  • 配置扫描规则
    扫描规则可以配置1个或多个，也可以不配置使用默认（扫描10秒）。扫描的时候，会根据配置的过滤选项，对扫描到的设备进行过滤，结果返回过滤后的设备。扫描时间配置为小于等于0，会实现无限扫描，直至调用BleManger.getInstance().cancelScan()来中止扫描。

      BleScanRuleConfig scanRuleConfig = new BleScanRuleConfig.Builder().setServiceUuids(serviceUuids)      // 只扫描指定的服务的设备，可选.setDeviceName(true, names)         // 只扫描指定广播名的设备，可选.setDeviceMac(mac)                  // 只扫描指定mac的设备，可选.setAutoConnect(isAutoConnect)      // 连接时的autoConnect参数，可选，默认false.setScanTimeOut(10000)              // 扫描超时时间，可选，默认10秒.build();BleManager.getInstance().initScanRule(scanRuleConfig);

    以上准备工作完成后，就可以开始进行扫描。

      BleManager.getInstance().scan(new BleScanCallback() {@Overridepublic void onScanStarted(boolean success) {}@Overridepublic void onLeScan(BleDevice bleDevice) {}@Overridepublic void onScanning(BleDevice bleDevice) {}@Overridepublic void onScanFinished(List<BleDevice> scanResultList) {}});

onScanStarted(boolean success): 会回到主线程，参数表示本次扫描动作是否开启成功。由于蓝牙没有打开，上一次扫描没有结束等原因，会造成扫描开启失败。
onLeScan(BleDevice bleDevice):扫描过程中所有被扫描到的结果回调。由于扫描及过滤的过程是在工作线程中的，此方法也处于工作线程中。同一个设备会在不同的时间，携带自身不同的状态（比如信号强度等），出现在这个回调方法中，出现次数取决于周围的设备量及外围设备的广播间隔。
onScanning(BleDevice bleDevice):扫描过程中的所有过滤后的结果回调。与onLeScan区别之处在于：它会回到主线程；同一个设备只会出现一次；出现的设备是经过扫描过滤规则过滤后的设备。
onScanFinished(List<BleDevice> scanResultList)：本次扫描时段内所有被扫描且过滤后的设备集合。它会回到主线程，相当于onScanning设备之和。

1.4. 设备信息

扫描得到的BLE外围设备，会以BleDevice对象的形式，作为后续操作的最小单元对象。它本身含有这些信息：
String getName()：蓝牙广播名
String getMac()：蓝牙Mac地址
byte[] getScanRecord()： 被扫描到时候携带的广播数据
int getRssi() ：被扫描到时候的信号强度
后续进行设备连接、断开、判断设备状态，读写操作等时候，都会用到这个对象。可以把它理解为外围蓝牙设备的载体，所有对外围蓝牙设备的操作，都通过这个对象来传导。

1.5. 连接、断连、监控连接状态

拿到设备对象之后，可以进行连接操作。

    BleManager.getInstance().connect(bleDevice, new BleGattCallback() {@Overridepublic void onStartConnect() {}@Overridepublic void onConnectFail(BleException exception) {}@Overridepublic void onConnectSuccess(BleDevice bleDevice, BluetoothGatt gatt, int status) {}@Overridepublic void onDisConnected(boolean isActiveDisConnected, BleDevice bleDevice, BluetoothGatt gatt, int status) {}});

onStartConnect()：开始进行连接。
onConnectFail(BleException exception)：连接不成功。
onConnectSuccess(BleDevice bleDevice, BluetoothGatt gatt, int status)：连接成功并发现服务。
onDisConnected(boolean isActiveDisConnected, BleDevice bleDevice, BluetoothGatt gatt, int status)：连接断开，特指连接后再断开的情况。在这里可以监控设备的连接状态，一旦连接断开，可以根据自身情况考虑对BleDevice对象进行重连操作。需要注意的是，断开和重连之间最好间隔一段时间，否则可能会出现长时间连接不上的情况。此外，如果通过调用disconnect(BleDevice bleDevice)方法，主动断开蓝牙连接的结果也会在这个方法中回调，此时isActiveDisConnected将会是true。

1.6. GATT协议

BLE连接都是建立在 GATT (Generic Attribute Profile) 协议之上。GATT 是一个在蓝牙连接之上的发送和接收很短的数据段的通用规范，这些很短的数据段被称为属性（Attribute）。它定义两个 BLE 设备通过Service 和 Characteristic 进行通信。GATT 就是使用了 ATT（Attribute Protocol）协议，ATT 协议把 Service, Characteristic以及对应的数据保存在一个查找表中，次查找表使用 16 bit ID 作为每一项的索引。

关于GATT这部分内容会在下面重点讲解。总之，中心设备和外设需要双向通信的话，唯一的方式就是建立 GATT 连接。当连接成功之后，外围设备与中心设备之间就建立起了GATT连接。
上面讲到的connect(BleDevice bleDevice, BleGattCallback bleGattCallback)方法其实是有返回值的，这个返回值就是BluetoothGatt。当然还有其他方式可以获取BluetoothGatt对象，连接成功后，调用：

BluetoothGatt gatt = BleManager.getInstance().getBluetoothGatt(BleDevice bleDevice)；

通过BluetoothGatt对象作为连接桥梁，中心设备可以获取外围设备的很多信息，以及双向通信。

首先，就可以获取这个蓝牙设备所拥有的Service和Characteristic。每一个属性都可以被定义作不同的用途，通过它们来进行协议通信。下面的方法，就是通过BluetoothGatt，查找出所有的Service和Characteristic的UUID：

    List<BluetoothGattService> serviceList = bluetoothGatt.getServices();for (BluetoothGattService service : serviceList) {UUID uuid_service = service.getUuid();List<BluetoothGattCharacteristic> characteristicList= service.getCharacteristics();for(BluetoothGattCharacteristic characteristic : characteristicList) {UUID uuid_chara = characteristic.getUuid();}}

1.7. 协议通信

APP与设备建立了连接，并且知道了Service和Characteristic（需要与硬件协议沟通确认）之后，我们就可以通过BLE协议进行通信了。通信的桥梁，主要就是是通过 标准的或者自定义的Characteristic，中文我们称之为“特征”。我们可以从 Characteristic 读数据和写数据。这样就实现了双向的通信。站在APP作为中心设备的角度，常用于数据交互的通信方式主要有3种：接收通知、写、读，此外还有设置最大传输单元，获取实时信号强度等通信操作。

  • 接收通知
    有两种方式可以接收通知，indicate和notify。indicate和notify的区别就在于，indicate是一定会收到数据，notify有可能会丢失数据。indicate底层封装了应答机制，如果没有收到中央设备的回应，会再次发送直至成功；而notify不会有central收到数据的回应，可能无法保证数据到达的准确性，优势是速度快。通常情况下，当外围设备需要不断地发送数据给APP的时候，比如血压计在测量过程中的压力变化，胎心仪在监护过程中的实时数据传输，这种频繁的情况下，优先考虑notify形式。当只需要发送很少且很重要的一条数据给APP的时候，优先考虑indicate形式。当然，从Android开发角度的出发，如果硬件放已经考虑了成熟的协议和发送方式，我们需要做的仅仅是根据其配置的数据发送方式进行相应的对接即可。
    打开notify

      BleManager.getInstance().notify(bleDevice,uuid_service,uuid_characteristic_notify,new BleNotifyCallback() {@Overridepublic void onNotifySuccess() {// 打开通知操作成功}@Overridepublic void onNotifyFailure(BleException exception) {// 打开通知操作失败}@Overridepublic void onCharacteristicChanged(byte[] data) {// 打开通知后，设备发过来的数据将在这里出现}});

    关闭notify

      BleManager.getInstance().stopNotify(uuid_service, uuid_characteristic_notify);

    打开indicate

      BleManager.getInstance().indicate(bleDevice,uuid_service,uuid_characteristic_indicate,new BleIndicateCallback() {@Overridepublic void onIndicateSuccess() {// 打开通知操作成功}@Overridepublic void onIndicateFailure(BleException exception) {// 打开通知操作失败}@Overridepublic void onCharacteristicChanged(byte[] data) {// 打开通知后，设备发过来的数据将在这里出现}});

    关闭indicate

      BleManager.getInstance().stopIndicate(uuid_service, uuid_characteristic_indicate);

    这里的通知操作用到了两个关键的参数，uuid_service和uuid_characteristic_notify（或uuid_characteristic_indicate），就是上面提到的Service和Characteristic，此处以字符串的形式体现，不区分大小写。

  • 读写

      BleManager.getInstance().read(bleDevice,uuid_service,uuid_characteristic_read,new BleReadCallback() {@Overridepublic void onReadSuccess(byte[] data) {// 读特征值数据成功}@Overridepublic void onReadFailure(BleException exception) {// 读特征值数据失败}});BleManager.getInstance().write(bleDevice,uuid_service,uuid_characteristic_write,data,new BleWriteCallback() {@Overridepublic void onWriteSuccess(int current, int total, byte[] justWrite) {// 发送数据到设备成功（分包发送的情况下，可以通过方法中返回的参数可以查看发送进度）}@Overridepublic void onWriteFailure(BleException exception) {// 发送数据到设备失败}});

    进行BLE数据相互发送的时候，一次最多能发送20个字节。如果需要发送的数据超过20个字节，有两种方法，一种是主动尝试拓宽MTU，另一种是采用分包传输的方式。框架中的write方法，当遇到数据超过20字节的情况时，默认是进行分包发送的。

  • 设置最大传输单元MTU

      BleManager.getInstance().setMtu(bleDevice, mtu, new BleMtuChangedCallback() {@Overridepublic void onSetMTUFailure(BleException exception) {// 设置MTU失败}@Overridepublic void onMtuChanged(int mtu) {// 设置MTU成功，并获得当前设备传输支持的MTU值}});

  • 获取设备的实时信号强度Rssi

      BleManager.getInstance().readRssi(bleDevice,new BleRssiCallback() {@Overridepublic void onRssiFailure(BleException exception) {// 读取设备的信号强度失败}@Overridepublic void onRssiSuccess(int rssi) {// 读取设备的信号强度成功}});

在BLE设备通信过程中，有几点经验分享给大家：

  • 两次操作之间最好间隔一小段时间，如100ms（具体时间可以根据自己实际蓝牙外设自行尝试延长或缩短）。举例，onConnectSuccess之后，延迟100ms再进行notify，之后再延迟100ms进行write。
  • 连接及连接后的过程中，时刻关注onDisConnected方法，然后做处理。
  • 断开后如果需要重连，也请延迟一段时间，否则会造成阻塞。

2. BLE开发实践方面的理解

在分解FastBle源码之前，我首先介绍一下BLE通信一些理论知识。

2.1 蓝牙简介

蓝牙是一种近距离无线通信技术。它的特性就是近距离通信，典型距离是 10 米以内，传输速度最高可达 24 Mbps，支持多连接，安全性高，非常适合用智能设备上。

2.2 蓝牙技术的版本演进

  • 1999年发布1.0版本，目前市面上已很少见到；
  • 2002年发布1.1版本，目前市面上已很少见到；
  • 2004年发布2.0版本，目前市面上已很少见到；
  • 2007年发布的2.1版本，是之前使用最广的，也是我们所谓的经典蓝牙。
  • 2009年推出蓝牙 3.0版本，也就是所谓的高速蓝牙，传输速率理论上可高达24 Mbit/s；
  • 2010年推出蓝牙4.0版本，它是相对之前版本的集大成者，它包括经典蓝牙、高速蓝牙和蓝牙低功耗协议。经典蓝牙包括旧有蓝牙协议，高速蓝牙基于Wi-Fi，低功耗蓝牙就是BLE。
  • 2016年蓝牙技术联盟提出了新的蓝牙技术标准，即蓝牙5.0版本。蓝牙5.0针对低功耗设备速度有相应提升和优化，结合wifi对室内位置进行辅助定位，提高传输速度，增加有效工作距离，主要是针对物联网方向的改进。

2.3 Android上BLE功能的逐步演进

在Android开发过程中，版本的碎片化一直是需要考虑的问题，再加上厂商定制及蓝牙本身也和Android一样一直在发展过程中，所以对于每一个版本支持什么功能，是我们需要知道的。

  • Android 4.3 开始，开始支持BLE功能，但只支持Central Mode（中心模式）
  • Android 5.0开始，开始支持Peripheral Mode（外设模式）

中心模式和外设模式是什么意思？

  • Central Mode： Android端作为中心设备，连接其他外围设备。
  • Peripheral Mode：Android端作为外围设备，被其他中心设备连接。在Android 5.0支持外设模式之后，才算实现了两台Android手机通过BLE进行相互通信。

2.4 蓝牙的广播和扫描

以下内容部分参考自BLE Introduction 。
关于这部分内容，需要引入一个概念，GAP（Generic Access Profile），它用来控制设备连接和广播。GAP 使你的设备被其他设备可见，并决定了你的设备是否可以或者怎样与设备进行交互。例如 Beacon 设备就只是向外发送广播，不支持连接；小米手环就可以与中心设备建立连接。

在 GAP 中蓝牙设备可以向外广播数据包，广播包分为两部分： Advertising Data Payload（广播数据）和 Scan Response Data Payload（扫描回复），每种数据最长可以包含 31 byte。这里广播数据是必需的，因为外设必需不停的向外广播，让中心设备知道它的存在。扫描回复是可选的，中心设备可以向外设请求扫描回复，这里包含一些设备额外的信息，例如设备的名字。在 Android 中，系统会把这两个数据拼接在一起，返回一个 62 字节的数组。这些广播数据可以自己手动去解析，在 Android 5.0 也提供 ScanRecord 帮你解析，直接可以通过这个类获得有意义的数据。广播中可以有哪些数据类型呢？设备连接属性，标识设备支持的 BLE 模式，这个是必须的。设备名字，设备包含的关键 GATT service，或者 Service data，厂商自定义数据等等。

广播流程

外围设备会设定一个广播间隔，每个广播间隔中，它会重新发送自己的广播数据。广播间隔越长，越省电，同时也不太容易扫描到。

刚刚讲到，GAP决定了你的设备怎样与其他设备进行交互。答案是有2种方式：

  • 完全基于广播的方式
    也有些情况是不需要连接的，只要外设广播自己的数据即可。用这种方式主要目的是让外围设备，把自己的信息发送给多个中心设备。使用广播这种方式最典型的应用就是苹果的 iBeacon。这是苹果公司定义的基于 BLE 广播实现的功能，可以实现广告推送和室内定位。这也说明了，APP 使用 BLE，需要定位权限。

    基于非连接的，这种应用就是依赖 BLE 的广播，也叫作 Beacon。这里有两个角色，发送广播的一方叫做 Broadcaster，监听广播的一方叫 Observer。

  • 基于GATT连接的方式
    大部分情况下，外设通过广播自己来让中心设备发现自己，并建立 GATT 连接，从而进行更多的数据交换。这里有且仅有两个角色，发起连接的一方，叫做中心设备—Central，被连接的设备，叫做外设—Peripheral。

    • 外围设备：这一般就是非常小或者简单的低功耗设备，用来提供数据，并连接到一个更加相对强大的中心设备，例如小米手环。
    • 中心设备：中心设备相对比较强大，用来连接其他外围设备，例如手机等。

    GATT 连接需要特别注意的是：GATT 连接是独占的。也就是一个 BLE 外设同时只能被一个中心设备连接。一旦外设被连接，它就会马上停止广播，这样它就对其他设备不可见了。当设备断开，它又开始广播。中心设备和外设需要双向通信的话，唯一的方式就是建立 GATT 连接。

    GATT 通信的双方是 C/S 关系。外设作为 GATT 服务端（Server），它维持了 ATT 的查找表以及 service 和 characteristic 的定义。中心设备是 GATT 客户端（Client），它向 Server 发起请求。需要注意的是，所有的通信事件，都是由客户端发起，并且接收服务端的响应。

2.5 BLE通信基础

BLE通信的基础有两个重要的概念，ATT和GATT。

  • ATT
    全称 attribute protocol，中文名“属性协议”。它是 BLE 通信的基础。ATT 把数据封装，向外暴露为“属性”，提供“属性”的为服务端，获取“属性”的为客户端。ATT 是专门为低功耗蓝牙设计的，结构非常简单，数据长度很短。

  • GATT
    全称 Generic Attribute Profile， 中文名“通用属性配置文件”。它是在ATT 的基础上，对 ATT 进行的进一步逻辑封装，定义数据的交互方式和含义。GATT是我们做 BLE 开发的时候直接接触的概念。

  • GATT 层级
    GATT按照层级定义了4个概念：配置文件（Profile）、服务（Service）、特征（Characteristic）和描述（Descriptor）。他们的关系是这样的：Profile 就是定义了一个实际的应用场景，一个 Profile包含若干个 Service，一个 Service 包含若干个 Characteristic，一个 Characteristic 可以包含若干 Descriptor。

    GATT层级

  • Profile
    Profile 并不是实际存在于 BLE 外设上的，它只是一个被 Bluetooth SIG 或者外设设计者预先定义的 Service 的集合。例如心率Profile（Heart Rate Profile）就是结合了 Heart Rate Service 和 Device Information Service。所有官方通过 GATT Profile 的列表可以从这里找到。

  • Service
    Service 是把数据分成一个个的独立逻辑项，它包含一个或者多个 Characteristic。每个 Service 有一个 UUID 唯一标识。 UUID 有 16 bit 的，或者 128 bit 的。16 bit 的 UUID 是官方通过认证的，需要花钱购买，128 bit 是自定义的，这个就可以自己随便设置。官方通过了一些标准 Service，完整列表在这里。以 Heart Rate Service为例，可以看到它的官方通过 16 bit UUID 是 0x180D，包含 3 个 Characteristic：Heart Rate Measurement, Body Sensor Location 和 Heart Rate Control Point，并且定义了只有第一个是必须的，它是可选实现的。

  • Characteristic
    需要重点提一下Characteristic， 它定义了数值和操作，包含一个Characteristic声明、Characteristic属性、值、值的描述(Optional)。通常我们讲的 BLE 通信，其实就是对 Characteristic 的读写或者订阅通知。比如在实际操作过程中，我对某一个Characteristic进行读，就是获取这个Characteristic的value。

  • UUID
    Service、Characteristic 和 Descriptor 都是使用 UUID 唯一标示的。

    UUID 是全局唯一标识，它是 128bit 的值，为了便于识别和阅读，一般以 “8位-4位-4位-4位-12位”的16进制标示，比如“12345678-abcd-1000-8000-123456000000”。

    但是，128bit的UUID 太长，考虑到在低功耗蓝牙中，数据长度非常受限的情况，蓝牙又使用了所谓的 16 bit 或者 32 bit 的 UUID，形式如下：“0000XXXX-0000-1000-8000-00805F9B34FB”。除了 “XXXX” 那几位以外，其他都是固定，所以说，其实 16 bit UUID 是对应了一个 128 bit 的 UUID。这样一来，UUID 就大幅减少了，例如 16 bit UUID只有有限的 65536（16的四次方） 个。与此同时，因为数量有限，所以 16 bit UUID 并不能随便使用。蓝牙技术联盟已经预先定义了一些 UUID，我们可以直接使用，比如“00001011-0000-1000-8000-00805F9B34FB”就一个是常见于BLE设备中的UUID。当然也可以花钱定制自定义的UUID。

3. FastBle源码解析

通过上面BLE的基础理论，我们可以分析到，BLE通信实际上就是先由客户端发起与服务端的连接，再通过服务端的找到其Characteristic进行两者间的数据交互。

在FastBle源码中，首先看BleManager中的connect()方法：

public BluetoothGatt connect(BleDevice bleDevice, BleGattCallback bleGattCallback) {if (bleGattCallback == null) {throw new IllegalArgumentException("BleGattCallback can not be Null!");}if (!isBlueEnable()) {BleLog.e("Bluetooth not enable!");bleGattCallback.onConnectFail(new OtherException("Bluetooth not enable!"));return null;}if (Looper.myLooper() == null || Looper.myLooper() != Looper.getMainLooper()) {BleLog.w("Be careful: currentThread is not MainThread!");}if (bleDevice == null || bleDevice.getDevice() == null) {bleGattCallback.onConnectFail(new OtherException("Not Found Device Exception Occurred!"));} else {BleBluetooth bleBluetooth = new BleBluetooth(bleDevice);boolean autoConnect = bleScanRuleConfig.isAutoConnect();return bleBluetooth.connect(bleDevice, autoConnect, bleGattCallback);}return null;
}

这个方法将扫描到的外围设备对象传入，通过一些必要的条件判断之后，调用bleBluetooth.connect()进行连接。我们去看一下BleBluetooth这个类：

public BleBluetooth(BleDevice bleDevice) {this.bleDevice = bleDevice;
}

上面的BleBluetooth的构造方法是传入一个蓝牙设备对象。由此可见，一个BleBluetooth可能代表你的Android与这一个外围设备整个交互过程，从开始连接，到中间数据交互，一直到断开连接的整个过程。在多连接情况下，有多少外围设备，设备池中就维护着多少个BleBluetooth对象。

MultipleBluetoothController就是控制多设备连接的。它里面有增加和移除设备的方法，如下图的addBleBluetooth和removeBleBluetooth，传入的参数就是BleBluetooth对象，验证了上面的说法。

public synchronized void addBleBluetooth(BleBluetooth bleBluetooth) {if (bleBluetooth == null) {return;}if (!bleLruHashMap.containsKey(bleBluetooth.getDeviceKey())) {bleLruHashMap.put(bleBluetooth.getDeviceKey(), bleBluetooth);}
}public synchronized void removeBleBluetooth(BleBluetooth bleBluetooth) {if (bleBluetooth == null) {return;}if (bleLruHashMap.containsKey(bleBluetooth.getDeviceKey())) {bleLruHashMap.remove(bleBluetooth.getDeviceKey());}
}

回到BleBlutooth的connect方法：

public synchronized BluetoothGatt connect(BleDevice bleDevice,boolean autoConnect,BleGattCallback callback) {addConnectGattCallback(callback);isMainThread = Looper.myLooper() != null && Looper.myLooper() == Looper.getMainLooper();BluetoothGatt gatt;if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {gatt = bleDevice.getDevice().connectGatt(BleManager.getInstance().getContext(),autoConnect, coreGattCallback, TRANSPORT_LE);} else {gatt = bleDevice.getDevice().connectGatt(BleManager.getInstance().getContext(),autoConnect, coreGattCallback);}if (gatt != null) {if (bleGattCallback != null)bleGattCallback.onStartConnect();connectState = BleConnectState.CONNECT_CONNECTING;}return gatt;
}

可见，最终也是调用了原生API中的BluetoothDevice的connectGatt()方法。在蓝牙原理分析中讲到，连接过程中要创建一个BluetoothGattCallback，用来作为回调，这个类非常重要，所有的 GATT 操作的回调都在这里。而此处的coreGattCallback应该就扮演着这个角色，它是BluetoothGattCallback的实现类对象，对操作回调结果做了封装和分发。

private BluetoothGattCallback coreGattCallback = new BluetoothGattCallback() {@Overridepublic void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {super.onConnectionStateChange(gatt, status, newState);if (newState == BluetoothGatt.STATE_CONNECTED) {gatt.discoverServices();} else if (newState == BluetoothGatt.STATE_DISCONNECTED) {closeBluetoothGatt();BleManager.getInstance().getMultipleBluetoothController().removeBleBluetooth(BleBluetooth.this);if (connectState == BleConnectState.CONNECT_CONNECTING) {connectState = BleConnectState.CONNECT_FAILURE;if (isMainThread) {Message message = handler.obtainMessage();message.what = BleMsg.MSG_CONNECT_FAIL;message.obj = new BleConnectStateParameter(bleGattCallback, gatt, status);handler.sendMessage(message);} else {if (bleGattCallback != null)bleGattCallback.onConnectFail(new ConnectException(gatt, status));}} else if (connectState == BleConnectState.CONNECT_CONNECTED) {connectState = BleConnectState.CONNECT_DISCONNECT;if (isMainThread) {Message message = handler.obtainMessage();message.what = BleMsg.MSG_DISCONNECTED;BleConnectStateParameter para = new BleConnectStateParameter(bleGattCallback, gatt, status);para.setAcitive(isActiveDisconnect);para.setBleDevice(getDevice());message.obj = para;handler.sendMessage(message);} else {if (bleGattCallback != null)bleGattCallback.onDisConnected(isActiveDisconnect, bleDevice, gatt, status);}}}}@Overridepublic void onServicesDiscovered(BluetoothGatt gatt, int status) {super.onServicesDiscovered(gatt, status);BleLog.i("BluetoothGattCallback：onServicesDiscovered "+ '\n' + "status: " + status+ '\n' + "currentThread: " + Thread.currentThread().getId());if (status == BluetoothGatt.GATT_SUCCESS) {bluetoothGatt = gatt;connectState = BleConnectState.CONNECT_CONNECTED;isActiveDisconnect = false;BleManager.getInstance().getMultipleBluetoothController().addBleBluetooth(BleBluetooth.this);if (isMainThread) {Message message = handler.obtainMessage();message.what = BleMsg.MSG_CONNECT_SUCCESS;BleConnectStateParameter para = new BleConnectStateParameter(bleGattCallback, gatt, status);para.setBleDevice(getDevice());message.obj = para;handler.sendMessage(message);} else {if (bleGattCallback != null)bleGattCallback.onConnectSuccess(getDevice(), gatt, status);}} else {closeBluetoothGatt();connectState = BleConnectState.CONNECT_FAILURE;if (isMainThread) {Message message = handler.obtainMessage();message.what = BleMsg.MSG_CONNECT_FAIL;message.obj = new BleConnectStateParameter(bleGattCallback, gatt, status);handler.sendMessage(message);} else {if (bleGattCallback != null)bleGattCallback.onConnectFail(new ConnectException(gatt, status));}}}@Overridepublic void onCharacteristicChanged(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic) {super.onCharacteristicChanged(gatt, characteristic);Iterator iterator = bleNotifyCallbackHashMap.entrySet().iterator();while (iterator.hasNext()) {Map.Entry entry = (Map.Entry) iterator.next();Object callback = entry.getValue();if (callback instanceof BleNotifyCallback) {BleNotifyCallback bleNotifyCallback = (BleNotifyCallback) callback;if (characteristic.getUuid().toString().equalsIgnoreCase(bleNotifyCallback.getKey())) {Handler handler = bleNotifyCallback.getHandler();if (handler != null) {Message message = handler.obtainMessage();message.what = BleMsg.MSG_CHA_NOTIFY_DATA_CHANGE;message.obj = bleNotifyCallback;Bundle bundle = new Bundle();bundle.putByteArray(BleMsg.KEY_NOTIFY_BUNDLE_VALUE, characteristic.getValue());message.setData(bundle);handler.sendMessage(message);}}}}iterator = bleIndicateCallbackHashMap.entrySet().iterator();while (iterator.hasNext()) {Map.Entry entry = (Map.Entry) iterator.next();Object callback = entry.getValue();if (callback instanceof BleIndicateCallback) {BleIndicateCallback bleIndicateCallback = (BleIndicateCallback) callback;if (characteristic.getUuid().toString().equalsIgnoreCase(bleIndicateCallback.getKey())) {Handler handler = bleIndicateCallback.getHandler();if (handler != null) {Message message = handler.obtainMessage();message.what = BleMsg.MSG_CHA_INDICATE_DATA_CHANGE;message.obj = bleIndicateCallback;Bundle bundle = new Bundle();bundle.putByteArray(BleMsg.KEY_INDICATE_BUNDLE_VALUE, characteristic.getValue());message.setData(bundle);handler.sendMessage(message);}}}}}@Overridepublic void onDescriptorWrite(BluetoothGatt gatt, BluetoothGattDescriptor descriptor, int status) {super.onDescriptorWrite(gatt, descriptor, status);Iterator iterator = bleNotifyCallbackHashMap.entrySet().iterator();while (iterator.hasNext()) {Map.Entry entry = (Map.Entry) iterator.next();Object callback = entry.getValue();if (callback instanceof BleNotifyCallback) {BleNotifyCallback bleNotifyCallback = (BleNotifyCallback) callback;if (descriptor.getCharacteristic().getUuid().toString().equalsIgnoreCase(bleNotifyCallback.getKey())) {Handler handler = bleNotifyCallback.getHandler();if (handler != null) {Message message = handler.obtainMessage();message.what = BleMsg.MSG_CHA_NOTIFY_RESULT;message.obj = bleNotifyCallback;Bundle bundle = new Bundle();bundle.putInt(BleMsg.KEY_NOTIFY_BUNDLE_STATUS, status);message.setData(bundle);handler.sendMessage(message);}}}}iterator = bleIndicateCallbackHashMap.entrySet().iterator();while (iterator.hasNext()) {Map.Entry entry = (Map.Entry) iterator.next();Object callback = entry.getValue();if (callback instanceof BleIndicateCallback) {BleIndicateCallback bleIndicateCallback = (BleIndicateCallback) callback;if (descriptor.getCharacteristic().getUuid().toString().equalsIgnoreCase(bleIndicateCallback.getKey())) {Handler handler = bleIndicateCallback.getHandler();if (handler != null) {Message message = handler.obtainMessage();message.what = BleMsg.MSG_CHA_INDICATE_RESULT;message.obj = bleIndicateCallback;Bundle bundle = new Bundle();bundle.putInt(BleMsg.KEY_INDICATE_BUNDLE_STATUS, status);message.setData(bundle);handler.sendMessage(message);}}}}}@Overridepublic void onCharacteristicWrite(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic, int status) {super.onCharacteristicWrite(gatt, characteristic, status);Iterator iterator = bleWriteCallbackHashMap.entrySet().iterator();while (iterator.hasNext()) {Map.Entry entry = (Map.Entry) iterator.next();Object callback = entry.getValue();if (callback instanceof BleWriteCallback) {BleWriteCallback bleWriteCallback = (BleWriteCallback) callback;if (characteristic.getUuid().toString().equalsIgnoreCase(bleWriteCallback.getKey())) {Handler handler = bleWriteCallback.getHandler();if (handler != null) {Message message = handler.obtainMessage();message.what = BleMsg.MSG_CHA_WRITE_RESULT;message.obj = bleWriteCallback;Bundle bundle = new Bundle();bundle.putInt(BleMsg.KEY_WRITE_BUNDLE_STATUS, status);bundle.putByteArray(BleMsg.KEY_WRITE_BUNDLE_VALUE, characteristic.getValue());message.setData(bundle);handler.sendMessage(message);}}}}}@Overridepublic void onCharacteristicRead(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic, int status) {super.onCharacteristicRead(gatt, characteristic, status);Iterator iterator = bleReadCallbackHashMap.entrySet().iterator();while (iterator.hasNext()) {Map.Entry entry = (Map.Entry) iterator.next();Object callback = entry.getValue();if (callback instanceof BleReadCallback) {BleReadCallback bleReadCallback = (BleReadCallback) callback;if (characteristic.getUuid().toString().equalsIgnoreCase(bleReadCallback.getKey())) {Handler handler = bleReadCallback.getHandler();if (handler != null) {Message message = handler.obtainMessage();message.what = BleMsg.MSG_CHA_READ_RESULT;message.obj = bleReadCallback;Bundle bundle = new Bundle();bundle.putInt(BleMsg.KEY_READ_BUNDLE_STATUS, status);bundle.putByteArray(BleMsg.KEY_READ_BUNDLE_VALUE, characteristic.getValue());message.setData(bundle);handler.sendMessage(message);}}}}}
};

在收到连接状态、读、写、通知等操作的结果回调之后，通过消息队列机制，交由相应的Handler去处理。那处理消息的Handler在哪里？举例其中的write操作Handler handler = bleWriteCallback.getHandler();，handler对象被包含在了这个write操作的callback中。

public abstract class BleBaseCallback {private String key;private Handler handler;public String getKey() {return key;}public void setKey(String key) {this.key = key;}public Handler getHandler() {return handler;}public void setHandler(Handler handler) {this.handler = handler;}
}

所有的操作的callback都继承自这个BleBaseCallback抽象类，它有两个成员变量。一个key，标识着这个callback归属于哪一个Characteristic的操作；另一个handler，用于传递底层发来的操作结果，最终将结果交由callback去抛给调用者，完成一次接口回调。

private void handleCharacteristicWriteCallback(BleWriteCallback bleWriteCallback,String uuid_write) {if (bleWriteCallback != null) {writeMsgInit();bleWriteCallback.setKey(uuid_write);bleWriteCallback.setHandler(mHandler);mBleBluetooth.addWriteCallback(uuid_write, bleWriteCallback);mHandler.sendMessageDelayed(mHandler.obtainMessage(BleMsg.MSG_CHA_WRITE_START, bleWriteCallback),BleManager.getInstance().getOperateTimeout());}
}

上面这段源码解释了这个机制，每一次write操作之后，都会对传入的callback进行唯一性标记，再通过handler用来传递操作结果，同时将这个callback加入这个设备的BleBlutooth对象的callback池中管理。
这样就形成了APP维持一个设备连接池，一个设备连接池管理多个设备管理者，一个设备管理者管理多个不同类别的callback集合，一个callback集合中含有多个同类的不同特征的callback。

架构图

Android BLE(3) ---FastBle解析相关推荐

  1. android手机上的ancs,Android BLE开发之操作IOS ANCS

    前言 之前写过两篇有关于ANCS的文章,最近一段时间老是有人问关于得到ANCS服务的问题,因为IOS ANCS不同于其他的Peripheral一样对周边所有的蓝牙设备广播自己,而是仅有连接上配对并连接 ...

  2. Android BLE学习（一）： Android搜索BLE设备

    http://my.csdn.net/lidec 背景 总结一下最近ble的学习情况.自从入手ble 51822开发板后就开始不停加班,中途出于好奇,业余时间写了一些单片机上json解析相关的东西,妄 ...

  3. 快速接入 Android BLE 开发的基础框架

    代码地址如下: http://www.demodashi.com/demo/12092.html * Android BLE基础操作框架,基于回调,操作简单.包含扫描.多连接.广播包解析.服务读写及通 ...

  4. Android BLE(1)---蓝牙通讯学习

    Android BLE蓝牙通讯学习 在app应用的开发过程中,一般和蓝牙接触的不多,但是随着智能穿戴设备的发展,穿戴设备和手机关联的app越来越多,之前也是没怎么接触过这一块的东西,正好最近需要做一个 ...

  5. Android 系统（252）---Android:BLE智能硬件开发详解

    Android:BLE智能硬件开发详解 目录 前言 BLE是个什么鬼 BLE中的角色分工 主要的关键词和概念  GATT(Generic Attribute Profile ) Characteris ...

  6. Android BLE新手进入

    我们提到了中央设备(central)和外围设备(peripheral),在这里我们可以这样简单的理解: 中央设备(central): 收到外围设备发出的广播信号后能主动发起连接的主设备, 例如我们给摩 ...

  7. Android BLE的总结-概念篇

    Android BLE的总结 其实BLE是个通用的技术术语,与平台无关的,即ios和Android以及一些嵌入式系统或单片机都可以有BLE模块.在进行Android BLE相关的应用开发前,我们有必要 ...

  8. Android ble连接过程,Android BLE的一些基础知识及相关操作流程 - 全文

    前言: 本文主要描述Android BLE的一些基础知识及相关操作流程,不牵扯具体的业务实现,其中提供了针对广播包及响应包的解析思路,希望对正在或即将面临Android BLE开发的伙伴们有所引导. ...

  9. Android BLE设备蓝牙通信框架BluetoothKit

    BluetoothKit是一款功能强大的Android蓝牙通信框架,支持低功耗蓝牙设备的连接通信.蓝牙广播扫描及Beacon解析. 关于该项目的详细文档请关注:https://github.com/d ...

最新文章

  1. 【 数字信号处理 】定点数的表示之定点数的字长问题
  2. Linux 配置多个Tomcat
  3. 4. 寻找两个有序数组的中位数
  4. MySql的连接查询
  5. 14.vue路由脚手架
  6. freemarker小例子
  7. 强大的独立日期选择器(date picker)插件 - Kalendae
  8. 找出二维数组中每行的最小数但最小数的列不能相同
  9. Golang并发（五） - Select
  10. Android 12 将支持游戏“边下边玩”
  11. 一个基于区块链的AI平台即将ICO：这可以说是今年最潮的项目了
  12. node.js之第一天
  13. nim3取石子游戏 (威佐夫博弈)
  14. BootStrap的基本使用
  15. Windows Phone开发（37）：动画之ColorAnimation 转：http://blog.csdn.net/tcjiaan/article/details/7526026...
  16. android水波纹动画制作,flash动画制作实例：横向水波纹效果
  17. LPDDR4 与 DDR4 与 LPDDR4x 内存：有何不同？
  18. Result类的写法
  19. 正确使用pageX、pageY、offsetLeft、offsetTop
  20. 1.Spring入门

热门文章

  1. Keil综合（02）工程窗口各项图标描述
  2. Linux并发与竞争
  3. (3)散列函数设计：直接定址法
  4. linux input输入子系统分析《四》：input子系统整体流程全面分析
  5. mysql中的各种函数（日期函数、字符串函数、数学函数...）
  6. django 跳转其他网站_Django 实战 | 搭一个 GitHub 用户展示网站 04
  7. 【Java数据结构与算法】第十七章 二分查找（非递归）和分治算法（汉诺塔）
  8. 力扣报错“AddressSanitizer: heap-buffer-overflow on address...”的解决办法
  9. finalize()方法什么时候被调用？析构函数(finalization)的目的是什么？
  10. python常用模块之time和datetime