一、背景
“遠看山有色，近聽水‘有’聲”，景區語音導覽是智慧景區重點業務之一，以用地圖可以邊走邊聽景區各景點的語音介紹為主要訴求，實作高德智慧景區地圖不僅可以看，還可以聽，進而使使用者互動體驗得到跨越式提高。
我們想要讓“技術有溫度”，讓講解更加有感情和内涵，最好可以通過講解構造一個“UGC景區講解生态圈”，并且還能幫助講解創作者有一定的收益，以達到“生态圈的正向循環”，讓線上導遊“天下沒有難做的生意”。
試想一下，當遊客走進故宮，這時，高德地圖的語音包可以播放：“故宮有180萬件寶貝，青銅館、陶瓷館……”這段話的講解人，是著名收藏家、古董鑒賞家馬未都，是不是更加吸引你關注？另外，當你漫步到延禧宮，語音包則會立刻講一講延禧宮與大熱的電視劇《延禧攻略》有什麼關系，并且有背景音插入，是多麼生動形象。
是以，我們開發選型并沒有采用傳統的TTS技術（由文本内容生成機器語音），而是采用了更加通用音頻格式(比如mp3)，作為講解的音頻輸入源，友善講解者進行二次創作。本文将簡單回顧高德智慧景區随身聽播放器的架構設計與實作。
二、架構設計前思考
“夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也”，拉開戰鬥序幕之前我們應該盡量去“廟算”，提前預防和判斷并保證技術風險可控，俗稱“防火”。“防火”更能看出本事，而“救火”隻是能力。開發應盡量做到“不打無準備之仗”。
首先，如何提升開發和後續疊代效率？此問題涉及到是純Native開發還是用跨平台混合技術開發。如果用純Native，雙端開發人力可能會使工作量翻倍，後期可維護性也差，經常需要雙端同步拉齊。但純Native開發聲音相關的技術方案成熟且風險較小。而用跨平台混合技術開發，優點和缺點正好與單純Native開發相反。經過小組多次技術讨論，看長遠利益，最終确定用跨平台技術方案，用該方案雖然技術挑戰和風險大（比如需要和跨平台架構支撐團隊一起“無中生有”的去打通JS的播放鍊路和各種音頻中斷能力回調等），但這個方案有個強有力的好處，就是可以“Write Once, Run Everywhere”（這裡的Everywhere主要是指移動端作業系統），這樣可以天然的拉齊雙端業務代碼能力，大大節約開發周期和人力，對業務快速功能疊代很有優勢，再苦再累再難也值得為此努力。
其次，如何節省CPU和記憶體資源？做移動開發的同學都知道，音頻播放是耗系統軟硬體資源的（比如CPU、記憶體還有電量等），另外音頻播放不僅僅是涉及到單個App的事情，還涉及到第三方App音頻播放的影響（比如系統來電聲音焦點搶占，其他音樂App播放焦點搶占問題等）。
是以，業務層開發，要對底層播放器提供的播放能力進行二次封裝，一是要控制播放器執行個體的随意建立。二是要處理各第三方App的音頻播放焦點的申請和釋放等邏輯業務。由此可見，搭建一個通用的業務播放器架構勢在必行，受益良多。
再次，如何使業務與音頻本身的播放架構能力隔離？業務多變，而音頻播放能力相對來說是穩定的，其基本能力包括但不局限于（首次&續接）播放，暫停，搶占，打斷，音量調節（漸漸變強），實體（如耳機）按鍵響應，打斷後場景恢複，緩存，預加載，強弱網絡和播放異常等。這些音頻本身的技術能力，最好應該是和純業務是解耦的，盡量做到“高内聚，低耦合”。
後來，經過深思熟慮，我們認為設計模式中的“ObserverPattern觀察者模式”，比較切合這一技術背景。純業務和音頻架構本身制定通用的接口協定，然後純業務自由注冊監聽器到音頻播放架構中，根據關心的回調事件自由處理自己的業務，而音頻架構本身隻做主要的焦點搶占，現場恢複和事件分發等事情，非常符合SRP原則（單一職責），後續調試和維護都很友善。
最後，如何實作跨Page播放能力？如下圖所示：
随身聽很多業務是有跨Page播放要求的，如果将播放能力直接提供出來，由各個頁面的Page自己維護，勢必會生出很多的Audio，混亂而且頁面互相通信交換資訊成本高。後經過讨論，就有了如下圖的架構方式設計：
結合跨平台底層播放器的特性，虛拟出來一個BizService放在跨平台架構的Service容器（和安卓裡面的Service概念差不多，提供一個無界面的可以處理公共業務的容器）裡面，處理Page頁面業務管理和資訊交換以及緩存管理，BizService隻和BizVoiceMediaCenter互動管理音頻資料，也就是說BizVoiceMediaCenter是通用播放器架構對外一個"門面"（Facade門面設計模式）。BizVoiceMediaCenter裡面會有且僅有一個VoiceMediaAlbum執行個體（播放專輯，提供“上一曲”，“下一曲”，順序播放，續播等能力）。
三、架構設計和開發
首先，我們先簡單看下跨平台底層播放器的生命周期，如下圖所示：
熟悉Native開發的同學應該知道，跨平台底層播放器的架構和生命周期，和Android本身系統播放器非常相似，差異點是音頻焦點被搶占和恢複的回調部分，iOS裝置是onInterrupted，當音頻被其他應用打斷開始時回調，如電話鈴聲響起觸發此回調（在此回調中儲存播放器狀态，以便在onInterruptedEnd回調中恢複播放）。onInterruptedEnd，當音頻被其他應用打斷結束時回調，如挂斷後觸發此回調。而Android是onFocusChanged，當音頻焦點變化後回調。當然還有其它一些細微差别，比如雙端，播放錯誤碼不一緻，播放異常逾時邏輯不一緻等。但這些都可以通過在業務層建構自己VoiceMediaPlayer來拉齊以及處理通用音頻焦點搶占和丢失場景的邏輯。
通過上面分析，我們可以大體搭出如下圖業務播放器的整體架構圖(圖中箭頭表示資料流的方向)。
我們可以很容易的看出，業務對跨平台底層播放器Audio進行了二次封裝為VoiceMediaPlayer，拉齊和處理通用業務場景（比如搶焦點，播放，現場恢複，播放異常，藍牙或耳機實體按鍵響應等）。
VoiceMediaPlayer再上層是VoiceMediaAlbum（播放專輯），VoiceMediaAlbum專輯類，主要是處理順序播放，上一曲，下一曲，整個專輯播放事件（單曲播放資訊和進度，整體播放進度透出，自動切換順序，循環或業務指定下一曲播放等），VoiceMediaAlbum和業務層的BizVoiceMediaCenter打交道，當然BizVoiceMediaCenter也可以直接和VoiceMediaPlayer打交道，但我們一般不建議這麼做，即便是就播放一首音頻，我們也希望，把這首音頻當成一個專輯來包裝和調用（随身聽業務也确實是這麼做的)，這樣更加規範和友善以後擴充。
最後，我們來看看整體架構的詳細類設計圖，如下圖所示：
四、落地産出
高德智慧景區随身聽播放器架構完成後，很好的支撐了随身聽後續版本的開發。此外，後續因業務需求對産品做了多次疊代和變更，但播放器的架構幾乎不需要做很大調整和更新（即使後面又增加了離線播放能力），很好驗證了其穩定性和可擴充能力。下面一系列圖，我們可以看出這顆“種子”(景區随身聽播放器架構)，開出的美麗的“花”，如下圖所示：
以上各個頁面底層都共用了這個播放器架構，很友善的實作了音頻的跨頁面播放和管理，以及異常中斷的統一處理。高效滿足了相關音頻業務的播放能力要求，也為高德智慧景區随身聽業務後續疊代開發打下了堅實的地基。
溫馨提示：
由高德地圖發起，阿裡雲天池平台作為支撐平台的AMAP-TECH算法大賽初賽已經開啟，賽題為基于車載視訊圖像的動态路況分析，權威評委、豐厚獎金、終面通道、榮譽證書，歡迎大家參與，一起用技術幫助更多人美好出行!
初賽（7月8日-8月31日，UTC+8）。賽題詳情及參賽連結：
https://tianchi.aliyun.com/competition/entrance/531809/introduction