BLE GATT协议详解：从基础概念到开发实践

1. GATT 基础概念与设计哲学

在蓝牙低功耗（BLE）技术体系中，GATT（Generic Attribute Profile）扮演着数据通信"交通规则"的角色。它定义了设备间如何组织、发现和交换数据，是整个BLE应用开发的基石。理解GATT不仅需要掌握其技术规范，更要领会其背后的设计哲学。

1.1 从通信困境到标准化方案

在没有GATT的世界里，BLE设备间的通信就像两个没有共同语言的人尝试对话：

• 设备A发送0xA1B2表示"请求温度"
• 设备B回复0x1E表示"当前30℃"
  这种硬编码的通信方式存在明显缺陷：

1. 互操作性差：每个设备厂商需要自定义协议，APP必须针对不同设备单独适配
2. 扩展性弱：新增功能需要修改通信协议，可能导致版本兼容问题
3. 开发效率低：开发者需要重复实现基础通信逻辑

GATT通过三层抽象解决了这些问题：

1. 服务（Service）：将设备功能模块化（如心率监测、电池电量）
2. 特征值（Characteristic）：定义具体数据点（如当前心率值）
3. 描述符（Descriptor）：提供数据控制参数（如通知开关）

1.2 GATT与ATT的协同关系

GATT构建在ATT（Attribute Protocol）协议之上，两者关系如下表所示：

ATT协议为GATT提供了四个基础操作原语：

1. 读请求/响应：客户端读取服务器属性值
2. 写请求/响应：客户端修改服务器属性值
3. 通知：服务器主动推送数据（无需确认）
4. 指示：服务器主动推送数据（需客户端确认）

GATT则在ATT基础上定义了：

• 标准化的服务/特征值UUID
• 预定义的特征值属性
• 标准化的描述符（如CCCD）
• 发现流程规范

这种分层设计使得：

• ATT保持轻量级，适合低功耗设备
• GATT提供丰富的语义，满足复杂应用需求

2. GATT 数据模型深度解析

2.1 服务层设计原理

服务是GATT数据库的最高层抽象，其设计遵循以下原则：

服务声明结构

cpp复制// 典型服务声明示例
typedef struct {
    uint16_t start_handle;  // 服务起始句柄
    uint16_t end_handle;    // 服务结束句柄
    uuid_t   uuid;          // 服务UUID
} gatt_service_t;

服务类型对比

服务设计最佳实践

1. 功能正交：每个服务应聚焦单一功能领域（如"电池服务"只处理电量相关）
2. 合理拆分：复杂功能应拆分为多个服务（如设备信息与设备控制分离）
3. 版本兼容：新增功能尽量通过新服务实现，避免修改现有服务

2.2 特征值设计细节

特征值是实际数据交互的载体，其完整定义包含两部分：

特征值声明结构

cpp复制typedef struct {
    uint8_t   properties;   // 属性位掩码
    uint16_t  value_handle; // 特征值数值句柄
    uuid_t    uuid;         // 特征值UUID
} gatt_characteristic_t;

属性位掩码详解

• BIT(0)：允许广播读取
• BIT(1)：允许读取
• BIT(2)：允许无响应写入
• BIT(3)：允许写入
• BIT(4)：允许通知
• BIT(5)：允许指示
• BIT(6)：需要认证
• BIT(7)：需要授权

特征值数值存储

• 数据类型由UUID定义（如0x2A37表示心率测量值）
• 存储格式遵循蓝牙SIG规范（如心率值采用uint8_t）
• 权限由属性位掩码控制

2.3 描述符机制剖析

描述符为特征值提供元数据和控制接口，最重要的两类描述符：

客户端特征配置描述符（CCCD）

• UUID固定为0x2902
• 16位无符号整数，取值：
  • 0x0000：禁用通知/指示
  • 0x0001：启用通知
  • 0x0002：启用指示

特征值用户描述描述符

• UUID固定为0x2901
• UTF-8字符串，提供人类可读的描述
• 最大长度受ATT MTU限制（通常20字节）

描述符访问控制

• 通常只允许远程设备读取
• CCCD一般允许远程设备读写
• 关键描述符可能需要加密连接

3. GATT 操作流程实战分析

3.1 服务发现流程详解

服务发现是GATT交互的第一步，完整流程如下：

1. 初级发现：通过Discover All Primary Services请求获取所有主服务

   • 请求包：{Opcode=0x10, StartHandle=0x0001, EndHandle=0xFFFF}
   • 响应包：{HandleRange=[0x0001-0x000A], UUID=0x180D}（心率服务）

2. 特征值发现：通过Discover All Characteristics获取服务内特征值

   • 请求包：{Opcode=0x08, StartHandle=0x0001, EndHandle=0x000A}
   • 响应包：{Properties=0x10, ValueHandle=0x0003, UUID=0x2A37}

3. 描述符发现：通过Find Included Services和Discover All Descriptors获取完整结构

优化技巧

• 缓存发现结果减少重复发现
• 按需发现非必要服务节省功耗
• 使用更精确的句柄范围缩小搜索空间

3.2 数据交互模式对比

GATT支持多种数据交互模式，各有适用场景：

通知机制实现细节

1. 客户端写入CCCD启用通知（WriteReq(0x2902, 0x0001)）
2. 服务器检测特征值变化
3. 服务器检查CCCD状态
4. 若启用则发送Handle Value Notification
5. 客户端无需回复直接处理数据

3.3 错误处理与流控

GATT定义了完善的错误处理机制：

常见错误码

• 0x01：无效句柄
• 0x02：读取不被允许
• 0x03：写入不被允许
• 0x04：无效PDU
• 0x05：认证不足
• 0x06：请求不支持

流控实现方案

1. 基于MTU：协商合适的ATT MTU大小（默认23字节）
2. 基于信用：L2CAP层的流控机制
3. 应用层控制：通过特定特征值实现自定义流控

4. GATT 开发实践与优化

4.1 服务端设计要点

资源受限设备优化

1. 精简服务定义：只暴露必要接口
2. 使用16位UUID：减少存储占用
3. 合理设置MTU：平衡吞吐量与内存使用
4. 延迟初始化：非核心服务可动态注册

安全配置建议

• 敏感操作需要加密连接
• 关键特征值设置认证要求
• 实现配对绑定流程
• 定期更新LTK（长期密钥）

4.2 客户端开发技巧

高效发现策略

1. 先发现标准服务，再发现厂商服务
2. 按需发现特征值和描述符
3. 缓存服务结构减少重复发现
4. 实现服务变更通知处理

数据交互优化

• 批量读写相关特征值
• 合理使用通知/指示机制
• 实现MTU交换获取更大传输单元
• 处理连接参数更新请求

4.3 调试与问题排查

常见问题诊断表

调试工具推荐

1. nRF Connect：全面的BLE调试APP
2. Wireshark：配合蓝牙嗅探器进行协议分析
3. bluetoothctl：Linux下的命令行工具
4. Android Bluetooth HCI Log：安卓系统级日志

5. GATT 高级特性与演进

5.1 扩展特性应用

长特征值处理

• 当数据超过MTU时，使用Read Blob Request分片读取
• 写入长数据使用Prepare Write和Execute Write

服务变更通知

• 服务表变化时通过Service Changed特征值通知客户端
• 客户端应重新发现服务

特征值扩展属性

• 通过Characteristic Extended Properties描述符声明
• 支持如可靠写入等高级特性

5.2 蓝牙5.x增强

LE Coded PHY

• 增加通信距离
• 需要平衡数据速率和功耗

2M PHY

• 提高数据传输速率
• 适合大数据量传输场景

LE Audio

• 基于LC3编解码器
• 引入新的GATT服务定义

5.3 设计模式演进

复合设备模型

• 单个物理设备暴露多个逻辑设备接口
• 通过不同的GATT服务实现

代理服务架构

• 设备作为GATT服务端和客户端的组合
• 实现数据中继和协议转换

面向服务架构（SOA）

• 服务动态注册和发现
• 支持运行时服务组合