4. 事件循环（Event Loop）：深入剖析事件循环的架构，如何从队列中取出事件并分发

事件循环，说白了就是整个GUI系统的“心脏”。它一直在跳，不停地从队列里拿事件，然后发给对应的处理函数。我刚开始做嵌入式GUI时，总觉得这玩意儿很简单——不就是个while(1)嘛？后来踩了坑才发现，里面的门道多着呢。

咱们先看一张整体架构图，心里有个谱。

4.1 事件循环的本质

事件循环就是一个无限循环。它反复做三件事：取事件 → 分事件 → 等事件。我习惯把它比作餐厅里的传菜员——后厨做好了菜（事件产生），传菜员端给对应的客人（事件分发），然后回来继续等下一道菜。

在嵌入式系统里，这个循环通常长这样：

while (1) {
    Event evt = event_queue_get();   // 从队列取事件
    if (evt.type != EVT_NONE) {
        event_dispatch(&evt);        // 分发事件
    }
    system_idle();                    // 空闲处理
}

嗯，这里要注意：event_queue_get() 这个函数很关键。它有两种实现方式——阻塞式和非阻塞式。我个人更推荐非阻塞式，尤其是在单核MCU上。为什么呢？因为阻塞式会让CPU干等，浪费宝贵的处理时间。

关键区别：

阻塞式：队列为空时，CPU进入休眠或自旋等待。优点是响应快，缺点是浪费功耗。
非阻塞式：队列为空时立即返回空事件，CPU可以去做别的事。优点是利用率高，缺点是需要额外的轮询机制。

4.2 队列的底层实现

事件队列说白了就是一个缓冲区。但怎么设计这个缓冲区，直接影响系统性能。我在项目中遇到过一个问题：用链表实现队列，结果事件多了之后，内存碎片越来越严重，最后系统崩了。

后来我改用环形缓冲区，问题就解决了。环形缓冲区没有动态内存分配，不会产生碎片。它的结构很简单：

typedef struct {
    Event buffer[EVENT_QUEUE_SIZE];  // 固定大小的数组
    uint16_t head;                   // 读指针
    uint16_t tail;                   // 写指针
    uint16_t count;                  // 当前事件数
} EventQueue;

// 入队
int event_queue_push(EventQueue *q, const Event *evt) {
    if (q->count >= EVENT_QUEUE_SIZE) {
        return -1;  // 队列满了
    }
    q->buffer[q->tail] = *evt;
    q->tail = (q->tail + 1) % EVENT_QUEUE_SIZE;
    q->count++;
    return 0;
}

// 出队
int event_queue_pop(EventQueue *q, Event *evt) {
    if (q->count == 0) {
        return -1;  // 队列空了
    }
    *evt = q->buffer[q->head];
    q->head = (q->head + 1) % EVENT_QUEUE_SIZE;
    q->count--;
    return 0;
}

我的经验：队列大小怎么定？一般取系统最大事件数的1.5倍。比如你的系统最多同时处理10个事件，队列就设15个。太小了容易丢事件，太大了浪费内存。我曾经在一个项目里把队列设成256，结果RAM直接爆了——后来发现实际最多只用8个。

4.3 事件分发的策略

事件从队列里取出来之后，怎么分？这里有几个策略，我按推荐程度排个序：

策略	原理	适用场景	我的评价
直接分发	根据事件类型，直接调用对应的处理函数	简单系统，事件类型少	简单粗暴，但扩展性差
窗口路由	事件先发给当前活动窗口，窗口再分发给子控件	带窗口管理器的GUI	最常用，我90%的项目都用这个
回调注册	每个控件注册自己的回调函数，事件直接调用	控件数量固定，不频繁变化	灵活，但要注意回调不能阻塞
消息映射	用一张映射表，事件ID对应处理函数指针	大型系统，事件类型多	查表快，但维护映射表麻烦

我个人最常用的是窗口路由 + 回调注册的组合。窗口路由负责把事件送到正确的窗口，窗口内部再用回调注册把事件分给具体的控件。这样既保证了事件流的清晰，又保持了每个控件的独立性。

4.4 事件循环的优先级处理

你想想看，如果同时来了一个触摸事件和一个定时器事件，先处理哪个？这就涉及到优先级了。

我一般把事件分成三个优先级：

高优先级：触摸、按键、外部中断。这些需要立即响应，否则用户会觉得卡。
中优先级：定时器、通信数据。可以稍微等一等，但不能等太久。
低优先级：重绘请求、后台任务。可以排队慢慢处理。

实现方式有两种：

多队列：每个优先级一个队列，循环时先处理高优先级队列。
单队列+优先级标记：所有事件放一个队列，但每个事件带一个优先级字段，取出时按优先级排序。

我曾经踩过的坑：在一个智能家居面板项目里，我用了多队列方案。结果高优先级事件太多，低优先级的重绘事件一直得不到处理，界面卡在上一帧。后来我加了“饥饿保护”——如果低优先级事件等待超过50ms，强制提升优先级。这才解决了问题。

4.5 空闲处理的艺术

事件循环里，队列为空的时候干什么？很多新手直接让CPU空转，这太浪费了。我建议利用这段时间做三件事：

低功耗休眠：进入WFI（Wait For Interrupt）模式，有事件时通过中断唤醒。适合电池供电的设备。
后台任务：比如垃圾回收、数据压缩、日志写入。注意这些任务不能阻塞太久。
界面刷新：检查是否有脏区域需要重绘。我习惯在空闲时做增量刷新，而不是每次都全屏重绘。

void system_idle(void) {
    // 1. 检查是否有脏区域需要重绘
    if (g_dirty_rect_count > 0) {
        flush_dirty_rects();
        return;  // 重绘后立即返回，继续检查事件
    }
    
    // 2. 执行低优先级后台任务
    run_background_tasks();
    
    // 3. 如果没有任何事做，进入低功耗模式
    if (g_task_count == 0 && g_dirty_rect_count == 0) {
        enter_sleep_mode();
    }
}

小技巧：空闲处理里不要做复杂计算。我曾经把FFT算法放在空闲里跑，结果触摸事件来了要等FFT算完才能响应，用户一划就卡。后来我把复杂计算拆成小块，每次空闲只算一小部分，问题就解决了。

4.6 事件循环的实时性保障

嵌入式GUI最怕什么？怕事件循环被阻塞。一旦阻塞，整个界面就死了。我总结了几条铁律：

每个事件处理时间 < 1ms：如果某个事件处理需要更长时间，拆成多个小事件或者放到后台线程。
禁止在事件处理中等待：比如等待串口数据、等待文件读写。这些应该用异步方式。
设置看门狗：如果事件循环超过100ms没响应，强制重启。这在产品中非常重要。

我曾经在一个医疗设备项目里，因为一个文件写入操作阻塞了事件循环，导致触摸响应延迟了200ms。测试的时候没发现，结果临床使用时医生操作不跟手，差点出事故。从那以后，我所有的事件处理函数都加了时间戳监控，超时自动报警。

4.7 小结

事件循环是整个GUI系统的调度核心。它从队列里取事件，按优先级和路由策略分发给对应的处理函数，空闲时做后台任务或进入低功耗模式。设计好的事件循环，要关注三点：队列不能满、分发不能慢、空闲不能浪费。

嗯，这一章的内容就到这儿。记住，事件循环就像系统的脉搏——脉搏稳了，系统就稳了。

📚 课程目录

4. 事件循环（Event Loop）：深入剖析事件循环的架构，如何从队列中取出事件并分发

4.1 事件循环的本质

4.2 队列的底层实现

4.3 事件分发的策略

4.4 事件循环的优先级处理

4.5 空闲处理的艺术

4.6 事件循环的实时性保障

4.7 小结