4、分层架构实战：应用层、服务层、驱动层的职责划分与接口设计
说到嵌入式软件的分层架构，很多人第一反应是「不就是把代码分成几个文件夹吗？」。嗯，我早年也这么干过——结果项目一复杂，改一个LED闪烁的延时，居然要翻三个文件，还差点把Wi-Fi协议栈搞崩了。
分层架构的核心，不是代码的物理分离，而是职责的边界定义。说白了，就是让每一层只干自己该干的事，别越界。
4.1 三层架构的职责边界
我习惯把嵌入式软件切成三层：应用层、服务层、驱动层。每一层都有明确的「领地」。
| 层级 | 核心职责 | 典型内容 | 依赖对象 |
|---|---|---|---|
| 应用层 | 业务逻辑、状态机、用户交互 | 任务调度、协议解析、UI流程 | 服务层接口 |
| 服务层 | 功能抽象、数据管理、策略封装 | 传感器融合、日志系统、参数管理 | 驱动层接口 |
| 驱动层 | 硬件操作、寄存器读写、中断处理 | GPIO、I2C、SPI、UART底层操作 | MCU外设 |
举个例子你就明白了。假设你要做一个温湿度采集器：
- 驱动层：只负责操作SHT30传感器的I2C时序，读出原始字节。
- 服务层：把原始字节换算成温度和湿度值，做滤波、单位转换。
- 应用层：决定「温度超过30度就开风扇」——它只调用服务层的
get_temperature()，根本不知道底层是I2C还是SPI。
我在一个智能家居项目里遇到过这样的坑：应用层代码直接调用了驱动层的i2c_write()。后来换了传感器型号，驱动接口变了，结果改了20多处应用代码。你说冤不冤？
4.2 接口设计：层与层之间的「契约」
接口是分层架构的灵魂。我个人的经验是：接口要稳定、抽象、最小化。
4.2.1 驱动层接口设计
驱动层暴露的接口，应该是对硬件操作的原子化抽象。比如：
/* 驱动层接口示例 */
int8_t sht30_init(void);
int8_t sht30_read_temperature(float *temp);
int8_t sht30_read_humidity(float *humi);
int8_t sht30_deinit(void);注意看，这里没有出现i2c_start()、i2c_stop()这些底层细节。调用者只需要知道「初始化」、「读温度」、「读湿度」就够了。
4.2.2 服务层接口设计
服务层是承上启下的关键。它把驱动层的原始数据加工成业务可用的信息。
/* 服务层接口示例 */
typedef struct {
float temperature;
float humidity;
uint32_t timestamp;
} env_data_t;
int8_t env_service_init(void);
int8_t env_service_get_data(env_data_t *data);
int8_t env_service_set_alert_threshold(float temp_high, float humi_high);服务层可以缓存数据、做均值滤波、甚至触发报警。应用层调用env_service_get_data()时，拿到的已经是处理好的结果。
我曾经在一个项目中，服务层还负责数据有效性校验。比如温度值超出-40~125度范围，直接返回错误码，而不是把脏数据往上抛。这个设计后来帮我们挡掉了好几次现场故障。
4.2.3 应用层接口设计
应用层基本不对外提供接口——它是消费方。但应用层内部的任务模块之间，也需要定义清晰的接口。
/* 应用层任务接口示例 */
void app_temp_monitor_task(void *param);
void app_display_task(void *param);
void app_alert_task(void *param);每个任务只通过服务层获取数据，任务之间通过消息队列或事件标志组通信，不直接调用对方的函数。
4.3 分层架构的依赖关系图
下面这张图，是我每次做架构设计时都会先画出来的。它清晰地展示了层与层之间的依赖方向。
4.4 实战中的避坑指南
理论说完了，聊聊我在实际项目中踩过的坑。
我曾经见过一个服务层函数，里面直接调用了
HAL_GPIO_WritePin()。后来换了MCU平台，所有HAL接口都变了，服务层代码几乎重写。正确做法：服务层只能调用驱动层暴露的抽象接口，永远不要直接操作寄存器或HAL。
有个同事为了「性能优化」，在应用层里直接读取了ADC寄存器。结果换了ADC通道后，应用层代码改了三天。
正确做法：应用层只调用服务层接口。性能问题通过服务层缓存或DMA解决，而不是绕过分层。
#include "driver/gpio.h"，直接打回。这是分层架构的红线。
4.5 接口设计的「最小暴露」原则
接口不是越多越好。我个人的原则是：只暴露调用方真正需要的。
比如一个温湿度传感器驱动，你不需要把sht30_calc_crc()暴露出来——那是驱动内部的事。你只需要暴露init、read、deinit就够了。
为什么？因为接口越多，耦合越重。你想想看，如果上层代码依赖了驱动层的CRC校验函数，以后换了不带CRC的传感器，上层代码也得改。这不就违背了分层的初衷吗？
| 原则 | 说明 | 反面案例 |
|---|---|---|
| 最小暴露 | 只暴露调用方必须的接口 | 把内部辅助函数也放在头文件里 |
| 稳定契约 | 接口一旦发布，尽量不修改 | 频繁修改接口参数类型 |
| 单一职责 | 一个接口只做一件事 | sht30_read_all()同时返回温度、湿度、状态 |
| 错误传递 | 所有接口统一返回错误码 | 有的返回指针，有的返回bool，有的直接死机 |
嗯，说到错误传递，我记得有个项目，驱动层返回NULL表示失败，服务层返回-1表示失败，应用层用false表示失败。调试的时候，一个错误要查三层代码才能定位。后来我统一改成int8_t错误码，世界清净了。
4.6 小结
分层架构不是什么高深的理论，它就是让代码各司其职。驱动层管硬件，服务层管逻辑，应用层管业务。接口是它们之间的契约，契约越清晰，代码越健壮。
下次你写代码前，不妨先画一张分层图，问问自己：这一行代码，应该放在哪一层？