第二讲：Wind River System Viewer 入门：工具架构、数据采集原理、Trace 与 Profile 模式的区别
好，咱们开始第二讲。今天聊的是 System Viewer，也就是我们常说的 SV。说实话，这工具我用了快十年了，每次调试复杂系统时，它都是我的首选。你想想看，一个系统跑着跑着突然卡顿，或者某个任务莫名其妙超时，这时候你怎么办？靠 printf 打日志？那效率太低了。System Viewer 就是干这个的——让你看到系统内部到底发生了什么。
一、工具架构：三层结构，各司其职
System Viewer 的架构其实不复杂，我习惯把它分成三层来理解：
- 数据采集层：跑在目标机上的 Agent，负责收集事件
- 数据传输层：通过某种通道把数据传到主机
- 数据展示层：主机上的 GUI 工具，负责解析和可视化
嗯，这里要注意一点：数据采集层是侵入式的。什么意思？就是它会在你的系统里插入一些 hook 点，用来捕获任务切换、中断发生、信号量操作这些事件。我在项目中遇到过一个问题——有个客户说 SV 采集数据时系统变慢了，后来发现是他把采集频率设得太高，导致 hook 函数占用了太多 CPU 时间。
二、数据采集原理：事件驱动，不是轮询
很多人以为 System Viewer 是像示波器那样不断采样，其实不是。它是事件驱动的——只有当特定事件发生时，才会记录一条日志。比如：
- 任务 A 被挂起
- 中断 ISR 进入
- 信号量被释放
- 内存分配失败
每个事件都带有一个时间戳，精度可以达到纳秒级。这些事件被缓存在目标机的内存里，然后通过以太网、串口或者 JTAG 传到主机。
我个人习惯用以太网传输，因为带宽大，不会丢数据。但如果你用的是串口，那就要小心了——串口速度慢，事件一多就会溢出。我记得有一次调试一个多核系统，事件量太大，串口根本扛不住，最后只能改用 JTAG 才把数据完整抓下来。
三、Trace 模式 vs Profile 模式：两种视角
好，接下来是重点——Trace 和 Profile 到底有什么区别？说白了，一个看细节，一个看全局。
| 特性 | Trace 模式 | Profile 模式 |
|---|---|---|
| 数据量 | 大，记录每个事件 | 小，只记录统计信息 |
| 时间精度 | 纳秒级 | 毫秒级 |
| 适用场景 | 定位具体问题 | 了解整体性能 |
| 对系统影响 | 较大 | 较小 |
| 典型用途 | 任务切换分析、中断延迟分析 | CPU 占用率、任务执行时间分布 |
3.1 Trace 模式：像看录像一样
Trace 模式会把系统里发生的每一个事件都记录下来。你可以在时间轴上看到：任务 A 在时间 T1 被抢占，任务 B 在 T2 开始运行，然后在 T3 释放了一个信号量，接着任务 C 被唤醒……
这种模式最适合用来回答「为什么」的问题。比如：为什么我的任务总是超时？用 Trace 模式一看，哦，原来是有个高优先级的中断一直在抢 CPU。
我曾经用 Trace 模式抓过一个诡异的 bug——一个任务每隔几分钟就会莫名其妙地挂起。Trace 日志显示，每次挂起前都有一个特定的中断发生。后来发现，那个中断处理函数里有个死循环，只是概率性触发。如果没有 Trace，这种问题根本没法查。
3.2 Profile 模式：像看统计报表
Profile 模式不记录每个事件，而是每隔一段时间采样一次，统计出各种指标。比如：CPU 总占用率、每个任务的 CPU 占用率、中断频率、信号量等待时间分布等等。
这种模式适合用来回答「是什么」的问题。比如：我的系统 CPU 占用率是多少？哪个任务最耗 CPU？用 Profile 模式跑个几分钟，结果就出来了。
嗯，这里有个坑要注意——Profile 模式是采样的，所以它只能给出近似值。如果你需要精确到纳秒级的数据，那还是得用 Trace 模式。我一般把 Profile 模式当作「体检」，Trace 模式当作「CT 扫描」。
3.3 什么时候用哪个？
我个人的经验是：
- 先 Profile，后 Trace：先用 Profile 模式跑一段时间，看看整体情况。如果发现某个任务 CPU 占用率异常高，或者某个中断触发频率异常，再用 Trace 模式去抓那个任务的执行细节。
- 系统启动阶段用 Trace：系统刚启动时，事件量不大，Trace 模式完全扛得住。而且启动阶段最容易出问题，比如任务初始化顺序不对、资源竞争等。
- 长时间运行用 Profile：如果你的系统要跑几天甚至几个月，那肯定不能用 Trace，数据量太大。Profile 模式可以长时间运行，只记录统计信息，对系统影响也小。
wdSysViewerStart() 和 wdSysViewerStop()。
四、实战经验：一个典型的调试流程
最后，我分享一个我常用的调试流程，供你参考：
- 发现问题：客户反馈系统偶尔卡顿，但无法稳定复现。
- Profile 模式跑 10 分钟：发现任务 A 的 CPU 占用率在某个时间段突然飙升到 80%。
- 设置触发条件：在任务 A 的 CPU 占用率超过 70% 时，自动启动 Trace 采集。
- Trace 模式抓 2 秒：看到任务 A 在某个循环里反复调用一个函数，那个函数里有个信号量等待超时。
- 定位根因：原来是另一个任务没有及时释放信号量，导致任务 A 一直在重试。
- 修复验证：修改代码后，再用 Profile 模式跑 30 分钟，确认问题不再出现。
你看，整个过程 Profile 和 Trace 交替使用，效率很高。如果你只用 Trace，那 10 分钟的数据量可能就有几十 GB，分析起来很痛苦。如果你只用 Profile，那又看不到具体的执行细节。
好，这一讲就到这里。下一讲我们会深入 Trace 模式，看看如何用时间轴视图分析任务切换和中断延迟。到时候我会分享一个我处理过的真实案例——一个因为中断嵌套导致系统崩溃的 bug，保证让你大开眼界。