拒绝面条代码!用 Linux＂通知链＂实现模块间的极度解耦

手把手教你实现 C 语言版的"观察者模式"，让代码像积木一样随意插拔

 你见过这种"上帝函数"吗？

干嵌入式的兄弟们，应该都写过或者见过这样的代码：

// system_state.c#include "led.h"#include "lcd.h"#include "wifi.h"#include "bluetooth.h"#include "sensor.h"// ... 还有一堆头文件void Enter_LowPower_Mode(void) {    Led_Off();           // 关灯    Lcd_Sleep();         // 关屏    Wifi_PowerDown();    // 关网    Bluetooth_Close();   // 关蓝牙    Sensor_Suspend();    // 挂起传感器    // 每次增加一个模块，这里就要加一行    // 头文件也要跟着加    // 改到你想砸键盘...}

看着眼熟吧？这玩意儿我管它叫"上帝函数"——它什么都知道，什么都管，跟个包工头似的，手底下有多少人它门儿清。

问题在哪？

第一，耦合度爆炸。system_state.c 把所有外设模块都 include 了一遍。下个项目如果不需要蓝牙，你得回来改这个文件；加个新传感器，还得改这个文件。改来改去，总有一天你会忘记某个地方，然后 bug 就来了。

第二，多人协作就是灾难。 你改 LED 逻辑要动这个文件，同事加 WiFi 功能也要动这个文件，另一个同事调传感器还是这个文件。三个人一起 push，Git 冲突解到你怀疑人生。

有没有办法让核心逻辑"啥也不知道"？它只管喊一嗓子"我要睡了"，谁听见谁自己处理，核心压根不关心有多少模块在监听？

还真有。Linux 内核里有个叫 Notifier Chain（通知链） 的机制，专门干这事儿。你可以把它想象成村口的大喇叭——村长喊一声"开会了"，至于谁来、来了干嘛，村长不管，各家自己看着办。

 原理解析：从"点对点"到"发布-订阅"

先来看看传统做法和通知链的本质区别。

传统模式：挨家挨户敲门

你手里有份名单，上面写着：张三、李四、王五。每次有事，你得一个一个打电话通知。

问题来了——

• • 张三换号了？你得改名单。
• • 新来个赵六？你得加名单。
• • 李四不干了？你得删名单。

名单在你手里，所有变动你都得亲自处理。这就是传统的函数直接调用，主控模块必须知道所有被调用模块的存在。

通知链模式：大喇叭广播

换个思路：我不维护名单了，谁想听消息，自己来登记。

我就装个大喇叭，喊一嗓子"开饭了"，谁爱听谁听。新来的人自己来登记，走的人自己注销，我这边啥都不用改。

这就是经典的发布-订阅模式，也叫观察者模式。

Linux 内核怎么用的？

Linux 内核里到处都是通知链：

• • USB 设备插拔 → 通知链
• • 网络接口状态变化 → 通知链
• • CPU 频率调整 → 通知链
• • 系统休眠唤醒 → 通知链

内核用 atomic_notifier_chain_register() 这类函数来实现。听起来高大上，其实剥开来看，核心就两样东西：

链表 + 函数指针

没了。就这么简单。

链表负责把所有"订阅者"串起来，函数指针负责存储每个订阅者的回调函数。事件触发时，遍历链表，挨个调用函数指针，完事。

 手把手造轮子：定义属于你的 Notifier

理论讲完，开始撸代码。

第一步：定义核心结构体

参考 Linux 内核的 struct notifier_block，我们自己定义一个：

// notifier.h// 回调函数类型：接收事件类型和附加数据，返回处理结果typedef int (*notifier_fn_t)(int event, void *data);// 通知块结构体typedefstruct notifier_block {    notifier_fn_t callback;          // 回调函数指针struct notifier_block *next;     // 指向下一个节点    int priority;                    // 优先级，数值越大越先执行} notifier_block_t;// 返回值定义#define NOTIFY_OK       0   // 处理完毕，继续通知下一个#define NOTIFY_STOP     1   // 处理完毕，停止通知后续节点

结构体就三个成员，简单粗暴。重点说下 priority 这个字段——在嵌入式里，执行顺序是要命的事。

举个例子：系统关机前，你得先让文件系统把缓存刷到 Flash 里，然后才能关掉存储控制器。顺序反了，数据就丢了。优先级就是用来控制这个顺序的。

第二步：实现注册函数

订阅者想收通知，得先来登记。我们实现一个注册函数，把新节点按优先级插入链表：

// notifier.cint notifier_chain_register(notifier_block_t **head, notifier_block_t *node){    notifier_block_t **curr = head;    // 按优先级从高到低找到合适的位置    while (*curr && (*curr)->priority >= node->priority) {        curr = &((*curr)->next);    }    // 插入节点    node->next = *curr;    *curr = node;    return 0;}

这里用了二级指针的技巧，可以统一处理头插、尾插、中间插入的情况，代码更简洁。不熟悉二级指针的同学，建议拿纸画画指针指向关系，多画几次就通了。

第三步：实现通知函数

有人登记了，那我喊话的时候得能通知到。遍历链表，逐个调用回调函数：

int notifier_call_chain(notifier_block_t *head, int event, void *data){    notifier_block_t *curr = head;    int ret = NOTIFY_OK;    while (curr) {        ret = curr->callback(event, data);        // 如果某个回调要求停止，就不再通知后面的节点        if (ret == NOTIFY_STOP) {            break;        }        curr = curr->next;    }    return ret;}

代码不复杂，但有个细节：回调函数可以返回 NOTIFY_STOP 来阻止事件继续传播。这个机制后面会详细讲。

第四步：注销函数（可选）

模块卸载时，得把自己从链表里摘掉：

int notifier_chain_unregister(notifier_block_t **head, notifier_block_t *node){    notifier_block_t **curr = head;    while (*curr) {        if (*curr == node) {            *curr = node->next;            node->next = NULL;            return 0;        }        curr = &((*curr)->next);    }    return -1;  // 没找到}

到这里，一个麻雀虽小五脏俱全的通知链就搞定了。总共也就几十行代码，但能解决大问题。

实战演练：重构"低功耗系统"

光说不练假把式，我们用通知链重构开头那个"上帝函数"。

定义事件源

首先在系统核心模块里定义一个通知链头，以及事件类型：

// sys_core.c#include "notifier.h"// 定义事件类型enum sys_event {    EVENT_SLEEP,        // 进入休眠    EVENT_WAKEUP,       // 唤醒    EVENT_SHUTDOWN,     // 关机};// 休眠事件通知链的链表头static notifier_block_t *sleep_chain_head = NULL;// 提供注册接口给外部模块int sleep_notifier_register(notifier_block_t *node){    return notifier_chain_register(&sleep_chain_head, node);}

注意看，sys_core.c 现在只暴露了一个注册接口，它压根不知道也不关心谁会来注册。

各模块独立注册

LCD 模块这样写：

// lcd.c#include "notifier.h"// LCD 的休眠回调static int lcd_sleep_handler(int event, void *data){    if (event == EVENT_SLEEP) {        // 关闭背光、进入低功耗模式        LCD_BacklightOff();        LCD_EnterSleep();    }    return NOTIFY_OK;}// 定义通知块，优先级设为 50static notifier_block_t lcd_sleep_notifier = {    .callback = lcd_sleep_handler,    .priority = 50,};void LCD_Init(void){    // 初始化硬件...    LCD_HardwareInit();    // 注册到休眠通知链    sleep_notifier_register(&lcd_sleep_notifier);}

WiFi 模块同样的套路：

// wifi.c#include "notifier.h"static int wifi_sleep_handler(int event, void *data){    if (event == EVENT_SLEEP) {        Wifi_Disconnect();        Wifi_PowerDown();    }    return NOTIFY_OK;}// WiFi 优先级设低一点，让它后关static notifier_block_t wifi_sleep_notifier = {    .callback = wifi_sleep_handler,    .priority = 30,};void Wifi_Init(void){    Wifi_HardwareInit();    sleep_notifier_register(&wifi_sleep_notifier);}

触发事件

现在回头看 Enter_LowPower_Mode，它变成了什么样？

// sys_core.cvoid Enter_LowPower_Mode(void){    // 就这一行，完事    notifier_call_chain(sleep_chain_head, EVENT_SLEEP, NULL);}

一行代码。

没有 include 任何外设头文件，不知道有多少模块在监听，不关心它们具体干什么。它就是个大喇叭，喊一嗓子"我要睡了"，谁听见谁自己处理。

效果对比

改造前：

• • 加个新模块 → 改 sys_core.c，加 include，加函数调用
• • 删掉某个模块 → 改 sys_core.c，删 include，删函数调用
• • 多人协作 → 都在改同一个文件，冲突不断

改造后：

• • 加个新模块 → 在新模块的 Init 里自己注册，完事
• • 删掉某个模块 → 直接把文件删了，sys_core.c 不用动一个字
• • 多人协作 → 各改各的模块，互不干扰

这就是极度解耦的威力。

进阶玩法：带返回值的拦截机制

前面提到回调函数可以返回 NOTIFY_STOP，这是个很实用的机制。

场景

假设系统要休眠，但文件系统正在写数据。这时候直接休眠会丢数据，怎么办？

解决方案

让文件系统的回调函数返回 NOTIFY_STOP，阻止休眠流程继续：

// filesystem.cstatic int fs_sleep_handler(int event, void *data){    if (event == EVENT_SLEEP) {        if (fs_is_writing()) {            // 正在写数据，拒绝休眠            printf("文件系统忙，拒绝休眠\n");            return NOTIFY_STOP;        }        // 没在写，可以休眠        fs_sync();        fs_unmount();    }    return NOTIFY_OK;}// 文件系统优先级最高，第一个被通知static notifier_block_t fs_sleep_notifier = {    .callback = fs_sleep_handler,    .priority = 100,};

这样设计后，文件系统模块优先级最高，第一个收到休眠通知。如果它正在写数据，返回 NOTIFY_STOP，后面的 LCD、WiFi 都不会被通知到，休眠流程终止。

打个比方：老板说"下班"，但会计喊了一句"账还没算完"，于是大家都没法走。会计就是那个返回 NOTIFY_STOP 的角色。

这种机制在需要"协商"的场景特别有用，比如：

• • 电源管理：各模块投票决定是否可以休眠
• • 热插拔：设备拔出前确认没有正在使用
• • 配置变更：变更前检查是否会影响其他模块

 写在最后

通知链这东西，原理不复杂，代码量也不大，但它体现的设计思想是实打实的。

高内聚、低耦合这八个字，写代码的人都听过，但真正能在自己项目里落地的不多。通知链就是一个很好的切入点——它不需要你引入什么框架，不需要大规模重构，几十行代码就能搞定，却能显著改善模块间的依赖关系。

这种"发布-订阅"的思想，不只在嵌入式领域有用。你去看：

• • Android 的 Binder 机制
• • ROS 里的 Topic 通信
• • 前端的事件总线（EventBus）
• • 后端的消息队列（MQ）

底层逻辑都是一回事：解除发布者和订阅者之间的直接依赖。

如果你正在写的项目里有类似开头那种"上帝函数"，不妨试试通知链。改造成本不高，收益却很明显。

代码架构这东西，不是一朝一夕能练出来的。但每学会一种解耦的方法，你离"架构师"就近了一步。

🚀 嵌入式底层架构·进阶实战推荐

导语： 在嵌入式领域，只会写驱动的工程师很多，但懂架构、能设计通用框架的工程师很少。底层技术的终点是架构设计，如果你渴望突破职业天花板，掌握那些让代码“高内聚、低耦合”的工程哲学，以下内容不容错过。

💡 深度进阶：C 语言设计模式实战合集

专为嵌入式工程师打造，教你如何在资源受限环境下玩转面向对象。

本周重点推荐：