在iOS平台上开发具备后台音频播放能力的应用时，开发者常常会遇到一个棘手问题：用户正在用App听歌或听书，设备上的系统闹钟突然响铃，音频立刻被掐断，且闹钟结束后音乐没有自动续播。这背后的根本原因在于iOS对系统声音与第三方App音频采用了严格的优先级调度，而音频会话中断通知里新增的AVAudioSessionInterruptionWasSuspendedKey，则是我们判断中断来源、决定恢复策略的核心依据。
系统音频优先级与后台播放的中断机制
iOS的音频系统由AVAudioSession统一管理，每一个App在播放声音前都必须通过AVAudioSession设置自己的类别（Category）和模式（Mode）。当App声明为AVAudioSessionCategoryPlayback并开启后台模式后，理论上可以在锁屏或退到后台时继续出声。然而，系统闹钟、来电铃声、语音助手提示音被苹果划分为更高优先级的音频事件，它们一旦触发，就会强行抢占音频硬件，导致正在运行的App收到中断通知。
这种中断和普通来电不同，系统闹钟往往伴随设备从休眠中被唤醒，如果App当时处于挂起（suspended）状态，其中断通知的userInfo中会携带AVAudioSessionInterruptionWasSuspendedKey并设为true。很多开发者误以为只要收到中断结束通知就去调用setActive(true)恢复播放，结果在闹钟场景下要么恢复失败，要么与系统产生冲突。理解优先级的目的不是对抗系统，而是顺应调度：闹钟必须响，我们只需在合适的时机安静地接回音频。
从底层看，AVAudioSession的中断分为两种情境。第一种是App活跃时直接被其他音频源打断，此时wasSuspended为false，通常可在中断结束时立即恢复；第二种是App已被系统挂起，因闹钟等事件间接引发会话失效，wasSuspended为true，这时系统并不期望App马上强占资源，盲目恢复容易引发异常功耗或播放无声。
AVAudioSessionInterruptionWasSuspendedKey的正确读取方式
在代码中，我们应当监听AVAudioSessionInterruptionNotification，并在回调中解析userInfo。iOS在相关版本后于该字典中加入了AVAudioSessionInterruptionWasSuspendedKey，类型为NSNumber布尔值。需要注意的是，这个键并非所有中断都会返回，因此在读取时必须做可选绑定，避免崩溃。
下面是一段Objective-C的示例，展示如何安全地区分中断类型：
#import <AVFoundation/AVFoundation.h>
- (void)handleInterruption:(NSNotification *)notification {
NSDictionary *info = notification.userInfo;
if (!info) return;
AVAudioSessionInterruptionType type =
[info[AVAudioSessionInterruptionTypeKey] unsignedIntegerValue];
NSNumber *wasSuspended =
info[AVAudioSessionInterruptionWasSuspendedKey];
if (type == AVAudioSessionInterruptionTypeBegan) {
// 中断开始，先暂停业务逻辑
[self pausePlayback];
if (wasSuspended && wasSuspended.boolValue) {
NSLog(@"中断因App挂起引起，等待系统允许后再恢复");
} else {
NSLog(@"活跃时被打断，可准备常规恢复");
}
} else if (type == AVAudioSessionInterruptionTypeEnded) {
if (wasSuspended && wasSuspended.boolValue) {
// 挂起引发的中断结束，延迟并尝试重激活
dispatch_after(dispatch_time(DISPATCH_TIME_NOW,
(int64_t)(1.0 * NSEC_PER_SEC)),
dispatch_get_main_queue(), ^{
[self reactivateSession];
});
} else {
[self reactivateSession];
}
}
}
- (void)reactivateSession {
NSError *err = nil;
[[AVAudioSession sharedInstance] setActive:YES error:&err];
if (!err) {
[self resumePlayback];
}
}
上面的逻辑核心在于：当wasSuspended为true时，不在中断结束的瞬间立刻激活会话，而是稍作延迟，让系统完成闹钟音频的收尾。这样可以显著降低恢复失败的概率。实际项目中，延迟时间可根据设备状态调整，一般零点几秒到一秒即可。
Swift开发者同样可以使用同名键进行处理，语法上通过notification.userInfo?[AVAudioSession.interruptionWasSuspendedKey]获取。无论语言，原则一致：不要假设所有中断都能无缝恢复，必须依据wasSuspended的值分支处理。
冲突规避策略与用户体验优化
除了技术上的中断解析，产品层面也应建立合理预期。闹钟响铃属于用户明确设定的提醒，App不应试图压制或跳过，而是利用本地通知或界面提示告知用户“音频已暂停，闹钟结束后继续”。这种透明化处理能减少用户困惑，也符合苹果的人机界面指南。
在恢复播放前，建议检查当前音频会话状态以及其他可能的高优先级音频是否仍在占用。例如可使用AVAudioSession.sharedInstance().secondaryAudioShouldBeSilencedHint判断是否有其他App的音频正在播放。若系统仍处于繁忙态，继续延后恢复动作，避免频繁调用setActive造成电量损耗。
另一个常见误区是，在wasSuspended为true时反复重试激活。实验表明，若App在挂起后被闹钟唤醒，又立即以高频率请求音频资源，系统可能直接忽略请求甚至记录异常行为。正确做法是以单次延迟恢复为主，若失败则等待下一次用户前台操作再续播。通过结合AVAudioSessionInterruptionWasSuspendedKey与系统优先级认知，我们能在不打扰用户闹钟的前提下，最大化后台音频的连贯性。
AVAudioSession后台音频中断处理修改时间：2026-08-18 05:50:31