一、背景
“遠看山有色，近聽水‘有’聲”，景區語音導覽是智慧景區重點業務之一，以用地圖可以邊走邊聽景區各景點的語音介紹為主要訴求，實現高德智慧景區地圖不僅可以看，還可以聽，從而使使用者互動體驗得到跨越式提高。
我們想要讓“技術有溫度”，讓講解更加有感情和內涵，最好可以通過講解構造一個“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
