GME语音服务基于浏览器解决方案

点击观看大咖分享

随着游戏市场的日益成熟, 基于H5实现的游戏需要不断提升自身用户粘性; 依托于网页形式分发的便捷, 致力于网页实现的轻应用异军突起, 市场对Web端的应用对于语音能力需求日益强烈. 此时如何在网页端实现一个稳定, 便捷, 扩展性良好的音频服务SDK, 以及有什么需要关注的点 ? GME研发工程师白兴师将为您详细介绍GME在这个过程中踩过的坑, 绕过的弯路。

为什么会有GME

GME是腾讯云的PaaS服务主要提供语音的解决方案，目标就是提供一个一站式的语音解决能力。假设您是一个APP或者一个游戏，想使用语音能力，那你就可以接入GME，不用再考虑语音这一部分的服务器问题、语音细节优化等一些问题都可以不用考虑了，这是我们提供能力的初衷。

用几行代码就可以接入高效稳定的语音能力，能把它继承到业务里。随着游戏开发者、国内软件业的逐渐成熟，明显感觉到一些比较好的深耕的游戏，开发得比较好的用户粘性强的APP，生存状态比较好，反之生存状态就比较差一些。

怎么提高用户粘性，大家都能想到社交，这占了很大的一个比例。我个人来看，社交一般分为两块，一部分是面对面的一个社交，就是传统意义上的社交，可以通过一些肢体语言、眼神、触感完成社交。

但是在软件APP上社交就有点不大一样了，是更偏向远程的一种社交，远程在历史上是通过书信给家里寄信件，后来是电话，然后是电视，包括现在的一些实时音视频能力，模拟面对面的社交，但是远程社交在游戏里还有一些不太一样的体验，游戏是一个强交互的APP，大家在玩游戏的过程中更多在游戏的交互上，语音只是交互的一个辅助，语音文字就是很好的一个释放接入点。

举个例子，介绍我们提供的一些能力，语音这一块主要提供了直播能力、录播能力，还有比较高级的伴奏能力。

直播能力是实时的交互，像开黑的时候；录播能力，大家可以录一小段音频分享出去；伴奏能力，在炫舞里有一个大厅让大家在这唱歌，就像最近在短视频平台上大家可以接歌。这可以达成陌生人之间的破冰或者是分享传播的点。

音频系统介绍

下图是标准的实时音视频的系统示意图，以及各部分所要需求的一些技术。发送端采集编码，然后把编好的码通过网络发出去，到达了接收端，然后接收端把这些码，解码出来，再通过扬声器一些其它的外部输出设备播放出来。这过程中，有一些技术，例如如何保证采集音源的质量，如何去除音频里的一些杂质信息，说话的背景音去掉，产出有效信息。怎么把有效的信息在有效的带宽下，另外网络也是不确定的一个因素，安全稳当地送到对方接收端。接收端要考虑如果出现丢包、包损坏，是否能够还原，把一个高质量的音频解压播放。

​

Native前移到H5

我们之前做的是Native，后面我们有集成了H5的能力，想能跟既有系统达成互通。显然要知道原始的系统是怎么运行的，原始的系统的SDK会先经过一个新令层，通过一些接入点优化，尽快进入到系统里，系统会分配一个数据的服务器给到客户端，客户端通过IP+端口号连接到数据服务器，实现一个比较大的冲突的交互，这里面就是刚才说的那些数据传输、网络抗性过程。

传统WebRTC结构

知道了这过程之后再看，如果想把H5集成进来的话，我们技术选型选了WebRTC，原始的WebRTC结构。

优点：浏览器自带，方便，不需要特殊实现

缺点：因为流量问题，无法建立过多链接；浏览器封装实现无法保证（P2P）效果打洞成功率低；断链如何处理，无法控制；不是产品化，没有监控。

H5服务交互部署

我们就想到了一个解决方案，在H5端加了一个权限代理，就是代理服务器，代理服务器分成两块，是先通过url找到所需要的代理是谁，然后分配中心会把代理服务器分配给我，我只要跟代理服务器交互。代理服务器会把我所需要的语音包传达，通过模拟webrtc用户，然后通过音视频转码逻辑，转到了原始的系统里，这样就实现了互通。

​

Native和H5不同，natie把数据层连接，连接完之后走到数据层，通过转码转到webrtc，然后回到我的代理服务器，代理服务器跟H5互通。反过来在H5想互动，也是这样实现的。

这样有个好处，代理服务器一定是server，这样打洞的成功率基本就没有什么问题了，因为都是外网公共的IP的服务器，公网服务器在打洞成功率是有保证的，另外这是我们自己的服务器，可以控制一些流量参数下发，保证用户在一些特定场景下得到比较好的用户体验。

问卷

_为了给广大开发者提供最实用、最热门前沿、最干货的视频教程，请让我们听到你的需要，感谢您的时间！点击填写_ 问卷

腾讯云大学是腾讯云旗下面向云生态用户的一站式学习成长平台。腾讯云大学大咖分享每周邀请内部技术大咖，为你提供免费、专业、行业最新技术动态分享。