3. ESP32 BLE编程模型：双栈对比与事件驱动
ESP32 的 BLE 开发，说白了就是跟两个协议栈打交道：Bluedroid 和 NimBLE。很多初学者上来就问「我该学哪个？」——嗯，这个问题我当年也纠结过。今天咱们就把这两个栈掰开揉碎，看看它们到底有什么区别，以及怎么用事件驱动的方式把代码写利索。
3.1 Bluedroid vs NimBLE：双栈对比
ESP32 默认用的是 Bluedroid，这是 Android 系统移植过来的全功能栈。NimBLE 则是后来加入的轻量级替代方案，由 Apache Mynewt 项目贡献。我个人习惯把 Bluedroid 比作「瑞士军刀」，功能全但体积大；NimBLE 像「手术刀」，轻巧精准。
| 对比维度 | Bluedroid | NimBLE |
|---|---|---|
| 代码体积 | ~200KB+ | ~50KB |
| RAM 占用 | ~30KB | ~10KB |
| API 风格 | 回调 + GATT 事件 | 回调 + 主机/控制器分离 |
| 多连接支持 | 最多 3 个 | 最多 8 个 |
| BLE 5.0 特性 | 部分支持 | 完整支持 |
| 调试难度 | 中等 | 较低 |
我的建议：如果项目对 RAM 敏感（比如只有 100KB 可用），或者需要 BLE 5.0 的 2Mbps 速率、长包扩展，直接上 NimBLE。如果只是做简单的 Beacon 或串口透传，Bluedroid 也够用。
3.2 事件驱动架构：BLE 程序的核心
BLE 编程跟普通 MCU 编程最大的区别是什么？是「你不知道数据什么时候来」。连接请求、数据接收、断开通知——这些都是异步事件。所以 ESP-IDF 的 BLE 框架采用了事件驱动架构。
说白了，你注册一堆回调函数，然后系统在合适的时候调用它们。你想想看，这跟中断服务程序很像，只不过事件是在任务上下文中派发的。
避坑指南：我曾经在回调函数里做了延时操作，结果导致整个 BLE 协议栈卡死。记住：回调函数里不要做阻塞操作，把耗时工作扔到消息队列里处理。
3.3 回调函数注册：三步走
以 Bluedroid 为例，注册回调的流程非常固定：
- 初始化协议栈：调用
esp_bt_controller_init()和esp_bluedroid_init() - 注册应用回调：调用
esp_ble_gap_register_callback()和esp_ble_gattc_register_callback() - 使能协议栈：调用
esp_bluedroid_enable()
代码示例：
static void gap_event_handler(esp_ble_gap_cb_param_t *param) {
switch (param->event) {
case ESP_GAP_BLE_ADV_DATA_SET_COMPLETE_EVT:
esp_ble_gap_start_advertising(&adv_params);
break;
case ESP_GAP_BLE_ADV_START_COMPLETE_EVT:
if (param->adv_start_cmpl.status != ESP_BT_STATUS_SUCCESS) {
ESP_LOGE(TAG, "广告启动失败");
}
break;
default:
break;
}
}
void app_main(void) {
esp_bt_controller_config_t bt_cfg = BT_CONTROLLER_INIT_CONFIG_DEFAULT();
esp_bt_controller_init(&bt_cfg);
esp_bluedroid_init();
esp_bluedroid_enable();
esp_ble_gap_register_callback(gap_event_handler);
}注意：回调函数的注册顺序不能乱。必须先注册再使能，否则事件来了没人处理。我见过有人把 esp_bluedroid_enable() 放在注册前面，结果回调永远不触发。
3.4 内存管理要点：别让堆碎片搞崩你
BLE 协议栈对内存管理要求很高。为什么？因为数据包频繁收发，堆分配和释放非常频繁。如果处理不好，堆碎片会导致分配失败，然后协议栈就崩了。
我总结了几条经验：
- 预分配大块内存：用
heap_caps_malloc()指定内存类型，比如MALLOC_CAP_SPIRAM或MALLOC_CAP_INTERNAL - 避免频繁 malloc/free：用静态缓冲区或内存池代替
- 注意 MTU 大小：默认 23 字节，协商后可达 512 字节，缓冲区要留够
- GATT 数据库用静态数组：不要动态创建服务/特征
我曾经踩过的坑：在 NimBLE 中，如果 ble_gatts_register_svc() 返回 BLE_HS_ENOMEM，十有八九是堆不够了。后来我把 GATT 服务定义成 const 静态结构体，问题就解决了。
3.5 双栈事件处理流程对比
下面这张图展示了 Bluedroid 和 NimBLE 的事件处理流程差异：
3.6 内存分配策略对比
两个栈的内存管理方式也不同。Bluedroid 内部用了大量的动态分配，而 NimBLE 更倾向于静态分配。我建议你在项目初期就确定好内存策略：
| 场景 | 推荐策略 | 说明 |
|---|---|---|
| 单连接、数据量小 | Bluedroid + 默认配置 | 省事，不用调参 |
| 多连接、数据量大 | NimBLE + 静态内存池 | 避免碎片，稳定 |
| OTA 升级场景 | NimBLE + 外部 SPI RAM | 大缓冲区放外部 RAM |
| 低功耗传感器 | NimBLE + 最小配置 | RAM 占用可压到 8KB |
小技巧：用 esp_get_free_heap_size() 监控堆使用情况。如果发现可用内存持续下降，八成是内存泄漏了。我一般会在每个事件处理函数入口和出口打印一次堆大小。
3.7 总结：选栈就是选策略
Bluedroid 和 NimBLE 没有绝对的好坏。你想想看，如果你的产品只需要广播一个 Beacon，用 Bluedroid 完全没问题。但如果你要做 BLE Mesh 网关，同时管理几十个节点，那 NimBLE 的多连接能力和低内存占用就是刚需。
我个人习惯是：原型阶段用 Bluedroid，因为调试工具多；量产阶段切 NimBLE，因为稳定省资源。当然，如果你从一开始就确定用 NimBLE，那也完全没问题——它的 API 设计更现代，学习曲线反而更平缓。