<强>一、背景
"远看山有色,近听水的 <强>有” <>强声强”,景区语音导览是智慧景区重点业务之一,以用地图可以边走边听景区各景点的语音介绍为主要诉求,实现高德智慧景区地图不仅可以看,还可以听,从而使用户交互体验得到跨越式提高。
我们想要让“技术有温度”,让讲解更加有感情和内涵,最好可以通过讲解构造一个“UGC景区讲解生态圈”,并且还能帮助讲解创作者有一定的收益,以达到“生态圈的正向循环”,让线上导游”天下没有难做的生意”。
试想一下,当游客走进故宫,这时,高德地图的语音包可以播放:“故宫有180多万件宝贝,青铜馆,陶瓷馆……”这段话的讲解人,是著名收藏家,古董鉴赏家马未都,是不是更加吸引你关注?另外,当你漫步到延禧宫,语音包则会立刻讲一讲延禧宫与大热的电视剧《延禧攻略》有什么关系,并且有背景音插入,是多么生动形象。
所以,我们开发选型并没有采用传统的TTS技术(由文本内容生成机器语音),而是采用了更加通用音频格式(比如mp3),作为讲解的音频输入源,方便讲解者进行二次创作。本文将简单回顾高德智慧景区随身听播放器的框架设计与实现。
<强>二、架构设计前思考
"夫未战而庙算胜者,得算多也;未战而庙算不胜者,得算少也”,拉开战斗序幕之前我们应该尽量去“庙算”,提前预防和判断并保证技术风险可控,俗称“防火”。“防火”更能看出本事,而“救”火只是能力。开发应尽量做到“不打无准备之仗”。
首先, <>强如何提升开发和后续迭代效率? 此问题涉及到是纯本地开发还是用跨平台混合技术开发。如果用纯本地,双端开发人力可能会使工作量翻倍,后期可维护性也差,经常需要双端同步拉齐。但纯本地开发声音相关的技术方案成熟且风险较小。而用跨平台混合技术开发,优点和缺点正好与单纯本地开发相反,经过小组多次技术讨论,看长远利益,最终确定用跨平台技术方案,用该方案虽然技术挑战和风险大(比如需要和跨平台架构支撑团队一起“无中生有”的去打通JS的播放链路和各种音频中断能力回调等),但这个方案有个强有力的好处,就是可以“写alt="高德智慧景区随身听播放器框架设计与实现">
随身听很多业务是有跨页播放要求的,如果将播放能力直接提供出来,由各个页面的页面自己维护,势必会生出很多的音频,混乱而且页面相互通信交换信息成本高。后经过讨论,就有了如下图的架构方式设计:
结合跨平台底层播放器的特性,虚拟出来一个BizService放在跨平台框架的服务容器(和安卓里面服务的概念差不多,提供一个无界面的可以处理公共业务的容器)里面,处理页面页面业务管理和信息交换以及缓存管理,BizService只和BizVoiceMediaCenter交互管理音频数据,也就是说BizVoiceMediaCenter是通用播放器框架对外一个“门面“(正面门面设计模式).BizVoiceMediaCenter里面会有且仅有一个VoiceMediaAlbum实例(播放专辑,提供“上一曲”,“下一曲”,顺序播放,续播等能力)。
<强>三、架构设计和开发
首先,我们先简单看下跨平台底层播放器的生命周期,如下图所示:
熟悉本机开发的同学应该知道,跨平台底层播放器的架构和生命周期,和Android本身系统播放器非常相似,差异点是音频焦点被抢占和恢复的回调部分,iOS设备是onInterrupted,当音频被其他应用打断开始时回调,如电话铃声响起触发此回调(在此回调中保存播放器状态,以便在onInterruptedEnd回调中恢复播放).onInterruptedEnd,当音频被其他应用打断结束时回调,如挂断后触发此回调,而Android是onFocusChanged,当音频焦点变化后回调。当然还有其它一些细微差别,比如双端,播放错误码不一致,播放异常超时逻辑不一致等。但这些都可以通过在业务层构建自己VoiceMediaPlayer来拉齐以及处理通用音频焦点抢占和丢失场景的逻辑。
通过上面分析,我们可以大体搭出如下图业务播放器的整体框架图(图中箭头表示数据流的方向)。
,
