高德智慧景區隨身聽播放器框架設計與實現

一、背景

“遠看山有色，近聽水‘ 有’ 聲”，景區語音導覽是智慧景區重點業務之一，以用地圖可以邊走邊聽景區各景點的語音介紹為主要訴求，實現高德智慧景區地圖不僅可以看，還可以聽，從而使用戶交互體驗得到跨越式提高。

我們想要讓“技術有溫度”，讓講解更加有感情和內涵，最好可以通過講解構造一個“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