面试翻车现场
面试一家做自动驾驶的公司，面试官问："你的ROS2系统延迟是多少？怎么优化的？"
我说大概几十毫秒吧，没太关注。他皱了皱眉："做实时系统，延迟是最基本的指标。你知道怎么测量端到端延迟吗？DDS的延迟主要在哪里？"
这个问题让我意识到，做机器人不能只关注功能实现，性能指标同样重要。特别是自动驾驶、工业控制这类对延迟敏感的场景。
通信延迟优化
ROS2的通信延迟主要来自三个环节：序列化/反序列化、DDS传输、回调处理。
序列化开销和消息大小成正比。一个简单的Float64消息序列化只要几微秒，但一个100万像素的点云可能要几毫秒。优化思路是减小消息大小——对点云做降采样，对图像做压缩，只传必要字段。
DDS传输延迟和网络配置有关。默认的DDS配置不一定是最优的。比如FastDDS可以通过XML配置调整分段大小、缓冲区大小、传输协议等。CycloneDDS也有类似的配置选项。一般来说，局域网内用UDP直连延迟最低，如果不需要跨网段通信，可以关掉组播发现，用单播配置。
回调处理延迟和Node内部逻辑有关。如果回调函数里有耗时操作（比如图像处理、路径规划），会阻塞后续消息的处理。解决办法是把耗时操作放到单独的线程或者用异步处理。
测量端到端延迟的方法：在发布端打时间戳，在订阅端计算当前时间和消息时间戳的差值。注意这个差值包含了时钟偏差，所以两台机器之间测的不准。同一台机器上的测量比较可靠。
内存优化
ROS2系统的内存消耗主要来自几个方面：DDS中间件、消息数据缓存、点云和图像数据。
DDS中间件本身会占用一定内存（通常几十MB），这部分不太好优化。但消息数据的缓存是可以控制的。
QoS的History深度直接影响内存占用。如果你设了history_depth=100，DDS会缓存最近100条消息。对于大数据量话题（点云、图像），这个值设太大内存会爆。建议传感器数据用history_depth=1，只保留最新的。
点云是内存大户。一个100万像素的点云，每个点32字节（xyz+intensity+rgb），就是32MB。如果每秒10帧，每秒处理320MB数据。优化方法是在驱动端就降采样——只保留需要的点，丢掉远处的或者地面上的。
图像数据也是大头。一张1920x1080的RGB图像是6MB，如果同时处理多个相机的数据，内存消耗很快。可以用压缩图像（CompressedImage）减少传输和存储开销，但解压需要额外CPU。
CPU优化
CPU优化主要关注两个方面：减少不必要的计算，合理分配线程。
不必要的计算包括：发布了没人订阅的数据（用get_subscription_count()检查一下再计算）、过高的处理频率（如果下游只需要10Hz的数据，没必要100Hz处理）、重复的TF查询（缓存查询结果，不要每帧都查）。
线程分配在Component化后变得更重要。同一个Container里的多个Component共享线程池，如果某个Component的回调耗时太长，会影响其他Component。给耗时的Component分配独立的CallbackGroup和线程，避免互相干扰。
另一个CPU优化手段是利用SIMD和GPU加速。点云处理、图像处理的计算密集部分，用PCL的SIMD优化或者OpenCV的GPU模块可以显著提升速度。但这需要额外的开发工作。
DDS配置调优
DDS是ROS2通信的核心，它的配置直接影响性能。
以CycloneDDS为例，几个关键配置项：Internal/SocketReceiveBufferSize影响接收缓冲区大小，大数据量场景要调大；Internal/MinimumSocketReceiveBufferSize设最小缓冲区；Discovery/SPDPRequestInterval控制发现间隔，节点数量多时可以增大以减少网络负载。
以FastDDS为例，可以通过XML配置调整：分段大小（maxMessageSize）、缓冲区大小、线程数量等。对于低延迟场景，可以开启共享内存传输（SHM），同一台机器上的Node之间不走网络栈，延迟能降低一个数量级。
共享内存传输是性能优化的大杀器。如果你的所有Node都在同一台机器上，强烈建议开启SHM。CycloneDDS和FastDDS都支持，配置方法不同但原理一样。
具体说说CycloneDDS开启共享内存的配置方法。你需要在XML配置文件中添加<SharedMemory>段落，设置enabled为true。配置完后用ros2 topic info -v验证，如果看到传输方式显示为"shared memory"就说明生效了。我有一次配置完发现延迟没变化，排查了半天发现是环境变量CYCLONEDDS_URI指向了旧的配置文件，新配置根本没加载。用export CYCLONEDDS_URI=file:///path/to/your/config.xml指定正确路径后重启节点就正常了。另外，FastDDS的共享内存配置需要通过FASTDDS_DEFAULT_PROFILES_FILE环境变量指定XML文件，里面配置<transport_descriptors>添加SHMTransport。两个DDS实现的配置方式不同，但效果差不多——同一台机器上的通信延迟能从毫秒级降到微秒级。
实际优化案例
我之前做过一个移动机器人项目，初始版本端到端延迟大概在120ms左右，目标是压到50ms以内。
第一步优化点云处理。原始点云大概120万点，驱动端降采样到30万点，光这一步延迟就降了30ms。第二步是把感知Pipeline从同步改成异步，用多线程并行处理不同区域的数据。第三步开启DDS共享内存传输，因为所有Node都在同一台工控机上。
最终延迟压到了35ms左右。其中共享内存贡献最大，光DDS传输延迟就从8ms降到了不到1ms。点云降采样贡献其次。异步处理的效果反而没有预期明显，因为瓶颈主要在数据量而不是处理逻辑。
这个项目让我学到一点：性能优化一定要先测量，找到真正的瓶颈再动手。很多时候你以为是算法慢，其实是数据传输占了大头。
性能分析工具
ROS2生态里有几个好用的性能分析工具。
ros2 topic hz和ros2 topic bw可以实时查看话题的发布频率和带宽。如果频率不稳定或者带宽异常高，说明有问题。
rqt_plot可以画曲线图，把延迟、CPU占用等数据可视化。你发一个包含延迟数据的topic，用rqt_plot实时看曲线，比看终端里的数字直观多了。
btmon是DDS层面的监控工具，可以看到每个话题的消息数量、传输速率、丢包率等。FastDDS还有专门的fastdds discovery和监控工具。
Linux系统层面，top/htop看CPU，free -h看内存，iostat看磁盘IO。如果想看更详细的CPU占用分解，可以用perf工具做性能剖析，找到具体哪个函数占CPU最多。
对于实时性要求高的场景，可以用trace-cmd和trace-cmd report做内核级的延迟分析，看看线程调度、中断处理的耗时分布。
上线后的持续监控
性能优化不是一次性的工作，上线后需要持续监控。
建议建立性能基线。系统上线前跑一遍性能测试，记录关键指标（端到端延迟、CPU占用、内存峰值、DDS丢包率）作为基线。之后每次版本更新都对比基线，如果某个指标明显劣化，在合入代码前就要排查原因。
自动化性能回归测试很有价值。在CI流水线中加入性能测试环节，每次构建后自动跑一组标准场景，收集性能数据并生成趋势图。如果延迟突然从35ms跳到60ms，趋势图上一眼就能看出来，不用等到线上出问题才发现。
监控告警也要做。用Prometheus采集性能指标，Grafana做可视化，设置告警阈值。当CPU持续超过80%或者延迟超过100ms时自动通知值班人员。
面试中怎么聊
面试官问性能优化，你可以说："通信延迟优化主要从三方面入手——减小消息大小、优化DDS配置、异步处理耗时回调。内存优化重点是控制QoS深度和降采样大数据。CPU优化要避免无效计算和合理分配线程。DDS层面，共享内存传输是同一台机器上最有效的优化手段，延迟能降低一个数量级。实际项目中要先用工具测量瓶颈在哪，不要盲目优化。"能讲出具体优化案例和数据的候选人，在面试中非常有竞争力。面试官想听到的不只是理论，而是你真的做过什么、效果怎么样。比如"我把延迟从120ms优化到35ms"，比"我知道要优化DDS配置"有说服力得多。另外，如果你能提到上线后持续监控性能指标的习惯，面试官会更加认可。
上一篇：第139篇 ROS2调试技巧——常见错误的排查思路和工具
下一篇预告：第141篇 ROS2日志系统——rcl_logging配置和日志分析
