1. 性能调优概述：嵌入式系统性能指标、调优目标与原则、调优方法论

大家好，我是你们的老朋友。今天咱们聊聊嵌入式系统性能调优这件事。说实话，我入行那会儿，调优基本靠猜——哪里卡顿就改哪里，改完能不能跑全靠运气。后来踩的坑多了，才慢慢总结出一套方法论。今天就把这些经验掰开揉碎了讲给你听。

1.1 嵌入式系统的性能指标

先说说性能指标。很多人一上来就问「系统快不快」，其实这是个很模糊的问题。我习惯把性能拆成几个维度来看：

• 响应时间：从事件发生到系统做出反应的时间。比如按键按下到屏幕亮起，这个时间如果超过100ms，用户就会觉得「卡」。
• 吞吐量：单位时间内能处理的任务数量。比如一个数据采集系统，每秒能处理多少帧数据。
• 实时性：任务能否在规定时间内完成。硬实时系统（比如安全气囊）错过截止时间就是事故，软实时系统（比如视频播放）偶尔卡顿还能接受。
• 资源利用率：CPU、内存、总线、外设的占用情况。我见过一个项目，CPU占用率才30%，但内存带宽已经跑满了——瓶颈往往不在你想的地方。
• 功耗：嵌入式设备很多是电池供电的，性能调优不能只看速度，还得看「每瓦性能」。说白了，就是跑得快还得吃得少。

1.2 调优目标与原则

调优目标怎么定？我个人的习惯是：先问三个问题。

1. 用户能感知到什么？ 比如一个智能门锁，用户只关心「按指纹后门锁反应快不快」，至于后台有没有跑OTA升级，用户不关心。
2. 系统最不能忍受什么？ 医疗设备不能死机，工业控制器不能丢数据。这些是底线，调优不能碰。
3. 成本允许吗？ 换一颗更快的CPU当然能提升性能，但成本涨了30%，老板能同意吗？

基于这些，我总结了三条调优原则：

原则	说明	我的经验
二八原则	80%的性能问题集中在20%的代码上	别上来就优化所有代码，先找到热点
可量化原则	没有数据就没有调优	我习惯先跑一遍基准测试，记录基线数据
渐进式原则	一次只改一个变量，改完立刻验证	我曾经一次改了三个参数，结果系统崩了，根本不知道是哪个改出的问题

1.3 调优方法论

方法论这东西，说白了就是一套「遇到问题怎么下手」的流程。我常用的方法分四步：

第一步：测量与监控

没有测量就没有发言权。我习惯在系统里埋一些性能探针，比如：

• 用GPIO翻转来测量关键函数的执行时间
• 用DMA的计数寄存器来监控数据吞吐量
• 用RTOS的任务状态钩子来统计CPU占用率

举个例子，测量一个函数执行时间：

// 用GPIO翻转测量函数执行时间
void measure_function(void) {
    GPIO_SetBits(GPIOA, GPIO_Pin_0);  // 开始
    // 你的业务代码
    GPIO_ResetBits(GPIOA, GPIO_Pin_0); // 结束
}
// 用示波器看GPIOA_0的脉宽，就是函数执行时间

第二步：定位瓶颈

拿到数据后，怎么找瓶颈？我一般按这个顺序排查：

1. CPU是否过载？ 看任务调度延迟，如果高优先级任务频繁被抢占，说明CPU不够用。
2. 内存是否够用？ 看堆栈溢出、内存碎片、缓存命中率。我遇到过一个问题：系统跑着跑着突然变慢，查了半天发现是malloc/free导致的内存碎片，后来改用静态内存池解决了。
3. I/O是否阻塞？ 看外设的等待时间。比如SPI通信，如果从设备响应慢，CPU就得空转等待。
4. 中断是否合理？ 中断太频繁会拖垮系统。我建议把高频中断（比如1ms一次）改成DMA+定时器轮询，能省下不少CPU。

第三步：制定方案

找到瓶颈后，怎么改？我列几个常用手段：

• 算法优化：比如把O(n²)的排序改成O(n log n)，效果立竿见影。
• 空间换时间：用查表法代替实时计算，用缓存减少重复计算。
• 任务拆分：把一个大任务拆成多个小任务，利用空闲时间片执行，避免长时间阻塞。
• 硬件加速：能用DMA就别用CPU搬数据，能用硬件CRC就别软件算。

第四步：验证与迭代

改完之后，一定要重新测量。我见过有人改完代码自我感觉良好，结果一测发现性能反而下降了。为什么会这样？因为优化可能引入了新的瓶颈。比如你用查表法加速了计算，但查表占用了更多内存，导致缓存命中率下降——这就是典型的「按下葫芦浮起瓢」。

所以我的习惯是：每次改完，跑一遍完整的基准测试，对比前后数据。如果性能提升不明显，就回退方案，换一条路试试。

1.4 总结

好了，这一章的内容就这些。总结一下：

• 性能指标要量化，别凭感觉说「快」或「慢」。
• 调优原则是二八原则、可量化、渐进式。
• 方法论就是测量→定位→方案→验证，循环迭代。

下一章咱们会深入讲「性能测量工具与分析方法」，到时候我会带大家实操一下怎么用示波器、逻辑分析仪和性能分析工具。咱们下章见。