第2章事件驱动架构

事件驱动架构：事件循环、事件队列、事件分发机制详解

聊到游戏输入系统，有个概念绕不开——事件驱动架构。

说白了，游戏就是个“等事件→处理事件→再等事件”的死循环。玩家按了个键，这叫事件；鼠标动了一下，这也是事件；甚至你啥都没干，系统还在那跑渲染、播音乐，那也是内部定时器触发的事件。

我个人习惯把事件驱动拆成三块来看：事件循环、事件队列、事件分发。搞懂了这三兄弟，你写输入系统时心里就有底了。

1. 事件循环——游戏的心脏跳动

先问个问题：游戏是怎么做到“一直活着”的？

答案是事件循环。它就像心脏，每跳一次，就处理一批事件。

我见过不少新手，上来就写 while True 死循环，然后里面塞一堆逻辑。嗯，这其实也算事件循环，只不过是最糙的那种。

真正的游戏事件循环，长这样：

while (game.isRunning) {
    // 1. 收集输入事件
    Event event = inputSystem.pollEvent();
    
    // 2. 处理事件
    while (event != null) {
        dispatch(event);
        event = inputSystem.pollEvent();
    }
    
    // 3. 更新游戏逻辑
    update();
    
    // 4. 渲染画面
    render();
}

你看，核心就四步。但这里有个坑——事件处理不能卡太久。我曾经在一个项目里，把资源加载塞进了事件处理函数里，结果游戏直接卡成PPT。后来学乖了，耗时操作一律异步或者分帧处理。

注意：事件循环里千万别做阻塞操作。比如网络请求、文件读写、大资源加载。这些事请扔到子线程或者协程里去。

2. 事件队列——事件的“缓冲区”

事件队列，说白了就是个先进先出的列表。玩家按键盘那一刻，事件就被扔进队列里。事件循环再从队列头部一个个取出来处理。

为什么要用队列？直接处理不行吗？

你想想看，玩家一秒能按多少次键？如果每次按键都立刻触发逻辑，那游戏逻辑会被打断得七零八落。用队列的好处是：输入采集和逻辑处理解耦了。

我习惯把事件队列分成两种：

类型	特点	适用场景
无界队列	不限制大小，事件全收	单机游戏，玩家操作频率可控
有界队列	固定大小，满了就丢弃旧事件	网络游戏，防止恶意刷事件

我个人更推荐有界队列。为什么？因为玩家要是连点鼠标100下，你真要处理100次吗？很多情况下，只处理最后几次就够了。

小技巧：我曾在FPS项目里用环形缓冲区实现事件队列。性能好，而且不会产生内存碎片。代码大概长这样：

class RingBufferEventQueue:
    def __init__(self, capacity=64):
        self.buffer = [None] * capacity
        self.head = 0
        self.tail = 0
        self.capacity = capacity
    
    def push(self, event):
        next_tail = (self.tail + 1) % self.capacity
        if next_tail != self.head:  # 队列没满
            self.buffer[self.tail] = event
            self.tail = next_tail
        else:
            # 队列满了，丢弃最旧的事件
            self.buffer[self.tail] = event
            self.tail = next_tail
            self.head = (self.head + 1) % self.capacity
    
    def pop(self):
        if self.head == self.tail:
            return None  # 队列为空
        event = self.buffer[self.head]
        self.head = (self.head + 1) % self.capacity
        return event

3. 事件分发——谁的事谁来管

事件从队列里取出来了，然后呢？得发给对应的处理器。

这就涉及事件分发机制。我见过三种主流做法：

硬编码分发：写一堆 if-else 判断事件类型。简单粗暴，但代码膨胀快。
观察者模式：事件源和监听器解耦。事件来了，广播给所有注册过的监听器。
委托分发：用委托或函数指针，把事件直接绑定到具体处理函数上。

我个人最常用观察者模式。举个例子：

class EventDispatcher:
    def __init__(self):
        self.listeners = {}
    
    def register(self, event_type, callback):
        if event_type not in self.listeners:
            self.listeners[event_type] = []
        self.listeners[event_type].append(callback)
    
    def dispatch(self, event):
        if event.type in self.listeners:
            for callback in self.listeners[event.type]:
                callback(event)

# 使用示例
dispatcher = EventDispatcher()
dispatcher.register("KEY_DOWN", on_player_move)
dispatcher.register("MOUSE_CLICK", on_player_shoot)

# 事件循环里
while running:
    event = queue.pop()
    if event:
        dispatcher.dispatch(event)

这样做的好处是：新增一种事件类型，不需要改分发器代码。只需要注册新的监听器就行。

    核心要点：事件分发要遵循“谁关心谁处理”的原则。UI事件交给UI系统，输入事件交给输入系统，网络事件交给网络系统。别搞一个大而全的处理器，那会变成维护噩梦。

4. 避坑指南——我踩过的那些坑

讲完理论，说点实战中容易翻车的地方。

坑一：事件处理顺序依赖

我曾经在项目里，让移动事件依赖了UI事件的执行结果。结果UI事件处理慢了半拍，角色移动就卡顿。后来强制规定：同一帧内的事件，彼此不能有执行顺序依赖。

坑二：事件队列溢出

有次做手机游戏，玩家疯狂点击屏幕，事件队列直接爆了。后来加了防抖逻辑：同类型事件在短时间内只处理最后一次。

坑三：忘记清理事件监听器

场景切换时，旧场景的监听器还活着。新场景的事件触发后，旧监听器也跟着响应。结果就是各种诡异bug。解决方案：场景销毁时，统一注销所有监听器。

5. 总结一下

事件驱动架构，说白了就是三件事：

事件循环——保证游戏一直活着，不断处理新事件
事件队列——给事件排队，防止逻辑被打乱
事件分发——把事件交给对的人处理

搞懂这三块，你写输入系统时就不会手忙脚乱了。下次遇到输入延迟、事件丢失、逻辑混乱的问题，先检查这三个环节，八成能找到原因。

📚 课程目录

事件驱动架构：事件循环、事件队列、事件分发机制详解

1. 事件循环——游戏的心脏跳动

2. 事件队列——事件的“缓冲区”

3. 事件分发——谁的事谁来管

4. 避坑指南——我踩过的那些坑

5. 总结一下