第三章 代码级功耗优化：编译器、循环与内存访问

代码级的功耗优化，说白了就是让芯片少干活、干快活。编译器选项、循环展开、分支预测、内存访问模式——这些听起来像是性能调优的手段，但它们在功耗上的影响，往往比你想的要大得多。

我刚开始做低功耗项目时，总觉得功耗是硬件的事，软件能做的有限。直到有一次，一个传感器节点的电池续航死活达不到设计指标，最后发现罪魁祸首是编译器优化等级没开对。嗯，从那以后我再也不敢轻视代码级功耗优化了。

3.1 编译器优化选项：选对等级，功耗立降

编译器优化选项，是功耗优化的第一道门槛。不同的优化等级，生成的代码在功耗上可能差出 20%~40%。

优化等级	典型功耗节省	适用场景	风险
-O0	基准	调试阶段	代码体积大，功耗高
-Os	15%~25%	Flash 受限的 MCU	可能牺牲部分性能
-O2	20%~35%	通用低功耗场景	编译时间增加
-O3	25%~40%	计算密集型任务	代码膨胀，可能增加功耗

除了全局优化等级，还有几个编译器选项值得单独关注：

• -ffunction-sections -fdata-sections：让链接器只链接实际用到的函数和数据，减少代码体积，间接降低功耗。
• -fomit-frame-pointer：省略帧指针寄存器，减少函数调用开销，省下几个时钟周期。
• -flto（链接时优化）：跨文件优化，能消除冗余代码，但会增加编译时间。

3.2 循环展开：用空间换时间，但别过头

循环展开，说白了就是把循环体复制几份，减少循环控制指令的执行次数。这样做的好处是减少了分支跳转和循环计数器的更新，坏处是代码体积增大。

为什么会这样？因为每次循环迭代，CPU 都要执行一次条件判断和跳转。这些操作虽然单个功耗不大，但累积起来就很可观了。

// 原始循环
for (int i = 0; i < 4; i++) {
    array[i] = array[i] * 2;
}

// 手动展开
array[0] = array[0] * 2;
array[1] = array[1] * 2;
array[2] = array[2] * 2;
array[3] = array[3] * 2;

展开后的代码少了 4 次条件判断和 4 次跳转。在 Cortex-M4 上，这大约能省下 12~16 个时钟周期。对于高频调用的函数，效果很明显。

实际项目中，我建议遵循以下原则：

• 循环次数固定且较小（4~16 次）时，手动展开收益最大。
• 循环体本身很短（几条指令）时，展开效果明显。
• 循环次数很大时，交给编译器自动展开，或者使用 #pragma unroll 指令。

3.3 分支预测：让 CPU 少猜错

分支预测失败，是功耗的隐形杀手。每次预测错误，CPU 都要清空流水线，重新取指。在 Cortex-M 系列中，一次分支预测失败大约浪费 3~5 个时钟周期。对于低功耗 MCU，这已经是不小的开销了。

你想想看，如果在一个高频中断服务函数里，有一个分支预测失败率很高的条件判断，那功耗会白白浪费多少？

优化分支预测的核心思路就一条：让最常见的情况走最快的路径。

// 不推荐：异常情况放在前面
if (error_flag) {
    handle_error();  // 很少执行
} else {
    normal_process(); // 经常执行
}

// 推荐：正常情况放在前面
if (!error_flag) {
    normal_process(); // 经常执行
} else {
    handle_error();  // 很少执行
}

为什么这样能优化？因为大多数 CPU 的分支预测器会假设条件跳转不成立（即继续顺序执行）。把大概率发生的情况放在 if 分支里，能减少预测失败的概率。

if (__builtin_expect(!error_flag, 1)) {
    normal_process();
} else {
    handle_error();
}

这个宏告诉编译器：!error_flag 为真的概率很高（第二个参数 1 表示期望为真）。编译器会据此调整代码布局，把大概率路径放在顺序执行的位置。

我记得在一个 BLE 协议栈项目中，用 __builtin_expect 优化了 3 个关键分支后，整体功耗降低了约 5%。虽然不多，但对于电池供电的设备，这 5% 可能就是几天的续航差距。

3.4 内存访问模式：对齐、连续、少跨页

内存访问模式对功耗的影响，往往被低估。实际上，一次未对齐的内存访问，可能比对齐访问多消耗 2~3 倍的功耗。

为什么会这样？因为 CPU 的内存总线通常按字（4 字节）或半字（2 字节）对齐访问。如果数据没有对齐，CPU 需要额外读取两次，然后拼接数据。这多出来的总线访问，就是功耗的浪费。

访问模式	额外功耗	典型场景
对齐访问	0%	结构体成员按 4 字节对齐
未对齐访问	+50%~100%	强制类型转换后的指针访问
跨页访问	+100%~200%	数组跨越 Flash 页边界
非连续访问	+20%~50%	链表遍历

优化内存访问模式，我总结了三条原则：

1. 数据对齐：结构体成员按自然对齐排列，必要时使用 __attribute__((aligned(4)))。
2. 连续访问：尽量使用数组而非链表，利用 CPU 的预取机制。
3. 减少跨页：将频繁访问的数据放在同一 Flash 页或 RAM 区域内。

3.5 知识体系总览

下面这张图，把本章的核心知识点串起来了。你可以把它当作一个快速参考框架。

3.6 实战建议：从哪开始？

如果你刚开始做代码级功耗优化，我建议按这个顺序来：

1. 先改编译器选项：这是投入产出比最高的。从 -O0 切到 -Os，功耗立竿见影。
2. 再优化热点循环：用 profiler 找出 CPU 占用最高的函数，手动展开小循环。
3. 然后处理分支：把高频路径放在 if 分支，低频路径放在 else 分支。
4. 最后检查内存访问：确保结构体对齐，数组连续，避免跨页。