1. 事件驱动模型基础：从轮询到中断，理解UI事件循环的本质

各位同学，咱们今天聊点最底层的。UI 事件循环，说白了就是「程序怎么知道用户动了？」。你点了一下鼠标，敲了一下键盘，屏幕上的按钮就亮了——这背后到底发生了什么？

我刚开始做 GUI 开发时，也以为这是魔法。后来踩了不少坑，才明白这背后就两个模型：轮询和中断。嗯，今天咱们就把这层窗户纸捅破。

1.1 轮询模型：最朴素的「我问问你」

轮询（Polling）的思路很简单：程序每隔一小段时间，主动去检查一下有没有新事件。就像你每隔 5 分钟去门口看看有没有快递——虽然效率低，但逻辑清晰。

核心特征：

程序主动查询事件源
查询间隔固定（比如每 16ms 一次）
没有事件时 CPU 空转

我记得早期做嵌入式 UI 时，用的就是纯轮询。代码大概长这样：

while (1) {
    // 检查鼠标
    if (mouse_has_event()) {
        process_mouse_event();
    }
    // 检查键盘
    if (keyboard_has_event()) {
        process_keyboard_event();
    }
    // 检查触摸
    if (touch_has_event()) {
        process_touch_event();
    }
    // 睡一会儿，别把 CPU 跑满
    sleep(10);  // 10ms 轮询一次
}

你想想看，这个模型有什么问题？

延迟不可控：如果用户在 sleep 期间点了鼠标，最多要等 10ms 才能响应。对于 60fps 的动画来说，10ms 已经能感觉到卡顿了。
CPU 浪费：大部分时间没有事件，但程序还在傻乎乎地轮询。我见过一个项目，轮询间隔设成了 1ms，结果 CPU 占用直接飙到 30%。
扩展性差：事件源一多，轮询列表越来越长，每次循环都要遍历一遍。

我的经验：轮询不是不能用，但只适合事件频率高、延迟要求不苛刻的场景。比如游戏手柄的输入轮询，每秒 60 次，配合垂直同步，效果还不错。

1.2 中断模型：让系统「主动通知你」

中断（Interrupt）的思路完全相反。程序不主动问，而是告诉系统：「有事件了叫我」。就像你给快递小哥打电话：「到了打我手机」——不用干等，该干嘛干嘛。

中断模型的核心是事件驱动。系统检测到外部输入，立即暂停当前任务，跳转到事件处理函数。处理完再回来继续干活。

核心特征：

事件源主动通知程序
响应延迟极低（微秒级）
CPU 利用率高（无事可做时休眠）

现代操作系统里的中断处理流程大致如下：

// 伪代码：中断注册与处理
void interrupt_handler() {
    // 保存当前上下文
    save_context();
    
    // 读取事件类型
    EventType type = read_event_register();
    
    // 分发事件
    switch (type) {
        case MOUSE_CLICK:
            handle_mouse_click();
            break;
        case KEY_PRESS:
            handle_key_press();
            break;
        case TOUCH:
            handle_touch();
            break;
    }
    
    // 恢复上下文
    restore_context();
}

// 注册中断
register_interrupt_handler(IRQ_MOUSE, interrupt_handler);
register_interrupt_handler(IRQ_KEYBOARD, interrupt_handler);

我曾经在一个实时系统里用过纯中断模型。响应速度确实快，但有个坑——中断处理函数里不能做复杂操作。比如你不能在中断里直接更新 UI 布局，因为那可能涉及内存分配和锁操作，容易死锁。

注意：中断处理函数应该「快进快出」。复杂逻辑要放到下半部（Bottom Half）或工作队列里执行。否则中断嵌套一多，系统就崩了。

1.3 事件循环：轮询与中断的「混血儿」

实际 UI 框架既不是纯轮询，也不是纯中断。它们用的是事件循环（Event Loop）——一种巧妙的混合模型。

事件循环的工作原理是这样的：

系统底层用中断捕获硬件事件（鼠标、键盘、触摸）
中断处理函数把事件放入一个事件队列，然后立即返回
主线程的事件循环不断从队列里取事件，分发给对应的处理函数

你想想看，这其实就是「中断采集 + 轮询分发」的组合。既保证了低延迟，又避免了中断处理复杂逻辑的问题。

下面这张图展示了事件循环的核心流程：

1.4 主流 UI 框架的事件循环对比

不同框架的事件循环实现各有千秋。我整理了一张对比表，方便你理解：

框架	事件循环类型	队列模型	典型延迟	我的评价
Qt	信号-槽 + 事件循环	单队列，优先级排序	< 5ms	最成熟，但信号-槽连接多了会慢
GTK	主循环 + 空闲回调	单队列，可插队	< 10ms	轻量，但调试事件流比较痛苦
Flutter	Dart 事件循环 + 微任务	双队列（事件+微任务）	< 1ms	微任务机制很赞，但容易死锁
浏览器	宏任务 + 微任务	多队列，分层处理	< 4ms	最复杂，但也是最强

我的建议：如果你刚开始学事件循环，先从 Qt 入手。它的信号-槽机制把事件分发包装得很直观，调试工具也完善。等你理解了「谁发出、谁接收、怎么排队」这三个问题，再看其他框架就一通百通了。

1.5 避坑指南：我曾经踩过的坑

做 UI 事件处理这些年，我栽过不少跟头。挑几个典型的说说：

事件处理里做耗时操作：有一次我在按钮点击事件里直接做了文件读写，结果界面卡了 2 秒。用户以为程序死了，疯狂点按钮——事件队列里瞬间堆了 50 个点击事件。处理完这 50 个事件，程序直接崩溃。后来我学乖了，耗时操作一律扔到工作线程。
忘记移除事件监听：动态创建了一个弹窗，注册了键盘事件。弹窗关闭时忘了移除监听，结果每次按键都触发一个已经销毁的对象的回调。查了两天才找到原因。嗯，现在我的代码里，addEventListener 和 removeEventListener 永远是成对出现的。
事件循环嵌套：在一个事件处理函数里又启动了新的事件循环。比如在 Qt 的 QDialog::exec() 里又弹了一个对话框。这种嵌套循环很容易导致事件顺序错乱，而且调试起来特别头疼。我现在的原则是：能不用 exec() 就不用，一律用异步回调。

重要提醒：事件循环不是万能的。如果你发现 UI 响应越来越慢，先检查事件队列里是不是积压了太多未处理的事件。用 profiler 看一眼队列长度，比瞎猜强一百倍。

1.6 小结：从轮询到中断，再到事件循环

咱们今天聊了三个模型：

轮询：简单但低效，适合高频事件
中断：高效但复杂，适合底层硬件
事件循环：取两者之长，是现代 UI 的基石

理解了事件循环的本质，你就掌握了 UI 事件处理的「第一性原理」。后面咱们聊事件冒泡、事件捕获、自定义事件，都是在这个基础上搭积木。

记住一句话：事件循环不是魔法，它只是一个「排队 + 分发」的机制。你理解了队列，就理解了事件循环的一半。

📚 课程目录

1. 事件驱动模型基础：从轮询到中断，理解UI事件循环的本质

1.1 轮询模型：最朴素的「我问问你」

1.2 中断模型：让系统「主动通知你」

1.3 事件循环：轮询与中断的「混血儿」

1.4 主流 UI 框架的事件循环对比

1.5 避坑指南：我曾经踩过的坑

1.6 小结：从轮询到中断，再到事件循环