標籤：
聲音
無論聲音是你app使用者體驗的主要部分還是一個可選的增益，你都要知道使用者對聲音有何期待以及如何滿足這些期待。
理解使用者的期待
使用者可以使用裝置的控制來影響聲音，並且他們可能使用有線或無線耳機。人們也對他們的行為如何影響他們聽到的聲音抱有很多期待。雖然你可能會發現有些期待很驚人，但這都遵循使用者，而不是裝置，決定的使用者控制。
當使用者想要做如下事情的時候他們會使裝置靜音：
- 避免被不期待的聲音幹擾，比如電話鈴聲和收到簡訊的聲音
- 避免聽到使用者行為副產品的聲音，比如鍵盤或其他反饋聲音、附帶聲音或者app啟動聲音
- 避免聽到對使用遊戲非必要的遊戲聲音，比如音效和配樂
比如說，在電影院內使用者使他們的裝置靜音避免打擾到其他的人。在這種情況下，使用者依然想要在他們的裝置上使用app，但不想被他們不期待或者請求明顯的聲音所驚嚇，比如鈴聲或者新簡訊聲。
靜音開關不會關閉單獨由使用者動作導致的和明確為了產生聲音的聲音。比如：
- 一個只播放媒體的app中的媒體播放不會被靜音，因為媒體播放是明確被使用者請求的。
- 語言學習app中的音效素材不會被靜音，因為使用者明確要聽到它。
- 語音交談app中的對話不會被靜音，因為使用者啟動app的唯一目的就是進行語音交談。
使用者使用裝置的音量按鈕來調整他們裝置可以播放的所有聲音的音量，包括歌曲、app聲音和裝置聲音。無論靜音開關的位置在哪，使用者都可以使用音量按鈕來安靜任何聲音。使用音量按鈕來調整一個app當前播放的音量同樣會調整所有系統的音量，包括鈴聲音量。
IPHONE當沒有聲音播放時使用音量按鈕會調整鈴聲音量。
使用者使用耳機來私下聽聲音並解放他們的雙手。無論這些裝置是有線還是無線，使用者都有著特殊的使用者體驗的期待。
當使用者插上耳機，或者串連到一個無線聲音裝置時，他們想要繼續聽到當前的聲音，但是是私下的。因此，他們希望當前現正播放聲音的app能夠不暫停地繼續播放。
當使用者拔出耳機，或者從一個無線裝置中斷連線（或者裝置超出距離或者關閉）時，他們不想自動分享他們聽的內容給其他人。因此他們希望當前現正播放聲音的app暫停，允許他們在準備好的時候重新播放。
定義你app的聲音行為
如果有必要，你可以對你的app調整相關的，獨立的音量水平來產生最好的混合音訊輸出。但最終輸出的音量應該總是由系統音量所管理，無論是音量按鈕還是音量滑動條。這意味著app的聲音輸出依然由所屬的使用者來掌控。
合適的話，確保你的app可以選擇音頻線路。（音頻線路指聲音訊號的一個電子線路，例如從裝置到耳機或者從裝置到話筒。）即使人們不物理地插上或者拔出無線聲音裝置，他們也希望能夠選擇一個不同的音頻線路。為了處理這個，iOS會自動顯示一個控制器讓使用者選擇一個輸出的音頻線路（使用MPVolumeView類來讓控制器顯示在你的app中）。因為選擇一個不同的音頻線路是一個使用者發起的動作，他們期望當前播放的聲音不要暫停地繼續播放。
如果你需要顯示一個音量滑動條，當你使用MPVolumeView類時確保使用系統提供的音量滑動條。注意噹噹前使用的聲音輸出裝置不支援音量控制時，音量滑動條會被合適的裝置名稱替換。
如果你的app只產生對功能不是必須的UI音效，那麼就使用系統聲音服務。系統聲音服務時一個產生警告框、UI音效和震動的iOS技術；它不適用於任何其他目的。當你使用系統聲音服務來產生聲音時，你不能影響你的聲音與裝置上的聲音的互動方式，以及它被裝置配置打斷和更改時的響應。查看Audio UI Sounds (SysSound)擷取示範使用這個技術的簡單工程。
如果聲音在你的app中扮演了很重要的角色，使用音頻會話服務或者AVAudioSession類。這些編程介面不產生聲音；它們協助你表達你的聲音和裝置上的聲音應有的互動方式以及對裝置配置打斷和更改的響應。
IPHONE
無論你使用何種技術產生聲音或者定義它的行為，手機都可以中斷當前啟動並執行app。這是因為沒有app應該保護人們免於收到來電。
在音頻會話服務中，音頻會話功能作為你的app和系統之間的一個聲音媒介。其中一個最重要的方面就是類別（category），這定義了你app中聲音的行為。
為了體會音頻會話服務的優勢以及提供使用者期待的聲音體驗，你需要選擇最能描述你app中聲音行為的類別。這裡是你的app是只能在前台播放聲音還是也能在背景播放的情況。當你進行這個選擇時遵循下面的指南：
- 基於語義選擇音頻會話類別，而不是它精確地一系列行為。通過目的清晰地選擇一個類別，你確保你的app按照使用者期待的方式來行為。此外，這給了你的app最好的機會來在未來一系列的行為改善時表現得合適。
- 在很少的情況下，添加一個恰當的音頻會話來修改一個類別的標準行為。一個類別的標準行為代表了使用者最期待的內容，所以在你改變行為前要仔細地考慮。比如說，你可能會恰當地添加緊急降低來確保你的聲音比所有其他的聲音都低（尤其是來電聲音），如果這是使用者期望你的app做的話。（查看Fine-Tuning a Category來學習更多關於音頻會話屬性的內容。）
- 考慮基於予你當前裝置的聲音環境來選擇類別。這在某些情況下，比如，使用者可以在聽其他聲音而不是你的聲道時使用你的app，就會有意義。如果你這樣做，確保避免在你的app啟動時讓你的使用者停止他們正在聽的音樂或者進行一個聲道的選擇。
- 一般來說，在你的app運行時避免改變類別。主要的改變類別的原因是你的app需要在不同的時間支援錄音和播放的時候。這種情況下，在錄音類別和播放類別之間按需轉換會比選擇播放和錄音類別好。因為選擇錄音類別可以確保在錄音中不想起提示音——比如收到簡訊的提示音。
表1列出了你可以使用的音頻會話類別。不同的類別允許聲音被靜音開關（或者裝置鎖屏）靜音、和其他聲音混合或者當app在後台時播放聲音。（查看Audio Session Programming Guide擷取他們在編程介面中的合適名稱和實體類別。）
表1 音頻會話類別和他們關聯的行為
| 類別 |
意義 |
可靜音 |
可混合 |
可後台播放 |
| 獨奏氛圍 |
聲音會加強app的功能，並且應該靜音其他聲音 |
是 |
否 |
否 |
| 氛圍 |
聲音會加強app的功能但不應該靜音其他聲音 |
是 |
是 |
否 |
| 播放 |
聲音對app功能是必要的而且可能和其他聲音混合 |
否 |
否（預設）
是（當添加和其他聲音混合的效能時） |
是 |
| 錄音 |
音頻是使用者記錄的 |
否 |
否 |
是 |
| 播放和錄音 |
聲音代表音訊輸入和輸出，順序或同時的 |
否 |
否（預設）
是（當添加和其他聲音混合的效能時） |
是 |
| 音頻處理 |
App執行藉助硬體的音頻編碼（不播放或錄音） |
不適用 |
否 |
是 |
* 如果你選擇音頻處理類別並且想要在後台執行音頻處理，你需要保護你的app避免在完成音頻處理之前被掛起。查看Implementing Long-Running Background Tasks學習如何這樣做。
這裡是一些情景，可以說明如何選擇一個提供使用者期待的音頻體驗的音頻會話類別。
情景一：一個協助人們學習一門新語言的教育類app。你提供：
- 當使用者想要聽準確發音的樣本時播放單詞和短語的錄音。
在這個app中，聲音對主要功能是必須的。人們使用這個app來聽他們正在學習的語言的單詞和短語，所以即使裝置鎖了或者切換到靜音了也應該播放聲音。因為使用者需要清洗地聽到聲音，他們期待其他他們可能播放的音頻靜音。
為了產生使用者期待這個app所有的音頻體驗，你應該使用播放類別。即使這個類別可能允許和其他音訊混合，這個app應該使用預設行為來確保其他的音頻不和使用者明確選擇去聽的教育內容相競爭。
情景二：一個網路電話（VoIP）app。你提供：
在這個app中，聲音對主要功能是必須的。人們使用這個app來與他人交流，並且經常在他們使用不同的app的時候。使用者期待當他們切換靜音或者鎖上裝置的時候也能收到電話，並且他們期待在對話期間其他音頻是靜音的。他們也期待當app在後台時能夠持續通話。
為了產生使用者期待這個app所有的音頻體驗，你應該使用播放和錄音類別，並且你要確保你的音頻會話只在你需要的時候活動，這樣使用者就可以在通話之間使用其他的音頻。
情景三：一個允許使用者指導一個角色完成不同任務的遊戲。你提供：
在這個app中，聲音很好地加強了使用者體驗，但對主任務不是必要的。同樣，使用者希望可以靜音地玩遊戲或者聽他們音樂庫的音樂而不是遊戲配樂。
最好的策略是判斷使用者在啟動你的app的時候是否在聽其他音頻。不要要求使用者選擇是繼續聽其他音頻還是挺你的配樂。相反，使用音頻會話服務的功能AudioSessionGetProperty來詢問kAudioSessionProperty_OtherAudioIsPlaying屬性的狀態。給予這個詢問的回答，你可以選擇氛圍或者獨奏氛圍類別（兩個類別都允許使用者靜音玩遊戲）：
- 如果使用者在聽其他音頻，你應該假設他們傾向於繼續聽並且不想被強制聽遊戲配樂。在這種情況下，你應該選擇氛圍類別。
- 如果使用者在啟動你的app時沒有在聽任何其他音頻，你應該選擇獨奏氛圍類別。
情景四：一個提供準確、即時的使用者目的地的導航指令的app。你提供：
在這個app中，無論app是否在後台，語音導航指令代表了主要任務。因此，你應該使用播放類別，允許你的音頻在裝置被鎖、切換到靜音或者在後台時播放音頻。
為了允許人們在使用你的app時聽其他音頻，你可以添加kAudioSessionProperty_OverrideCategoryMixWithOthers屬性。然而，你也希望確保使用者在他們當前播放的音頻之上可以聽清語音指令。因此，你可以對音頻會話申請kAudioSessionProperty_OtherMixableAudioShouldDuck屬性來確保你的音頻比其他所有現正播放的音頻要響，不過iPhone的手機音頻除外。這個設定允許app在背景時候恢複其音頻會話的活動，確保使用者可以擷取導航的即時更新。
情景五：一個允許使用者更新他們的文本和圖形到網頁的部落格app。你提供：
- 伴隨使用者動作的多種簡短音效（比如當一個提交上傳時播放的聲音）
在這個app中，聲音加強了使用者體驗，但不是必須的。主任務與音頻沒有關係，而且使用者不需要聽到任何聲音來成功地使用app。在這種情景下，你應該使用系統聲音服務來產生聲音。這是因為app中所有聲音的音頻環境都遵循這個技術的預期使用目的，即產生符合使用者期待的遵守裝置鎖屏和靜音開關的方式的UI音效和警告音。
管理音頻中斷
有時候，當前播放的音頻會被其他app的音頻打斷。在iPhone上，比如說，一個打過來的電話會在通話期間打斷當前app的音頻。在多任務環境下，這種音頻中斷的頻率會很高。
為了提供一個使用者喜歡的音頻體驗，iOS依靠你來：
每個app都需要識別它能夠導致的音頻中斷類型，但不是每個app都要決定如何響應音頻中斷的結束。這是因為大部分類型的app應該通過回複音頻來響應音頻中斷的結束。只有那些主要或部分播放媒體的app——和那些提供媒體播放控制項的app——需要額外定義合適的響應。
概念上說，有兩種類型的音頻中斷，基於導致中斷的音頻類別和使用者期待app在中斷結束時響應的方式：
- 可恢複中斷是由使用者在主要聆聽體驗中臨時查看的音頻導致的。
在可恢複中斷結束後，顯示媒體播放控制項的app應該恢複在中斷髮生時進行的內容，無論是播放音頻還是保持暫停。沒有媒體播放控制項的app應該恢複播放音頻。
比如說，考慮一個使用者正在iPhone上聽一個音樂播放app，在音樂中間收到一個VoIP電話。使用者回覆這個電話，期待在他們通話的時候播放app能夠靜音。在通話結束後，使用者期待這個播放app自動地回複播放音樂，因為音樂——而不是通話——構成了他們的主要聆聽體驗並且他們沒有在電話到來前暫停音樂。另一方面如果使用者在電話到來前暫停了音樂播放，他們會期待音樂在通話結束後保持暫停。
其他可以導致可恢複中斷的app有鬧鐘、音頻提示（比如語音提示駕駛方向）等其他中斷音頻。
- 不可恢複中斷是由使用者作為主要聆聽體驗的音頻，比如媒體播放app的音頻，造成的。
在不可恢複中斷結束後，顯示媒體播放控制項的app不應該恢複播放音頻。沒有媒體播放控制項的app應該恢複播放音頻。
比如說，考慮使用者聆聽一個音樂播放app（音樂app1），而另一個不同的音樂播放app（音樂app2）打斷了。作為響應，使用者決定聽一段時間的音樂app2。在退出音樂app2之後，使用者不期望音樂app1自動回復播放，因為他們有意讓音樂app2變成他們的主要聆聽體驗。
下面的指南協助你決定提供什麼資訊以及如何在一個音頻中斷結束後繼續。
識別你的app可以導致的音頻中斷類型。當你的音頻終止時通過在下面兩種方式中的一種來停止你的音頻會話。
- 如果你的app導致一個可恢複中斷，伴隨AVAudioSessionSetActiveFlags_NotifyOthersOnDeactivation標識停止你的音頻會話
- 如果你的app導致一個不可恢複中斷，不要伴隨任何標識來停止你的音頻會話
提供或不提供，這個標識允許iOS給中斷的app能力來自動回復播放它們的音頻。
決定當一個音頻中斷時你是否應該恢複音頻。你基於這個決定來提供你app的音頻音頻使用者體驗。
- 如果你的app顯示人們用來播放或暫停音訊媒體播放控制項，你需要在一個音頻中斷結束時檢查AVAudioSessionInterruptionFlags_ShouldResume標識。
如果你的app接收到應該恢複的標識，你的app應該：
- 如果你的app在中斷髮生的時候現正播放音頻，則恢複播放
- 如果你的app在中斷髮生的時候沒有播放音頻，則不恢複播放
- 如果你的aoo不顯示播放或暫停控制項，你的app應該總是在音頻中斷結束的時候恢複自己的播放音頻，無論是否提供了應該恢複的標識。
比如說，一個播放配樂的遊戲應該總是在中斷結束後自動回復播放配樂。
合適的話，處理媒體遠端控制事件
app可以在使用者使用iOS媒體控制項或者配件控制項的時候接收遠端控制事件，比如耳機控制項。這允許你的app接收使用者從你的UI以外的地方輸入的資訊，無論你的app當前是在前台還是後台播放音頻。
app可以發送視頻給支援AirPlay的硬體——比如Apple TV——並且當播放繼續時過渡到後台。這種app可以接收使用者通過遠端控制事件輸入的資訊，這樣使用者就可以在app在後台時控制視頻的播放。此外，這種類型的app也可以在背景時候在中斷結束後恢複音頻會話。
尤其是，一個媒體播放app需要合適地響應媒體遠端控制事件，特別是當它在背景播放音頻或者視頻的時候。
為了滿足當你的app在後台時播放媒體相關的職責，確保遵循下述指南：
有意義的時候限制你的app接收遠端控制事件的時間。比如說，如果你的app協助使用者閱讀內容、搜尋資訊和聆聽音頻，它應該只在使用者在音頻環境下的時候接收遠端控制事件。當使用者離開音頻環境後，你應該放棄接收事件的能力。如果你的app讓使用者在支援AirPlay的裝置上播放音頻或視頻，它應該在媒體播放期間接收遠端控制事件。遵循這些指南允許使用者假設一個不同的app媒體——並且用耳機控制項控制它——當他們在你app中無媒體環境的時候。
儘可能地使用系統提供的控制項來提供AirPlay支援。當你使用MPMoviePlayerController類來支援AirPlay播放時，你可以從允許使用者選擇當前範圍內的AirPlay裝置的標準控制中獲益。或者你可以使用MPVolumeView類來顯示使用者可以選擇的支援AirPlay音頻或視頻的裝置。使用者習慣這些標準控制項的表現和行為，所以他們知道如何在你的app中使用它們。
不要重新改變事件的目的，即使事件在你的app中沒有意義。使用者期待iOS媒體控制項和配件控制項在所有app中的功能一致。你不用處理你app不需要的事件，但你處理的事件必須產生使用者期待的體驗。如果你重新定義一個事件的意義，你會迷惑使用者並且可能導致他們進入一個無知的狀態。
本文翻譯自蘋果官方開發文檔查看完整合集：https://github.com/Cloudox/iOS-Human-Interface-Guidelines著作權：http://blog.csdn.net/cloudox_
《iOS Human Interface Guidelines》——Sound
