【IOS】Audio Session Programming Guide 翻譯 by kk(二)

定義一個音頻會話

音頻會話是 App 和 IOS 之間的媒介,用來為 App 配置相關的音頻屬性和行為。在加載過程中,App 會自動創建一個音頻會話的單例。開發者可以通過配置音頻會話來描述 App 對音頻的需求。比如:

  • 在 App 播放聲音的時候,開發者是想讓其他 App 的聲音停止還是和自己的聲音混合在一起?
  • 當碰到系統鬧鐘或其他聲音響起的時候,App 中的聲音會作出什么反應?
  • 當用戶插拔耳機時, App 中的聲音功能會作出什么反應?
    音頻會話的配置會影響 App 運行期間幾乎所有的音頻活動(除了通過系統聲音服務 API 播放的 UI 音效)。開發者可以通過查詢音頻會話來獲取 App 運行設備上的硬件特性(頻道數、采樣率等)。這些硬件特性因設備而異, App 可以根據用戶行為改變這些特性。
    開發者可以顯式得開啟或關閉自己的音頻會話。開發者需要在 App 開始播放聲音或使用錄音功能之前開啟音頻會話。另外,系統可以在接到電話或鬧鐘響起時關閉App音頻會話,這種行為被稱為中斷(interruption)。音頻會話的 API 中提供了對中斷進行響應和恢復的方法。

音頻會話的默認行為

音頻會話具有如下的默認行為:

  • 支持后臺播放,不支持錄音
  • 當用戶將手機切換到靜音模式后,App 會被靜音。
  • 設備鎖屏后,App 會被靜音。
  • 當 App 的音頻開始后,設備正在播放的其他聲音會被靜音。

上述行為由默認音頻會話類別 <code>AVAudioSessionCategorySoloAmbient</code> 提供。音頻會話類別(coming soon)介紹了如何在 App 內使用類別。
盡管音頻會話會在 App 開始播放或錄制音頻時自動開啟,但這種默認的開啟方式會帶來風險。舉例來說,如果用戶使用 App 過程中有電話打入,而用戶選擇了拒接電話讓 App 繼續運行。如果沒有使用合理的后臺播放技術,那 App 的聲音將不會再播放。下一章(coming soon)描述了一些處理這類問題的策略,處理中斷(coming soon)中有進一步的討論。

開發者可以在開發過程中使用這種默認行為來提高開發效率。如果要發布 App ,那么只有在以下場景中才能安全的忽略音頻會話:

  • App 除了系統聲音服務(<code>System Sound Services</code>)或 <code>UIKit</code> 中的 <code>playInputClick</code> 方法外,不使用其他音頻 API 處理音頻。
    系統聲音服務是一種用來播放UI音效及觸發震動的IOS技術,不適用于其他任何場景。詳情見System Sound Services Reference
    UIKit 中的 <code>playInputClick</code> 方法允許開發者在特定的輸入或鍵盤輔助視圖(accessory view)中播放標準的鍵盤按鍵音。它的音頻會話行為由系統自動處理。詳情見Playing Input Clicks
  • App 不使用音頻

如果不滿足上述條件,一定不要在需要發布的 App 中使用默認的音頻會話。

為什么通常情況下默認的音頻會話不能滿足開發者的要求

如果開發者不對音頻會話進行初始化、配置和顯式調用,那么 App 就不能對中斷或音頻源的變化作出響應,也不能控制系統如何處理不同 App 間音頻的混合。
以下場景描述了音頻會話的默認行為,以及開發者如何來改變它:

  1. 開發者開發了一款播放有聲書的 App。用戶開始聽《 The Merchant of Venice》,正當 Bassanio 大人要出場的時候,自動鎖屏的時間到了,屏幕變黑了,有聲書的音頻也被靜音了。
    為了避免鎖屏靜音這種情況,開發者需為音頻會話配置一個支持后臺播放的類別,同時要在 <code>UIBackgoundModes</code> 中添加 <code>audio</code> 標志。
  2. 開發者開發了一款使用基于 OpenAL 音效的第一視角射擊類游戲。游戲中提供背景音樂,但也為用戶提供了關閉游戲背景音樂,并播發音樂庫中的音樂的功能。在選擇一曲激昂的音樂開始播放后,用戶朝著敵軍開了一槍,槍響了,用戶播放的音樂卻停了。
    為了保證用戶選擇的音樂能不被干擾的繼續播放,需要將音頻會話設置為允許混合的模式。開發者可以選擇 <code>AVAudioSessionCategoryAmbient</code>類別 ,也可以通過修改 <code>AVAudioSessionCategoryPlayback</code> 類別來支持混合。
  3. 開發者開發了一款使用音頻隊列服務(<code>Audio Queue Services</code>)進行后臺播放的流媒體電臺 App。正當用戶在收聽的時候,電話來了,App 的聲音按照期望中的那樣停止了。用戶選擇了拒接這個電話,關閉了鬧鐘,然后點擊播放按鈕來繼續收聽,卻發現未能如愿。用戶必須重啟 App 才能恢復后臺播放。
    要優雅的處理這種音頻隊列的中斷,開發者需要設置合適的類別,注冊 <code>AVAudioSessionInterruptionNotification</code> 通知,并讓 App 對不同的通知作出相應的反應。

系統怎樣解決音頻需求之間的競爭

在 App 啟動時,系統的內置 App(短信、音樂、Safari、電話等)可能會在后臺運行。這些內置的 App 可能會播放聲音,比如收到短信后。
如果將 IOS 設備看作一個飛機場,把 App 看作滑行的飛機,那么系統就是調度中心。飛機向調度中心發布一個使用聲音的請求,同時聲明它需要的優先級,而最終何時獲得超過“正在跑道上”使用音頻的其他飛機的權限由調度中心決定。App 通過音頻會話來跟系統進行交互。下圖描述了一個典型的場景:你的 App 想要在音樂 App 正在播放音樂的時候播放聲音。這種情況下,你的 App 會中斷音樂 App。


圖片來自官方文檔

<small>
第一步,App 請求開啟它的音頻會話。這種請求可能會在 App 加載過程中產生,也可能會在響應用戶點擊某個播放按鈕的事件中產生。第二步,系統開始處理這次請求。圖中的 SpeakHere App 使用了需要其他音頻靜音的類別。
在第三和第四步中,系統關閉了音樂 App 的音頻會話,停止了音樂在后臺的播放。最終,系統開啟了 SpeakHere 的音頻會話,SpeakHere 可以開始播放聲音了。
系統對于是否開啟或關閉設備上音頻會話有最終的決定權。決策過程中,電話總是擁有最高的優先權,沒有 App 的音頻權限能夠超過電話。接到電話后,無論當前正在執行什么音頻動作或是設置了哪種音頻類別,App 都會被中斷,用戶都會獲得“你接到了電話”的提醒。
</small>

集成 <code>AVCaptureSession</code>

<code>AV Foudation</code> 中的捕獲 API(<code>AVCaptureDevice</code>、<code>AVCaptureSession</code>)可以使開發者得到同步獲取來自相機或麥克風的音頻或視頻輸入。在 IOS7 中,表示麥克風輸入的 <code>AVCaptureDevice</code> 對象可以共享 App 的 <code>AVAudioSession</code>。默認情況下,<code>AVCaptureSession</code> 會在使用麥克風的時候會給 <code>AVAudioSession</code> 設置最適合錄音的配置。如果將 <code>automaticallyConfiguresApplicationAudioSession</code> 屬性設為 <code>NO</code>,這種默認配置會被當前開發者的AVAudioSession配置覆蓋,<code>AVCaptureDevice</code> 也會不加修改的采用開發者的配置。在 AVCaptureSession Class ReferenceMedia Capture 中可以獲得更多相關信息。

初始化音頻會話

系統在 App 的加載過程中提供了一個音頻會話的對象。在處理中斷之前,開發者必須初始化這個會話。
<code>AV Foundation</code> 框架會利用開發者獲取對 <code>AVAudioSession</code> 對象的引用時觸發的隱式初始化,來管理中斷。

//隱式初始化音頻會話
AVAudioSession *session = [AVAudioSession sharedInstance];

<code>session</code> 變量代表了一個已經被初始化且可以馬上使用的音頻會話。官方推薦在使用 <code>AVAudioSession</code> 類中的中斷通知,或 <code>AVAudioPlayer</code> 和 <code>AVAudioRecorder</code> 的代理協議來處理音頻中斷時,隱式的初始化音頻會話。

添加音量和音頻源管理

<code>MPVolumeView</code> 類提供了在 App 中控制音量和音頻源的方法。音量視圖提供了一個控制音量的滑塊和一個選擇音頻輸出源的按鈕。官方建議在將音頻源切換到內置揚聲器時,使用 <code>MPVolumeView</code> 的音頻源選擇器(route picker)而不是 <code>AVAudioSessionPortOverride</code>。詳情見 MPVolumeView Class Reference

響應遙控器事件

用戶可以通過遙控器事件來控制 App 中的多媒體。開發者可能希望 App 中播放的音頻或視頻內容對來自 transport controls 或外接輔助設備的遙控事件做出響應。IOS 將這些命令轉化為 <code>UIEvent</code> 對象分發給 App。App 接收到事件后將它們發送給對應的 first responder。如果 first responder 不對事件進行處理,那么事件將會在 responder 鏈中向上傳遞。
只有正在播放音頻、且具有“Now Playing”信息的 app,才能對遙控器事件做出響應。詳情見 Remote Control EventsMPNowPlayingInfoCenter Class Reference

開啟或關閉音頻會話

雖然系統在 App 加載的時候自動開啟你的音頻會話,但蘋果官方推薦的做法是在 App 的 <code>viewDidLoad</code> 方法中顯式的開啟,并在開啟前設置合適的硬件參數。為 App 進行硬件優化 中有相關的示例代碼。通過這種方式,開發者可以測試音頻會話是否成功開啟。如果 App 中包含一個類似播放/暫停的 UI 元素,在用戶按下播放鍵時開啟會話則是更好的方式。在切換音頻會話的開啟/關閉狀態時,對是否成功的切換了會話狀態做出檢查是有必要的。開發者應在代碼中對系統駁回的請求進行優雅的處理。
系統會在鬧鐘提醒、日歷提醒或接到電話時將關閉你的音頻會話。當用戶關閉提醒或拒接電話后,系統會允許你重新開啟會話。在中斷結束后是否重新開啟音頻會話由 App 的類型決定,[Audio Guidelines By App Type](Audio Guidelines By App Type.md) 中有相關的介紹。
下面的代碼展示了如何開啟音頻會話。

NSError *activationError = nil;
BOOL success = [[AVAudioSession sharedInstance] setActive: YES error: &activationError];
if (!success) { /* handle the error in activationError */ }

將 <code>setActive</code> 的參數設置為 <code>NO</code> 可以關閉會話。
如果使用 <code>AVAudioPlayer</code> 或 <code>AVAudioRecorder</code> 來播放或錄制音頻時,系統會負責在中斷結束后重新開啟音頻會話。然而,官方推薦通過注冊消息通知來顯式開啟會話,來保證會話成功開啟并對 App 的狀態和 UI 進行更新。
大多數 App 不需要顯式的關閉音頻會話。一些需要顯式關閉的特例包括 VoIP(網絡電話)App、逐向(在轉彎時對用戶做出提醒)導航 App 和某些錄音 App。
對于一般在后臺運行網絡電話 App,要保證它的音頻會話在處理通話時是開啟的,而在后臺準備接收通話時則處于關閉狀態。
對于使用錄音類別的 App 的音頻會話僅在錄音時開啟。在錄音開始前和錄音結束后要關閉會話以保證類似短信提示音的其他聲音能夠順利播放。

App加載時檢查是否存在正在播放的其他音頻

在用戶打開 App 時,設備可能正在播放其他的聲音:音樂 App 可能正在播放音樂,或者瀏覽器正在播放流媒體。這種情況產生的影響對于游戲 App 來說可能更為顯著。許多游戲會有自己的背景音樂和音效。IOS Human Interface Guidelines 建議開發者假定用戶在玩游戲時希望保持他們原來播放的音頻作為背景音樂,同時保留游戲的音效。
檢查 <code>otherAudioPlaying</code> 的屬性值來判斷 App 加載過程中是否正在播放其他音頻;如果是的話,將游戲的背景音樂靜音,并使用 <code>AVAudioSessionCategorySoloAmbient</code> 類別。詳情見音頻會話類別(coming soon)。

跨 App 音頻(Inter-App Audio)

跨 App 音頻的最基礎的使用形式是通過一個節點(node) app 將它的音頻輸出到另一個寄主(host) App。寄主 App 可能會將它的輸出發送給節點 App,經過節點 App 的處理后,將處理結果反饋給寄主 App。寄主 App 需要一個始終處于開啟狀態的音頻會話,而節點 App 只需要在從寄主 App 或系統接收音頻輸入時開啟音頻會話。根據以下方案來設置跨 App 的音頻:

  • 為寄主 App 和節點 App 設置“inter-app-audio”權限
  • 為寄主 App 在 <code>UIBackgoundModes</code> 添加 <code>audio</code> 屬性。
  • 為使用音頻輸入輸出源、同時連接到跨 App 音頻寄主的節點 app 的 <code>UIBackgoundModes</code> 添加 <code>audio</code> 屬性。
  • 將寄主和節點 App 的類別設為 <code> AVAudioSessionCategoryOptionMixWithOthers</code>。
  • 對于連接到寄主的節點 App,保證它的音頻會話在收到系統的音頻輸入或產生音頻輸出時處于開啟狀態。

以上內容翻譯自蘋果官方文檔,僅供學習,請勿用于商業用途,侵刪。轉載注明出處。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,546評論 6 533
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,570評論 3 418
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,505評論 0 376
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,017評論 1 313
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,786評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,219評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,287評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,438評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,971評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,796評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,995評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,540評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,230評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,662評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,918評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,697評論 3 392
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,991評論 2 374

推薦閱讀更多精彩內容