高德智慧景區隨身聽播放器框架設計與實現
一、背景
「遠看山有色，近聽水『有』聲」，景區語音導覽是智慧景區重點業務之一，以用地圖可以邊走邊聽景區各景點的語音介紹為主要訴求，實現高德智慧景區地圖不僅可以看，還可以聽，從而使用戶交互體驗得到跨越式提高。
我們想要讓「技術有溫度」，讓講解更加有感情和內涵，最好可以通過講解構造一個「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容器（和Android裡面的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）。賽題詳情及參賽鏈接：
//tianchi.aliyun.com/competition/entrance/531809/introduction
