1. 性能调优概述：为什么嵌入式代码需要优化？时间效率与代码压缩的平衡艺术

嵌入式开发圈子里有个老说法：「硬件不够，软件来凑」。这话糙理不糙。我做了十几年嵌入式，见过太多项目因为代码效率问题翻车——有的跑不到目标帧率，有的Flash塞不下新功能，有的电池撑不过半天。

说白了，嵌入式代码优化不是炫技，是刚需。

1.1 为什么嵌入式代码必须优化？

先看几个真实场景：

• 资源受限：MCU的Flash可能只有64KB，RAM只有8KB。你写的每一行代码都在跟这些硬指标较劲。
• 实时性要求：电机控制、传感器采样、通信协议栈——错过一个deadline，系统就出故障。
• 功耗敏感：电池供电的设备，CPU多跑1ms，待机时间就少一截。
• 成本压力：选更便宜的芯片，意味着代码必须更高效。

我记得有一次做工业控制器的项目，客户指定了一颗8位MCU，Flash只有32KB。功能需求列了满满两页纸。团队里有人提议换芯片，但成本已经锁死。最后我们硬是通过代码压缩和算法优化，把固件塞进了32KB，还跑出了要求的响应时间。嗯，那段时间加班确实多，但收获也大。

1.2 时间效率 vs 代码压缩：一对天生的冤家

你想想看，优化往往意味着取舍：

优化方向	常用手段	时间效率	代码体积
查表法	预计算+查表代替实时计算	↑ 大幅提升	↓ 体积增大（表占空间）
循环展开	减少循环控制开销	↑ 小幅提升	↓ 体积增大
函数内联	消除函数调用开销	↑ 小幅提升	↓ 体积增大
共用代码段	合并相似逻辑	→ 可能略降	↑ 体积减小
状态机压缩	用位域/枚举代替分支	→ 基本不变	↑ 体积减小

从表格能看出来：想快，往往要牺牲空间；想小，往往要牺牲速度。但这不是绝对的——有些优化能同时兼顾，比如用合适的数据结构、避免冗余计算。

1.3 优化的三个层次

我个人习惯把优化分成三个层次，从高到低：

1. 架构层：选对算法、数据结构、任务划分。这是收益最大的层次。
2. 代码层：循环优化、内存访问模式、编译器选项。中规中矩的优化。
3. 指令层：内联汇编、寄存器分配、指令流水线。收益有限，但有时不得不做。

我曾经接手过一个项目，前任工程师在指令层折腾了两个月，把一段汇编代码优化得眼花缭乱。结果我一测，整个系统80%的时间花在另一个模块的冒泡排序上。把排序换成快速排序，性能直接翻倍。这就是架构层的威力。

1.4 嵌入式优化的核心原则

做优化这么多年，我总结了几条铁律：

• 先测量，后优化：没有profiling数据，不要动代码。
• 优化瓶颈，而非全部：帕累托法则在这里同样适用——20%的代码消耗80%的时间。
• 保持可读性：优化后的代码如果没人能看懂，那就是技术债。
• 回归测试：优化不能改变功能。每次改完都要跑测试。
• 文档记录：为什么这么改？权衡了什么？给后来人留条活路。

1.5 本章知识体系

下面这张图概括了嵌入式代码优化的核心脉络：

1.6 一个简单的优化案例

光说不练假把式。看一段实际代码：

// 优化前：每次循环都计算平方
for (int i = 0; i < 100; i++) {
    int val = read_sensor(i);
    int squared = val * val;  // 每次都要算
    process(squared);
}

// 优化后：查表法
static const int square_lut[256] = {
    0, 1, 4, 9, 16, 25, /* ... 预计算 */
};

for (int i = 0; i < 100; i++) {
    int val = read_sensor(i);
    int squared = square_lut[val & 0xFF];  // 查表，O(1)
    process(squared);
}

这个例子很简单，但体现了优化的本质：用空间换时间。查表法让每次计算从乘法变成了内存访问，速度提升明显。代价是256字节的Flash空间——在大多数场景下，这笔交易是划算的。

1.7 本章小结

嵌入式代码优化不是玄学，是工程。它要求你：

• 清楚知道为什么要优化（资源、实时、功耗、成本）
• 明确优化什么（时间还是体积，或者两者兼顾）
• 掌握怎么优化（从架构到指令，层层递进）
• 始终牢记平衡（没有银弹，只有取舍）

接下来的课程，我会带着你从实际项目出发，一步步拆解这些优化技术。每一章都会有真实案例、可运行的代码、以及我踩过的坑。准备好了吗？