1. 课程导入
在嵌入式实时操作系统的工程实践中，“能跑起来”与“跑得稳、跑得快、跑得省”之间往往隔着一条很深的鸿沟。RT-Thread 作为一款应用广泛的国产实时操作系统，提供了线程调度、IPC、设备框架、内存管理、DFS、网络协议栈等丰富组件。组件越多，系统行为越复杂，性能问题就越难凭直觉定位。本课程的目标，是帮助你把“性能调试与优化”从经验型的手艺，变成一套可复现、可度量、可验证的工程方法。
一、学习目标：从现象到根因的闭环能力
本课程不追求罗列 API，而是围绕一条主线展开：观测 → 度量 → 定位 → 优化 → 回归验证。学完之后，你应当具备以下能力：
- 能说清 RT-Thread 中影响性能的关键机制：线程调度与优先级、时钟节拍、临界区与关中断、IPC 阻塞唤醒、内存分配、Cache 与总线访问。
- 能使用 FinSH/MSH、list_thread、list_timer、list_sem、list_mem 等命令快速获取系统运行态快照。
- 能借助 CPU 占用率统计、线程栈水位、执行时间测量、逻辑分析仪与 GPIO 打点等手段量化性能指标。
- 能针对启动慢、响应抖动、吞吐不足、内存碎片、功耗偏高等典型问题给出优化方案并验证收益。
- 能建立性能基线，把优化前后的数据放进同一张表里对比，避免“感觉变快了”的伪优化。
二、核心概念：先建立统一的语言
在讨论性能之前，需要先统一几个高频概念，否则团队沟通时很容易各说各话。
| 概念 | 含义 | 常见观测手段 |
|---|---|---|
| 实时性 | 系统对外部事件在确定时间内响应的能力，关注最坏情况而非平均值 | 中断延迟打点、示波器/逻辑分析仪 |
| 吞吐量 | 单位时间内完成的有效工作量，如网络包速率、采样帧率 | 计数器统计、吞吐压测 |
| CPU 占用率 | 空闲线程之外的时间占比，反映 CPU 繁忙程度 | CPU 使用率统计、idle hook |
| 抖动 | 周期任务实际执行间隔的波动范围 | 时间戳记录、最大/最小间隔统计 |
| 栈水位 | 线程栈历史最大使用量，用于判断栈是否过大或濒临溢出 | list_thread 的 max used |
| 内存碎片 | 空闲内存总量足够但无法满足连续分配请求 | list_mem、memheap 统计 |
这些指标之间存在权衡关系。例如提高采样吞吐量可能推高 CPU 占用率，缩短临界区可能增加上下文切换次数。优化的本质，是在约束条件下寻找最合适的平衡点，而不是把某一个指标压到极致。
三、整体知识框架：一张图看清全貌
下图给出本课程的知识框架。左侧是观测与度量手段，中间是被观测的系统对象，右侧是优化方向与验证闭环。理解这张图，有助于你在遇到问题时快速判断“该看哪里、该改哪里”。
四、方法流程：一次完整的性能排查怎么走
面对“系统卡顿”“响应变慢”这类模糊描述，建议按下面的顺序推进，避免一上来就改代码。
- 定义问题与指标：把“卡”翻译成可度量指标，例如“按键到屏幕刷新超过 200 ms”“周期任务抖动超过 5 ms”。
- 建立基线：在未修改代码前记录 CPU 占用率、栈水位、关键路径耗时，作为后续对比依据。
- 缩小范围：用 list_thread 查看各线程状态与优先级，判断是某个线程长期占用 CPU，还是频繁阻塞唤醒。
- 定位热点：结合 GPIO 打点或时间戳，测量中断服务程序、临界区、内存分配等可疑路径的耗时。
- 实施优化：一次只改一个变量，例如先调整优先级，再考虑缩短临界区，避免多因素耦合导致无法归因。
- 回归验证：重复同一压测场景，对比优化前后数据，确认收益真实且未引入新问题。
下面是一段典型的现场排查命令记录，可作为日常调试的起点：
msh /> list_thread
thread pri status sp stack size max used left tick error
-------- --- ------- ---------- ---------- ------ ---------- ---
tshell 20 ready 0x00000060 0x00001000 18% 0x0000000a OK
sensor 15 suspend 0x00000080 0x00000800 62% 0x00000005 OK
comm 12 ready 0x00000090 0x00001000 41% 0x00000003 OK
tidle0 31 ready 0x00000040 0x00000200 35% 0x00000010 OK
msh /> list_mem
total memory: 65536
used memory : 28672
maximum allocated memory: 32768
msh /> free
从上面的输出可以读出：sensor 线程栈水位已达 62%，需要关注是否接近溢出；comm 线程优先级较高且处于 ready，若其内部存在长循环，就可能挤压低优先级任务。这些判断都建立在“先看数据”的基础上。
五、典型场景与常见误区
举一个常见场景：某设备按键响应偶发延迟。初学者往往直接怀疑按键驱动，但实际原因可能是高优先级通信线程在临界区内执行了耗时操作，导致中断被延迟响应。此时正确的做法是先测量中断延迟，再检查临界区代码，而不是盲目修改按键扫描周期。
另一个误区是忽视编译器优化等级与 Cache 配置的影响。同一段代码在 -O0 与 -O2 下的执行时间可能相差数倍，开启 D-Cache 后内存访问模式也会显著改变性能特征。因此，性能数据必须连同编译配置、主频、Cache 状态一起记录，否则不同人测出的结果无法比较。
六、学习路径建议
本课程后续内容将沿着“观测工具 → 调度与中断 → IPC 与内存 → 设备与网络 → 综合调优”的顺序展开。建议你按以下节奏学习：
- 先掌握 FinSH 命令与 CPU 占用率统计，能独立获取系统快照。
- 再理解调度器与中断机制，能解释优先级反转、临界区过长带来的后果。
- 然后深入 IPC 与内存管理，能根据场景选择信号量、邮箱、消息队列或内存池。
- 最后结合设备框架与网络协议栈，完成端到端的性能调优与回归验证。