4、内联函数与宏：函数调用开销的优化策略
函数调用，看似简单，背后却藏着不少开销。每次调用都要压栈、跳转、传参、恢复现场……在嵌入式这种资源受限的环境里，频繁调用小函数，代价可能比你想象的大得多。
我早年做一款传感器采集模块时，就吃过这个亏。一个读取温度的函数，在循环里被调了上千次，结果整个采集周期硬生生慢了 30%。后来一查，函数调用开销占了将近一半。从那以后，我对“小函数”就格外敏感。
解决这类问题，最直接的手段就是——内联。C 语言给了我们两个选择：宏（Macro）和内联函数（Inline Function）。它们都能消除调用开销，但用法和风险天差地别。
4.1 函数调用的真实成本
先算一笔账。一个典型的函数调用，在 ARM Cortex-M 上大概需要这些步骤：
| 步骤 | 操作 | 周期数（约） |
|---|---|---|
| 1 | 压栈（保存 R0-R3, LR） | 4-8 |
| 2 | BL 跳转 | 2-3 |
| 3 | 函数体执行 | N |
| 4 | 出栈 + 返回 | 4-8 |
你看，光是压栈出栈和跳转，就占了 10-20 个周期。如果函数体本身只有 5 条指令，那调用开销比实际干活还多。说白了，这就是在“空转”。
4.2 宏：古老而危险的利器
宏是预处理阶段直接做文本替换。没有调用，没有跳转，效率极高。但代价是——没有类型检查，容易产生副作用。
举个例子，一个求最大值的宏：
#define MAX(a, b) ((a) > (b) ? (a) : (b))用起来好像没问题：
int x = 5, y = 3;
int z = MAX(x, y); // 正常，z = 5但如果你这么写：
int z = MAX(x++, y); // 展开后：((x++) > (y) ? (x++) : (y))
// x 被自增了两次！这就是宏的经典陷阱——参数副作用。我当年调试一个电机控制程序，电流值忽大忽小，查了两天才发现是宏里套了自增运算。从那以后，我给自己定了个规矩：宏的参数，绝不允许带副作用。
宏的避坑指南
- 每个参数都要加括号：防止运算符优先级问题
- 整个表达式也要加括号：防止被外部运算符“拆散”
- 避免使用自增/自减：宏展开后可能执行多次
- 多语句宏用 do-while(0) 包裹：保证语法正确
// 多语句宏的正确写法
#define SAFE_SWAP(a, b) do { \
typeof(a) _tmp = (a); \
(a) = (b); \
(b) = _tmp; \
} while(0)MYLIB_MAX，避免冲突。
4.3 内联函数：编译器的“建议”
内联函数是 C99 引入的关键字。它告诉编译器：“这个函数，你最好把它展开到调用处。”但注意，这只是建议，不是命令。编译器有权忽略它。
static inline int max(int a, int b) {
return (a > b) ? a : b;
}内联函数的好处很明显：
- 有类型检查：编译器会检查参数类型，出错时给警告
- 没有副作用问题：参数只求值一次
- 支持调试：大多数 IDE 可以单步进入内联函数
但也不是完美无缺。内联函数如果太大，会导致代码膨胀。我见过一个项目，把所有函数都加了 inline，结果固件体积翻了一倍，Flash 直接爆了。
4.4 宏 vs 内联函数：一张表说清楚
| 对比维度 | 宏 | 内联函数 |
|---|---|---|
| 处理阶段 | 预处理（文本替换） | 编译期（语法分析后） |
| 类型检查 | 无 | 有 |
| 参数副作用 | 容易触发 | 安全 |
| 调试支持 | 差（展开后难以跟踪） | 好（可单步） |
| 代码膨胀 | 每次调用都展开 | 由编译器决定 |
| 适用场景 | 常量定义、简单运算、汇编封装 | 小函数、类型安全要求高 |
你看，内联函数在大多数场景下都优于宏。那宏是不是该被淘汰了？也不是。有些场景，宏依然是唯一选择。
4.5 宏的“不可替代”场景
我总结了三个宏仍然必须出马的场景：
- 获取调用位置信息：
__FILE__、__LINE__只能在宏里用 - 条件编译：
#ifdef、#if是宏的专属领域 - 汇编指令封装：比如 ARM 的
__NOP()、__WFI()，通常用宏定义
// 场景1：调试打印宏
#define DEBUG_PRINT(fmt, ...) \
printf("[%s:%d] " fmt, __FILE__, __LINE__, ##__VA_ARGS__)
// 场景3：汇编指令封装
#define ENABLE_IRQ() __asm volatile("cpsie i")
#define DISABLE_IRQ() __asm volatile("cpsid i")4.6 内联策略的实战选择
实际项目中，我一般按这个优先级来决策：
- 默认不用：先写普通函数，让编译器优化
- 性能热点分析：用 profiler 找出真正的热点函数
- 小函数手动内联：对热点中的小函数，加
static inline - 宏兜底：只有内联函数搞不定时，才用宏
举个例子，一个 I2C 起始信号的产生函数：
// 普通函数版本
void i2c_start(void) {
SDA_HIGH();
delay_us(5);
SCL_HIGH();
delay_us(5);
SDA_LOW();
delay_us(5);
SCL_LOW();
}
// 内联版本（适合高频调用）
static inline void i2c_start_inline(void) {
SDA_HIGH();
delay_us(5);
SCL_HIGH();
delay_us(5);
SDA_LOW();
delay_us(5);
SCL_LOW();
}在 I2C 通信中，每次传输字节都要调用 start 信号。如果总线频率是 400kHz，每秒可能调用几千次。这时候，内联版本的收益就很明显了。
4.7 本章知识体系
下面这张图，帮你理清内联优化策略的整体脉络：