事件驱动

这是学界面编程最需要转的那个弯：写普通程序时，流程由你控制；写界面程序时，流程由用户控制。你不再是"指挥官"，而变成了"值班员"——坐在那里等事情发生，事情来了就处理，没事就闲着。这个思维反转，比任何 API 都重要。

命令式脚本 vs 事件驱动：根本区别在哪

先看一段最普通的脚本。它体现的是"命令式"思维：我说一步，机器做一步，做完就结束。

# 命令式脚本：控制权在我手上，从上到下跑完就退出

data  = read_file("orders.csv")      # 1. 读文件
clean = remove_duplicates(data)      # 2. 去重
total = sum(row.amount for row in clean)  # 3. 求和
print("总金额：", total)              # 4. 输出
# 程序结束 —— 谁也没法"插话"

这段代码的特点是：执行顺序在写代码的时候就完全确定了。你读代码，从第一行读到最后一行，就知道程序的一生。中途没有任何"外人"能插手。

现在看界面程序。它的结构完全变了：

# 事件驱动：我只登记"什么情况下做什么"，然后把控制权交出去

button_save.on_click   = lambda: save_file()          # 登记：点保存 → 存盘
button_cancel.on_click = lambda: window.close()       # 登记：点取消 → 关窗
input_name.on_change   = lambda t: validate_name(t)   # 登记：改文字 → 校验
window.on_resize       = lambda w, h: relayout(w, h)  # 登记：窗口变了 → 重排

app.run()   # ← 关键的一行：控制权从此交给框架，它会一直循环等事件

差别在哪？代码的书写顺序，不再等于执行顺序。

上面四行登记代码，谁先执行完全取决于用户先点了什么。用户可能先改名字、再点保存、再改窗口大小；也可能进来直接点取消，那么另外三个函数一次都不会执行。你在写代码的时候，根本不知道也不需要知道它们的执行顺序。

这带来一个非常重要的心态转变：你的代码从"一段流程"变成了"一堆规则"。你不再描述"先干什么后干什么"，而是描述"如果发生 A，就做 X；如果发生 B，就做 Y"。程序的实际行为，是这些规则被用户以随机顺序触发出来的结果。

事件循环：整个界面世界的心跳

那么"等事件"这件事，在代码层面到底是怎么实现的？答案朴素到令人意外：一个永不结束的 while 循环。

这个循环叫事件循环（Event Loop），也叫消息循环、主循环。你调用的 app.run()、mainloop()、app.exec()，进去以后就是它。所有 GUI 程序，从 1984 年的 Macintosh 到今天的浏览器和手机 App，骨架都是这个循环。

// 事件循环的本质（所有 GUI 框架的核心，简化版）

while (程序还没被要求退出) {

    event = 事件队列.取出下一个();     // ① 取事件（队列空就在这儿睡着，不耗 CPU）

    if (event == null) continue;

    target = 根据坐标或焦点.找到目标控件(event);   // ② 分发 Dispatch

    target.处理(event);              // ③ 处理 Handle —— 你写的回调在这里被调用

    if (有控件被标记为"脏了") {
        重新布局();
        重新绘制();                   // ④ 重绘 Repaint
        提交给屏幕();
    }
}

四个步骤，逐个说清楚。

① 取事件。操作系统会把键盘、鼠标、触摸、窗口变化等硬件和系统消息，塞进属于你这个程序的一个队列里。循环每一轮从队头拿一个。注意：队列空的时候，循环不是在疯狂空转，而是被操作系统挂起休眠——所以一个没人操作的窗口，CPU 占用是 0%。这也是为什么你的编辑器开着一整天也不烫手。

② 分发。拿到一个"鼠标在 (420, 310) 处按下"，框架得回答：这个坐标落在谁身上？于是它顺着上一节讲的控件树从根往下找，找到最深的那个覆盖该坐标的控件。键盘事件不看坐标，看焦点——谁持有焦点就给谁。

③ 处理。目标控件先自己处理（比如按钮把自己画成按下状态），然后调用你注册的回调。如果它不处理或者处理完不拦着，事件还会顺着树往上冒泡给父控件，直到有人"消费"掉它。

④ 重绘。回调可能改了状态（文字变了、颜色变了、多了一行）。框架不会立刻重画——那太浪费了。它只是给受影响的控件打个"脏"标记，等这一轮事件处理完，一次性把所有脏区域重新布局、绘制、送屏。这叫批量重绘，是性能的关键。

然后回到 ①，继续。这个循环每秒转几十到几百轮，界面的"活着"就是它在转。

回调函数与监听器：把代码"寄存"起来

事件驱动能成立，靠的是一个语言机制：函数本身可以被当成数据传来传去。

你写 button.onClick = saveFile，注意这里 saveFile 后面没有括号——你不是在"调用"它，而是把这个函数本身交给按钮保管。按钮把它存起来，等到真的被点击的那一刻，才由框架替你调用。这种"我交出去、别人在合适的时机替我调用"的函数，就叫回调函数（Callback）。

监听器（Listener / Observer）是回调的组织形式。它解决了一个实际问题：一个事件可能有多个人关心。比如"文档被修改了"这件事，标题栏想加个星号、自动保存想重置计时器、撤销栈想记一笔——三个互不相干的模块。于是框架允许挂多个回调，事件发生时按顺序全都通知一遍。

// 一个事件挂多个监听器，互不干扰

doc.addEventListener('change', () => titleBar.showModifiedMark());
doc.addEventListener('change', () => autoSave.resetTimer());
doc.addEventListener('change', () => undoStack.push(doc.snapshot()));

// 不再关心时，可以摘掉（这一步新手常忘，是内存泄漏的常见原因）
doc.removeEventListener('change', someHandler);

这套机制的妙处是解耦：文档模块完全不知道标题栏、自动保存、撤销栈的存在，它只负责喊一声"我变了"。谁想听谁自己来登记。这让各个模块可以独立开发、独立删除，互不牵连。这个模式在设计模式里叫观察者模式，是整个事件驱动世界的理论底座。

主线程不能阻塞：为什么界面会"未响应"

现在讲本节最有实用价值的一段。你一定见过这个场景：点了个按钮，窗口整个白掉、变灰、标题栏出现"（未响应）"、鼠标转圈、点哪儿都没反应。

这是怎么造成的？回到事件循环那段代码看第 ③ 步——target.处理(event)。这一行是同步调用：你的回调不返回，循环就走不到下一轮。

假设你在按钮回调里写了一个耗时 8 秒的操作（下载文件、读一个巨大的 Excel、跑一段复杂计算）：

// ❌ 灾难写法：把主线程占死 8 秒
button.onClick = () => {
    const data = downloadHugeFile();   // 同步等待，8 秒不返回
    render(data);
};

在这 8 秒里，事件循环卡在第 ③ 步动不了。后果是连锁的：

• 新事件只进不出你移鼠标、点其他按钮、按键盘，这些事件都乖乖排进队列，但没人来取——因为取事件的那个循环正被你占着。
• 画面彻底冻结重绘也在循环里（第 ④ 步）。循环不转就不重绘，于是窗口被别的窗口遮挡后再露出来，那块区域是空白或者花的。
• 系统判定"假死"操作系统会定期给窗口发一个探测消息，若几秒内没被处理，就认为程序挂了，于是给标题栏加上"未响应"，并弹出"结束进程"的选项。

所以有一条铁律：主线程（UI 线程）上的每个回调，都必须在十几毫秒内返回。为什么是十几毫秒？因为屏幕通常每秒刷新 60 次，每帧的预算只有 16.7 毫秒。超过这个数，就会掉帧、就是"卡"；超过几百毫秒，用户就明确感到"顿"；超过几秒，就是"未响应"。

常见事件类型：都有哪些"事"会来

事件的种类看着杂，其实按来源分四大类，认清来源就不会乱。

另外还有一类容易被忽略的：自定义事件。框架允许你自己定义"购物车已更新"、"登录状态变化"这类业务事件，走同一套监听器机制。这让事件驱动不只是"处理用户输入"的工具，而成为整个程序内部模块通信的骨架。

异步与后台线程：为什么它们是必需品

既然主线程不能占，耗时的活儿放哪？两条路。

第一条：异步（Async）。适用于"等待型"任务——网络请求、读写文件、等定时器。这类任务的特点是 CPU 其实没在算，只是在等外部返回。异步的做法是：发起请求后立刻返回，把"结果回来以后干什么"登记成一个回调。等结果真的到了，操作系统往事件队列里塞一个"完成"事件，事件循环取到它，再执行你的回调。

// ✅ 异步写法：发起后立刻返回，不占主线程

button.onClick = async () => {
    spinner.show();                          // 立刻给反馈（反馈类控件的价值）
    try {
        const data = await fetchHugeFile();  // 这里"让出"主线程，循环继续转
        render(data);                        // 结果回来后，自动回到主线程继续
    } finally {
        spinner.hide();
    }
};

关键在 await 那一行：它不是"停在这里等"，而是"把函数剩下的部分登记成回调，然后返回，让事件循环去干别的"。所以在等待的这段时间里，界面依然能滚动、能响应、动画照转。这就是所谓的非阻塞。

第二条：后台线程（Worker Thread）。适用于"计算型"任务——图片处理、数据压缩、大规模排序、模型推理。这类任务 CPU 是真的在满负荷算，光靠异步没用，必须换个 CPU 核心去跑。做法是把任务丢给一个独立线程，算完了通过消息通知主线程。

但这里有一条几乎所有 GUI 框架都强制的铁律：只有主线程可以碰界面。后台线程算完了，不能自己去改控件的文字或颜色，必须把结果"投递"回主线程，由主线程更新。违反这条规则，轻则界面画错，重则直接崩溃。

为什么这么严格？因为界面的状态是一棵共享的树，如果两个线程同时改它，就会出现"一个线程正在遍历这棵树画画，另一个线程把节点删了"这种灾难。框架的解决办法很干脆：不给你并发的机会——所有界面修改都排成一队，交给主线程串行执行。

把三节内容串起来

到这里，第 1 章的骨架就完整了：GUI 提供了窗口、图标、菜单、指针这套视觉语言；控件 是搭建界面的可复用积木，并按树形嵌套组织；而事件驱动 是让这棵静态的树"活起来"的发动机。

三者的关系可以这样理解：控件树是身体，事件循环是心跳，你写的回调是反射。心跳不停，身体才有反应；而反射必须够快，快不了就得把活儿交给别人干——这就是异步存在的全部理由。

下一章开始，我们往下钻一层：这些控件最终是怎么变成屏幕上的像素的。