7. 事件驱动核心组件：事件源、事件总线、事件处理器注册、事件路由
事件驱动架构，说白了就是「谁出事，谁喊一嗓子；谁关心，谁接活儿」。我在嵌入式项目里摸爬滚打这么多年，发现很多同学一上来就写回调函数嵌回调函数，最后代码缠成一团乱麻。其实只要把四个核心组件理清楚——事件源、事件总线、处理器注册、事件路由——整个系统就能像流水线一样清晰。
我个人习惯把事件驱动比作一个「消息邮局」。事件源是寄信人，事件总线是邮局的分拣中心，处理器注册就是邮局里的收件人名单，而事件路由则是邮递员按地址送信。嗯，咱们一个一个拆开看。
7.1 事件源：谁在产生事件？
事件源就是系统中所有能「发出信号」的东西。按键按下、串口收到一帧数据、定时器溢出、传感器阈值触发……这些都是事件源。我在项目中见过最离谱的写法是把事件源的检测逻辑直接塞进主循环的 if 里，结果一个按键要轮询好几层，耦合度极高。
其实事件源只需要做一件事：把事件「扔」到总线上。它不需要知道谁会处理，也不需要关心处理结果。说白了，它就是喊一嗓子：「按键按下啦！」然后继续干自己的活。
7.2 事件总线：核心的「消息邮局」
事件总线是事件驱动架构的心脏。它维护一个队列，接收来自各个事件源的消息，然后按顺序分发给对应的处理器。你想想看，如果没有总线，每个事件源都要直接调用处理器，那代码就变成蜘蛛网了。
总线通常需要做这几件事：
- 接收事件：从事件源那里拿到事件结构体（一般包含事件ID、数据指针、时间戳等）。
- 暂存队列：用环形缓冲区或链表把事件存起来，防止丢失。我习惯用静态分配的环形缓冲区，避免动态内存碎片。
- 触发分发：在空闲时（比如主循环或RTOS的idle任务）从队列里取出事件，交给路由模块。
这里有个坑：事件总线的队列长度一定要根据最坏情况来定。我记得有一次做车载仪表盘，没算好队列深度，连续快速按菜单键时事件溢出，界面直接卡死。后来我加了水位报警，队列超过80%就丢旧事件保新事件。
7.3 事件处理器注册：谁关心什么事件？
处理器注册，就是告诉总线：「我对某某事件感兴趣，有消息就叫我。」这本质上是一个映射表：事件ID → 回调函数列表。同一个事件可以有多个处理器，比如按键按下既需要更新界面，又需要播放提示音。
注册接口一般长这样：
// 注册一个事件处理器
// event_id : 事件类型 (如 0x01 表示按键事件)
// handler : 回调函数指针
// priority : 优先级 (0最高, 数值越大优先级越低)
void event_register(uint8_t event_id, event_handler_t handler, uint8_t priority);我个人习惯在系统初始化阶段就把所有处理器注册好。这样运行时就不需要动态注册了，既安全又高效。你想想看，如果运行时还能注册，万一注册表被破坏，整个系统就崩了。
7.4 事件路由：谁该处理这个事件？
事件路由是连接总线和处理器的桥梁。它拿到一个事件后，去注册表里查这个事件ID对应的处理器列表，然后按优先级依次调用。路由的核心逻辑其实很简单：
void event_route(event_t *evt) {
// 根据事件ID查找处理器列表
handler_list_t *list = &handler_table[evt->id];
if (list->count == 0) {
// 没人关心这个事件，直接丢弃
return;
}
// 按优先级排序后依次调用
for (int i = 0; i < list->count; i++) {
handler_t *h = &list->handlers[i];
h->callback(evt); // 调用处理器
}
}这里有个细节：路由时要不要支持事件传播阻断？比如某个处理器处理后不想让后面的处理器再执行。我一般会加一个返回值或标志位，让处理器可以「消费」掉事件。但要注意，滥用这个机制会让系统行为变得难以预测。
7.5 四个组件如何协同工作？
咱们用一个实际场景串起来：假设有一个按键事件，按下后需要点亮LED并记录日志。
- 事件源：GPIO中断检测到按键按下，构造一个事件结构体（ID=KEY_PRESS, data=键值），调用
event_post()扔到总线队列。 - 事件总线：把事件放入环形缓冲区，返回。中断结束。
- 主循环/任务：调用
event_dispatch()，从队列取出事件，交给路由。 - 事件路由：查注册表，发现 KEY_PRESS 事件有两个处理器：LED控制（优先级0）和日志记录（优先级1）。先调用LED控制，再调用日志记录。
- 处理器：LED控制函数点亮GPIO；日志记录函数把事件写入Flash或串口。
你看，整个过程每个组件各司其职，互不干扰。这就是事件驱动架构的魅力——解耦、灵活、可扩展。
7.6 一张表总结核心组件
| 组件 | 职责 | 常见实现 | 注意事项 |
|---|---|---|---|
| 事件源 | 产生事件并投递到总线 | 中断服务函数、轮询检测、定时器回调 | 非阻塞，不处理业务逻辑 |
| 事件总线 | 暂存事件队列，触发分发 | 环形缓冲区、静态数组、RTOS消息队列 | 队列长度要足够，防止溢出 |
| 处理器注册 | 维护事件ID到回调函数的映射 | 静态数组、哈希表、链表 | 初始化时注册完毕，避免运行时动态修改 |
| 事件路由 | 根据事件ID查找并调用处理器 | 查表 + 优先级排序 + 循环调用 | 路由本身要快，不阻塞 |
嗯，四个核心组件讲完了。其实事件驱动没有想象中那么玄乎，说白了就是「分而治之」——把事件产生、传递、注册、路由拆成四个独立模块，每个模块只关心自己的事。你想想看，这样写出来的代码，是不是比满屏的回调嵌套好维护多了？