鉴于多任务处理，我如何在 iOS 中处理其他音频播放？答案

【问题标题】：How do I handle other audio playing, in light of multitasking, in iOS?鉴于多任务处理，我如何在 iOS 中处理其他音频播放？
【发布时间】：2011-04-29 02:42:01
【问题描述】：

在Audio Session Cookbook 中有一个关于“Checking if Other Audio is Playing During App Launch”的部分。

我正在使用 MonoTouch（但请随意给出 Objective-C 的答案，API 是相同的），因此该文档中的代码如下所示：

bool otherAudioPlaying = AudioSession.OtherAudioIsPlaying;
if(otherAudioPlaying)
    AudioSession.Category = AudioSessionCategory.AmbientSound;
else
    AudioSession.Category = AudioSessionCategory.SoloAmbientSound;

结果是，如果我的应用程序以播放 iPod 音乐启动，那么 iPod 音乐将继续播放并阻止我使用硬件音频解码器（反正我不需要）。如果我的应用启动时没有播放 iPod 音乐，我可以使用硬件解码器。

然后我可以使用otherAudioPlaying 的值来确定是否开始播放我自己的音乐。

现在它在不支持多任务处理的旧操作系统上运行良好。但是通过多任务处理，用户可以离开我的应用程序（背景），开始在 iPod 上播放音乐，然后重新进入我的应用程序。然后他们的 iPod 音乐将被静音，而我的音乐将重新开始播放。

我希望在我的应用程序返回前台时让 iPod 音乐继续播放 - 即使我的应用程序在后台运行时正在播放我自己的音乐（并使用硬件解码器）。

（并且，反过来 - 如果我的应用程序在后台运行且没有播放音乐，我想检测是否可以在它返回时开始播放音乐）。

我该怎么做？（最好不要突然切断我的音频，保持通常发生的良好淡出。）

编辑：我还应该指出，我的所有音频工作都是在主线程之外完成的。

【问题讨论】：

设置AudioSession.category=AVAudioSessionCategoryAmbient，不管是否播放其他音频有什么问题？
@William 如果我将类别设置为 Ambient，那么我自己就不能将解码硬件用于我自己的音乐（并且在 CPU 上执行此操作会占用过多的 CPU 时间）。

标签： iphone ios ios4 audioqueue audiosession

【解决方案1】：

关于您对 refulgentis 答案的最后评论，您可以在 applicationWillResignActive 中暂停您的音乐，并为 applicationDidEnterBackground 保留状态保存操作和清理。这可能更好地避免在后台转换状态期间出现任何奇怪的行为。

【讨论】：

【解决方案2】：

为什么不在您的应用委托多任务消息中实现它呢？在后台，暂停您的音频（必要时存储当前播放位置），并在应用程序恢复焦点时将其重新启动。

只是为了澄清一点：通过重置您的音频播放器状态来响应您的委托中的 applicationDidEnterBackground:，并通过按照您现在的方式设置它来响应 applicationWillEnterForeground:。您还可以让设置音频播放的对象通过 NSNotificationCenter 响应 UIApplicationWillEnterBackgroundNotification/UIApplicationWillEnterForegroundNotification，这可能会更容易一些，但代价是从您的应用委托类中抽象出您的应用在后台执行的操作。

【讨论】：

我知道applicationDidEnterBackground，我认为解决方案将涉及响应它。我想弄清楚的是“暂停您的音频”和“重置您的音频播放器状态”位需要什么。
嗯...我想我不明白。如果这是关于 AudioSession 的问题，你知道如何启动它，我假设类似的方法停止它？如果您真的不知道，我会查找文档并再次回答。在更平庸的层面上：我不能告诉你如何重置你的音频播放器状态，因为我不知道你是如何设置它的。如果你停止它，iOS 会认为它重置。
我的音频播放器只是一个简单的硬件 AudioQueue，基本上是“音频队列服务编程指南”中描述的内容（除了它在与我接收通知的主线程不同的线程上处理） .问题是在 applicationDidEnterBackground 期间与 AudioQueue/AudioSession API 交互会导致奇怪的行为或崩溃。不幸的是，文档（据我所知）没有描述 API 的这两个部分的交互方式。