创游世界广播机制完全指南
一句话摘要
广播是创游世界中跨对象、跨层级通知消息的事件驱动机制，核心价值在于解耦发起者和处理者，使 UI、地图、物体、自定义组件之间不需要硬绑死。推荐使用「UI 发广播 → 地图统一处理」的架构模式。
适合谁阅读
- 遇到「广播没效果」或「广播乱发」问题的开发者
- 想理解 UI 与地图如何正确通信的制作者
- 需要设计复杂项目架构的进阶用户
- 需要做联机项目的开发者
你将学到什么
- 广播不是普通函数调用，而是事件通知机制
- 广播的三种核心用途（事件表达、动作请求、状态变化通知）
- 广播与 UI、地图、自定义组件的关系
- 广播命名的最佳实践
- 联机环境下广播的性能优化
- 广播的常见误区与避坑建议
一、广播基础概念
1.1 什么是广播
广播是一种「发消息给多个对象」的事件通知机制。
类比理解：
- 想象现实中的电台广播
- 发送者相当于电台
- 所有调到对应频道的接收者都可以收到信号
- 发送者不需要知道谁在收听
1.2 广播的工作原理
发送广播 → 所有监听该广播的脚本执行关键特点：
- 发送者不需要知道监听者的具体信息
- 监听者通过订阅事件来接收并响应消息
- 广播可以跨越对象、跨越层级传递
1.3 广播不是普通函数调用
很多初学者会把广播理解成：
- 一个「远程执行」按钮
- 或者简单地「让别的地方跑一段脚本」
但广播更接近：
- 一种事件通知机制
- 一种跨层解耦方式
- 一种连接 UI、地图、物体、自定义组件的中介
关键价值：把发起者和处理者拆开。
二、广播的三种核心用途
用途 A：表达事件发生
广播用于表示「发生了什么」。
示例：
- 按钮被点击 → 发送「按钮_点击」广播
- 任务完成 → 发送「任务_完成」广播
- 角色死亡 → 发送「角色_死亡」广播
- 机关触发 → 发送「机关_触发」广播
特点：
- 广播名称表达事件本身
- 所有关心这个事件的对象都可以监听
- 不关心事件后应该怎么处理
用途 B：表达动作请求
广播用于表示「我希望系统执行什么」。
示例：
- 请求打开界面 → 发送「请求_打开背包」广播
- 请求开始下一波 → 发送「请求_开始波次」广播
- 请求刷新排行榜 → 发送「请求_刷新排行」广播
特点：
- 广播名称表达意图或请求
- 真正的处理逻辑由接收方决定
- 发送方不需要知道具体实现
用途 C：表达状态变化通知
广播用于表示「某个状态已经变化，请相关对象自行同步」。
示例：
- 背包更新 → 发送「背包_更新」广播
- UI 需要刷新 → 发送「刷新_界面」广播
- 任务阶段变更 → 发送「任务_阶段变更」广播
特点：
- 广播名称表达状态变化
- 接收方根据自身逻辑决定如何响应
- 适合多人联机同步
三、广播在创游中的位置
3.1 广播常出现的位置
- 地图级广播
- UI 收发广播
- 玩家向当前 UI 发广播
- 物体或组件响应广播
3.2 广播类型说明
| 类型 | 说明 |
|---|---|
| 地图广播 | 在地图范围内广播，全地图可见 |
| 系统广播 | 跨地图的系统级广播 |
| UI 广播 | UI 发出或接收的广播 |
| 向当前 UI 发广播 | 地图向当前显示的 UI 发广播 |
3.3 广播与组件的关系
自定义组件让「某个能力模块」可以自己监听和处理广播。
这意味着：
- 组件可以作为广播的接收端
- 组件也可以作为广播触发后的行为封装体
从设计角度看：
- 广播提供跨模块通知
- 自定义组件提供模块内部实现
两者配合：
- 外部低耦合通知
- 内部高内聚实现
四、推荐的数据流架构
4.1 UI 发广播，地图处理
这是当前资料里最值得反复强调的实践模式。
为什么 UI 不适合直接处理太多公共逻辑：
- UI 本质上更偏输入、展示、交互反馈
- 如果 UI 里直接承载大量公共数据写入
- 就容易出现性能压力、联机等待、逻辑难维护
为什么地图适合做汇总处理：
- 地图更像当前场景逻辑控制器
- 公共数据协调层
- 多对象共享规则承载层
推荐架构：
UI 操作
↓
发送广播（请求）
↓
地图/系统处理真值
↓
修改真值
↓
发送广播（通知）
↓
UI 更新显示4.2 具体示例
购买物品流程：
当点击购买按钮时
// UI 发请求
发送广播 "请求购买" 带参数 商品ID=1, 数量=1
结束
当收到广播 "请求购买" 时（地图脚本）
// 地图层处理逻辑
获取玩家变量 "金币"
获取配置表 商品列表 名为 "商品1" 的行
如果 玩家金币 大于等于 商品价格
设置玩家属性 "金币" 为 玩家金币 - 商品价格
执行玩家指令 "添加物品" 参数 商品ID=1, 数量=1
发送广播 "购买成功"
否则
发送广播 "金币不足"
结束
结束
当收到广播 "购买成功" 时（UI脚本）
// UI 收到通知后刷新显示
刷新界面
结束角色死亡流程：
当死亡时（角色脚本）
发送广播 "玩家_死亡"
结束
当收到广播 "玩家_死亡" 时（UI脚本）
显示失败界面
结束
当收到广播 "玩家_死亡" 时（任务脚本）
增加任务失败计数
结束
当收到广播 "玩家_死亡" 时（音效脚本）
播放死亡音效
结束五、广播命名规范
5.1 推荐的命名方式
广播名尽量表达「事件/意图」，而不是实现细节。
推荐的命名：
| 广播名 | 说明 |
|---|---|
| 开始挑战 | 表达事件 |
| 打开背包 | 表达意图 |
| 任务完成 | 表达状态变化 |
| 刷新界面 | 表达请求 |
| 玩家准备完成 | 表达玩家状态 |
| 道具_获得_玩家 | 表达道具相关事件 |
| 任务_阶段变更 | 表达任务状态变化 |
5.2 不推荐的命名
| 广播名 | 问题 |
|---|---|
| 广播1 | 无意义 |
| 执行那个功能 | 太模糊 |
| 改值 | 没有语义 |
| 刷新1 | 不知道刷新什么 |
| 刷新2 | 不知道刷新什么 |
命名越像「事件语言」，项目就越容易维护。
5.3 语义化命名示例
| 功能 | 不推荐 | 推荐 |
|---|---|---|
| 金币变化 | 刷新 | 金币_变化 |
| 背包更新 | 刷新背包 | 背包_更新 |
| 任务完成 | 任务 | 任务_完成 |
| 波次开始 | 下一步 | 波次_开始 |
六、联机环境下的广播
6.1 联机 UI 的特殊问题
问题：4.52.54 之前的版本，每个玩家设备会模拟所有玩家的 UI 逻辑，帧率被限制到 20 帧。
表现：
- 联机时 UI 很卡
- 多人同时操作时延迟明显
6.2 解决思路
方法 1：更新版本
- 更新到 4.52.54+ 版本
- 新版本优化了 UI 执行逻辑
方法 2：优化广播模式
// ❌ 不推荐：UI 直接处理多人数据
当点击按钮时
执行多人写入操作 × N次
结束
// ✅ 推荐：UI 只发一次广播，地图集中处理
当点击按钮时
发送广播 "请求操作"
结束
当收到广播 "请求操作" 时（地图脚本）
// 地图层集中处理所有逻辑
执行逻辑
发送广播 "操作完成"
结束方法 3：减少 UI 广播频率
- 不要在 UI 中做连续多次公共数据写入
- 合并多个小操作为一个请求广播
七、广播的常见误区
误区 1：广播是万能跳线
错误做法：
- 到处发广播
- 名称混乱
- 一个广播承担太多语义
后果：
- 很难追踪谁在响应
- 一改名字全项目崩
- 调试体验很差
误区 2：广播里塞太多底层细节
推荐做法：
- 广播表达「意图」
- 具体实现放在处理端
误区 3：能直接调就不分层
后果：
- UI 绑死地图内部结构
- 地图绑死对象细节
- 项目可复用性很差
短期看省事，长期看容易失控。
误区 4：一个广播干所有事
错误示例：
// ❌ 一个广播干了太多事
当点击按钮时
发送广播 "处理一切" // 扣钱+发道具+刷新UI+播音效+加成就
结束推荐做法：
// ✅ 多个职责明确的广播
当点击按钮时
发送广播 "请求购买"
结束
当收到广播 "请求购买" 时
扣钱
发道具
发送广播 "购买完成"
结束
当收到广播 "购买完成" 时
刷新UI
结束
当收到广播 "购买完成" 时
播放音效
结束
当收到广播 "购买完成" 时
增加成就进度
结束八、广播调试技巧
8.1 为什么广播没效果
检查清单：
- 广播名称是否完全一致（包括大小写）
- 监听脚本是否写在「当收到广播时」触发时机下
- 监听者在广播发送时是否仍然存在
- 广播时机是否在监听者初始化之后
- 监听者是否被销毁了
8.2 广播调试技巧
技巧 1：添加日志广播
当点击按钮时
发送广播 "调试_打印" 带参数 信息="按钮被点击"
结束
当收到广播 "调试_打印" 时
打印到日志 参数.信息
结束技巧 2：使用临时广播名
- 测试时使用带编号的广播名
- 测试完成后改成语义化名称
技巧 3：分步测试
- 先测试发送端
- 再测试接收端
- 最后串联完整流程
九、实战案例
9.1 多人联机游戏房间系统
// UI 发送请求
当点击准备按钮时
发送广播 "玩家_准备"
结束
// 地图层处理
当收到广播 "玩家_准备" 时
设置玩家属性 "已准备" 为 真
检查是否所有玩家都准备
如果 所有玩家都准备
发送广播 "游戏_开始"
结束
结束
// UI 响应
当收到广播 "游戏_开始" 时
隐藏准备界面
显示游戏界面
结束9.2 任务系统与成就系统联动
// 任务完成
当满足任务完成条件时
发送广播 "任务_完成" 带参数 任务ID=1
结束
// 任务系统响应
当收到广播 "任务_完成" 时
记录任务完成
发放奖励
发送广播 "奖励_发放"
结束
// 成就系统响应
当收到广播 "任务_完成" 时
检查是否解锁成就
如果 解锁成就
发送广播 "成就_解锁" 带参数 成就ID=5
结束
结束
// UI 系统响应
当收到广播 "成就_解锁" 时
显示成就弹窗
播放音效
结束相关页面
- 广播机制深度解析 - 广播机制详解
- 创游世界广播驱动项目结构实战 - 广播驱动架构实战
- 创游世界UI数据同步架构 - UI与真值解耦
- 常见问题与避坑指南 - 常见问题解决
最后更新：2026-06-16维护者：Azek431