目录
[5.MQTT 和 Unity 的事件系统](#5.MQTT 和 Unity 的事件系统)
[5.1.类比 MQTT 和 Unity 事件系统](#5.1.类比 MQTT 和 Unity 事件系统)
[5.2.什么时候用 MQTT，什么时候用 Unity 事件？](#5.2.什么时候用 MQTT，什么时候用 Unity 事件？)
1.定义
MQTT 全称 Message Queuing Telemetry Transport（消息队列遥测传输协议） ，是一种基于发布/订阅模式的轻量级通讯协议。
2.核心工作原理
核心工作原理是发布/订阅模式。它不像传统打电话（点对点），而更像"订阅报纸"。
1）发布者 (Publisher)：发送消息的设备或程序，它不关心谁在收。
2）订阅者 (Subscriber)：接收消息的设备或程序，它不关心谁在发。
3）代理 (Broker)：中间的"邮局"或"服务器"，负责接收所有消息，并根据主题 (Topic) 转发给对应的订阅者。
3.核心概念与特性
3.1.主题 (Topic)
主题可以理解为消息的"地址"，分层级，用 / 分隔。例如 sensor/floor1/temperature。订阅者可以使用通配符 + (单层) 或 # (多层) 来订阅一批主题。
3.2.服务质量 (QoS)
MQTT 保证消息可靠性的核心机制，共有三个级别：
1）QoS 0 (至多一次)：消息发出后就不管了，可能丢失。适合不重要的传感器数据。
2）QoS 1 (至少一次)：确保消息到达，但可能重复。适合大多数设备控制指令。
3）QoS 2 (恰好一次)：确保消息只到达一次，开销最大。适合计费、告警等不能出错的关键场景。
3.3.轻量级与低功耗
MQTT 协议头部最小只有 2 字节，网络开销极小，非常适合计算能力有限、网络带宽差、电量有限的物联网设备。
3.4.遗嘱机制 (Last Will)
如果客户端异常断开，Broker 会自动发布一条预设的"遗嘱"消息，通知其他设备该设备已离线。
4.典型应用
MQTT 广泛应用于物联网设备监控、车联网、智能家居等领域。例如，工厂里的传感器通过 MQTT 将温度数据实时上报给云端，手机 App 作为订阅者可以即时看到这些数据。
5.MQTT 和 Unity 的事件系统
从设计模式的角度来看高度相似，它们都采用了 发布-订阅（Pub/Sub）模式。但它们在作用范围、底层机制和运行环境上有着本质的区别。
从设计模式的角度来看高度相似，仅限于"模型层面"：
注册事件（监听事件） -> 订阅主题（Subscribe Topic）
响应（分发事件） -> 发布主题（Publish Topic）
在 Unity 中，事件机制是进程内（单机内存中）的通信；而 MQTT 是跨网络（不同设备、不同进程）的通信。
5.1.类比 MQTT 和 Unity 事件系统
|----------|--------------------------|--------------------------------------|
| 对比维度 | Unity 事件系统 | MQTT 协议 |
| 通信范围 | 仅限同一个 Unity 进程（或同一个应用域）内 | 跨进程、跨设备、跨网络（局域网/广域网） |
| 中间人 | 无（直接对象引用） | 必须有 Broker（消息代理服务器） |
| 生命周期 | 脚本销毁，事件自动失效 | 只要 Broker 在线，订阅者断线重连后仍能收到消息（取决于 QoS） |
| 消息格式 | 强类型 C# 对象（可以传复杂类） | 字节流（通常是 JSON、XML 或二进制） |
| 松耦合度 | 发布者需要持有订阅者对象的引用 | 发布者完全不知道订阅者是谁，只需要发给 Broker |
| 可靠性 | 如果不处理，异常会直接影响主线程 | 提供 QoS（0、1、2）机制，保证消息不丢或只丢一次 |
5.2.什么时候用 MQTT，什么时候用 Unity 事件？
|------------------------|------------------------------|
| 场景 | 推荐方案 |
| 同一 Unity 场景内，UI 与逻辑交互 | Unity 事件（轻量，直接，性能好） |
| Unity 与后端服务器通信 | 建议用 WebSocket / HTTP（如果已有后端） |
| Unity 与硬件设备通信（PLC、传感器） | MQTT（工业标准，稳定，支持断线重连） |
| 多台 Unity 客户端之间同步数据 | MQTT（通过 Broker 中转） |