iOS开发中为何要自定义通知广播中心？

嘿，这个问题问到点子上了——我自己在不少中大型项目里都见过团队搞自定义通知中心，甚至自己也写过几个，核心原因就是官方的NSNotificationCenter在某些场景下确实有够让人头疼的，咱们一个个说：

核心原因：官方NSNotificationCenter的痛点 #

• 类型安全缺失：官方通知用字符串当标识，比如NSNotification.Name("UserLoggedIn")，拼写错了编译器完全不会提醒，只有运行时才会发现没收到通知，排查起来贼麻烦。自定义的话，咱们可以用枚举、结构体来定义通知类型，比如：

  enum AppNotification {
      case userLoggedIn(User)
      case themeChanged(Theme)
  }
  

  编译期就能检查错误，再也不用怕拼错通知名了。

• 参数传递模糊且不安全：官方的userInfo是[AnyHashable: Any]?类型，取参数的时候必须强制类型转换，比如let user = notification.userInfo?["user"] as? User，一不小心就会转错类型或者拿到nil，很容易引发崩溃。自定义通知中心可以直接把参数和通知绑定，接收方拿到的就是强类型数据，根本不用做这些繁琐又危险的转换。

• 全局广播的混乱风险：官方的defaultCenter是全局单例，所有模块的通知都挤在同一个空间里，很容易出现命名冲突（比如两个模块都定义了"UserUpdated"通知），或者不小心监听了其他模块的通知，导致逻辑混乱。自定义的可以按业务模块拆分，比如NetworkNotificationCenter、UIUpdateNotificationCenter，各自管自己的通知，边界清晰，避免全局污染。

• 订阅生命周期管理麻烦：虽然iOS 9之后官方会自动移除观察者，但在一些复杂场景下（比如使用闭包监听、或者自定义对象的生命周期特殊），还是容易出现野指针或者内存泄漏的问题。自定义通知中心可以实现更优雅的订阅管理，比如返回一个Disposable对象，销毁时自动取消订阅，或者结合Combine的Publisher来管理，比手动调用removeObserver靠谱多了。

那官方的NSNotificationCenter完全不能用吗？ #

当然不是！如果你的项目很小，或者只是简单的跨组件通信（比如通知某个页面刷新数据），用官方的完全没问题——毕竟不用额外写代码，快速又省事。官方的通知中心经过苹果多年优化，性能和稳定性都有保障，只是在项目复杂度上来之后，它的弱点会被放大而已。

自定义NotificationCenter的适用场景 #

• 中大型项目/团队协作场景：当项目模块多、参与人数多的时候，自定义通知中心能帮你规范通知的使用，避免命名冲突和类型错误，提升代码的可维护性。
• 强类型要求高的场景：如果你的通知需要传递复杂的自定义数据，不想在userInfo里做繁琐的类型转换，自定义的能让参数传递更安全、更清晰。
• 需要自定义行为的场景：比如你需要实现通知的优先级排序、异步投递、过滤重复通知，或者要给通知添加日志、统计功能，官方的NSNotificationCenter很难做到这些，而自定义的可以根据需求灵活扩展。
• 模块化架构场景：比如采用Clean Architecture、MVVM等分层架构，不同层之间的通信用自定义通知中心作为桥梁，能更好地控制层与层之间的依赖关系，让架构更清晰。

总的来说，自定义NotificationCenter不是为了"替代"官方的，而是在特定场景下解决官方的痛点，让代码更健壮、更易维护。如果你的项目还在起步阶段，用官方的完全OK；但当项目复杂度上来之后，不妨试试自定义的，会发现省心很多。

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