nimble 蓝牙开发三：nimble BLE 应用介绍
- BLE 应用类型
- 未连接状态
- - 未连接状态下的 BLE 设备应用
  - 未连接状态的手机
- 连接状态
- - 连接状态下的 BLE 设备
  - 连接状态下的手机
- 蓝牙应用的实现
- GAP 应用
- - Boardcaster
  - Observer
  - Peripheral
  - Central
- GATT 应用
- - GATT 服务器
  - - GATT 服务器产生的事件
  - GATT 客户端
  - - GATT 客户端需要处理的 GAP 事件

nimble 蓝牙开发三：nimble BLE 应用介绍

BLE 应用类型

BLE 应用可以分为两类：

未连接状态下的广播 GAP 应用；
连接状态下的 GATT 应用。

未连接状态

未连接状态下的蓝牙应用使用广播进行数据交换，比如下图的手机 - 蓝牙扫描场景，使用手机可扫描到多个蓝牙设备：

未连接状态下的 BLE 设备应用

此时的 BLE 设备用于发送广播，接收扫描请求，再发送扫描响应，其数据流程逻辑图如下：

从上图中我们可以看到，Ble 设备通过广播和扫描响应与其他设备进行数据通信。

那么我们需要设置：

Boardcast 的广播数据；
扫描响应数据；
设置广播参数；
启动广播 GAP 流程。

未连接状态的手机

此时的手机用于扫描广播，发送扫描请求，再接收扫描响应，其数据流程逻辑图如下：
根据上图，我们可以需要设置：

扫描窗口等扫描参数；
启动扫描；
在广播报告 GAP 事件中解析广播数据。

连接状态

连接状态下的手机 - BLE 应用进行点对点通信：

BLE 设备做为 GATT 服务器，手机做为 GATT 客户端。

连接状态下的 BLE 设备

此时 BLE 设备定义了 GATT 服务与特征供手机访问，其流程逻辑图如下：

从上图可以得出：

BLE 设备首先执行 GAP 广播流程；
BLE 设备接收连接请求；进入连接状态；
BLE 设备做为 GATT 服务器，手机做为 GATT 客户端，手机使用 GATT 流程来查找 BLE 设备定义的服务、特征，并读 / 写特征值属性和特征描述符属性；

连接状态下的手机

链接状态下，手机做为 GATT 客户端, 使用 GATT 功能来来查找 BLE 设备定义的服务、特征，并读 / 写特征值属性和特征描述符属性；

其流程逻辑图如下：

从上图可以看出：

手机首先执行发现(扫描)流程，查找想要连接的 BLE 设备；
手机执行连接流程，发送连接请求，与指定的 BLE 设备建立连接；
进入连接状态后，手机使用 GATT 功能来访问 BLE 设备。

蓝牙应用的实现

上述的未连接状态下的蓝牙应用，和连接状态下的蓝牙应用是综合的、抽象的总述。

为了实现上述的蓝牙应用，BLE 规范都存在相对应的、标准的流程和角色，具体见下文。

GAP 应用

GAP 应用根据设备行为的不同分为 4 种角色：

角色	行为
Boardcaster	发送不可链接广播的蓝牙设备
Observer	接收不可链接广播的蓝牙设备
Peripheral	发送可连接广播的蓝牙设备，并可以建立点对点连接
Central	接收可连接广播，向可连接设备发送连接请求，建立点对点连接

GAP 角色的实际应用如下：

Boardcaster

Boardcaster 就是只发送广播的 BLE 设备，且该设备不可连接。

广播数据流程逻辑图如下：

从上图中我们可以看到，Boardcast 通过广播和扫描响应与其他设备进行数据通信。

那么我们需要设置：

Boardcast 的广播数据；
扫描响应数据；
设置广播参数；
启动广播 GAP 流程。

API 执行流程图如下：

Observer

Observer 接收不可连接广播，并可以选择发送扫描响应给广播设备。

Observer 的流程逻辑图如下：

根据上图，我们可以需要设置：

扫描窗口等扫描参数；
启动扫描；
在广播报告 GAP 事件中解析广播数据。

API 流程图：

Peripheral

Peripheral 用于发送可连接广播，并可建立连接。
流程逻辑图如下：

从上图中，我们可以得知，Peripheral 与 Boardcaster 相比，Peripheral 发送可连接广、可以接收连接请求并建立连接。

那么，我们需要发送可连接广播，其 API 执行流程与 Boardcaster API 执行流程一致：

Central

Central 用于扫描广播，并向可连接设备发送连接请求，然后进入连接状态。

其流程逻辑图如下：

根据上图，实现 Central 需要两个流程：

扫描流程，发现想要连接的可连接设备；
建立连接流程，与指定的可连接设备建立连接（指定对端地址）。

API 执行流程如下：

GATT 应用

GATT 应用按角色可分为：

GATT 角色对应的实际应用如下：

从上图可知，GATT 必须从广播状态过渡到连接状态。在手机 - BLE 设备的应用场景中：

BLE 设备首先做为 Peripheral 等待建立连接；
手机做为 Central 与指定的 BLE 设备建立连接；
BLE 设备做为 GATT 服务器，定义了服务与特征供手机访问；
手机使用 GATT 功能与流程，来访问 GATT 服务器上定义的服务与特征实现数据同通信。

GATT 服务器

GATT 服务器数据交换逻辑图如下：

GATT 服务器与 Peripheral 的数据交换逻辑是一样的

API 执行流程如下：

GATT 服务器产生的事件

可能产生的广播流程完成事件；
连接产生的连接完成事件；
各种原因导致的连接断开事件；
由自己启动的连接参数更新事件；
由 GATT 客户端访问 CCCD 产生的订阅事件；
由 GATT 的 MTU 交换功能产生的 MTU 事件；
其他的事件，不是很常用，就不例举了。

GATT 客户端

GATT 客户端数据交换逻辑图如下：

GATT 客户端的数据交换逻辑与 Central 数据交换逻辑是一致的。

API 执行流程如下：

GATT 客户端需要处理的 GAP 事件

对比 Central, GAP 客户端需要处理更多的事件，如下：

扫描广告期间的广告报告事件，查找想要连接的 BLE 设备，并启动连接；
连接事件，连接成功后，启动 GATT 服务发现功能；
接收 GATT 服务器发送的 notification / indication 事件，如果 GATT 客户端写 CCCD 属性的 notify / indicate 位为 1，那么可能会收到属性的 notification / indication，并触发该事件；
MTU 交换事件，如果 GATT 启动了 MTU 交换流程，则会产生该事件；
其他事件。