聲音

2018-08-12 21:55 更新

聲音(Sound)

無論聲音在你的應用中是主要體驗的一環(huán),還是錦上添花的元素,你都需要知道用戶對聲音表現(xiàn)的期望以及與如何滿足這些期望。

理解用戶期望(Understand User Expectations)

人們可以使用設備控件來調(diào)整聲音,他們還可能使用有線或無線的耳機和聽筒。人們也會對于他們的行為如何作用于他們聽到的聲音有各種各樣的期望。雖然你可能會發(fā)現(xiàn)有一些期望很讓人意外,但它們都會遵循用戶控制的原則,即應是用戶而非設備掌控聽到聲音的時機。

用戶會依據(jù)需要將設備靜音:

  • 避免被突兀的音效打斷,比如手機鈴聲和信息接收音等
  • 避免聽到用戶操作所產(chǎn)生的副產(chǎn)品的聲音,比如鍵盤或其他反饋音、偶然的聲音或應用啟動的聲音
  • 避免聽到那些在玩游戲時非必要出現(xiàn)的聲音,如音效和配樂 例如,在劇院中,用戶將他們的設備調(diào)至靜音以避免打擾劇院中的其他人。在這一情境下,用戶仍然希望能在他們的設備上使用應用,但他們不希望被無預期或突兀的聲音所打斷,如手機鈴聲或新消息音。

當用戶操作的明確目的就是聽到聲音時,鈴音/靜音開關(或靜音開關)不會屏蔽這些操作所產(chǎn)生的聲音。例如:

  • 在僅有媒體播放功能的應用中的進行媒體播放是不會被靜音的,因為播放媒體是用戶明確期望的。
  • 鬧鐘不能被靜音,因為鬧鐘是用戶明確設定使用的。
  • 語言學習應用中的音效素材不能被靜音,因為用戶進行了明確的操作希望聽到它。
  • 音頻對話應用中的對話不被靜音,因為用戶打開這個應用的唯一目的就是進行音頻對話。 用戶使用設備音量調(diào)節(jié)按鍵可調(diào)節(jié)他們的設備所能發(fā)出的所有聲音的音量,包括歌曲、應用音效和設備聲音。不管鈴聲/靜音(或靜音)的開關在什么位置,用戶都能使用音量調(diào)節(jié)按鍵屏蔽所有聲音,使用音量調(diào)節(jié)按鍵調(diào)節(jié)應用當前所播放的音頻時同樣調(diào)整了全局系統(tǒng)的音量,鈴聲音量除外。

    對于 iPhone:當沒有音頻播放時使用音量鍵可以調(diào)整鈴聲音量。

用戶使用耳機的目的在于能夠私密地收聽聲音以及解放他們的雙手。不管這些配件是有線的還是無線的,用戶對這個體驗都有特定的期待。

當用戶插入耳機或連接無線音頻設備時,他們期望能以私密的狀態(tài)繼續(xù)收聽當前播放的音頻。因此,他們希望應用能夠不中斷地繼續(xù)播放當前正在播放的音頻。

當用戶拔出耳機或斷開與無線設備的連接時(抑或設備超出范圍或關閉時),他們不希望他們剛剛收聽的內(nèi)容被自動地與他人分享。因此,他們希望正在播放音頻的應用暫停播放,讓他們能夠在自己想要繼續(xù)播放的時候再開啟。

定義應用的音頻行為(Define the Audio Behavior of Your App)

如果必要的話,你可以通過調(diào)整相關的、獨立的音量水平以在你的應用中制造最好的混音輸出效果。但最終音效輸出的音量也應該能由系統(tǒng)音量控制,可以通過音量鍵或音量滑塊進行調(diào)節(jié)。這意味著應用的音頻輸出的控制權仍然歸屬在用戶手中。

確保你的應用能適時地顯示音頻路徑選擇。(音頻路徑(audio route)是指音頻信號的電子通路,例如從設備到耳機或是從設備到揚聲器。)即使人們沒有物理性的插入或拔出音頻設備,他們也仍希望能選擇其他不同的音頻路徑。為了實現(xiàn)這一訴求,iOS 能自動顯示可讓用戶選擇輸出音頻路徑的控件(使用 MPVolumeView 類能允許這個控件顯示在你的應用中)。由于選擇不同的音頻路徑是用戶主動的行為,用戶期望當前播放的音頻能繼續(xù)不中斷。

如果你需要顯示音量滑塊,在使用 MPVolumeView 類時,確保使用的是系統(tǒng)提供的可用的音量滑塊。注意,當正在使用的音頻輸出設備不支持音量控制時,音量滑塊會被合適的設備名稱所替代。

如果你的應用只產(chǎn)生一些與其功能無必要關系的界面音效時,(盡量)使用系統(tǒng)音效服務(System Sound Services)。系統(tǒng)音效服務是一種能產(chǎn)生警示音、界面音效和發(fā)出振動的 iOS 技術;它不適合任何其他用途。當你使用系統(tǒng)音效服務(System Sound Services)來產(chǎn)生音效時,你不能干涉你的音頻與設備的音頻的交互方式,也不能干涉它處理干擾和設備配置變化的方式。想了解如何使用這一技術,請參閱 Audio UI Sounds (SysSound)中的范例項目。

如果音效在你的應用中扮演重要的角色,使用音頻會話服務(Audio Session Services)或是 AVAudioSession 類。這些程序接口不產(chǎn)生音效;相反,它們會幫助你了解你的音頻應該如何與設備的音頻進行交互以及如何響應設備配置的干擾與變化。

對于 iPhone:無論你使用什么樣的技術來制作音頻,無論你如何定義來它的行為,電話總是可以中斷當前運行的應用。這是因為任何應用都不應該阻止人們接收來電。

在音頻會話服務(Audio Session Service)中,音頻會話(audio session)執(zhí)行了你的應用與系統(tǒng)之間音頻中介的功能。音頻會話中最重要的方面之一就是類目(category),它定義了你的應用的音頻行為。

為了實現(xiàn)音頻會話服務帶來的好處并提供用戶期望的音頻體驗,你需要選擇可以完美描述應用音頻行為的類目(category)。具體情況取決于你的應用只在前臺播放音頻還是也要在后臺播放音頻。在你做這一選擇的時候,遵循以下這些原則:

  • 依據(jù)其語義而非精確的行為來選擇音頻會話類目。通過選擇目的清晰的類目,你可以確保你的應用能表現(xiàn)得符合用戶期望。除此之外,當以后行為的精確集合被重新定義時,它可以為你的應用提供最佳的機會使其合理運行。
  • 在極少數(shù)情況下,可以添加屬性到音頻會話中以修正一個類別的標準行為。一個類別的標準行為代表多數(shù)用戶的期望,因此在你改變那個行為之前你應該仔細地考慮。例如,你可以添加閃避(ducking)屬性以確保你的音頻聲音能比其他所有的音頻都大(除了電話音頻),如果這就是用戶所期望的。(欲了解更多關于音頻會話屬性的內(nèi)容, 請參見的 Fine-Tuning the Category。)
  • 依據(jù)設備當前的音頻環(huán)境來考慮你的類目選擇。這應該是合理的,舉個例子,用戶可以在使用你的應用的同時聽其他音頻而非你的配樂。如果要這樣做,須確保避免當你的應用啟動時,迫使用戶停止收聽當前的內(nèi)容或要需要額外地在兩者之間做出選擇。
  • 通常情況下,避免在你的應用運行時改變類目。改變類目的首要依據(jù)是你的應用是否需要在不同的時機支持錄音和播放。在這種情況下,更好的選擇是依據(jù)需要在錄音類目與播放類目之間轉(zhuǎn)換,而非同時選擇播放和錄音類目。這是因為選擇錄音類目可以確保正在錄音時不會聽到提示音,比如收到信息的提示音。 表35-1列舉了你可以使用的音頻會話類目。不同的類目可以允許通過鈴聲/靜音開關或靜音開關(或設備鎖)來實現(xiàn)靜音、與其他的音頻混合或者控制應用在后臺播放。(欲了解編程界面上所呈現(xiàn)的類目和屬性的準確名稱,請參見 Audio Session Programming Guide.)

表35-1 音頻會話類目及其相關行為

*如果你選擇音頻處理類目并且你希望在后臺運行音頻進程,你需要在完成音頻處理之前防止你的應用被暫停。欲了解如何實現(xiàn)這一功能,參見《iOS 應用編程指南》中的執(zhí)行長時間運行的后臺任務。

以下是一些示例情境,其中指示了如何選擇音頻會話類目以提供用戶喜歡的音頻體驗。

情境1:一個幫助人們學習新語言的教育類應用。你需要提供:

  • 用戶點擊特定控件時播放反饋音效
  • 當用戶想聽到正確發(fā)音的示例時播放字詞的錄音

在這個應用中,聲音對于主要功能是十分重要的。人們使用這個應用來聽他們正學習的語言的詞語與短語,因此即使當設備鎖定或者被調(diào)至靜音時也要能播放聲音。因為用戶需要清晰地聽到聲音,他們會期望其他他們可能播放的音頻都被靜音。

為了滿足用戶對于該應用所期望的音頻體驗,你應該使用播放(Playback )類目。雖然這一類目可以被定義為與其他音頻混合,但該應用應該使用默認的行為以確保其他的音頻不會干擾那些用戶明確選擇聽到的教育性內(nèi)容。

場景2:網(wǎng)絡協(xié)議電話(VoIP)應用。你需要提供:

  • 接收音頻輸入的能力
  • 播放音頻的能力

在該應用中,聲音對于主要功能是十分重要的。人們經(jīng)常會在使用另一個應用時使用該應用與他人進行交流。用戶期望能在他們將設備調(diào)至靜音或設備被鎖定時接聽電話,他們希望在來電期間其他音頻被靜音。他們也希望應用在后臺運行時也能繼續(xù)打電話。

為了滿足用戶對于該應用所期望的音頻體驗,你應該使用播放和錄音(Play and Record)類目,并且你要確保只有在你需要時才會激活你的音頻會話,以便用戶可以在打電話過程中使用其他音頻。

場景3:允許用戶在不同任務中操作角色的游戲。你需要提供:

  • 不同的游戲運行音效
  • 配樂

在該應用中,聲音會在很大程度上提升用戶體驗,但對于主任務并沒有那么重要。而且,用戶可能會希望能在玩游戲時靜音或聽他們樂單中的歌曲而不聽游戲配樂。

最好的策略是在你的應用啟動時確定用戶是否在收聽其他音頻。不要要求用戶選擇他們是要收聽其他音頻或是你的音效。而應該使用音頻會話功能中的 AudioSessionGetProperty 來請求 kAudioSessionProperty_OtherAudioIsPlaying 屬性的狀態(tài)。依據(jù)所請求的答案,你可以選擇環(huán)境(Ambient)或是個人環(huán)境(Solo Ambient)類目(這兩種類目都允許用戶靜音玩游戲):

  • 如果用戶正在聽其他音頻,你應該假設他們想要繼續(xù)聽并且不想被強迫收聽游戲音效。在這種情境下,你最好選擇環(huán)境(Ambient)類目。
  • 如果用戶在你的應用啟動時沒有在收聽其他音效,你最好選擇個人環(huán)境(SoloAmbient)類目。

情境4:一個為用戶到達目的地提供準確、實時導航指示的應用。你需要提供:

  • 路途中每一步的語音指示
  • 一些反饋音效
  • 支持用戶繼續(xù)收聽他們自己的音頻的能力

在該應用中,無論應用是否是在后臺運行,語音導航指示都表現(xiàn)為主要任務?;谶@一原因,你最好使用播放(Playback)類目,它允許你的音頻在設備被鎖定、靜音或是在后臺運行時仍可以播放。

你可以通過添加 kAudioSessionProperty_OverrideCategoryMixWithOthers 屬性來實現(xiàn)允許人們在使用你的應用時收聽其他音頻。但是你也想要確保用戶在他們正在播放其他音頻時能聽到語音提示。你可以為音頻會話添加 kAudioSessionProperty_OtherMixableAudioShouldDuck 屬性來確保你的音頻比其他音頻的聲音更大( iPhone 上的電話音頻除外)。這些設置允許應用在后臺運行時也可以恢復音頻會話,可以確保用戶能獲得實時更新的導航。

情境5:一個允許用戶上傳文本和圖片到網(wǎng)站上的博客應用。你需要提供:

  • 簡短的啟動音效文件
  • 伴隨用戶行為產(chǎn)生的各式各樣的短音效(例如當郵件被上傳后播放的音效)
  • 發(fā)送失敗時播放的提示音

在該應用中,聲音提升了用戶體驗,但也不是必需的。主任務與音頻并沒有關系,用戶也不是必須要通過收聽聲音才能成功使用應用。在這一情境中,你最好使用系統(tǒng)聲音服務來產(chǎn)生聲音。這是因為這個應用中所有聲音的音頻情境都符合本技術想要達到的目的,也就是說應制作符合用戶所期待的、能通過設備和鈴聲/靜音(或靜音)開關來調(diào)節(jié)的界面音效和提示音。

管理音頻中斷(Manage Audio Interruptions)

有時候,當前播放的音頻會被來自于不同應用的音頻所打斷。舉個例子,在 iPhone 上,來電會持續(xù)中斷當前應用的音頻。在多任務情境中,這種音頻中斷的頻率可能會很高。

為了提供用戶喜歡的音頻體驗,iOS 系統(tǒng)依賴于你能做到下面幾點:

  • 識別可能會引起應用中斷的音頻類型
  • 當應用在音頻中斷結(jié)束后繼續(xù)運行時進行合理地反饋

每個應用需要識別會引起音頻中斷的類型,但不是每個應用都需要決定如何在音頻中斷結(jié)束后進行反饋。這是因為多數(shù)類型的應用應在音頻中斷結(jié)束后恢復音頻。只有那些主要或部分由媒體播放組成(以及提供媒體播放控制)的應用,才必須用額外的步驟來決定什么是合適的反饋。

從概念上講,基于中斷當前音頻的音頻類型以及中斷結(jié)束后用戶所期望的特定的應用反饋方式,有兩種類型的音頻中斷:

  • 可恢復性中斷是(resumable interruption)被用戶視為臨時穿

插在他們的主要聆聽體驗中的音頻引起的。 在可恢復性中斷結(jié)束后,有媒體播放控件的應用應該恢復它被中斷前的任務,無論是繼續(xù)播放音頻還是保持暫停。沒有媒體播放控件的應用則應該恢復播放音頻。

舉個例子,試想用戶在 iPhone 上使用應用播放音樂時,在播一首歌的中間來了一個網(wǎng)絡電話。用戶接起了電話,期望在他們通話時播放的應用能靜音。在通話結(jié)束后,用戶希望播放的應用自動恢復播放歌曲,因為音樂而非電話才是他們的主要聆聽體驗,而他們在電話接入前也沒有暫停音樂。另一方面,如果用戶在電話接入前暫停了音樂播放,他們會希望電話結(jié)束后音樂仍保持暫停。

其他能引起可恢復性中斷的應用的例子還有那些具備鬧鐘、音頻提示(例如語音方向指示)或其他間歇性音頻功能的應用。

  • 不可恢復中斷(nonresumable interruption)是由那些被用戶

視為首要聽覺體驗的音頻所引起的,比如媒體播放產(chǎn)生的音頻。在不可恢復中斷結(jié)束后,顯示媒體播放控件的應用不應該恢復播放原來的音頻。而沒有媒體播放控件的應用應該恢復播放音頻。例如,假設用戶正在收聽一個音樂播放應用(音樂應用1),此時另一個音樂播放應用(音樂應用2)打斷了它。用戶終止后決定收聽音樂應用2一段時間。在退出音樂應用2之后,用戶不想要音樂應用1自動恢復播放,因為此時他們主動將音樂應用2作為首要的聽覺體驗。 下面的指南可以幫助你決定當一個音頻中斷后如何繼續(xù)以及提供什么信息:

確定由你的應用引起的音頻中斷的類型。在你的音頻結(jié)束時,你可以通過以下任意一種方式去禁用你的音頻會話來做到這一點:

  • 如果你的應用引起了一個可恢復性中斷,使用 AVAudioSessionSetActiveFlags_NotifyOthersOnDeactivation 標識禁用你的音頻會話。
  • 如果你的應用引起了一個不可恢復中斷,不用任何標識就可以禁用你的音頻會話。 無論提供與否,標識會在適宜的情況下允許iOS系統(tǒng)賦予被中斷的應用自動恢復播放它們的音頻的能力。

決定是否應該在一個音頻中斷結(jié)束后恢復音頻。你應依據(jù)你應用中所提供的音頻體驗來做這一決斷。

  • 如果你的應用給用戶呈現(xiàn)了用于播放或暫停音頻的媒體播放控件,你需要在一個音頻中斷結(jié)束后檢查AVAudioSessionInterruptionFlags_ShouldResume標識,如果你的應用接受應該恢復(Should Resume)標識,你的應用應該:
  • 恢復播放音頻(你的應用被打斷時在主動播放音頻)
    • 不恢復播放音頻(你的應用被打斷時沒有在主動播放音頻)
  • 如果你的應用沒有呈現(xiàn)任何用戶可用于播放或暫停音頻的媒體播放控件,你的應用無論是否有“應該恢復”標識,都始終應在音頻中斷結(jié)束后恢復之前播放的音頻。例如,播放配樂的游戲應該在被中斷后自動恢復播放配樂。

適時處理媒體遠程控制事件(Handle Media Remote Control Events, if Appropriate)

當人們使用 iOS 媒體控制器或輔助控制器(如耳機線控)時,應用要能響應遠程控制。使你的應用能接收來自于你的用戶界面之外的輸入,無論你的應用當前是在前臺還是后臺播放音頻。

應用可以在播放媒體的過程中,通過后臺向支持 Airplay 的硬件(如 Apple TV)發(fā)送視頻。這樣的應用可以接收通過遠程控制事件實現(xiàn)的用戶輸入行為,因此用戶可以控制處于后臺運行狀態(tài)的應用中的視頻播放。除此之外,這類應用在后臺運行時也能恢復被中斷的音頻。

當一個媒體播放應用在后臺播放音頻或視頻時,尤其需要合理響應媒體遠程控制事件。

當你的應用在后臺運行時,為了滿足與播放媒體特權相關的責任,要確保遵循以下這些原則:

限制你的應用接收遠程控制事件的次數(shù)。例如,當你的應用可以幫助用戶閱讀內(nèi)容、搜索信息或是收聽音頻時,它只有在用戶處于音頻場景中時才應該接收遠程控制事件。當用戶脫離音頻情境時,你應該放棄接收事件的能力。如果你的應用允許用戶在支持 AirPlay 的設備上播放音視頻,它應該在媒體播放期間都可以接收遠程控制事件。遵循這些原則能使用戶在你的應用中處于非媒體情境中時,通過耳機控制獲得另一個應用的媒體體驗。

盡可能地使用系統(tǒng)原生的控件以提供 AirPlay 支持。當你使用 MPMoviePlayerController 類實現(xiàn) AirPlay 播放功能時,你可以利用標準的控件使用戶可以選擇當前范圍內(nèi)支持 AirPlay 的硬件?;蛘吣憧梢允褂?MPVolumeView 類來顯示用戶可選擇的支持 AirPlay 的音頻或視頻設備。用戶習慣于這些標準控件的外觀和行為,因此他們可以理解如何在你的應用中使用它們。

不要改變事件的用途,即使這個事件在你的應用中沒有意義。用戶期望 iOS 系統(tǒng)的所有應用媒體控制和輔助控制能有功能上的統(tǒng)一。你不必實現(xiàn)你的應用所不需要的那些事件,但你所實現(xiàn)的事件必須產(chǎn)生符合用戶期望的結(jié)果。如果你重新定義一個事件的意義,你會使用戶困惑并冒險把他們帶入一個未知的狀態(tài),他們只能通過退出你的應用來逃離。

以上內(nèi)容是否對您有幫助:
在線筆記
App下載
App下載

掃描二維碼

下載編程獅App

公眾號
微信公眾號

編程獅公眾號