BLE技术解析：从广播机制到GATT服务优化

1. BLE技术全景概览：从蓝牙经典到BLE 5.x

上周调试智能门锁项目时遇到个典型场景：用户站在门前，手机却死活扫描不到门锁设备。用协议分析仪抓包后发现，工程师将广播间隔设置为5秒——这意味着用户可能早已失去耐心离开。这个案例让我回想起十年前调试蓝牙2.1的日子，那时光是配对过程就能耗掉半小时。蓝牙低功耗(BLE)技术经过多次迭代，如今已发展到BLE 5.x版本，其技术特性和应用场景都发生了翻天覆地的变化。

1.1 蓝牙经典的"重"架构

传统蓝牙(BR/EDR)设计初衷是处理高带宽应用，典型场景包括：

• 音频传输（如蓝牙耳机、音箱）
• 大文件传输（如手机间传图）
• 持续数据流（如HID设备）

其连接建立过程包含三个关键阶段：

1. 查询( Inquiry )：平均耗时5.12秒
2. 配对( Pairing )：涉及PIN码交换和链路密钥生成
3. 连接( Connection )：建立ACL链路和可能的多个逻辑通道

这种架构的协议栈复杂度令人咋舌，以经典蓝牙2.1协议栈为例：

• HCI层之上有L2CAP、RFCOMM等多层协议
• 每个协议层都有自己的状态机和缓冲管理
• 完整协议栈实现需要至少150KB ROM空间

功耗表现更是堪忧：

• 待机电流：1-5mA级别
• 活跃状态电流：20-30mA
• 建立连接延迟：通常>100ms

1.2 BLE的"轻"哲学

BLE从设计之初就贯彻了极简主义：

• 协议栈深度压缩，关键路径仅需3层（HCI→ATT→GATT）
• 连接建立时间可缩短至3ms
• 完整协议栈最小仅需80KB ROM

广播机制是BLE的精髓所在，设备可以处于三种状态：

1. 非连接广播：只发不收（电流<10μA）
2. 可连接广播：允许连接请求（电流≈800μA）
3. 扫描响应：回应主动扫描（电流≈1mA）

广播包结构设计极其紧凑，31字节空间需要承载：

• 设备标识（Flags）
• 本地名称（可缩短为缩写）
• 服务UUID（16/32/128位）
• 制造商特定数据（MFG Specific Data）

典型的广播数据结构示例：

c复制uint8_t adv_data[] = {
    0x02,  // 长度
    0x01,  // AD Type: Flags
    0x06,  // LE General Discoverable | BR/EDR Not Supported
    0x0A,  // 长度
    0x09,  // AD Type: Complete Local Name
    'D','O','O','R','-','L','O','C','K',
    0x03,  // 长度
    0x19,  // AD Type: Appearance
    0x00, 0x80, // 门锁外观类别
    0x05,  // 长度
    0xFF,  // AD Type: Manufacturer Specific
    0x4C,0x00, // 公司ID
    0x01,0xAB  // 自定义数据
};

广播间隔的设置需要权衡：

• 较短间隔（20ms-100ms）：快速发现但高功耗
• 中等间隔（100ms-1s）：平衡方案
• 较长间隔（>1s）：省电但用户体验差

关键经验：智能门锁类设备推荐使用100-500ms广播间隔，配合运动传感器触发广播可进一步优化功耗。

2. BLE广播协议深度解析

2.1 广播信道与跳频机制

BLE使用3个专