1. 事件驱动架构概述

各位同学，咱们今天聊聊事件驱动架构。说实话，我做了十几年嵌入式开发，真正让我觉得「这玩意儿能救命」的，就是事件驱动这套思路。你想想看，一个嵌入式系统里，外设那么多，中断那么乱，如果全靠主循环一个个轮询，迟早要出问题。

什么是事件驱动架构

事件驱动架构，说白了就是——系统不主动去「问」外设有没有事，而是等外设「告诉」系统有事了。这个「告诉」的动作，就是事件。

举个例子。你写一个按键程序。传统做法是主循环里不断读GPIO电平，读到低电平就认为按键按下。事件驱动怎么做？把GPIO配成下降沿中断，按键按下时硬件自动触发中断，你在中断服务函数里发一个「按键按下」事件，然后由事件处理器去响应。

我个人习惯把事件驱动架构拆成三个核心部件：

• 事件源——谁产生事件？中断、定时器、消息队列、其他任务。
• 事件队列——事件来了放哪儿？先进先出，排队处理。
• 事件处理器——谁来处理事件？一个调度器，或者一个状态机。

我在一个智能家居项目里用过这套架构。网关要同时处理Zigbee、Wi-Fi、蓝牙三种协议的数据。如果用轮询，CPU占用率直接飙到80%以上。改成事件驱动后，CPU占用率降到15%，而且响应延迟从毫秒级降到微秒级。嗯，这个对比很直观。

为什么选择事件驱动

你可能会问：轮询架构用了这么多年，为什么非要换？我直接给你列个对比表，一看就明白。

对比维度	事件驱动架构	传统轮询架构
CPU利用率	按需工作，空闲时休眠	持续轮询，浪费大量CPU周期
响应实时性	事件触发即响应，延迟低	取决于轮询周期，延迟不可控
代码可维护性	模块解耦，事件与处理分离	逻辑耦合，主循环越来越臃肿
功耗控制	天然支持低功耗模式	需要额外设计休眠策略
扩展性	新增事件不影响现有逻辑	新增外设需要修改主循环

我记得有一次做工业控制器，客户要求响应延迟不超过100微秒。轮询架构怎么做？主循环跑10kHz，每次循环检查所有外设。但外设一多，循环时间就拉长，根本满足不了。后来改成事件驱动，每个外设的中断直接触发事件，延迟稳稳控制在50微秒以内。

与传统轮询架构的对比

咱们再深入一点，看看两种架构在代码层面的差异。我写两段伪代码，你感受一下。

传统轮询架构：

while(1) {
    if(GPIO_ReadPin(BUTTON_PIN) == LOW) {
        // 处理按键
        handle_button_press();
    }
    if(UART_DataAvailable()) {
        // 处理串口数据
        handle_uart_data();
    }
    if(Timer_Expired()) {
        // 处理定时任务
        handle_timer_task();
    }
    // 外设越多，这里越长
    // CPU大部分时间在空转
}

事件驱动架构：

// 事件队列
EventQueue_t queue;

// 中断服务函数
void GPIO_IRQHandler() {
    Event_t evt = {EVT_BUTTON_PRESS, 0};
    EventQueue_Push(&queue, evt);
}

void UART_IRQHandler() {
    Event_t evt = {EVT_UART_DATA, uart_byte};
    EventQueue_Push(&queue, evt);
}

// 主循环只做一件事
while(1) {
    Event_t evt = EventQueue_Pop(&queue);
    if(evt.id != EVT_NONE) {
        EventDispatcher(&evt);
    } else {
        // 没有事件，进入休眠
        MCU_EnterSleep();
    }
}

看出来了吗？轮询架构里，主循环像个无头苍蝇，每个周期把所有外设问一遍。事件驱动架构里，主循环只做两件事：取事件、派发事件。没有事件就睡觉。

应用场景分析

事件驱动架构不是万能的，但它特别适合以下几类场景。我按优先级排了个序：

1. 物联网终端设备——传感器数据采集、无线通信、低功耗要求。事件驱动天然支持休眠唤醒。
2. 工业控制系统——多路传感器、多路执行器、硬实时响应。事件驱动能保证延迟可控。
3. 智能家居网关——同时处理多种协议、多种设备。事件驱动让系统解耦，新增设备不影响现有逻辑。
4. 汽车电子——CAN总线消息、传感器中断、安全关键功能。事件驱动架构配合状态机，能清晰管理复杂逻辑。
5. 可穿戴设备——电池供电、多传感器、用户交互。事件驱动让CPU大部分时间休眠，延长续航。

我去年做一个智能门锁项目，电池供电，要求待机一年。轮询架构根本做不到——主循环每10ms跑一次，CPU一直在工作。改成事件驱动后，平时深度休眠，只有按键、蓝牙、门磁触发时才唤醒。最终待机电流从2mA降到10μA，客户非常满意。

当然，事件驱动也有不适合的场景。比如超简单的单任务系统——一个LED闪烁、一个温度采集，轮询就够了，没必要引入事件队列的开销。再比如计算密集型任务——视频编码、FFT运算，这些需要CPU持续工作，事件驱动反而增加调度开销。

好了，这一章的内容就这些。下面我用一张SVG图把事件驱动架构的核心逻辑串起来，方便你记忆。

这张图把事件驱动架构的闭环画清楚了。事件源产生事件，事件队列暂存，事件处理器消费，没有事件就休眠。这个闭环就是事件驱动架构的命脉。