1. 性能优化导论：为什么嵌入式系统需要性能优化？

大家好，我是你们这门课的主讲。在嵌入式这行摸爬滚打了十几年，我见过太多项目因为性能问题翻车。有的产品上市后才发现响应慢，有的量产了才发现功耗压不住。说白了，性能优化不是锦上添花，而是嵌入式产品的生死线。

你可能会问：现在芯片主频越来越高，内存越来越大，为什么还要抠这点性能？嗯，我当年也这么想过。直到有一次，我负责一个工业控制器的项目，CPU跑在200MHz，内存只有256KB。客户要求中断响应必须在10微秒以内。那时候我才真正明白——嵌入式系统的资源永远是有限的，而性能优化，就是在有限资源里榨出最大价值。

1.1 嵌入式系统的性能瓶颈

嵌入式系统的性能瓶颈，我习惯把它分成三类。这三类问题，我在项目里都踩过坑。

瓶颈类型	典型表现	我踩过的坑
CPU瓶颈	计算密集任务耗时过长，中断响应延迟高	曾经一个FFT算法没做循环展开，CPU占用率直接飙到95%
内存瓶颈	频繁的malloc/free导致碎片，Cache miss率高	结构体没对齐，访问速度慢了3倍，查了两天才发现
I/O瓶颈	外设读写慢，DMA配置不当，总线竞争	SPI通信没用DMA，CPU空转等数据，功耗直接翻倍

1.2 为什么嵌入式系统尤其需要优化？

你想想看，桌面程序跑慢了，用户最多抱怨两句。嵌入式系统跑慢了，会怎样？

• 实时性失效：汽车安全气囊该弹的时候没弹，后果是什么？
• 功耗失控：物联网设备电池撑不过一天，产品直接废了。
• 成本超标：为了性能换更贵的芯片，BOM成本压不住。
• 可靠性下降：堆栈溢出、内存泄漏，系统跑着跑着就挂了。

我记得有个做智能门锁的朋友，产品上市后用户反馈开锁慢。一查，是加密算法没优化，每次认证要多花200毫秒。用户觉得体验差，退货率飙升。后来优化了算法，把时间压到50毫秒以内，问题才解决。你看，200毫秒的差距，可能就是产品的生死。

1.3 本课程的学习路径

这门课一共30章，我把它设计成三个递进阶段。每个阶段都有实战项目，不是光讲理论。

1.4 课程目标：你能带走什么？

学完这门课，我希望你能做到三件事：

1. 看得准：拿到一段代码，能快速判断性能瓶颈在哪。是CPU不够？还是内存访问慢了？还是I/O在拖后腿？
2. 改得对：知道用什么技术去优化。内存对齐、循环展开、Cache预取、SIMD……每种技术适合什么场景，心里有数。
3. 测得清：优化前后能量化对比。不是凭感觉说“快了”，而是用示波器、性能计数器、profiling工具给出数据。

1.5 一个真实的性能优化案例

讲个我自己的故事吧。几年前做一款音频处理设备，主控是Cortex-M4，主频168MHz。产品原型做出来，发现音频处理延迟太高，有可感知的“回声”。

一开始我怀疑是算法复杂度问题，花了两天优化算法，效果不明显。后来用profiling工具一查，发现80%的CPU时间花在了一个数据拷贝函数上。那个函数长这样：

// 优化前：逐字节拷贝
void audio_copy(uint8_t *dst, uint8_t *src, uint32_t len) {
    for (uint32_t i = 0; i < len; i++) {
        dst[i] = src[i];
    }
}

你看，这个函数每次只拷贝一个字节，循环次数等于数据长度。对于音频数据，一次处理4096个样本，就要循环4096次。而且每次访问都是非对齐的，Cache利用率极低。

优化后的代码：

// 优化后：32位对齐拷贝 + 循环展开
void audio_copy_fast(uint32_t *dst, uint32_t *src, uint32_t len_words) {
    // 一次拷贝4字节，循环次数减少到1/4
    for (uint32_t i = 0; i < len_words; i += 4) {
        dst[i]   = src[i];
        dst[i+1] = src[i+1];
        dst[i+2] = src[i+2];
        dst[i+3] = src[i+3];
    }
}

改动不大，就是把逐字节改成逐32位字，再做了4路循环展开。结果呢？

版本	执行时间（微秒）	CPU占用率	优化幅度
逐字节拷贝	128 μs	76%	—
32位对齐拷贝	42 μs	25%	提升3倍
32位对齐+循环展开	31 μs	18%	提升4倍

就这一处优化，音频延迟从可感知降到几乎不可感知。CPU占用率从76%降到18%，功耗也下来了。你看，有时候性能优化就是这么简单——找到热点，用对技术，效果立竿见影。