自定义NotificationCenter使用正确性及性能阈值技术问询

一、自定义NotificationCenter的实现正确性 #

直接实例化NotificationCenter创建自定义通知中心的做法是完全合规的。NotificationCenter本身支持多实例，系统默认的.default只是全局预初始化的一个实例而已。你用自定义实例隔离启动信息的广播流，避免与系统默认通知的观察者池混杂，这个思路非常适配你的业务场景，完全没问题。

实现时需要注意两个关键点：

• 把自定义通知中心封装成全局单例，防止重复创建实例导致观察者分散：

  final class AppLaunchNotificationCenter {
      static let shared = NotificationCenter()
      private init() {} // 禁止外部初始化
  }
  

• 确保所有业务库统一使用这个单例注册、接收通知，保证通知通路的一致性。

二、观察者数量的性能阈值 #

Apple没有给出明确的观察者数量阈值，性能影响取决于多个变量：

• 通知发送频率：如果只是启动时发送一次，哪怕有上百个观察者，性能损耗可以忽略；如果是高频触发（比如每秒几十次），几十个观察者就可能引发卡顿。
• 回调逻辑复杂度：每个观察者的回调如果包含大量计算、IO操作，哪怕只有十几个，也会拖慢线程。

根据实际开发经验：

• 对于启动这类低频通知，100个以内的观察者基本不会有性能问题；
• 对于高频通知，建议控制在20个以内，同时尽量简化回调逻辑。

三、后台线程处理通知的实践方案 #

将通知处理逻辑移至后台线程是合理的优化方向，推荐两种实现方式：

• 注册时直接指定后台队列：

  AppLaunchNotificationCenter.shared.addObserver(
      forName: Notification.Name(rawValue: "AppLaunchInfoBroadcast"),
      object: nil,
      queue: DispatchQueue.global(qos: .background)
  ) { notification in
      // 后台处理启动信息逻辑
  }
  

• 回调内部切换线程（适合需要后续更新UI的场景）：

  AppLaunchNotificationCenter.shared.addObserver(
      forName: Notification.Name(rawValue: "AppLaunchInfoBroadcast"),
      object: nil,
      queue: nil
  ) { notification in
      DispatchQueue.global(qos: .background).async {
          // 执行耗时处理逻辑
          DispatchQueue.main.async {
              // 切回主线程更新UI
          }
      }
  }
  

注意：如果通知携带UI相关对象，要避免循环引用，且所有UI操作必须在主线程执行。

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