嵌入式Linux下QT GUI主应用与旋钮监测应用的常用通信方式有哪些

以下是根据你的场景筛选的常用可行方案，按适配优先级排序：

Qt原生IPC方案（主程序为Qt环境优先选择，开发成本最低） #

• Qt D-Bus：基于Linux标准D-Bus机制封装的Qt模块，是Linux桌面/嵌入式系统级IPC的主流选择。你可以将旋钮监测程序封装为D-Bus服务端，注册位置上报信号接口，Qt主程序作为客户端直接监听信号即可，低延迟、支持异步通知，完全适配小数据量的旋钮位置实时上报场景，绝大多数嵌入式Linux发行版默认预装D-Bus服务，无需额外部署依赖。
• Qt Remote Objects（QtRO）：Qt官方专门面向进程/跨设备通信的模块，API封装程度更高，只需要提前编写.rep接口描述文件，编译后自动生成对应的调用、监听类，不需要手动处理数据序列化、连接保活等底层逻辑，同时支持本地Unix域套接字、TCP两种传输模式，后续如果要把旋钮监测程序迁移到外接硬件上也无需修改通信逻辑。
• Qt本地Socket（QLocalSocket/QLocalServer）：Qt对Unix域套接字的轻量封装，性能高于TCP回环通信，无额外模块依赖，你可以自定义极简通信协议（比如每次固定传输4字节的位置数值），开发门槛极低，适合不想引入D-Bus、QtRO等重模块的轻量化场景。

Linux原生通用IPC方案（旋钮监测程序不使用Qt框架时优先选择） #

• Unix域套接字：Linux原生高性能本地IPC方案，比TCP回环性能更高、稳定性更强，不会出现端口占用冲突，支持流、数据报两种传输模式，仅上报旋钮位置的场景用数据报模式即可，无需处理粘包问题。
• 命名管道（FIFO）：开发成本最低的方案，直接用标准文件操作API读写即可，你可以在系统固定路径下创建一个FIFO文件，旋钮程序往文件内写入位置数据，Qt主程序监听文件读事件即可获取数据，缺点是仅支持半双工通信，仅做单向位置上报完全够用。
• 共享内存+信号量：性能最高的IPC方案，适合高频、大数据量的传输场景，仅传输旋钮位置的场景下使用过重，还需要自行实现进程同步逻辑，一般不做优先推荐。
• 自定义信号（Signal）：如果旋钮档位仅10个以内的简单状态，可以直接用Linux自定义信号（SIGUSR1、SIGUSR2等），搭配sigqueue还可以附带简单的数值参数，缺点是可传递的数据量极小，仅适用于极简上报场景。

其他可选方案 #

• TCP/UDP回环通信：走127.0.0.1本地回环传输，优势是后续如果需要把两个程序部署到不同设备上几乎无需修改代码，缺点是性能低于Unix域套接字，还会占用本地端口。
• 本地MQTT代理：如果你的系统已经部署了MQTT broker，或者需要把旋钮位置同时上报给多个进程，可以选择该方案，但是需要额外依赖服务，轻量化场景不推荐。

内容的提问来源于stack exchange，提问作者Bob Kang