尧图网站建设 
zbus信号机制完全指南MatchRule订阅与SignalEmitter发射D-Bus信号【免费下载链接】zbusRust D-Bus crate.项目地址: https://gitcode.com/gh_mirrors/zb/zbuszbus是 Rust 生态中功能最完善的 D-Bus 通信 crate它的信号机制由两对核心 API 组成用MatchRule订阅感兴趣的信号用SignalEmitter向外发射信号。无论你是想监控 systemd 服务状态、实现桌面应用间的实时通知还是开发自己的 Linux IPC 服务掌握这套「订阅 发射」流程都是必过的第一课。本文用最少代码带你快速上手。 先搞懂D-Bus 信号到底是什么D-Bus 消息分四种方法调用、方法返回、错误、信号。方法调用一问一答调用方会等待返回值信号单向广播发出去就不管了没有返回值也不要求对方在线。一句话总结信号就是「公告栏」——服务状态变了就贴张公告谁感兴趣谁来读。zbus 中信号的完整生命周期角色核心 API所在模块发射方服务SignalEmitterzbus/src/object_server/signal_emitter.rs接收方客户端Proxy 的receive_*流zbus/src/proxy/mod.rs过滤订阅MatchRulezbus/src/match_rule/mod.rs⚠️ 关键认知总线上不会主动把广播信号发给所有客户端你必须先用匹配规则「登记订阅」总线才会把符合条件的信号转发给你。 订阅信号方式一Proxy 流式接收推荐这是 zbus 最顺手的姿势用#[proxy]宏声明信号签名宏会自动生成receive_信号名()方法返回一条Stream每次收到信号就吐出一个元素。以监控 systemd 新任务为例完整代码见zbus/examples/watch-systemd-jobs.rs#[proxy( default_service org.freedesktop.systemd1, default_path /org/freedesktop/systemd1, interface org.freedesktop.systemd1.Manager )] trait Systemd1Manager { // 声明 systemd 的 JobNew 信号签名 #[zbus(signal)] fn job_new(self, id: u32, job: OwnedObjectPath, unit: String) - zbus::Result(); } async fn watch_systemd_jobs() - zbus::Result() { let connection Connection::system().await?; let systemd_proxy Systemd1ManagerProxy::new(connection).await?; // 宏自动生成了 receive_job_new()返回信号流 let mut new_jobs_stream systemd_proxy.receive_job_new().await?; while let Some(msg) new_jobs_stream.next().await { let args: JobNewArgs msg.args().unwrap(); println!(JobNew: unit{} id{}, args.unit, args.id); } Ok(()) }三个要点#[zbus(signal)]只是声明签名不需要实现receive_job_new()内部会自动完成订阅登记订阅JobNew这个信号每个流元素里的参数被宏打包成了JobNewArgs结构体直接按字段取用即可。 订阅信号方式二MatchRule 手动匹配Proxy 方式适合「我盯着某一个信号」的场景而当你想按条件批量过滤比如只看某个发送者、某类参数值时就该用MatchRule构建器。它对应 D-Bus 规范中的「匹配规则」常见字段字段含义msg_type消息类型信号订阅通常设为Type::Signalsender限定信号发送者的总线名interface/member限定接口名和信号名add_arg/arg_path按信号参数值进一步过滤以订阅「属性变更」公告为例use zbus::MatchRule; let rule MatchRule::builder() .msg_type(zbus::message::Type::Signal) .sender(org.freedesktop.DBus)? .interface(org.freedesktop.DBus.Properties)? .member(PropertiesChanged)? .add_arg(org.zbus)? .build(); // 规则还能序列化成字符串再解析回来方便存储和传输 let rule_str rule.to_string(); let parsed MatchRule::try_from(rule_str.as_str())?;MatchRule支持Display与TryFromstr互转规则本质上就是一个形如typesignal, senderorg.freedesktop.DBus, memberPropertiesChanged的字符串。构建器源码位于zbus/src/match_rule/builder.rs。 发射信号SignalEmitter 的正确打开方式服务侧要发信号先拿到一个SignalEmitter实例再调用emit(接口名, 信号名, 参数)let emitter SignalEmitter::new(connection, /org/zbus/MyGreeter)?; emitter .emit(org.zbus.MyGreeter1, GreetedEveryone, ()) .await?;配合#[interface]宏会更优雅用#[zbus(signal_emitter)]属性让宏自动把发射器注入到方法参数里完整示例见zbus/src/object_server/mod.rs文档与 book 中的 service 章节#[interface(name org.zbus.MyGreeter1)] impl Greeter { // 方法参数自动注入 SignalEmitter无需手动创建 async fn go_away( self, #[zbus(signal_emitter)] emitter: SignalEmitter_, ) - zbus::Result() { // 信号由宏生成直接发射 emitter.greeted_everyone().await?; Ok(()) } /// 声明信号实现由宏自动生成 #[zbus(signal)] async fn greeted_everyone(emitter: SignalEmitter_) - zbus::Result(); /// 属性变更时宏会自动发射对应的 Changed 信号 #[zbus(property)] async fn set_greeter_name(mut self, name: String) { self.name name; } }两个实用技巧定向发送信号默认是广播用emitter.set_destination(总线名)可以只发给某个特定对端unicast实现在zbus/src/object_server/signal_emitter.rs第 68 行属性自动通知用#[zbus(property)]声明带 setter 的属性后zbus 会在属性更新时自动替你广播PropertiesChanged信号客户端订阅该信号即可实现属性变更推送。 实战场景我该用哪种组合需求推荐做法监听 systemd 任务/单元状态变化Proxy receive_job_new()流监听任意服务的属性变更MatchRule匹配PropertiesChanged监听对象新增/删除MatchRule匹配InterfacesAdded/InterfacesRemoved自己服务里状态变化通知 UI#[zbus(signal)]SignalEmitter私有通知只发给指定客户端SignalEmitter::set_destinationMatchRule构建器自带的文档示例覆盖了两类典型订阅属性变更、ObjectManager 对象新增可直接参考zbus/src/match_rule/mod.rs顶部的注释示例。 新手常见问题 FAQ1. 订阅了却收不到信号确认三件事msg_type设为Signal、sender/interface/member与真实信号一致、参数过滤值没有写错。最简单的排查法是先构建一条只限定类型的宽规则再逐步收紧。2. 信号会丢失吗信号是即发即弃的广播没订阅、总线繁忙或客户端断开时都不会重发。要求可靠的交付就用「方法调用 返回」信号只用于锦上添花的状态通知。3. 同步代码里能用吗可以。zbus 提供阻塞版 APIzbus/src/blocking/目录Connection::blocking_system()配合阻塞连接即可完成订阅与发射。4. 如何验证信号真的发出来了用系统自带的dbus-monitor命令在总线上旁听能直观看到信号从哪个服务发出、带了什么参数非常适合调试。小结订阅简单场景用 Proxy 自动生成的receive_*流复杂过滤用MatchRule构建器发射服务侧用SignalEmitter::emit配合#[zbus(signal)]宏几乎零样板代码核心心法信号是单向公告栏——先订阅、再发射缺一不可。掌握这两对 API你就能在 Rust 世界里自如地接入 Linux 系统服务生态了。【免费下载链接】zbusRust D-Bus crate.项目地址: https://gitcode.com/gh_mirrors/zb/zbus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 zbus信号机制完全指南：MatchRule订阅与SignalEmitter发射D-Bus信号
zbus信号机制完全指南MatchRule订阅与SignalEmitter发射D-Bus信号【免费下载链接】zbusRust D-Bus crate.项目地址: https://gitcode.com/gh_mirrors/zb/zbuszbus是 Rust 生态中功能最完善的 D-Bus 通信 crate它的信号机制由两对核心 API 组成用MatchRule订阅感兴趣的信号用SignalEmitter向外发射信号。无论你是想监控 systemd 服务状态、实现桌面应用间的实时通知还是开发自己的 Linux IPC 服务掌握这套「订阅 发射」流程都是必过的第一课。本文用最少代码带你快速上手。 先搞懂D-Bus 信号到底是什么D-Bus 消息分四种方法调用、方法返回、错误、信号。方法调用一问一答调用方会等待返回值信号单向广播发出去就不管了没有返回值也不要求对方在线。一句话总结信号就是「公告栏」——服务状态变了就贴张公告谁感兴趣谁来读。zbus 中信号的完整生命周期角色核心 API所在模块发射方服务SignalEmitterzbus/src/object_server/signal_emitter.rs接收方客户端Proxy 的receive_*流zbus/src/proxy/mod.rs过滤订阅MatchRulezbus/src/match_rule/mod.rs⚠️ 关键认知总线上不会主动把广播信号发给所有客户端你必须先用匹配规则「登记订阅」总线才会把符合条件的信号转发给你。 订阅信号方式一Proxy 流式接收推荐这是 zbus 最顺手的姿势用#[proxy]宏声明信号签名宏会自动生成receive_信号名()方法返回一条Stream每次收到信号就吐出一个元素。以监控 systemd 新任务为例完整代码见zbus/examples/watch-systemd-jobs.rs#[proxy( default_service org.freedesktop.systemd1, default_path /org/freedesktop/systemd1, interface org.freedesktop.systemd1.Manager )] trait Systemd1Manager { // 声明 systemd 的 JobNew 信号签名 #[zbus(signal)] fn job_new(self, id: u32, job: OwnedObjectPath, unit: String) - zbus::Result(); } async fn watch_systemd_jobs() - zbus::Result() { let connection Connection::system().await?; let systemd_proxy Systemd1ManagerProxy::new(connection).await?; // 宏自动生成了 receive_job_new()返回信号流 let mut new_jobs_stream systemd_proxy.receive_job_new().await?; while let Some(msg) new_jobs_stream.next().await { let args: JobNewArgs msg.args().unwrap(); println!(JobNew: unit{} id{}, args.unit, args.id); } Ok(()) }三个要点#[zbus(signal)]只是声明签名不需要实现receive_job_new()内部会自动完成订阅登记订阅JobNew这个信号每个流元素里的参数被宏打包成了JobNewArgs结构体直接按字段取用即可。 订阅信号方式二MatchRule 手动匹配Proxy 方式适合「我盯着某一个信号」的场景而当你想按条件批量过滤比如只看某个发送者、某类参数值时就该用MatchRule构建器。它对应 D-Bus 规范中的「匹配规则」常见字段字段含义msg_type消息类型信号订阅通常设为Type::Signalsender限定信号发送者的总线名interface/member限定接口名和信号名add_arg/arg_path按信号参数值进一步过滤以订阅「属性变更」公告为例use zbus::MatchRule; let rule MatchRule::builder() .msg_type(zbus::message::Type::Signal) .sender(org.freedesktop.DBus)? .interface(org.freedesktop.DBus.Properties)? .member(PropertiesChanged)? .add_arg(org.zbus)? .build(); // 规则还能序列化成字符串再解析回来方便存储和传输 let rule_str rule.to_string(); let parsed MatchRule::try_from(rule_str.as_str())?;MatchRule支持Display与TryFromstr互转规则本质上就是一个形如typesignal, senderorg.freedesktop.DBus, memberPropertiesChanged的字符串。构建器源码位于zbus/src/match_rule/builder.rs。 发射信号SignalEmitter 的正确打开方式服务侧要发信号先拿到一个SignalEmitter实例再调用emit(接口名, 信号名, 参数)let emitter SignalEmitter::new(connection, /org/zbus/MyGreeter)?; emitter .emit(org.zbus.MyGreeter1, GreetedEveryone, ()) .await?;配合#[interface]宏会更优雅用#[zbus(signal_emitter)]属性让宏自动把发射器注入到方法参数里完整示例见zbus/src/object_server/mod.rs文档与 book 中的 service 章节#[interface(name org.zbus.MyGreeter1)] impl Greeter { // 方法参数自动注入 SignalEmitter无需手动创建 async fn go_away( self, #[zbus(signal_emitter)] emitter: SignalEmitter_, ) - zbus::Result() { // 信号由宏生成直接发射 emitter.greeted_everyone().await?; Ok(()) } /// 声明信号实现由宏自动生成 #[zbus(signal)] async fn greeted_everyone(emitter: SignalEmitter_) - zbus::Result(); /// 属性变更时宏会自动发射对应的 Changed 信号 #[zbus(property)] async fn set_greeter_name(mut self, name: String) { self.name name; } }两个实用技巧定向发送信号默认是广播用emitter.set_destination(总线名)可以只发给某个特定对端unicast实现在zbus/src/object_server/signal_emitter.rs第 68 行属性自动通知用#[zbus(property)]声明带 setter 的属性后zbus 会在属性更新时自动替你广播PropertiesChanged信号客户端订阅该信号即可实现属性变更推送。 实战场景我该用哪种组合需求推荐做法监听 systemd 任务/单元状态变化Proxy receive_job_new()流监听任意服务的属性变更MatchRule匹配PropertiesChanged监听对象新增/删除MatchRule匹配InterfacesAdded/InterfacesRemoved自己服务里状态变化通知 UI#[zbus(signal)]SignalEmitter私有通知只发给指定客户端SignalEmitter::set_destinationMatchRule构建器自带的文档示例覆盖了两类典型订阅属性变更、ObjectManager 对象新增可直接参考zbus/src/match_rule/mod.rs顶部的注释示例。 新手常见问题 FAQ1. 订阅了却收不到信号确认三件事msg_type设为Signal、sender/interface/member与真实信号一致、参数过滤值没有写错。最简单的排查法是先构建一条只限定类型的宽规则再逐步收紧。2. 信号会丢失吗信号是即发即弃的广播没订阅、总线繁忙或客户端断开时都不会重发。要求可靠的交付就用「方法调用 返回」信号只用于锦上添花的状态通知。3. 同步代码里能用吗可以。zbus 提供阻塞版 APIzbus/src/blocking/目录Connection::blocking_system()配合阻塞连接即可完成订阅与发射。4. 如何验证信号真的发出来了用系统自带的dbus-monitor命令在总线上旁听能直观看到信号从哪个服务发出、带了什么参数非常适合调试。小结订阅简单场景用 Proxy 自动生成的receive_*流复杂过滤用MatchRule构建器发射服务侧用SignalEmitter::emit配合#[zbus(signal)]宏几乎零样板代码核心心法信号是单向公告栏——先订阅、再发射缺一不可。掌握这两对 API你就能在 Rust 世界里自如地接入 Linux 系统服务生态了。【免费下载链接】zbusRust D-Bus crate.项目地址: https://gitcode.com/gh_mirrors/zb/zbus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考