共计 3206 个字符，预计需要花费 9 分钟才能阅读完成。
一、背景
“远看山有色，近听水‘有 ’ 声”，景区语音导览是智慧景区重点业务之一，以用地图能够边走边听景区各景点的语音介绍为次要诉求，实现高德智慧景区地图不仅能够看，还能够听，从而使用户交互体验失去跨越式进步。
咱们想要让“技术有温度”，让解说更加有感情和外延，最好能够通过解说结构一个“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/co…
