企业官网建设流程全解析

055 — 组件间通信方案对比：EventBus / emitter / props 的选择策略

简介

在多模块、多组件的前端工程中，组件间通信是一个核心难题。选择不当的通信方式会导致代码耦合度高、数据流难以追踪、调试困难。MoneyTrack 根据不同的通信场景，有策略地使用了三种通信方案：EventBus用于全局跨模块刷新（如账单数据变更后刷新首页和统计页），emitter用于同一个 feature 内的模块间通信（如资产变更通知），@Prop 属性传递用于父子组件的直接数据传递。本章分析每种方案的优缺点和适用场景，并提供选型决策树供开发者参考。

核心知识点

1. 三种通信方式的对比概览

2. 通信方案选型决策树

在实际开发中，可以按照以下决策树来选择通信方案：

核心原则：能用 @Prop 解决的不用 emitter，能用 emitter 解决的不用 EventBus——缩小影响范围，让数据流清晰可控。

3. EventBus（全局刷新）

EventBus 采用发布-订阅模式，适用于"一对多"的广播场景：

• 优点：解耦彻底，发送方不需要知道谁在监听，非常适合跨 feature 的数据变更通知。
• 缺点：事件名需要全局唯一管理，调试时难以追踪调用链。过度使用会导致事件风暴——大量全局事件在系统中无序传递，数据流动失去可预测性。

4. emitter（模块内通信）

鸿蒙系统的emitterAPI 提供进程内的事件能力，与 EventBus 的关键差异包括：

emitter 有明确的EventEmitter实例管理，可以在模块内创建独立的 emitter 实例，避免全局事件污染。例如 asset_feature 模块内部的资产变更通知使用独立的 emitter 实例，不会与其他模块的事件名冲突。

5. @Prop 属性传递（父子组件）

• 优点：类型安全、数据流清晰、易于调试。
• 缺点：多层嵌套时传递繁琐（props drilling），此时可考虑使用 @Provide/@Consume 或 AppStorage。

6. 过度使用全局事件的后果

如果滥用 EventBus，会导致以下问题：

1. 调试困难：无法追踪事件的发送源和消费链，出现 Bug 时难以定位。
2. 性能下降：全局事件触发时，所有监听者都会执行回调，即使回调中做了空判断，函数调用本身仍有开销。
3. 内存泄漏：注册了 EventBus 监听的组件在销毁时需要显式取消注册，遗漏会导致内存泄漏和僵尸回调。
4. 可预测性降低：全局事件使数据流动变得隐式，新加入的开发者很难理解"修改 A 数据后，B、C、D 页面的哪部分会刷新"。

7. 通信性能考量

不同通信方式的性能表现差异明显：

• @Prop 传递：性能最优。数据变更触发最小粒度的组件更新，ArkUI 框架会精确计算需要重新渲染的组件。
• emitter：性能良好。原生实现的异步事件队列，适合高频但小数据量的通信场景。
• EventBus：自定义实现，建议避免高频触发（如每秒超过 10 次）。对于高频更新的数据（如计时器、实时行情），优先使用 @Prop 或 AppStorage。

项目代码案例

EventBus 全局刷新：

// 账单页面修改后发送全局刷新事件EventBus.emit(EventConstants.BILL_UPDATED);// 统计页面监听EventBus.on(EventConstants.BILL_UPDATED,()=>{this.refreshStatistics();});// 注意：组件销毁时需要取消注册aboutToDisappear(){EventBus.off(EventConstants.BILL_UPDATED);}

emitter 资产变更通信：

import{emitter}from'@kit.ArkTS';// 资产变更通知emitter.emit({eventId:EventId.ASSET_CHANGED},{data:{assetId}});// 监听资产变更emitter.on({eventId:EventId.ASSET_CHANGED},(data)=>{this.updateAssetInfo(data);});

选择通信方案的核心原则是：缩小影响范围，让数据流清晰可控。在 MoneyTrack 中，80% 的组件间通信使用 @Prop 解决，15% 使用 emitter，只有不到 5% 的跨模块场景使用 EventBus。

推荐参考文档

• 组件通信最佳实践
• emitter API 参考
• @Prop / @Link / @Event 装饰器文档