ESP32事件驱动架构优化：解决BLE与UART并发崩溃问题

1. 项目概述：从生产事故到架构重构

去年我们团队在开发一款工业级IoT设备时，遇到了一个令人抓狂的问题：当ESP32同时处理BLE数据传输和UART通信时，系统会随机崩溃，看门狗频繁触发重启。更糟糕的是，这个问题在开发环境的低负载下完全无法复现，只有在现场高并发场景才会出现。经过72小时不眠不休的排查，我们最终定位到问题根源——多个通信源（UART/SPI/BLE）共享缓冲区时，竞态条件导致的内存踩踏。

1.1 传统架构的致命缺陷

在最初的设计中，我们采用了典型的"回调嵌套"方式：

c复制void uart_callback() {
    if (ble_connected) {
        ble_send(data, () {
            if (send_success) {
                spi_read(response, () {
                    // 缓冲区操作缺乏保护
                });
            }
        });
    }
}

这种架构存在三个致命问题：

1. 调用栈不可控：每层回调都会消耗栈空间，最终导致栈溢出
2. 异常处理困难：深层嵌套中的错误难以捕获和恢复
3. 状态分散：全局变量散落在各个回调中，难以追踪和维护

1.2 事件驱动架构的优势

重构后的事件驱动架构带来了显著改进：

• 代码量减少60%：通过统一的事件管理机制消除了重复代码
• Bug清零：严格的资源管理和状态机设计消除了竞态条件
• 响应延迟<1ms：优先级调度确保关键事件及时处理
• CPU使用率下降86%：从85%降至12%，避免了忙等待

2. 核心架构设计

2.1 事件驱动架构的三层模型

我们采用了严格的分层设计：

code复制┌───────────────────────┐
│       应用层          │ ← 纯业务逻辑
├───────────────────────┤
│     事件管理层        │ ← 统一调度中心
├───────────────────────┤
│     硬件抽象层        │ ← 仅投递事件
└───────────────────────┘

2.1.1 硬件抽象层(HAL)设计原则

HAL层严格遵守"只投递事件，不做业务逻辑"的原则。以UART为例：

c复制static void uart_event_task(void *pvParameters) {
    while (1) {
        if (xQueueReceive(uart_event_queue, &event, portMAX_DELAY)) {
            app_event_t app_event = {
                .type = EVENT_UART_DATA_RECEIVED,
                .priority = EVENT_PRIO_NORMAL
            };
            //