王者荣耀成功的背后，看腾讯是如何针对自家产品做底层支持的
腾讯作为游戏界的巨头，旗下游戏项目众多，涉及品类也十分广泛，在腾讯游戏取得的瞩目成绩之下，离不雄厚的开底层技术积累所提供的支持。在腾讯体系下，已经可以实现依靠一套通用的底层技术实现多品类游戏开发，并解决多品类游戏研发和运营中出现的各种问题。
技术人员作为腾讯这个巨擘的幕后英雄鲜少走到台前被人们所熟知，但在今年ChinaJoy期间的中国游戏开发者大会上，来自腾讯的资深技术人员吴嘉伟为大家分享了腾讯底层技术这么多年来积累下来的经验。
龙虎豹将他的演讲内容进行了整理，由于并非专业技术人员，在听写过程中可能会出现错误，欢迎读者朋友指正。
以下为吴嘉伟的分享。
我今天分享的题目是“谈腾讯精品游戏的基础技术体系”，有一个问题是,到底什么是基础技术？基础技术这里我做一个简单的定义，我认为它说的是围绕游戏新玩法这样一些底层技术的集合。那么，底层技术它也分了很多，怎么去做一个分类呢？我这里大概就简单分了有六个，第一类大概就是引擎技术，引擎技术其实也有很多这种细分的品类，比如像2D的引擎，它可能更强调打击感，像3D引擎可能它更强调是用户上手的程度，像Hero引擎就更加强调游戏画面的写实性。下一个比较重要的技术，就是整个游戏的基础框架，基础框架实际上它是决定着游戏在上线之后的过程中，整体运行的一个效果，那么同时它也是决定游戏在研发初期，去快速完成代换的这样一个可行性。 第三个，就是网络通讯部门，其实一直都是网络游戏开发以来比较基础的模块，但是现在谈的更多是在弱网的条件下，技术模块的效果，以及在全球发行化的过程中，整个的网络通讯的方案。
音视频技术，其实很早以来都是整个游戏里面比较基础的模块。好像它和一个游戏整体的玩法没有太大的联系，随着现在游戏整体品类不断的发展，其实我们看到现在有越来越多的项目，像狼人杀、MOBA、FPS游戏里面的这种组队开黑的玩法，其实也逐渐碰到这样一些核心的玩法。关于测试这方面，其实它主要是保证整体测试，保证游戏在整体发布之后的整体质量。游戏安全这一部分其实很简单，主要是保证整个游戏的一个公平性，以及个人财产的安全性。我今天主要是围绕技术框架，网络通讯以及音视频相关的给大家做一个简单的分享。
我们来看一下腾讯基础的底层框架，实际上它经过了十多年的发展，从最开始端游的时候发展而来，不管是从网络介入，还是从数据存储，从数据的描述和表达到底层的小型中间件；从与游戏逻辑相关的一些特性，包括到整体的逐渐的管理，运营用户的与数据相关的附件，都有相应的一些设计。在整体的组件里面有几个比较关键的技术，第一个是Debussy技术，它其实主要是负责基层间通讯或者是跨界通讯的这样一个技术。另外一个，是一个叫做T/R的组件，这个组件主要是负责数据的序列化以及转序列化相关的这样一些工作。同时它还有各种数据表达的这样一些能力，比如说像内存、文件或者是excel等等，只要有基于TGR数据的描述，都可以相互地转告或者是打通。另外一个，实际上重要的是Torm组件，其实是一个数据关系对象的组件，它能够将mqsql表的管理缩减为整个对象管理。
在端游时代，实际上分区分服这种架构设计，整体对数据库的压力其实不是太大，随着手游玩法的变更，全区全服这种结构似乎越来越盛行，那么我们也发现到，qver存储效似乎护会更高一点。在此基础上，我们开发一个叫做techbus的组件，这个组件主要是能够在海量的用户中，从一个比较好的性能，成本之间达到一个比较好的效果。其实随着整个底层框架时间的发展，我们其实发现整个组件规模越来越大，参数也越来越多，编程也越来越复杂，整体升级以后的难度也越来越高。在此基础上，我们将这些离散的组件把它集合起来，然后统一优化，形成优化的这样一个服务，这个也大大加速了整体游戏接入的一个效果。刚刚讲的大概是基础组件以及整个在服务化引进的相关的一些事情，实际上后台的这样一些框架组件，其实他们扮演的是幕后英雄这样一个角色，很难被前端用户或者大部分玩家感知到。而我们能感受到的，包括比如说像游戏下载速度是不是够快，或者是不是很好地能够去体验到副本的一些玩法。那么我在整个接入的过程中，是会出现这种卡顿的这样一些情况，包括说我在与人副本会在沟通的过程中，或者说在开黑的过程中，整体语音的这种交互是否是足够地清晰，实际上这些是能够被用户所感知到的。
接下来，我将从技术基础它如何去改善用户体验的这样一些角度去做一些简单的分享。我们首先看一下整体的一个游戏中心；第二我会介绍网络相关这样一些模型，包括像对战，像MMO这些接入的问题；第三个主要是会介绍一下整体的语音在游戏中应用的这样一些情况，第四个就是讲一下我们整个游戏一个对外服务或者对外推广的情况。
我们首先看一下游戏更新这一块主要挑战大概是什么。其实这里它们会存在两个矛盾。第一个矛盾，就是说游戏安装越大，然后推广成本越高，简单来讲，一个100兆的包想把它推广下去，或者一个150兆的包想推广下去，其实这整个成本是不太一样的。第二个就是说对于整体的分发类的用户问题，其实在整个一个分布的环节下都会存在这样一个问题，那就是劫持问题。这些问题到了最关键的因素，就是整个游戏业务在推广或者说在活跃回复的情况下，可能是说没有达到你的预期，因此整个的一个下载更新或者整个推广的一个方案，需要在整体的唯独去考虑一些事情，怎么去解决这样一些问题。
腾讯的游戏更新的方案，实际上它是一个以底层为基础，然后在上面逐渐去扩展的方案。首先，本身必须有这样一个海量的支撑，有tv级别带宽输出的这样一个稳定，在全国的范围内，都有相应的机房的分布，实际上也就是能够让用户就近访问，能够起到这样一个效应，同时也能应对突发的带宽的一些情况。这个是在最底层的这样一个硬件支撑层面，在整个引擎层面，它本身具备TYP的下载能力，同时它也具备一些抗劫持的能力。它本身交验这样一些方式，所以能够经常地去发现环境或者发现被劫持的这样一个情况，整个分析策略上，实际上可以分为差异分析、简单分析，同时也可以在多个电子市场，也会存在多渠道发布的这样一些问题。那在整个更新的方案上，可以简单地把它划分为程序的资源更新以及热更新和动态下载这样的情况。
我们首先来看一下程序资源的申请战略情况，其实相对于整体的安卓或者是iOS这块的升级来说，其实相对于端游——端游本身它是一个比较开放式的环境，其实不太需要去区分程序升级或者是资源升级。但是由于iOS或者是安卓的特性，它们本身是有一些沙箱的切换。所以，每次更新的时候，相当于可能你只需要更新很少的一些资源，但实际上缺乏完整的包，实际上这两种更新的方式效益不是太高。那么，为了解决这样一些问题，我们实际上采取的是仿效在PC上的这种模式，把2进制的程序的升级或者是说把资源的升级拆分得更细，这样通过这种更细的拆分来达到整体一个提高效率的目标。那么举个简单的例子，比如说是两个ATK之间的两个之间的差异更新，可能整体算下来，它们的差异大小可能只能减少10%左右的样子，如果我们现在采用了纯粹的程序，以及资源分离的这种方式，那么整体减少大小可以到15%或者到20%的样子。这个是程序和资源更新的矛盾的问题。
另外一个是，对于通用的多版本发布的问题，实际上在端游的时候，我一直是采用逐版本发布的这种方式，那么这种方式的特点就是一个用户如果他一周不去访问这个游戏，那么他可以下载大量的这样一些资源，在手游的时代，实际上大家更看重流量，是怎么样能够更好地帮助用户去节省资源？那么我们采用的方法是将唯一的资源，将更新的资源，将它放置在服务器上，通过客户端动态服务器去计算商业对比的这种方式，来投到每个用户不同需要下载的这样一个最小的集合。那么，通过这种方式，实际上你会发现不管你是在玩《王者荣耀》也好，还是在玩其他游戏也好，不管你多长时间都没有去更新，都只需要更新一次。另外一个问题是如何去防止劫持。实际上这种方式其实也是一些比较常规的，或者说大家在业界比较通用的一些做法。简单来说，就是一个 URL。然后， https，也会有一些资源或者在类似的时间上的这种方式去绕过时间劫持的情况。但同时，也需要去做好相应监控的工作，因为在一些大规模发布或者在更新的过程中，经常会发现某一个省或者市出现大面积劫持的情况。那么我们整体系统要好好地去反馈出这一点，公司也有相应的这样一个机制帮我们去做一下，这个事情现在大概就介绍到这里。
我们看下一部分，从整各游戏资源质量保证的方式来看，实际上会经过很多轮外网恢复测试。可能第一轮10万用户通过这样一些规模，第二个就是其他的一些用户。但是最终发现了一个问题是什么？就是不管你去经过多少外网用户测试的情况，最终你都会发现整个程序一定会存在大量问题。为了去解决这样一些问题，实际上整个热更新的环节，在整各游戏里面是比较刚需的问题。热更新从方案上来看，其实可以分为安卓的方案，因为本身安卓它是可以去加载SO的，简单来说由于一个函数问题，函数地址的这种替换跳转的这种方式，再去加载一个新的SO，这个新的SO肯定是对以前的SO有个小的规模，这种方式实际上就是一个比较传统的APP的更新的方式。另外一种方式，就是说是在iOS里面，iOS它本身因为cocos在游戏里面应用不并不多，在整个游戏实际上还是unity引擎会更多一点。在这种情况下，实际上是需要一个游戏的APP去起承一些类似于解释器的环境，再通过脚本运行的方式来打造替换。
业界一般的做法，是插入了Lua，我们是采用XLua的方式， XLua它本身具有三个特点：第一个特点，是说XLua它的系统会非常高，主要是通过数据在序列化和反序列化 的过程当中，将C# 把它下载到native。那么这样的话，就可以做到这个项目完全没有这些，因为这个也是与其他的XLua。第二个，整体来说， XLua现在来说还是非常方便的。它主要是通过空间层代码的这种方式，它可以将一个C#类对象这样一些简单数据类型标记出来，在Lua之间形成这种无缝穿插，这样的话其实也就方便了一些开发者和用户针对这种数据类型一个一个去展开。第三个是关于hotfix热更新的操作，其实它是可以自动地去申请埋点的代码，可以做到在危急时刻，能够对整体的这种方法，操作类服务，属性事件或者是函数能够无缝做到从私下切换成Xlua的实现。
另外一个，是关于动态下载。其实现在大家在用因特网之后，其实也可能会感觉到，如果你是一个500兆的安卓包或者是100兆的安卓包你的承接重要成本是不太一样的，我们一直在这块做了相应的装接工具。简单来说是一个动态下载的方式，对于业务这一层来说，需要做的事情就是说需要提供一个资源分析的这种过程，能够把必要资源和非必要资源给分离出来，再通过我们的工具可以做成一个相对比较经典的包。对于玩家这一部分来说，主要一个问题是，玩家在使用游戏体验的安装包的情况下，通过怎么样的策略和方式，能够去达到比较无损的体验。
在这里其实我们的动态下载系统大概做了两件事情，第一件事情就是通过按需下载这种方式，对有些资源去做一些区别管理，那么这个管理实际上是对必要资源和非必要能够做一个统一的管理，不仅是从升级的这个流程上，还是说从读取的这种方式上，都能够做到在逻辑审批上一致。这样的话，使用起来才会非常得方便。第二部分是安全下载的一个过程，我们实现了一个比较好的优先级的通道机制。简单来说，比如在一张地图里面，在我视野范围内的这样一些NPC也好，或者是说玩家也好，它是一个二位进制 的是也去做一个，而在我们视野之外的这样一些物部件，是以自卫的这种方式。那么可能在一些特殊的场景地图里面，也会采用一些预判或者AI的方式，能够提前知道用户它可能会要发生什么剧情，那么通过这种方式的话，我们可以尽量让有损的体验变得无损。
我们先看一下网络接入的情况，首先看一下整体的一个大盘还是这样一个数据。实际上，我们可以从上面这张图可以看到，目前的话大概是占65%的情况，实际的这样一种用户，看完以后马上也要进入到5G时代，但是从我们整个海量的数据分析来对比，我们对比2013年的时候手游最开始的一个情况，以及2017年这样一个情况，我们可以发现随着基础设施的建设，整体的物理面度的质量相对于手游初期的时候越来越好，但是因为wifi这样一种上网其实本身它会导致网络闪断，切换以及流动这样一些问题，可能会影响用户体验。有了这样一些基础的数据，其实我们可以对于游戏业务来说，他们需要关注的是在现有的网络质量一个情况下，游戏的玩法怎么样能够做到比较好的匹配。首先，看一下对于基本通用的这种方式，那么这种方式其实也是目前大部分手游应用到，或者端游页游应用，这种方式主要是想去解决两个问题。
第一个问题，是本身腾讯的账户体系它非常多，既有手游基于ONI的方式，那么同时也有基于端游的方式。在页游的时候，可能还会存在一些三方打通的方式，比如说我想是基于微信的方式，实际上都是以云端为核心的账号体系。如果这么多的接入方式把它放在整个的电路设备来看，实际上这个跟game sever就会非常得多，那它整个逻辑就显得不够纯粹。因此在整体的game sever之前，我们加入了一个叫做中间件这样一个组件。这个组件程主要一个功能就是说我可以再建立一个TCP或者UVP基础之上，能够建立一个抽象安全的通道，同时能够把平台的健全或者是说账号体系能够把它给分离出来，那么对最终的gamesolo来说，它需要做的一件事情就是知道我进去过，还是没有通过。那么我们到底是在哪个平台去做的健全，最终的一个账号体系是什么样子的。那么，为了屏蔽这种账号体系的差异性，我们甚至做了一些账号缩小的事情，这样对业务现在看起来，整个的账号能够形成一个统一的完整的系统。
这个是在前端我们去做的这样一些工作，那么在后端，我们是将与游戏玩法之外这种可以相互提炼的这样一些逻辑，我们是把它给集中起来，就是像这些排行或者支付这样一些游戏的逻辑关系的这样一些服务集中起来。其中的这种模块化的方式提供给game server，其实也是它整个的一个开发的效果。这种方式是比较常规的一种，因为对于刚刚看到那种统一进入的方式，实际上它是一个单点切入的模型。单点切入的模型其实比较适合于早期的手游或者端游。简单来讲，就是客户端去计算一个分数，计算完分数之后，再把它上报到服务器，服务器最终再对接到数据库里面。实际上这种方式的话，存在一些管理上面一些弊端，如果是去承载MMO或者RPG这样一些玩法，我们会经常发现一些跳线的问题。所谓跳线就是说，我从一个地图跳到另外一个地图，或者从技术上来讲，就是说我从一个服务器断开然后我要去连接到另外一个服务器。那么，在端游的时候，这种体验在物网这种环境下，其实相对来说会显得比较平滑，到手游的时候，实际上这种方式我们越来越觉得它会觉得这种给用户带来体验会非常得差，特别是说在一个地图结合的部分，如果反复地这种切，实际上效果会非常不好。那么，另外一个问题就是对于整体后台系统，其实有比较大的挑战，因为你会不断地去跟登录然后再去数据库拉取相应的信息，然后会导致逻辑问题。我们提出了一种新的通讯的方式，它是一个叫做网上的通讯，这种通讯方式它有一个特点，就是你从任何一个切入点去切入，实际上你都可以将消息投接其他的逻辑结点上去。那么这种方式在整个MMO或者RPG模型里面，能够比较好地去解决就是用户跳线的问题。
然后第三个，是最近比较火的关于PVP对战这样一个模型。实际上，对于PVP对战来说会有两种方式，第一种就是C/S模型，C/S模型它简单来说就是客户端里服务器去做免测，最终是以服务器计算的这样一个效果为主。但是C/S这种方式，它有一个比较好的特点，就是客户端可以去表现。因为你最终以服务器的机构为准的话，我们服务器告诉我需要怎么去做就好。实际上，我们可以看到，这种方式它对于网络要求的其实没有那么得敏感，因为对于C/S模型来说，他们有很多的这种差帧或者表现的这样一些操作方。其实我们可以看到LOL就是一个简单的C/S模型，那么在150-200毫秒这种情况之下，我们可以看到它这里的表现还是相当的平稳。
另外一种PVP的模型，是帧同步模型，这种模型它起源于早期的类似于《星际争霸》这种游戏，因为一些条件上的限制，导致了它必须采用很少的数据捕获方式来达到自己这种比较大规模的数据同步。帧同步的模型来说，实际上我觉得它比较适合早期的这种原型的开发。简单来说，就是客户端将一些简单的工作序列把它发给服务器，让服务器去做组成或打包相应的工作，然后再去做一个广播。因此对服务器来讲，它的整体的承载相对来说会比较高，它的并发性也会比较高，但是不好的地方是，它将的逻辑都集中在客户端，那么在这里对于客户端来讲，会有两点非常关键，第一点就是本身客户端的性能，如果很难去达到性能要求的话，其实这种方式就很难适用在这个游戏里面，举个简单例子，比如说我们在《星际》里面可以看到16位数的快放的这样一些情况。假如说在整体的某一个游戏里面，如果是不能够再渲染或者在其他的逻辑跟上这样的目的，其实就很难适应这个模型。另外一点，帧同步这种模式实际上它对整体网络的抖动影响是非常得敏感，因为它所有的表现，包括计算都集中在客户端。这样来说，实际上我们可以看到整体上帧同步实际上它是一个能够简单去开发，但是你想把它做好却很难。
我们接下来讲针对这两个模型的网络优化的问题，实际上不管是这个模型还是状态同步 模型也好，实际上他们都很难再用以前TCP的方式来做基础的传输模式，tcp本身其实因为它是具备这种超时规避这样一些机制，它不再适合作为弱网这种网络环境下的通讯方式，本身APP它又是一种不可靠的这种实验方式，游戏的业务特性又要求某些消息确实是更优的，因此在这个基础上面，需要在UDP的这种方式上，去实现这种可靠的通讯方式。简单来说，这种可靠的通讯方式，无非是两个，一般都会采用消息重传来实现其可靠性，采用消息重传的时候有两种方式，一种是发送者发起，另一种是接收者发起。对于发送者发起的方式的这种传输，实际上有一个比较关键的点，就是基于一个RTT的平台测量，在这个测量基础之上，你能够去做到快速的传导，RTT的这个实际上它只是一个测量，它其实是很难预测到下一秒到底会发生什么样的问题。我们之前做过很多的这样一些测试，比如说在PC的端游上，我们发现做出来的这种效果，会比TCP那种效果会好非常多，但是实际在wifi模拟的这种情况下，在外网运行的情况下，确实发现有时候效果是不是比TCP还要差，那怎么样去解决这样一些问题？最简单的办法就是看整体游戏的特性，实际上可以说是通过多位冗余，或者是通过动态冗余的方式。这样的话，通过流量去换延迟的这种做法，能够在一定程度上去改善这种网络拥塞的一些问题。
再看一下我们整个的一个解决方案，说一下为什么我们要去做这样一件事情。本身腾讯整个的游戏的成分它会非常非常多，如果都采用不同的解决办法，实际上在这里的效益，在整体的应用上都很难地去形成一个比较快速的demo模型这样一个过程。那么我们在整个构建统一方案的问题上，其实也是希望说我们能够将底层做得非常简单，非常可靠，那么在应用这一层其实是可以留给用户调优的空间。
那么，整各的这样一个统一方案，简单来看，大概它分成三层，最下面的是一个传输层，在传输层首先我们可以分为用户是一个UTP，在用户基础之上，它需要去实现一些可靠消息的类型，那么也需要去实现一些非可靠消息的类型。这里其实还有很多这样一些细分，比如说快速可靠的消息，或者非快速可靠的这种消息，实际说我们在整个UDP的业务管理基础之上，是做了非常多的这种测试和模拟这样一些工作，也参考了其他的这样一些像国外的一些游戏已经适用网络层的解决方案。实际上他们通常的一种做法，就是我需要对整个通道做一种分级的处理，这个就好比是说一条高速公路通道。你可以把它分为一个可以开到120的这种快车道，也可以分为可以开到100的慢车道，当然也有80的这种比较慢的车道，但同时又限制你必须开到60以上，那么你才能够在这条高速公路上比较正常地进行。就是说对整体的流量的或者说对通讯通道的管理方式是需要有比较好的策略，才能够保证你整体不会发生堵车，比如说你的整个的吞吐，还有包括你的延时都能够在一定的合理范围之内去得到控制。
这个传输层，它实际上是一个最底层的这种通讯方式模型的选择，那么在它的基础之上，是相应的逻辑层的功能，刚才我讲的健全的功能，要排队的功能，还有数据包合并、缓存这个问题，或者是加密、压缩，防止冲击这样一些功能，或者作为相应逻辑上的一些功能，他们在审核的方案里面，那么在整个的一个监控模型上又会分为单点的模型，以及网上的模型。它也是一个不同游戏模型的选择。那么对于业务来说，他们可以分为一个公共层的这种逻辑，比如健全排队，还有强压缩等等，那么也有分为它私有的一些逻辑，比如说它的移动包，它的攻击包，这些是可以看成一个可丢失的输入。对于说像买一个装备或者是说去换枪，最终的数据结算上报到系统，这个也是后来作为一个比较单面的数据，这个是整体的一个解决方案。
前两天大家还看到一个新闻，就是说我们现在到底是音频时代还是视频时代。实际上关于语音这一部分，我们正好是在2015这个点，正好是在行业里面视频还是在发展，然后大家相互去竞争的这种情况下，其实没有对语音的这个细分的市场去做一个比较全面的这样一个分析。然后，可能我们看到的这样一些机会，推出的一个叫GVoice的产品，它目前也是放在腾讯这样一个有游戏服务的团队。它的一个主要方式是想说全面提升整体游戏的交互的体验，从目前运行的这个情况来看，实际上从某些维度上，它的整体的一个话务量也是超过了某些运营商。它主要提供3个功能，第一个功能是一个实时语音功能，第二个是类似于组队语音，或者是类似于一个电话本沟通的这种方式，是一个语音电台的这种模式，实际上它就有点像说是一个喜马拉雅或者说像有主播在讲，然后大量听众在收听的方式，还有就是说是类似于基于微信消息的方式。
（图5）
那么作为一个内在SDK，它必须有几个比较重要的特性，首先这点它会非常的低功耗，因为你不可能去跟有些逻辑去抢内存，那么同时它作为是一个辅助的功能，不能占用太多资源，同时它需要很多平台的这种监管，包括多种引擎的适配，在接入上能够做到非常简单。接下来看一下语音这一块目前两个典型的使用场景，第一种场景就是类似于在《王者荣耀》里面，这种小的语音的模式。那么这种模式它的一个特点是从技术上来讲，它需要用户能够在较短的时间内，能够听得清其他用户的发言，但是它对整体一致的要求，其实不是要求那么严格。第二个模式，是类似于这种国战语音的方式，它的要求是，因为在这种模式下面，一般是一个主播开着比较劲爆的背景音乐，然后对大家的指挥或者种行为会有一定的煽动效果。所以，在这种情况下，需要对整体一致要控制得非常得好，然后用户要定得非常得清晰，但是在这种情况下，确实不再去考虑流量这样一个问题。
我们看一下语音的这样一个整体的流程，包括它整个处理结构的情况，我们简单地分为前处理和后处理，中间是通过网络来进行的。在前处理的过程中，首先第一个要做的就是降噪。第二个是做VAD，这里是一个比较关键的点，它会语音之外信息能够把它给过滤掉。为了达到节省带宽的目的，因为我们现在在这边开的策略相对都会比较得严格。那么VAD把整个声音给过滤之后的话，需要去做一个ATC争议这样一件事情，它实际上是说把整个的人声，能够相对来说提高到一个比较高的水平。第四块是LTC，它其实是一个啸叫音质的功能，因为在以前，其实我们更多的是考虑用户在使用过程中，他们不会坐在一起，我们最近发现其实很多的人，比如说在网吧，大家坐在一起。那么在这里的话，两个音源相近，就容易出现啸叫情况。所以，在这个地方也需要去做相应处理去优化近距离啸叫问题。最难的一个问题就是回声消除问题，实际上从整个业界来看，大家都在去想办法去解决这个问题。那么对于这里其实在总体的这样一个环境下面会存在一些挑战，比如说像在有背景的这种情况下，如果我们每个人都去说话，甚至某些背景里面，还有一些人的声音，那么在这种情况下，想把这样的声音消掉或者说听得非常舒服还是非常有挑战。
在整体的这样一个前处理过程中，我们会将整个语序进行编码，然后再把发送给服务器，在服务器这边目前这边是采用一个整理集群这种模式，那么它在接入上会有三个特点，第一个特点就是它是一个就近接入的方式，我们也收集了海量的 Jrpl，并且在QS上做相应的测试，它能够保证这个用户的接入点是一个最好的接入点。那么，另外一点，整个的这种网络它实际上是4G网络体系，通过内网去进行传输。因为在深圳，还有在其他地方都有相应的布点，可以打造整个语音传输的最优化的效果。我们再看第三个梳理逻辑，相对来说会比较简单，它主要是去处理整个数据包在网络都懂得情况下，可能会产生这种跳音或者变音的情况，那么现在的话，我们在整个服务器端其实也做的一些类似于混音的处理，其实也是想去减少整体用户的这么一个带宽或者占用的问题。我们看一下实时语音，刚才我们有简单地介绍，比如说在《王者》的时候，我们场景下面，其实我们更多的是去考虑一个平衡型的效果，比如说我们希望用户能够听得见用的好，然后像在国战的场景下，其实我们希望整体这样一个音质的效果会非常得优，我们看到带宽的这个一个情况。所以，整体来说它是一个多维度的这样一个需要去考虑的问题。简单来讲，第一个就是带宽，或者怎么样能尽量地去减少带宽延迟。第二块就是对于有些音效的影响，到底是是以语音的这块为主，还是背景音乐这块为主，还是以游戏音效为主，其实也是需要在不同语音场景里面去做权衡与选择。
第三个是关于监督系统。目前其实监督系统，我们是整个实际用户处理里面非常困难的一部分，相对来说iOS的体系这种系统还更加容易去调优，但是对于安卓的整个系统来说，其实是做了300机型的这样一个团队，它甚至有更多的这样一些机型，包括更多的这样一些安卓团队等等。
第四个，就是关于网络丢包的这种情况。对于网络丢包这种情况，目前其实也有类似于像FEC或者说强行编码这种情况，可能在这个场景里面，需要有其他的这种某一次会造成双方卡顿，尤其核心网的发生，有些数据这样一些情况。那对于整体的一个新闻化的这样设计，你需要对所有的算法去做相应的一些采集，来包括对整体的这种音频需要去做相应的这种优化，来保证整体的SDK系统的比较轻量化。最终一个请大家看到的是一个音质上的问题。目前来说其实好的办法就是说我提高编码，然后我提高我们的冗余，但是这是一个比较常规的做法。
我们看到一下在《王者荣耀》的语音里，我们主要是优化了一些思路和方式，第一个是怎么去做一个的过程，那传统的这种语音储备或者语音的方式它是每秒钟不间断地向服务器发送，但是在一些电话的场景下面，还会出现需要去制造一些环境音，或者是说一些制造一些数据音的方式，让用户觉得我没有掉线。在游戏的这种场景下面讲，其实不太适合。那我们的做法就是只要你说的话，我们才去发报，你不说话，我们是不去发报的。因此，延伸监测这个模块就显得非常非常得重要。那么，目前常规的做法就是说在延伸整个声音频段的范围，但是其实也还是有其他方式，比如说你可以采用一些类似于音阶的手段尽可能地来识别，到底哪些是人声，哪些是背景音。
第二个要解决的是啸叫问题，我们刚才也讲过，就是在某些场景下，大家可能坐在一起，说白了，就是去做一些移向移位的操作。或者是把整个的一个征信能够尽量地放低，相应的这种模型错开。
第三个，主要是合并消除，合并消除现在可以去优化的大概有两点，第一点是怎么样能够更好地去擦除回声，然后还有一个点就是对于播麦交替的距离探测，也会有一些好的效果，但目前还是在一个尝试的状态。对于我们丢包的这种情况，目前其实能做的事情也还是挺多的，就你刚才说的这种可靠的冗余这种方式。但是到底选择哪一种方式，是需要取决于在当前的这种网络环境下，能够支持你去辨别，不会对游戏整体造成过多的影响。
再看一下，我在这种优化的情况下，实际上刚才也提过，它其实更多的是说，它既有背景音又有MP3的这种音乐，然后又能听清楚人的声音。那在这种情况下，怎么做？简单来说，就是去提高均衡，通过提升人声的这种声音能量的方式，同时对整个的一个伴奏，去做高频处理，对音乐部分进行相应压制，通过这种方式去达到均衡，让整体的效果听起来，既能够听得清楚人讲话，同时也能够听得清楚MP3或者是说背景音乐给人的这种比较亢奋的效果。那在音质的这个提升上，其实主要是针对人声的饱和度，简单来说就是对你的音色或者对于一个平面变换的方位，让这个声音显得更加得好听。
那么现在前面也讲了挺多，我们在不同的场景下面，不仅是在网络应用的场景，还是说是在语音的这种场景，都会针对不同游戏去做相应的适配。其实做了这么多，也是想能够把它给开放出发，我们更好地能够服务到其他一些游戏上，所以我们又要有一个叫做，腾讯游戏服务的平台，它是基于在整个腾讯语音的基础之上，它游戏服务子板块的平台。
目前开放的服务，有语音存储下载，然后还有一些游戏相关导航问路的玩法，还有包括我们针对数据分析的这样一些特性的功能。有些语音计划，刚才简单介绍过，这里就不再重复了。然后，数据存储之前在提过一个叫做techbas的系统，这个系统实际上目前是大规模地运用于整体的数据存储。那么这个系统刚才讲了，它其实有一个最大的特点，就是它能够在海量的用户之间，能够在性能与成本之间找到一个比较好的平衡，那么同时它也可以比较好地去适应业务的这样一些特性，比如说第一个就是活动的特性，能在短时间内，不会有海量的并发，但是也能够保证在高并发条件下，整个的一QBS效率也好，还有包括QS的质量，还有包括我的查询的量，都能够达到比较好的标准。
第二点，是整体本身游戏的数据存储，它有个特点，就是它经常会存在一些荷负，或者是说一些扩容的问题。那么（英文）这个系统，它可以保证做到不管你是对数据的分类也好，还是对数据的合并也好，实际上可以做到在线无损的扩容。
游戏下载更新服务，这个之前也简单地讲过，我们把整体的服务，把它分装在一起，其实也是想去解决游戏在发行过程中，可能会遇到的这种局域化发行的问题，那么目前与腾讯在合作，在全球大概10到20多个国家都有相应的这种布点），那么依赖于当地本身的CDN建设，我们可以将整体的内容分发，可以扩充到全世界大概20多个地区。目前这个地区的数量其实还是在不断地增长当中，我们可以看到最近比较火的印度市场，还有包括像南美华西市场，实际上都有相应的布点。
我今天分享大概就到这里，谢谢大家收听！
