高德智慧景區(qū)隨身聽播放器框架設(shè)計與實(shí)現(xiàn)

一、背景

“遠(yuǎn)看山有色，近聽水‘ 有’ 聲”，景區(qū)語音導(dǎo)覽是智慧景區(qū)重點(diǎn)業(yè)務(wù)之一，以用地圖可以邊走邊聽景區(qū)各景點(diǎn)的語音介紹為主要訴求，實(shí)現(xiàn)高德智慧景區(qū)地圖不僅可以看，還可以聽，從而使用戶交互體驗(yàn)得到跨越式提高。

我們想要讓“技術(shù)有溫度”，讓講解更加有感情和內(nèi)涵，最好可以通過講解構(gòu)造一個“UGC景區(qū)講解生態(tài)圈”，并且還能幫助講解創(chuàng)作者有一定的收益，以達(dá)到“生態(tài)圈的正向循環(huán)”，讓線上導(dǎo)游“天下沒有難做的生意”。

試想一下，當(dāng)游客走進(jìn)故宮，這時，高德地圖的語音包可以播放：“故宮有180萬件寶貝，青銅館、陶瓷館……”這段話的講解人，是著名收藏家、古董鑒賞家馬未都，是不是更加吸引你關(guān)注？另外，當(dāng)你漫步到延禧宮，語音包則會立刻講一講延禧宮與大熱的電視劇《延禧攻略》有什么關(guān)系，并且有背景音插入，是多么生動形象。

所以，我們開發(fā)選型并沒有采用傳統(tǒng)的TTS技術(shù)（由文本內(nèi)容生成機(jī)器語音），而是采用了更加通用音頻格式(比如mp3)，作為講解的音頻輸入源，方便講解者進(jìn)行二次創(chuàng)作。本文將簡單回顧高德智慧景區(qū)隨身聽播放器的框架設(shè)計與實(shí)現(xiàn)。

二、架構(gòu)設(shè)計前思考

“夫未戰(zhàn)而廟算勝者，得算多也；未戰(zhàn)而廟算不勝者，得算少也”，拉開戰(zhàn)斗序幕之前我們應(yīng)該盡量去“廟算”，提前預(yù)防和判斷并保證技術(shù)風(fēng)險可控，俗稱“防火”?！胺阑稹备芸闯霰臼?，而“救火”只是能力。開發(fā)應(yīng)盡量做到“不打無準(zhǔn)備之仗”。

首先， 如何提升開發(fā)和后續(xù)迭代效率？此問題涉及到是純Native開發(fā)還是用跨平臺混合技術(shù)開發(fā)。如果用純Native，雙端開發(fā)人力可能會使工作量翻倍，后期可維護(hù)性也差，經(jīng)常需要雙端同步拉齊。但純Native開發(fā)聲音相關(guān)的技術(shù)方案成熟且風(fēng)險較小。而用跨平臺混合技術(shù)開發(fā)，優(yōu)點(diǎn)和缺點(diǎn)正好與單純Native開發(fā)相反。經(jīng)過小組多次技術(shù)討論，看長遠(yuǎn)利益，最終確定用跨平臺技術(shù)方案，用該方案雖然技術(shù)挑戰(zhàn)和風(fēng)險大（比如需要和跨平臺架構(gòu)支撐團(tuán)隊一起“無中生有”的去打通JS的播放鏈路和各種音頻中斷能力回調(diào)等），但這個方案有個強(qiáng)有力的好處，就是可以“Write Once, Run Everywhere”（這里的Everywhere主要是指移動端操作系統(tǒng)），這樣可以天然的拉齊雙端業(yè)務(wù)代碼能力，大大節(jié)約開發(fā)周期和人力，對業(yè)務(wù)快速功能迭代很有優(yōu)勢，再苦再累再難也值得為此努力。

其次， 如何節(jié)省CPU和內(nèi)存資源？做移動開發(fā)的同學(xué)都知道，音頻播放是耗系統(tǒng)軟硬件資源的（比如CPU、內(nèi)存還有電量等），另外音頻播放不僅僅是涉及到單個App的事情，還涉及到第三方App音頻播放的影響（比如系統(tǒng)來電聲音焦點(diǎn)搶占，其他音樂App播放焦點(diǎn)搶占問題等）。

所以，業(yè)務(wù)層開發(fā)，要對底層播放器提供的播放能力進(jìn)行二次封裝，一是要控制播放器實(shí)例的隨意創(chuàng)建。二是要處理各第三方App的音頻播放焦點(diǎn)的申請和釋放等邏輯業(yè)務(wù)。由此可見，搭建一個通用的業(yè)務(wù)播放器框架勢在必行，受益良多。

再次， 如何使業(yè)務(wù)與音頻本身的播放框架能力隔離？業(yè)務(wù)多變，而音頻播放能力相對來說是穩(wěn)定的，其基本能力包括但不局限于（首次&續(xù)接）播放，暫停，搶占，打斷，音量調(diào)節(jié)（漸漸變強(qiáng)），物理（如耳機(jī)）按鍵響應(yīng)，打斷后場景恢復(fù)，緩存，預(yù)加載，強(qiáng)弱網(wǎng)絡(luò)和播放異常等。這些音頻本身的技術(shù)能力，最好應(yīng)該是和純業(yè)務(wù)是解耦的，盡量做到“高內(nèi)聚，低耦合”。

后來，經(jīng)過深思熟慮，我們認(rèn)為設(shè)計模式中的“ObserverPattern觀察者模式”，比較切合這一技術(shù)背景。純業(yè)務(wù)和音頻框架本身制定通用的接口協(xié)議，然后純業(yè)務(wù)自由注冊監(jiān)聽器到音頻播放框架中，根據(jù)關(guān)心的回調(diào)事件自由處理自己的業(yè)務(wù)，而音頻框架本身只做主要的焦點(diǎn)搶占，現(xiàn)場恢復(fù)和事件分發(fā)等事情，非常符合SRP原則（單一職責(zé)），后續(xù)調(diào)試和維護(hù)都很方便。

最后，如何實(shí)現(xiàn)跨Page播放能力？如下圖所示：

隨身聽很多業(yè)務(wù)是有跨Page播放要求的，如果將播放能力直接提供出來，由各個頁面的Page自己維護(hù)，勢必會生出很多的Audio，混亂而且頁面相互通信交換信息成本高。后經(jīng)過討論，就有了如下圖的架構(gòu)方式設(shè)計：

結(jié)合跨平臺底層播放器的特性，虛擬出來一個BizService放在跨平臺框架的Service容器（和安卓里面的Service概念差不多，提供一個無界面的可以處理公共業(yè)務(wù)的容器）里面，處理Page頁面業(yè)務(wù)管理和信息交換以及緩存管理，BizService只和BizVoiceMediaCenter交互管理音頻數(shù)據(jù)，也就是說BizVoiceMediaCenter是通用播放器框架對外一個"門面"（Facade門面設(shè)計模式）。BizVoiceMediaCenter里面會有且僅有一個VoiceMediaAlbum實(shí)例（播放專輯，提供“上一曲”，“下一曲”，順序播放，續(xù)播等能力）。

三、架構(gòu)設(shè)計和開發(fā)

首先，我們先簡單看下跨平臺底層播放器的生命周期，如下圖所示：

熟悉Native開發(fā)的同學(xué)應(yīng)該知道，跨平臺底層播放器的架構(gòu)和生命周期，和Android本身系統(tǒng)播放器非常相似，差異點(diǎn)是音頻焦點(diǎn)被搶占和恢復(fù)的回調(diào)部分，iOS設(shè)備是onInterrupted，當(dāng)音頻被其他應(yīng)用打斷開始時回調(diào)，如電話鈴聲響起觸發(fā)此回調(diào)（在此回調(diào)中保存播放器狀態(tài)，以便在onInterruptedEnd回調(diào)中恢復(fù)播放）。onInterruptedEnd，當(dāng)音頻被其他應(yīng)用打斷結(jié)束時回調(diào)，如掛斷后觸發(fā)此回調(diào)。而Android是onFocusChanged，當(dāng)音頻焦點(diǎn)變化后回調(diào)。當(dāng)然還有其它一些細(xì)微差別，比如雙端，播放錯誤碼不一致，播放異常超時邏輯不一致等。但這些都可以通過在業(yè)務(wù)層構(gòu)建自己VoiceMediaPlayer來拉齊以及處理通用音頻焦點(diǎn)搶占和丟失場景的邏輯。

通過上面分析，我們可以大體搭出如下圖業(yè)務(wù)播放器的整體框架圖(圖中箭頭表示數(shù)據(jù)流的方向)。

我們可以很容易的看出，業(yè)務(wù)對跨平臺底層播放器Audio進(jìn)行了二次封裝為VoiceMediaPlayer，拉齊和處理通用業(yè)務(wù)場景（比如搶焦點(diǎn)，播放，現(xiàn)場恢復(fù)，播放異常，藍(lán)牙或耳機(jī)物理按鍵響應(yīng)等）。

VoiceMediaPlayer再上層是VoiceMediaAlbum（播放專輯），VoiceMediaAlbum專輯類，主要是處理順序播放，上一曲，下一曲，整個專輯播放事件（單曲播放信息和進(jìn)度，整體播放進(jìn)度透出，自動切換順序，循環(huán)或業(yè)務(wù)指定下一曲播放等），VoiceMediaAlbum和業(yè)務(wù)層的BizVoiceMediaCenter打交道，當(dāng)然BizVoiceMediaCenter也可以直接和VoiceMediaPlayer打交道，但我們一般不建議這么做，即便是就播放一首音頻，我們也希望，把這首音頻當(dāng)成一個專輯來包裝和調(diào)用（隨身聽業(yè)務(wù)也確實(shí)是這么做的)，這樣更加規(guī)范和方便以后擴(kuò)展。

最后，我們來看看整體架構(gòu)的詳細(xì)類設(shè)計圖，如下圖所示：

四、落地產(chǎn)出

高德智慧景區(qū)隨身聽播放器框架完成后，很好的支撐了隨身聽后續(xù)版本的開發(fā)。此外，后續(xù)因業(yè)務(wù)需求對產(chǎn)品做了多次迭代和變更，但播放器的架構(gòu)幾乎不需要做很大調(diào)整和升級（即使后面又增加了離線播放能力），很好驗(yàn)證了其穩(wěn)定性和可擴(kuò)展能力。下面一系列圖，我們可以看出這顆“種子”(景區(qū)隨身聽播放器框架)，開出的美麗的“花”，如下圖所示：

以上各個頁面底層都共用了這個播放器框架，很方便的實(shí)現(xiàn)了音頻的跨頁面播放和管理，以及異常中斷的統(tǒng)一處理。高效滿足了相關(guān)音頻業(yè)務(wù)的播放能力要求，也為高德智慧景區(qū)隨身聽業(yè)務(wù)后續(xù)迭代開發(fā)打下了堅實(shí)的地基。

  溫馨提示：

由高德地圖發(fā)起，阿里云天池平臺作為支撐平臺的AMAP-TECH算法大賽初賽已經(jīng)開啟，賽題為基于車載視頻圖像的動態(tài)路況分析，權(quán)威評委、豐厚獎金、終面通道、榮譽(yù)證書，歡迎大家參與，一起用技術(shù)幫助更多人美好出行!

初賽（7月8日-8月31日，UTC+8）。賽題詳情及參賽鏈接：

https://tianchi.aliyun.com/competition/entrance/531809/introduction