1. ROS2性能全景：为什么性能重要？
大家好，欢迎来到这门课的第一章。
说实话，我见过太多团队把ROS2跑起来就完事了。节点能通信，话题能收发，就以为大功告成。结果呢？机器人一上产线，延迟飙到几百毫秒，CPU占用率直接拉满，系统动不动就丢数据。嗯，这种场景我太熟悉了。
性能问题，说白了就是你的系统在真实负载下能不能扛得住。ROS2虽然比ROS1强不少，但用不好，照样翻车。
1.1 为什么性能重要？
我个人的经验是：性能不是锦上添花，而是生存底线。
你想想看，一个自动驾驶小车，从感知到决策再到控制，整个链路如果延迟超过100ms，可能就撞上了。一个机械臂，如果控制周期不稳定，工件就报废了。这不是危言耸听，我在项目中就遇到过因为DDS配置不当导致丢帧，差点把协作机器人手臂给撞了。
所以，性能优化的核心目标就三个：
- 延迟要低 —— 数据从发到收，越快越好
- 吞吐量要大 —— 单位时间能处理的消息越多越好
- 实时性要稳 —— 延迟不能忽高忽低，抖动要小
核心观点：ROS2的性能优化，本质上是在资源约束下，找到延迟、吞吐量、实时性三者之间的最佳平衡点。
1.2 性能瓶颈的常见类型
做性能调优，第一步是知道瓶颈在哪。我习惯把瓶颈分成四类，你对照着排查就行。
1.2.1 CPU瓶颈
这是最常见的。节点里回调函数写得不好，或者计算量太大，CPU就满了。
- 回调阻塞：一个回调里做了耗时操作，其他回调排队等着
- 序列化/反序列化：消息太大，序列化耗时高
- DDS内部处理：DDS的线程调度也会吃CPU
避坑指南：我曾经在项目中遇到一个节点，回调里直接做图像处理，结果CPU占用率95%。后来改成异步处理，用单独的线程池，CPU降到30%。记住：回调里别干重活。
1.2.2 内存瓶颈
内存泄漏、频繁分配释放、大消息拷贝，这些都是内存杀手。
- 零拷贝失效：ROS2的零拷贝机制没用好，数据来回拷贝
- 消息堆积：发布者太快，订阅者来不及处理，队列爆了
- 内存碎片：频繁new/delete导致碎片化
1.2.3 网络瓶颈
分布式系统里，网络往往是短板。
- 带宽不足：大图像、点云数据把带宽占满
- 延迟抖动：Wi-Fi不稳定，或者交换机配置不对
- 丢包重传：DDS的可靠性策略导致重传，进一步加剧延迟
1.2.4 I/O瓶颈
读写磁盘、访问传感器，这些I/O操作如果慢，整个系统就被拖住。
- 日志写入：rosbag记录数据时，磁盘I/O成为瓶颈
- 传感器驱动：读取激光雷达、相机数据时，驱动层效率低
注意：很多时候瓶颈是混合的。比如CPU高可能是因为网络丢包导致重传，内存高可能是因为消息队列没设置好。别孤立地看问题。
1.3 性能优化的基本原则
做优化这么多年，我总结了几条铁律：
- 先测量，再优化 —— 没有数据，别瞎猜。用perf、ros2 topic hz、ros2 topic bw这些工具先测
- 找瓶颈，而不是优化所有 —— 80%的性能问题集中在20%的代码上
- 从架构层面优化 —— 改代码不如改设计。比如用组件节点代替独立节点，减少进程间通信
- 理解DDS配置 —— ROS2的性能很大程度上取决于底层DDS的配置。QoS策略、传输方式，这些都要懂
我的经验：有一次项目延迟高，我花了三天优化回调代码，效果甚微。后来发现是DDS的传输模式没选对，从UDP改成共享内存，延迟直接降了80%。所以，先看架构，再看代码。
1.4 性能度量指标
没有度量，就没有优化。我常用的指标就三个：
| 指标 | 定义 | 测量工具 | 典型目标值 |
|---|---|---|---|
| 延迟 | 消息从发布到接收的时间差 | ros2 topic hz、自定义时间戳 |
< 10ms（控制类） |
| 吞吐量 | 单位时间处理的消息数量或数据量 | ros2 topic bw、ros2 topic hz |
根据场景定，越高越好 |
| 实时性 | 延迟的抖动程度（标准差） | 统计延迟分布、最大最小延迟 | 抖动 < 1ms |
小技巧：测量延迟时，记得在发布端和接收端都用同一个时钟源（比如系统时钟），否则时间戳对不上。我吃过这个亏，测出来的数据全是错的。
1.5 知识体系总览
下面这张图，是我对本章知识体系的总结。你可以把它当作后续学习的导航图。
这张图把本章的核心内容串起来了。从核心目标出发，识别四大瓶颈，遵循优化原则，用三个指标度量，最后用工具落地。后面的章节，我们会逐一深入每个环节。
一句话总结：性能优化不是玄学，是科学。有方法、有工具、有指标。别怕，跟着我一步步来。