BLE协议栈ATT层核心机制与实战优化

1. BLE协议栈中的ATT层核心定位

在蓝牙低功耗（BLE）技术体系中，属性协议（Attribute Protocol, ATT）扮演着通信基石的角色。作为GATT（通用属性规范）的基础传输层，ATT定义了设备间数据交换的基本规则。实际开发中遇到的90%以上的BLE通信问题，根源往往可以追溯到对ATT机制的理解偏差。

ATT采用客户端-服务器架构模型，这种非对称设计使得资源受限的设备（如传感器）只需实现轻量级的服务器角色。我曾参与过一个医疗穿戴设备项目，设备端作为ATT服务器仅需12KB RAM即可稳定运行，而手机端作为客户端负责复杂的数据聚合逻辑。这种角色划分完美体现了BLE的低功耗设计哲学。

2. ATT协议数据单元深度解析

2.1 报文结构解剖

每个ATT PDU（协议数据单元）由以下要素构成：

code复制| Opcode (1字节) | Parameters (变长) |

Opcode字段的高位比特标识操作类型：

• 0x00-0x3F：客户端请求（Request）
• 0x40-0x7F：服务器响应（Response）
• 0x80-0x9F：服务器通知（Notification）
• 0xA0-0xBF：服务器指示（Indication）

在开发智能门锁时，我们曾遇到指令丢失问题。通过抓包分析发现是Opcode解析错误导致——将0x1B（WRITE REQUEST）误判为0x9B（非标准操作码）。这个教训让我养成了在代码中严格校验Opcode范围的习惯。

2.2 关键操作码实战详解

2.2.1 读操作集群

• READ BY TYPE (0x08)：用于发现特定类型的所有属性
  • 请求参数：Starting Handle + Ending Handle + Attribute Type UUID
  • 典型应用场景：快速定位服务特征值
  • 响应格式：Attribute Handle + Attribute Value

在心率监测项目中，我们使用此操作快速定位0x2A37特征值，相比全量搜索效率提升80%。

2.2.2 写操作差异

• WRITE REQUEST (0x12)：需要对方确认的写入
  • 必须等待ATT_WRITE_RSP (0x13)