消息队列基础：为什么BLE应用需要消息队列？阻塞与非阻塞模型

做BLE开发的朋友，十有八九都遇到过这种场景：蓝牙连接刚建立，你正忙着处理配对，结果广播事件又来了；你刚想发个通知，连接参数更新请求又插进来。这时候如果每个事件都直接处理，代码很快就乱成一锅粥。

我刚开始做BLE项目时，就吃过这个亏。当时一个简单的温湿度计，事件一来就原地处理，结果广播和连接中断互相干扰，设备时不时就死机。后来我意识到——我们需要一个缓冲区，把事件排队，让CPU按顺序处理。这就是消息队列。

消息队列是什么？

说白了，消息队列就是一个先进先出（FIFO）的缓冲区。中断或回调函数把事件“扔”进队列，主循环或任务再从队列里“取”出来处理。

你可以把它想象成超市的收银台。顾客（事件）来了，先排队（入队），收银员（CPU）一个一个处理（出队）。不会出现插队，也不会漏掉谁。

为什么BLE应用特别需要消息队列？

BLE协议栈本身就是一个事件驱动的系统。你想想看，一个典型的BLE应用会收到多少种事件：

• 连接事件：设备连接、断开、连接参数更新
• 广播事件：广播开始、停止、扫描请求
• 服务事件：发现服务、特征值读写、通知使能
• 数据事件：收到数据、发送完成
• 定时器事件：周期性任务、超时处理

这些事件可能在任何时刻发生。如果没有消息队列，你只能在回调函数里直接处理。但回调函数里能做多少事？我告诉你，非常有限。

处理方式	优点	缺点
直接在回调中处理	响应快，代码简单	阻塞协议栈，容易死锁，不能做耗时操作
使用消息队列	不阻塞回调，可排队处理，支持耗时操作	增加一点内存开销，需要额外代码

我在一个项目中遇到过这种情况：回调里直接调用了一个I2C读取函数，结果I2C总线被占用，协议栈等不到响应，直接断连了。从那以后，我所有BLE回调里只做一件事——把事件入队。

阻塞模型 vs 非阻塞模型

消息队列的读写操作，有两种基本模型。我分别说说它们的用法和坑。

阻塞模型

阻塞模型的意思是：当队列为空时，读操作会一直等待，直到有新消息进来。同样，当队列满时，写操作也会等待，直到有空间。

// 阻塞读示例
void task_handler(void *arg) {
    msg_t msg;
    while (1) {
        // 队列为空时，这里会阻塞，不会空转CPU
        queue_receive(&ble_msg_queue, &msg, WAIT_FOREVER);
        process_message(&msg);
    }
}

这种模型的好处是CPU利用率高——没有消息时任务直接挂起，不浪费CPU。坏处是容易死锁。我记得有一次，我在一个任务里阻塞等待消息，但发送消息的任务优先级更低，结果两个任务互相等，系统直接卡死。

非阻塞模型

非阻塞模型正好相反。读队列时，如果队列为空，立即返回一个错误码；写队列时，如果队列满了，也立即返回。不会等待。

// 非阻塞读示例
void ble_callback(ble_event_t *event) {
    msg_t msg;
    msg.type = event->type;
    msg.data = event->data;
    
    // 队列满时直接丢弃，不阻塞回调
    if (queue_send(&ble_msg_queue, &msg, NO_WAIT) != OK) {
        // 记录丢包，或者采取其他措施
        log_error("Message queue full, dropping event");
    }
}

非阻塞模型在中断或回调函数里特别有用。你不能在中断里等，对吧？但非阻塞也有代价——可能丢消息。如果队列满了，新消息就被丢弃了。

我曾经在一个项目中，队列深度设得太小，结果高频数据流把队列撑爆了，关键事件丢失，设备行为变得很奇怪。排查了两天才找到原因。

两种模型的对比

特性	阻塞模型	非阻塞模型
适用场景	任务上下文，专职处理	中断/回调，不能等待
CPU利用率	高（不空转）	低（需要轮询或通知）
风险	死锁、优先级反转	丢消息、队列溢出
实现复杂度	低（RTOS自带）	中（需要处理满队列）

实际BLE应用中的消息队列设计

说了这么多理论，我们来看看实际BLE项目里怎么用。下面是我常用的一个模式：

// 定义消息类型
typedef enum {
    MSG_BLE_CONNECTED,
    MSG_BLE_DISCONNECTED,
    MSG_BLE_DATA_RECEIVED,
    MSG_BLE_DATA_SENT,
    MSG_SENSOR_READY,
    MSG_TIMER_EXPIRED
} msg_type_t;

// 定义消息结构
typedef struct {
    msg_type_t type;
    uint8_t *data;
    uint16_t len;
    uint32_t timestamp;
} msg_t;

// 创建消息队列
#define MSG_QUEUE_SIZE 16
static queue_t ble_msg_queue;

void app_init(void) {
    queue_create(&ble_msg_queue, MSG_QUEUE_SIZE, sizeof(msg_t));
}

// BLE回调函数 - 只做入队
void ble_on_data_received(uint8_t *data, uint16_t len) {
    msg_t msg;
    msg.type = MSG_BLE_DATA_RECEIVED;
    msg.data = data;
    msg.len = len;
    msg.timestamp = get_tick();
    
    // 非阻塞入队，不等待
    queue_send(&ble_msg_queue, &msg, NO_WAIT);
}

// 主处理任务 - 阻塞出队
void main_task(void *arg) {
    msg_t msg;
    while (1) {
        // 阻塞等待消息
        queue_receive(&ble_msg_queue, &msg, WAIT_FOREVER);
        
        switch (msg.type) {
            case MSG_BLE_DATA_RECEIVED:
                process_received_data(msg.data, msg.len);
                break;
            case MSG_BLE_CONNECTED:
                start_sensor_collection();
                break;
            // ... 其他消息处理
        }
    }
}

这个模式的好处很明显：回调函数里只做入队，主任务里统一处理。回调函数执行时间极短，不会阻塞协议栈；主任务可以放心地做耗时操作，比如写Flash、发数据到云端。

消息队列在BLE架构中的位置

下面这张图展示了消息队列在BLE软件架构中的核心位置。你可以看到，所有外部事件都先经过消息队列，再由任务调度器分发处理。

从这张图可以看得很清楚：消息队列是事件源和处理任务之间的缓冲层。它让不同优先级、不同上下文的代码能够安全地通信。没有它，你的BLE应用就像没有红绿灯的十字路口——迟早要出事故。

避坑指南

最后，分享几个我踩过的坑：

• 队列深度设太小：高频事件一来就丢消息。我建议先估算峰值事件率，再留50%余量。
• 在中断里用阻塞入队：这会导致中断响应时间变长，甚至死锁。记住，中断里永远用NO_WAIT。
• 多个任务共用一个队列：如果多个任务都从同一个队列取消息，要考虑消息的归属问题。我一般一个队列只配一个消费者。
• 忘记处理队列满的情况：非阻塞模式下，队列满时一定要有处理逻辑。可以丢弃旧消息，也可以丢弃新消息，但不能什么都不做。