Iphone 音量控制iOS的最佳实践？

硬件音量控制

我正在试图了解对于大多数无声但偶尔会发出声音的应用程序来说，什么是最佳实践。这样的应用程序可以利用iOS设备上的侧音量控制，避免在NSVolume control小部件中设计，我认为这不如硬件侧音量控制方便。这种方法将适用于MapQuest 4 mobile等应用程序，在这些应用程序中，您偶尔会收到音频提示，这些提示与其他音乐播放器很好地融合（使用音频闪避），但大多数情况下都是无声的。我想知道其他人是如何解决这个问题的

我开发了这样一个系统，它运行得相当好。在我的方法中，我查询音频API以确定是否正在播放其他音乐（iPod、AOL Radio、Pandora等），然后仅在没有播放其他音频时启动音频会话。这将硬件端音量控制绑定到应用程序，而不是（iPhone）振铃器。当你走到后台时，挑战就来了。只有在应用程序不使用音频时，我的方法才会在后台终止（停用）会话。如果有音频播放，则在播放结束时禁用会话

停止播放的想法是，如果我的应用程序继续在后台运行，用户可以根据自己的喜好调整铃声音量

这个问题源于我在2008-2009年在iOS上开发MapQuest 4 mobile语音导航功能时遇到的问题。在该应用程序中，我们希望侧音量开关在应用程序运行时始终控制转向建议的音量。后来我意识到，在到达目的地并将应用程序发送到后台后，我无法控制铃声音量。这是几年前的事了，但我相信这个应用程序仍在后台运行，这导致了这个问题。这是一个有趣的案例，当用户正在导航时，如果您继续音频会话，会将应用程序发送到后台吗？当应用程序在后台运行时，用户是否更愿意更改应用程序的音量或铃声音量

我的一般用例（当我发布这个问题时）涉及在后台导航，同时在前台运行另一个应用程序（通常是音乐播放器）。然而，当用户坐在主屏幕上时，将导航应用程序发送到后台也是很常见的。此时停用音频会话才有意义

---

这并不像看上去那么直截了当，但我的方法在大多数情况下都有效。不过，我想知道是否还有其他更可行的办法来解决这个问题。其他人在干什么？在自动滑入/滑出的视图中只包含音量控制是否更有意义？有没有我没有考虑过的事情？你是如何处理这个问题的？你有什么一般性的建议吗？

我建议你把问题分成几段，因为现在很难阅读。你应该把文本分成几段，这有点难阅读。更新后的内容会让你的眼睛更容易看。我不完全理解你的问题。你是否在问当你的应用程序进入后台时应该做什么？或者，您是在询问将应用程序内音量控制与系统音量控制分开吗？我是在问，在这种情况下，首选的做法是什么，或者您做了什么？应用程序内的音量控制感觉笨重/凌乱，而硬件音量控制感觉更自然。我将试着重新表述我的问题，使之更清楚。