📚 课程目录第3章嵌入式状态机设计原则

嵌入式状态机设计原则：四个核心法则

做状态机设计这些年，我踩过不少坑。刚开始写状态机时，总觉得能跑就行。后来项目越做越大，代码越来越乱，才明白设计原则有多重要。

今天聊的这四个原则，是我在实际项目中反复验证过的。说白了，它们就是帮你写出「好维护、好扩展、不出错」的状态机代码。

核心原则一览：

单一职责原则 —— 一个状态只做一件事
开闭原则 —— 对扩展开放，对修改关闭
状态显式化 —— 状态变化要看得见
避免状态爆炸 —— 用组合代替继承

原则一：单一职责原则

一个状态只做一件事。听起来简单，做起来不容易。

我记得有个项目，同事写了个「CONNECTING」状态，里面既要做网络连接，又要处理用户输入，还要更新显示。结果出问题时，根本分不清是哪个环节挂了。

判断标准：如果一个状态的处理函数超过 50 行，或者包含两个以上不相关的逻辑分支，就该拆分了。

好的做法是这样的：

// 错误示范：一个状态做三件事
void state_connecting(void) {
    // 1. 网络连接
    if (tcp_connect() != OK) { ... }
    // 2. 用户输入处理
    if (uart_has_data()) { ... }
    // 3. 显示更新
    lcd_update();  
}

// 正确做法：拆成三个状态
void state_tcp_connect(void) {
    // 只做网络连接
    if (tcp_connect() == OK) {
        set_state(STATE_AUTH);
    }
}

void state_handle_input(void) {
    // 只处理用户输入
    if (uart_has_data()) {
        process_command();
    }
}

void state_update_display(void) {
    // 只更新显示
    lcd_update();
    set_state(STATE_IDLE);
}

原则二：开闭原则

对扩展开放，对修改关闭。说白了就是：加新功能时，别去改已经跑得好好的代码。

我曾经维护过一个通信协议栈，每次加一个新命令，都要在状态机的主 switch-case 里加分支。改了一年，那个函数膨胀到 800 行。后来重构时，我用了函数指针表，新增命令只需要加一条表项。

做法	新增功能	风险
switch-case 硬编码	修改主函数	高（可能影响已有逻辑）
函数指针表	添加表项	低（不影响其他状态）
状态注册机制	注册新状态处理器	极低（完全解耦）

注意：开闭原则不是让你把所有代码都抽象化。嵌入式资源有限，过度设计反而坏事。我一般只在「确定会扩展」的地方用这个原则。

原则三：状态显式化

状态变化要看得见。代码里不能藏着掖着。

你想想看，一个状态机如果状态变化全靠全局变量暗地里传递，调试时有多痛苦？我曾经接手过一个项目，状态切换靠 5 个全局标志位组合判断。出问题时，我花了三天才理清状态流转路径。

显式化的做法：

用枚举定义所有状态 —— 不要用魔法数字
状态切换集中管理 —— 统一通过 set_state() 函数
记录状态历史 —— 至少保留最近 3 次状态切换记录
状态入口/出口动作明确 —— 进入状态做什么，离开时清理什么

// 显式化示例
typedef enum {
    STATE_INIT,
    STATE_IDLE,
    STATE_RUNNING,
    STATE_ERROR,
    STATE_SLEEP
} state_t;

// 状态历史记录
static state_t state_history[8];
static uint8_t history_index = 0;

void set_state(state_t new_state) {
    // 记录历史
    state_history[history_index++ % 8] = current_state;
    
    // 执行旧状态退出动作
    state_exit_actions[current_state]();
    
    // 切换状态
    current_state = new_state;
    
    // 执行新状态进入动作
    state_entry_actions[new_state]();
}

原则四：避免状态爆炸

状态爆炸是状态机设计中最常见的坑。两个维度各 5 个状态，组合起来就是 25 个状态。三个维度呢？125 个。

我做过一个智能家居网关项目，最初设计了「设备类型 × 连接方式 × 用户权限」的三维状态矩阵。写到一半发现状态数量已经失控了。后来改用分层状态机 + 状态组合，才把问题解决。

避免状态爆炸的三种策略：

分层状态机 —— 顶层状态控制业务流程，子状态处理细节
正交状态 —— 用多个独立状态机并行运行
状态压缩 —— 用位域或标志位组合表示正交维度

举个例子，一个通信设备的状态：

// 错误做法：笛卡尔积式状态枚举
typedef enum {
    // 连接状态 × 认证状态 × 数据状态
    STATE_DISCONNECTED_UNAUTH_NO_DATA,
    STATE_DISCONNECTED_UNAUTH_HAS_DATA,
    STATE_DISCONNECTED_AUTHED_NO_DATA,
    STATE_DISCONNECTED_AUTHED_HAS_DATA,
    STATE_CONNECTING_UNAUTH_NO_DATA,
    // ... 继续膨胀到 27 个状态
} state_t;

// 正确做法：分层 + 正交
// 第一层：连接状态机
typedef enum {
    LINK_DISCONNECTED,
    LINK_CONNECTING,
    LINK_CONNECTED
} link_state_t;

// 第二层：认证状态机  
typedef enum {
    AUTH_NONE,
    AUTH_PENDING,
    AUTH_OK
} auth_state_t;

// 第三层：数据状态机
typedef enum {
    DATA_EMPTY,
    DATA_PENDING,
    DATA_SENDING
} data_state_t;

我的经验：当状态数量超过 15 个时，就该考虑分层或正交设计了。别等到 50 个状态才动手重构，那时候改起来成本太高。

四个原则的优先级

实际项目中，这四个原则不是平级的。我个人的排序是：

优先级	原则	理由
1	状态显式化	可读性和可调试性的基础
2	单一职责	直接影响代码质量和可维护性
3	避免状态爆炸	决定架构的可扩展性
4	开闭原则	锦上添花，资源受限时可适当妥协

嗯，这四个原则说起来简单，真正用好需要项目经验的积累。我建议你在下一个状态机项目里，先盯着「状态显式化」和「单一职责」这两个原则做。等熟练了，再慢慢把另外两个加进来。