4、事件循环：主循环、阻塞与非阻塞模式、超时机制

事件循环，说白了就是整个GUI系统的“心脏泵”。它不停地问：“有事件发生吗？有的话赶紧处理，没有的话……嗯，那也得干点别的。”

我刚开始做嵌入式GUI那会儿，觉得事件循环不就是个while(1)嘛，有啥好讲的？后来踩了坑才明白——这个循环怎么写，直接决定了你的界面是“丝般顺滑”还是“卡成PPT”。

4.1 主循环——GUI的“永动机”

任何嵌入式GUI，不管底层用的是什么芯片，最终都会落到一个无限循环里。这个循环就是事件循环的主干。

// 最朴素的事件循环
int main(void)
{
    gui_init();
    
    while (1) {
        gui_event_t evt;
        if (gui_get_event(&evt)) {   // 有事件？
            gui_dispatch_event(&evt); // 派发处理
        }
        gui_refresh();               // 刷新显示
    }
}

你看，就这么几行。但这里藏着第一个坑：gui_get_event 和 gui_refresh 的调用频率怎么平衡？

我个人习惯把事件循环拆成三个核心阶段：

采集阶段——从硬件（触摸屏、按键、编码器）拿原始事件
处理阶段——把事件翻译成控件能理解的“消息”，然后派发
渲染阶段——把变化后的界面画出来

这三个阶段跑完一圈，就是一帧。帧率稳不稳，就看这一圈能不能在16ms（60fps）或33ms（30fps）内跑完。

核心原则：事件循环不能“死等”任何一件事。要么有超时，要么有回调，要么有轮询——总之，不能让循环卡住。

4.2 阻塞模式——简单但危险

阻塞模式，就是事件获取函数一直等到有事件才返回。听起来很合理，对吧？

// 阻塞模式：gui_get_event 不拿到事件不返回
while (1) {
    gui_event_t evt;
    gui_get_event_blocking(&evt);  // 一直等
    gui_dispatch_event(&evt);
    gui_refresh();
}

我曾经在一个小项目里这么写过。当时觉得“反正用户不操作就不需要刷新”，结果呢？

触摸屏按下后，如果手指滑动太快，中间的事件全丢了
动画效果？别想了，没事件的时候循环根本不跑
后台定时任务？比如“5秒无操作自动熄屏”——根本实现不了

避坑指南：我曾经在一个智能家居面板上用了纯阻塞模式，结果用户反映“按一下按钮，屏幕要等半秒才亮”。查了半天，发现是触摸中断处理里有个延时函数把事件循环堵死了。从那以后，我再也不敢在主循环里用阻塞式获取。

阻塞模式不是不能用，但只适合两种情况：

系统只有一个任务，且不需要后台处理
RTOS里，把阻塞交给操作系统调度，而不是自己死等

4.3 非阻塞模式——让循环“喘口气”

非阻塞模式，就是每次调用事件获取函数都立即返回。有事件就处理，没事件就干别的。

// 非阻塞模式：每次调用立即返回
while (1) {
    gui_event_t evt;
    if (gui_get_event_nonblocking(&evt)) {
        gui_dispatch_event(&evt);
    }
    gui_refresh();           // 没事件也要刷新（动画、闪烁等）
    gui_tick_update();       // 更新定时器、软件PWM等
    power_manage_check();    // 检查是否进入低功耗
}

这才是嵌入式GUI该有的样子。你想想看，一个智能手表，用户大部分时间只是抬腕看时间——这时候屏幕在刷新秒针，后台在检测心率，电池在省电。如果用了阻塞模式，这些全得停。

非阻塞模式的核心在于：事件获取函数必须能快速判断“有没有事件”，而不是“等事件”。通常的实现方式有：

事件队列 + 标志位：硬件中断把事件塞进队列，主循环检查队列是否为空
轮询寄存器：直接读硬件状态寄存器，有变化就生成事件
回调注册：底层驱动在事件发生时调用注册的回调函数

模式	CPU占用	响应延迟	适用场景
阻塞模式	低（空闲时休眠）	低（有事件立即响应）	单任务、无后台需求
非阻塞模式	中（持续轮询）	中（取决于轮询频率）	多任务、动画、低功耗
中断驱动	极低（事件触发）	极低（硬件级响应）	实时性要求高的场景

我的经验：非阻塞模式下，轮询频率不是越高越好。我曾经把轮询放到1ms一次，结果CPU全耗在“检查有没有事件”上了。后来改成10ms一次，配合事件队列缓冲，效果反而更好。记住：轮询频率 = 你能接受的最大响应延迟。

4.4 超时机制——给事件循环加个“闹钟”

非阻塞模式解决了“卡死”的问题，但带来了新麻烦：如果事件一直不来，循环就一直在空转。CPU白费电，电池哗哗掉。

超时机制就是用来解决这个的。它让事件获取函数在“等一段时间”后主动返回——不管有没有事件。

// 带超时的非阻塞模式
while (1) {
    gui_event_t evt;
    int ret = gui_get_event_timeout(&evt, 50);  // 最多等50ms
    if (ret == 1) {
        gui_dispatch_event(&evt);
    } else if (ret == 0) {
        // 超时了，没事件——正好干点别的
        gui_idle_task();
    }
    gui_refresh();
}

这个50ms的超时时间怎么定？我一般按这个逻辑来：

触摸屏：10-20ms。人手指滑动时，事件间隔大约5-15ms，超时太长会丢帧
按键：50-100ms。按键事件本来就稀疏，没必要频繁轮询
编码器：5-10ms。旋转编码器可能产生高速脉冲，超时太长会漏步
空闲任务：100-500ms。比如“无操作自动熄屏”，不需要太精确

关键点：超时机制不是让你“等事件”，而是让你“等一会儿，没事件就去做别的事”。它把阻塞模式的“死等”变成了“活等”。

4.5 三种模式的融合——实战中的事件循环

实际项目中，我很少只用一种模式。通常是把它们揉在一起：

// 实战中的混合事件循环
while (1) {
    // 阶段1：快速轮询高优先级事件（触摸、按键）
    gui_event_t evt;
    while (gui_get_event_nonblocking(&evt)) {
        gui_dispatch_event(&evt);
    }
    
    // 阶段2：处理定时任务（动画、闪烁、超时检测）
    gui_timer_process();
    
    // 阶段3：刷新显示
    gui_refresh();
    
    // 阶段4：低功耗休眠（如果允许）
    if (system_can_sleep()) {
        enter_sleep_mode(10);  // 休眠10ms，由RTC或中断唤醒
    }
}

你看，这个循环里：

高优先级事件用非阻塞轮询，确保不丢
定时任务用软件定时器管理，不依赖事件
刷新显示固定频率执行
空闲时进入低功耗，用超时或中断唤醒

我曾经在一个温控器项目里用这种结构。主控是STM32F103，72MHz主频，带一个320x240的彩屏。事件循环跑在50Hz（20ms一圈），空闲时CPU进入休眠，平均功耗只有3mA。用户操作时瞬间唤醒，响应延迟不超过30ms——嗯，这个数据我自己挺满意的。

注意：低功耗休眠和事件响应是矛盾的。休眠越深，唤醒越慢。我一般分三级：轻度休眠（保留RAM，唤醒<1ms）、中度休眠（关闭外设时钟，唤醒<5ms）、深度休眠（仅RTC运行，唤醒>10ms）。事件循环根据当前状态动态选择休眠等级。

4.6 事件循环的核心流程图

下面这张图，是我每次给团队新人讲事件循环时必画的。它把阻塞、非阻塞、超时三种模式的关系说清楚了。

嗯，这张图把三种模式的路径画得很清楚。你看阻塞模式那条线，一直在“等待-处理-等待”里打转，中间没有插针的地方。非阻塞模式多了一个“空闲任务”的分支，可以塞各种后台操作。超时模式则是两者的折中——等一会儿，不等死。

4.7 总结一下

事件循环这件事，说简单也简单，说复杂也复杂。我见过不少项目，功能逻辑写得挺好，就是事件循环没设计好，导致整个系统“看起来”很迟钝。

记住三个要点：

别让循环卡住——阻塞模式只在RTOS或单任务场景下用
给循环留“喘气”的空间——非阻塞模式让CPU有空干别的事
用超时控制节奏——既保证响应速度，又避免空转浪费

我个人习惯在项目初期就把事件循环的框架搭好，哪怕后面功能再多，只要这个“心脏”跳得稳，整个系统就不会乱。你想想看，是不是这个理？

📚 课程目录

4、事件循环：主循环、阻塞与非阻塞模式、超时机制

4.1 主循环——GUI的“永动机”

4.2 阻塞模式——简单但危险

4.3 非阻塞模式——让循环“喘口气”

4.4 超时机制——给事件循环加个“闹钟”

4.5 三种模式的融合——实战中的事件循环

4.6 事件循环的核心流程图

4.7 总结一下