一、GME简介

1、 为什么会有GME

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

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

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

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

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

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

2、音视频系统介绍

下图是标准的实时音视频的系统示意图，以及各部分所要需求的一些技术。

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

3、Native前移到H5

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

4、传统WebRTC架构

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

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

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

5、H5服务交互部署

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

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

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

6、接入流程设计

详细展开下，过程我们设想了，那我们怎么约定流程，大概分成这几步

1）开发者协助实现

鉴权Buffer生成、调用SDK接口进房、调用GME API

2）接入层

校验开发者传入参数合法、接入加速。

3）分配合理代理机给开发者

就近分配、负载均衡等逻辑。客户端APP就可以跟代理机进行双向交互了。

4）数据层

实现透传流控信令层命令、转码、录制、安全扫描等业务操作。

7、语音系统核心模块

做一个比较好的语音框架或者平台都一定要十分着重的考虑四个方面：采集播放、前处理、编解码、流控及抗性。

这四个方面先说在内部怎么实现，举个例子，像播放采集、前处理，在移动端可以使用电话类型，系统就可以很好帮我们处理了一些噪音，专业消除噪音能力，系统处理非常好。如果非电话类型，媒体类型的时候，我们有自己比较成熟、运行比较好的一些筛音效果，可以在移动端native断实现比较好，但是在H5端，限于计算力以及采集能力都不一样，平台限制、浏览器限制，很难把它集成，因为这些限制我们在web端很难把它做到浏览器上。

所以抛出了一个问题，我们怎么能在浏览器的框架下把功能实现，因为这确实很影响用户体验。包括编解码、流控及抗性，怎么在外部实现，我们后来决定把这些过程移到代理服务器上，让服务器帮我们做这件事情，就可以极大减轻客户端的压力，就是浏览器的压力，服务器在我们这计算能力大，至少比浏览器会大，计算力会提升，同时有一些代码效果也在我们这调试会更方便一点。

8、全台后下发调控

以网络这一块举例，基本流程如图所示，流控服不断下发信令给代理机，就会完成对应策略修改，会反馈给H5。它是依据什么流控下发呢，是一个两秒上报，通过两秒上报给把这个给到了流控，然后流控把策略下发下来，大概就是这么个过程。

9、流控总览

更复杂一点展开说，因为刚才说的大概就是一组策略，因为有时候开发者接入的不一样，可能应用的关注点不一样，所以需要的策略是不一样的，很难通过一个策略就完成所有的常见的配置定义，所以我们做了一套配置系统和特定细分的场景，可以完成一系列的配置，就像把刚才的配置完成了好多套。根据不同场景，达到对方不同的下发配置，这样就实现了让系统更聪明一点，更智能一点，也不用特别多的后续人工干预，让系统系统运行得更稳定。

我们同时也把前处理挪到了服务器上，这里的优化也是比较有意义的。例如静音检测VAD就把非人声说话的部分去掉了，很好得屏蔽掉非需要信息的获取，就像背景音、其他人说话，这样得到更多都是有效的信息。

二、演示&QA

Q：好多人问怎么去选一个好一点的服务。

A：我的个人看法是，如果是APP想引入某个能力，你作为一个评估者，首先需要知道一些领域知识，至少要知道流控、核心码率这些基本的概念、指标对于你的APP具体的一些行为影响。每个服务都有一些固定的优点和缺点，怎么去查找指标，然后和你的用户场景匹配上，最好的一个匹配度。知道这些矛盾点，得到匹配度就比较好选择了选择适合自己用户场景。举个例子，假设你的用户网络不是很好，你的用户整体网络都不是很好，那你就需要选择一个抗性指标、抗就暴率比较好的服务。一句话就是找到APP就关注点，找到可以影响关注点的指标，再选。在这基础之上，你还可以关注一下服务的一些周边设施，例如他的文档的可读性和易用性、接口的明确性，对评估接入的工作量是很好的一个借鉴作用。后面运营的时候，可能要考虑一下它的稳定性，像它的成功案例，像我们就是通过QQ以前积累，对机型有比较长时间运营，这些对系统的稳定性的保障，综合考虑一下。还要考虑一下是否还有其他工具支撑协助运营，大概这样考虑接入服务能力。

Q：是否要选择H5？

A：我的意见是经过做H5，我们认为还是比较不错的，但是它有一些问题，但是也有很多优点。优点就是脚本开发都是JS开发的，开发比较快，浏览器天然支持的，开发周期短。它有一些短板，在像ios系统、一些系统HTTP组件、外部组件支持不是很友好，安卓、某些小厂商的兼容性可能也是有问题的。所以这也是需要综合考虑一下，我的建议是，如果纯外部浏览器的应用，而且浏览器的版本基本固定的，这样用H5是一点问题都没有了，但我也遇到过一些APP开发，本来是用JS开发的，就是为了开发方便、接入方便，这样的话用我们H5，我是不大推荐的。

现在给大家演示一下怎么使用我们GME的H5能力。欢迎观看视频学习。