1. 课程导入
做嵌入式产品这么多年，我见过太多团队在功耗和性能之间反复折腾。
你想想看，一个智能门锁，电池续航要一年，但用户开锁时又希望秒级响应。这就是典型的矛盾——功耗和性能，天生就是一对冤家。
Zephyr RTOS 给了我们很多调优工具，但工具再多，方向错了也是白搭。我个人习惯，在动手调优之前，先把整个博弈关系理清楚。
1.1 核心矛盾：为什么功耗和性能总是打架？
说白了，芯片就那么多电。跑得快，功耗就高；跑得慢，功耗就低。但产品不会让你只选一头。
我在项目中遇到过一款可穿戴设备，MCU 主频从 64MHz 降到 32MHz，功耗确实降了 40%，但传感器数据采集直接超时，用户体验一塌糊涂。
核心矛盾点：
- 高频运行 → 任务响应快，但动态功耗呈指数上升
- 深度睡眠 → 功耗极低，但唤醒延迟可能错过关键事件
- 外设常开 → 数据不丢，但漏电流持续消耗电池
- 外设频繁开关 → 省电，但开关瞬间的浪涌电流反而更高
嗯，这里要注意：功耗不是简单的加减法。你关掉一个外设，省了 10μA，但每次开关多耗 5μA 的浪涌，如果开关频率太高，反而更费电。
1.2 Zephyr 的功耗模型：从架构层面理解
Zephyr 的功耗管理不是拍脑袋的。它有一套完整的框架，从硬件到应用层都有对应机制。
| 层级 | 机制 | 作用范围 | 我踩过的坑 |
|---|---|---|---|
| 硬件层 | SoC 电源状态 (PM_STATE) | 整个芯片 | 曾经没配好 PM_STATE，芯片进不了深度睡眠 |
| 内核层 | Tickless Idle | 系统调度 | 默认 tick 周期太长，导致唤醒延迟超标 |
| 设备层 | 设备电源管理 (PM_DEVICE) | 单个外设 | SPI 总线没做 PM，一直漏电 |
| 应用层 | 策略决策 | 业务逻辑 | 传感器采集频率没做动态调整，白白耗电 |
你看，Zephyr 把功耗管理分成了四层。每一层都有对应的 API 和配置项。但问题是——很多人只用了最上面一层，下面三层根本没碰。
我的建议：调优要从硬件层开始。先确认 SoC 能不能进目标睡眠状态，再谈上层策略。否则上层写得再好，底层进不去也是白费。
1.3 性能指标：不能只看跑分
性能不是 CPU 跑多快，而是用户感知到的响应速度。
我曾经帮一个客户调优 BLE 网关。他们只看 MIPS，觉得主频越高越好。结果呢？功耗上去了，但数据吞吐量没变——因为瓶颈在 BLE 协议栈，不在 CPU。
我一般关注这几个性能指标：
- 任务响应延迟：从事件发生到任务开始处理的时间
- 中断延迟：中断触发到 ISR 开始执行的时间
- 唤醒时间：从睡眠状态到恢复执行的时间
- 吞吐量：单位时间内处理的数据量
- 上下文切换开销：切换任务消耗的 CPU 周期
你想想看，如果唤醒时间占了 5ms，而你的业务周期只有 10ms，那 CPU 一半时间都在唤醒上，性能能好吗？
1.4 调优总览：一张图看懂全局
下面这张图是我自己总结的调优框架。每次做新项目，我都会先对着这张图走一遍。
这张图的核心逻辑是：从目标出发，选策略，定手段，用工具，最后验证闭环。缺了任何一环，调优都可能走偏。
1.5 避坑指南：新手最容易犯的三个错误
错误一：只看平均功耗，不看峰值
我曾经调一个 NB-IoT 终端，平均功耗只有 20μA，看起来很好。结果一测峰值，发射瞬间飙到 300mA，直接把电池电压拉垮，系统复位了。所以，峰值功耗和平均功耗一样重要。
错误二：睡眠状态配得太深，唤醒来不及
有个项目，我把 SoC 配进了最深的关机状态，功耗确实低到 1μA。但唤醒需要 50ms，而业务要求 10ms 内响应。结果就是——省了电，丢了功能。后来我改用浅睡眠 + 外设保持，功耗 10μA，唤醒 2ms，完美满足需求。
错误三：忽略外设的漏电流
很多人只关注 CPU 功耗，忘了外设。我遇到过一块板子，CPU 深度睡眠只耗 5μA，但一个没关的 I2C 上拉电阻就漏了 20μA。查了半天才发现。所以，外设的漏电流一定要逐个排查。
1.6 本章小结：调优的底层逻辑
功耗与性能的博弈，本质上是资源分配的艺术。
Zephyr 给了我们丰富的调优手段，但工具只是手段，理解业务场景才是关键。你需要知道：
- 哪些任务对延迟敏感？
- 哪些外设可以容忍延迟开关？
- 系统的瓶颈到底在哪？
我个人习惯，拿到一个新项目，先花一天时间做功耗和性能的基线测量。不测不知道，一测吓一跳。很多时候，你以为的瓶颈，根本不是真正的瓶颈。
接下来的章节，我会从睡眠管理开始，一步步带你走完整个调优流程。嗯，准备好了吗？