4. 事件驱动模型：事件循环、队列与分发

事件驱动模型，说白了就是程序怎么「感知」外部动作，然后做出反应。你点一下鼠标，敲一下键盘，或者网络数据到了——这些都得靠事件驱动来兜底。

我刚开始接触 GUI 编程时，总觉得事件就是个回调函数。后来做双缓冲项目，发现事件处理不好，画面卡顿、响应延迟全来了。嗯，这里面的门道比想象中深。

4.1 事件循环机制

事件循环是整个模型的发动机。它不停地在做一件事：取事件 → 处理事件 → 再取下一个。

看一个最简的事件循环伪代码：

while True:
    event = get_next_event()   # 从队列取事件
    if event is None:
        idle_process()         # 无事件时做空闲处理
        continue
    dispatch(event)            # 分发事件到对应处理器

这个循环一旦启动，就不会主动退出。你想想看，窗口程序为什么能一直响应？就是因为这个循环在后台跑着。

4.2 事件队列与分发

事件队列是个先进先出的缓冲区。所有外部事件先入队，再由事件循环按顺序取出。

分发机制决定了事件交给谁处理。常见的有两种：

分发方式	特点	适用场景
直接分发	事件直接调用注册的回调	简单 GUI、小型应用
层级分发	事件沿控件树向上冒泡	复杂 UI、双缓冲系统

我个人习惯用层级分发。为什么？因为双缓冲场景下，一个鼠标事件可能涉及多个图层。比如点击一个按钮，按钮自己处理，但如果按钮没处理，事件就冒泡到父容器——这很灵活。

4.3 阻塞与非阻塞模型

这是事件驱动里最容易踩坑的地方。我直接说结论：GUI 和双缓冲系统必须用非阻塞模型。

阻塞模型长这样：

def get_next_event():
    while queue.empty():
        sleep(0.01)   # 阻塞等待
    return queue.pop()

非阻塞模型长这样：

def get_next_event():
    if not queue.empty():
        return queue.pop()
    return None   # 立即返回，不等待

区别很明显。阻塞模型在等待事件时，CPU 空转或者线程挂起。非阻塞模型则能利用空闲时间做其他事——比如刷新画面、处理定时任务。

4.4 事件驱动与双缓冲的配合

双缓冲刷新和事件驱动是天生一对。为什么？

• 事件触发刷新：用户操作 → 事件入队 → 事件处理 → 标记脏区域 → 下一帧刷新
• 空闲时刷新：没有事件时，事件循环进入空闲处理，执行后台刷新或动画
• 避免重复刷新：多个事件可以合并到一次刷新中，减少绘制次数

我做过一个绘图板项目，鼠标移动时会产生大量事件。如果每个事件都触发一次刷新，画面会闪成什么样？后来我用事件队列合并，攒够一批事件再统一刷新——流畅多了。

4.5 事件驱动模型结构图

下面这张图展示了事件驱动模型的核心流程。我建议你仔细看看，尤其是「空闲处理」那条分支——很多人会忽略它。

4.6 实战建议

最后给几个实在的建议：

• 事件合并：多个同类事件（比如鼠标移动）可以合并成一个，减少处理次数
• 优先级队列：紧急事件（比如窗口关闭）应该优先处理，别让它在队列里排队
• 超时机制：事件处理不能无限等待，设置超时时间，超了就走空闲处理