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

一、背景

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

我們想要讓“技術有溫度”，讓講解更加有感情和內涵，最好可以通過講解構造一個“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 打交道，但我們一般不建議這麼做，即便是就播放一首音頻，我們也希望，把這首音頻當成一個專輯來包裝和調用（隨身聽業務也確實是這麼做的)，這樣更加規範和方便以後擴展。

最後，我們來看看整體架構的詳細類設計圖，如下圖所示：

四、落地產出

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