Windows下FastDDS进程间通信实践：从编译到联调全攻略

在Windows上做多进程架构，很多人的第一反应是命名管道或者Socket。我在一个桌面端采集项目里需要两个独立进程高频交换数据，最开始也用的TCP回环，后来数据量一上来，延迟和丢包问题开始冒头，这才把FastDDS拉进来。这篇文章把我从零到跑通整个流程的过程整理出来，包含选型、编译、代码、联调，还有一堆Windows环境下特有的坑。如果你正打算在Windows上用FastDDS做进程间通信，又不想在编译和环境适配阶段浪费太多时间，这篇应该能帮你少走不少弯路。

FastDDS是eProsima开源的DDS实现，底层走RTPS协议，核心能力是发布/订阅通信。它最大的特点是不管两个进程在同一台机器还是不同机器，只要处在同一个域、订阅同一个主题，就能自动发现并通信，不需要中间服务器，也不需要手动维护连接。这个特性拿到Windows桌面端做进程间通信，可以说是降维打击：你不需要关心TCP连接断了怎么重连，不需要处理UDP丢包，不需要自己设计心跳保活，把业务逻辑丢进发布/订阅模型里就行。

这篇文章适合几类人：刚接触DDS、想在Windows上快速跑通例子的新手；已经在用其他IPC方案、遇到瓶颈想换技术的开发者；以及需要在嵌入式或机器人项目里统一通信架构，先拿Windows环境做原型验证的团队。我会从编译环境讲到代码实现，再讲到联调排错，尽量把每个环节都展开，让你照着做就能跑起来。

1. 项目定位与整体思路

1.1 为什么在Windows上还用DDS

DDS一般在机器人、自动驾驶、军工通信这些领域出现得多，桌面端和工业软件里其实同样有价值。原因很简单：DDS天生就是为了解决"分布式场景下的实时通信"设计的，它天然同时具备跨进程、跨机器的能力，而且自带QoS和动态发现。把它用在Windows上的进程间通信，不是杀鸡用牛刀，而是一次到位。

从架构角度看，DDS对应用层暴露的是发布/订阅模型，你在设计模块时只需要关心业务逻辑，不需要关心"到底谁在收数据、收多少、收多久"。底层RTPS协议会自动做主题匹配和数据路由，新进程上线、老进程退出，都是动态发现的，不需要改任何代码。

在Windows桌面上做进程间通信，常见的候选方案无非是命名管道、Socket回环、共享内存、消息队列。它们各有适用场景，但也各有痛点：命名管道简单可靠，但只适合Windows环境，迁移到Linux就废了；Socket回环通用性最强，但UDP不保证可靠，TCP又引入端口管理和重连逻辑；共享内存性能最好，但同步、生命周期管理全得自己写，一个进程崩溃还要处理残留对象。

FastDDS在这些方案里属于"设计和性能都想兼顾"的那一类，而且它本身就有共享内存传输实现，单机场景性能并不弱。更关键的是，它的QoS机制可以针对不同数据流设置不同的可靠性策略，一套框架支持多种通信诉求，这是传统IPC方案很难做到的。

1.2 方案选型：FastDDS对比其他IPC手段

我放一张对比表，方便大家直观感受：

我实际项目里，同一个机器上同时跑采集和渲染两个进程，数据有两路：一路低频状态同步，一路高频传感器数据上报。这两路消息对可靠性和实时性的要求完全不同。状态消息不能丢，采集数据则可以接受少量丢帧换低延迟。传统方案基本是"要么全可靠要么全尽力"，调不了这么细。FastDDS的QoS可以针对不同Topic设置不同策略，一套框架解决多种通信需求，这是它最打动我的地方。

2. 环境准备与编译踩坑记录

2.1 依赖清单和版本选择

在Windows上编译FastDDS，首先要确认系统环境。我用的是Windows 10 22H2和Windows 11均测试过，Visual Studio 2019或2022都行，社区版就够了，安装时必须勾选"使用C++的桌面开发"这个工作负载。CMake版本建议3.20以上，FastDDS 2.10以后的版本对CMake版本要求越来越严，用太老版本的CMake会在配置阶段直接报错。

还需要准备Git，以及可选的Java JDK 11+和Gradle，这两个是给FastDDS-Gen用的。FastDDS-Gen是一个IDL编译器，用来把自定义的消息定义生成C++代码。如果你只是用简单的字符串或预定义类型通信，可以完全跳过FastDDS