监听应用后台通知时NotificationCenter的queue传nil和.main有什么区别

核心区别 #

首先我们先明确两种写法的代码：
第一种写法：

NotificationCenter.default.addObserver(forName: UIApplication.didEnterBackgroundNotification, object: nil, queue: nil) { _ in
    // 回调逻辑
}

第二种写法：

NotificationCenter.default.addObserver(forName: UIApplication.didEnterBackgroundNotification, object: nil, queue: .main) { _ in
    // 回调逻辑
}

首先引用苹果官方对queue参数的说明：

该参数指定回调闭包运行的操作队列，当传入nil时，闭包将在通知的发送线程上同步执行。

这里先纠正你的理解误区：传入.main并不会提升回调的执行优先级，仅会强制回调闭包在主队列执行。执行优先级由队列的QoS（服务质量等级）决定，主队列的QoS等级和系统发送该通知的线程优先级基本一致，不存在优先级更高的说法。
另外系统默认发送UIApplication.didEnterBackgroundNotification的线程就是主线程，因此绝大多数常规场景下，两种写法的执行效果完全一致，回调都会在主线程运行。

回调不触发的场景分析 #

两种写法本身不存在设计缺陷，不会主动导致回调漏触发，仅在极少数极端场景下会出现执行失败的情况：

• 第一种写法（queue: nil）的异常场景：仅当该通知被第三方代码手动在子线程投递时，回调才会在子线程执行，若你在回调内写了UI更新类的操作会触发崩溃，但回调本身还是会被调用，不会出现完全不执行的情况。
• 第二种写法（queue: .main）的异常场景：当通知触发时，如果主线程存在严重耗时任务积压，且在系统给应用分配的后台存活时间窗口（通常为几秒）内，回调任务还没有被主队列调度执行，系统会强制挂起应用进程，导致回调最终没有被运行。这种情况仅在主线程被卡死时才会出现，常规开发场景下概率极低。

使用建议 #

如果回调逻辑包含UI更新操作，选择queue: .main更稳妥，不需要额外做线程判断；如果仅做数据存储、状态同步等非UI操作，两种写法都可以稳定运行，没有本质差异。正常使用前提下无需担心回调漏触发的问题。

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