控制器间数据传递：Protocol/事件处理器 vs Notification哪种更优？

性能（CPU/RAM） #

逐级传递（事件处理器/Protocol） #

• CPU占用：完全是直接的方法调用或闭包执行，没有系统层面的额外查找、匹配逻辑，编译器还会做优化，CPU开销极低且稳定，几乎可以忽略。
• 内存占用：只依赖VC本身的层级引用链（本来就存在），传递数据时的临时对象也能快速释放，不会产生额外的内存负担，更不会有泄漏风险（只要正常管理VC生命周期）。

Notification通知 #

• CPU占用：每次发通知，系统都要遍历所有注册的观察者做匹配，要是通知多、观察者多，这个线性查找的开销会被放大，频繁发送时CPU占用会明显上升。
• 内存占用：每个观察者注册都会生成系统层面的对象，还要维护观察者列表。要是VC销毁时忘了注销观察者，直接会导致内存泄漏——通知中心会强引用VC，让它无法被释放，长期运行会吃掉更多RAM。另外，userInfo字典的创建销毁也有额外内存开销。

可靠性 #

逐级传递（事件处理器/Protocol） #

• 编译期校验：强类型定义的方法或协议，编译时就能检查出参数类型、方法签名的错误，不会出现运行时因参数不匹配崩溃的情况。
• 链路清晰：每一步的传递都在代码里有明确的调用关系，调试时顺着调用栈就能追踪数据流向，定位问题快。
• 无意外触发：只有持有上层VC引用的对象才能发起传递，不会出现无关模块误触发的情况。

Notification通知 #

• 弱类型风险：userInfo里的参数没有编译期校验，键名拼错、类型不匹配都是运行时才会暴露的问题，很容易导致崩溃或数据错误。
• 调试难度高：发送方和接收方完全解耦，出问题时很难追踪通知的来源和接收方，排查成本高。
• 泄漏隐患大：只要忘了在VC销毁时调用removeObserver，就会引发内存泄漏，严重时还会导致野指针崩溃。

结论 #

如果你的第五层VC和WebSocket的交互不算频繁，且VC层级相对稳定，优先用逐级传递（Protocol/事件处理器）——性能开销可以忽略，可靠性强，后期维护调试也省心。

如果App里有大量跨模块、跨层级的WebSocket交互，或者VC层级经常变动，Notification可以作为补充，但必须严格做到：VC销毁时及时注销观察者，统一规范userInfo的参数键名和类型，尽可能降低风险。

内容的提问来源于stack exchange，提问作者martin wotterman