在日前的Unite 2017开发者大会中，巨人网络资深客户端软件工程师李东旭分享了《球球大作战》客户端优化的经验。
在《球球大作战》上线之前，国内市场没有与之相似的休闲竞技产品，解决多人实时在线竞技的技术手段也需要重新摸索，而随着这款产品在版本和内容的迭代过程中，更多的新功能也要求它能够有更好的优化。
针对这些问题，李东旭进行了逐一的解答并分享了他们一步步摸索下来的经验。以下内容经游戏葡萄整理发布（附全部演讲PPT）：
大家好，我是李东旭，来自巨人网络，目前在球球项目组从事游戏性开发、功能开发还有系统优化工作。今天给大家带来的是《球球大作战》客户端优化经验分享。主要分两块，第一块讲的是关于版本迭代，第二块是关于我们遇到的问题，以及解决方案。
先来简单介绍一下这个游戏，《球球大作战》是全球首款实时对战的休闲手游，一经推出就受到苹果、安卓双端推荐，迅速风靡全球，取得众多佳绩，深受玩家喜爱。目前该游戏已在全球100多个国家同步上线，并在苹果App Store中国区游戏免费榜稳居Top10，DAU到达百万，超过1亿玩家已投入其中并热爱上这款游戏。
球球在2015年5月份立项，第一个版本两周后就上线了。这个版本主要是核心玩法，由两个人制作完成，一个前端一个服务器。因为游戏玩法比较新颖，所以我们无法预估玩家的情况，于是第一个版本的目标就尽快让它面对玩家，让玩家来评估这个新颖的玩法的接受程度。
没想到推出后，玩家反馈这个游戏非常好玩，非常新颖，以前在手游上没见过。之后我们就开始大力推进这个项目，可以看到，在我们后续迭代的过程中，基本都是每隔两周、三周就发布一个新版本，速度非常快。
其实昨天我们也发了一个新版本，基本这两年，每隔两到三周就发一个新版本。这跟普通的大型手游有很大区别，一般的大型手游，他们的开发耗时比较长，从立项到第一个版本见玩家，基本就已经过了大半年以上了。
这种情况下，如果团队有过大型游戏的经验还好一些，但是对那些没经验的团队来说，这带来的风险是非常高的。你不知道你做的这些东西，玩家喜不喜欢，很有可能就失败了，失败的概率也非常高。
这里给大家展示一下我们的版本迭代体系。我们先有一个需求，然后就进行开发，开发完成之后就立马进行测试，OK的话就直接发布了。周期就控制在两到三周，每个版本都按照这样来进行一个循环。
这样有一个好处，迭代非常快，能在做完一个核心玩法之后，马上发布出去来验证这个玩法到底好不好。这在游戏前期，效果非常好，但是到后期，你的项目越来越庞大，已经很难做到两到三周了。尤其是测试这一块，测试的工作量会越来越大，所以我们引入了一个测试服的体系。
测试服就是我们单独做一个测试版本，它比我们的现在版本功能要新许多，一些新的东西在里面给玩家测试。我们会保证一部分玩家能优先玩到新的功能，然后根据他们对新功能的反馈来继续完善，OK的话就发布。这就和MIUI的开发版跟稳定版挺像的，有了测试服之后，也不能做到完美，后面项目越来越复杂，两到三周就很难实现了。
为了更加完善我们的玩法，以及需求，我们加入了一个玩家反馈的体系，有了这个体系，我们在功能方面，能更正确地做一些选择。这里的玩家反馈的来源如下图，主要的就是通过QQ群、游戏内反馈，还有玩家见面会这三个大块来直接面对面跟玩家沟通，取得玩家的建议。尤其是每次版本发完之后，有可能会遇到一些问题或者bug，通过游戏内的反馈，能及时看到一些问题，然后通过热更新，就能立刻解决。
接下来我分享一下，在之前那些版本迭代过程中，我们遇到的一些问题，以及解决方案。主要有三个问题，第一个问题是同步，第二个是卡顿，第三个是我们年初的时候做了一个LBS的玩法，怎么把真实的地图显示在Unity里。
先看第一个，同步问题。
球球是一个实时对战的手游，在同步这块肯定免不了，我们也在一些同步的机制上、模式上，也做了一些选择，然后根据我们游戏的特性，选择合理的同步方案。
分析游戏的特性，能看到首先，球球这个游戏的规则主要是球跟球之间的计算关系，它们的关系规则简单，可以用公式来概括。用的最多就是一些物理的公式，这些比较简单，我们就很容易做出来。
其次，就是快速游戏，这个游戏中途可以随意加入退出，而且我们的进入游戏是没有载入时间的，点击按纽，就直接进去了。
最后一个就是实时观战，玩家可以观战其他玩家，在这种情况下，客户端是没有任何操作的，全靠服务器把数据发过来。
根据这些特性，我们也做了一些选择。
最终我们选择了状态同步机制。这个机制有一些好处，就是开发效率比较高，这个开发效率是相对而言的，对别的游戏状态同步可能比较麻烦，但是对我们游戏的这种机制，其实开发效率非常高的。
然后客户端的计算量大大降低，方便性能优化。客户端的一些球跟球之间的逻辑，是能用公式来概括的，而且球跟球之间的计算，因为球的数量很多，所以计算量非常大。所以这一点我们让客户端不需要计算，直接通过服务器计算，然后把结果发过来。同时因为是在服务器上计算，它的反外挂功能也比较简单。
断线重连方面，因为计算都在服务器，所有信息都在服务器，一旦断线，就可以立马连上去，恢复当前的状态。传输协议我们现在用的是TCP，TCP大部分情况下还好，主要是在延迟的情况下，TCP比UDP要差一点，之后我们会逐步将TCP替换成UDP，或者是让TCP和UDP共存。
我们看一下服务器逻辑，其实第一个版本我们服务器是不参与计算的，就是P2P的模式，客户端跟其他客户端相互连接，服务器只负责转发客户端之间的消息。这种情况下延迟非常高，因为手机跟手机之间，还有网络跟网络之间都是不一样的，大多数情况下你看到一个球，另一个玩家就没看到，然后他被吃了，他不知道怎么回事。
所以第二个版本，我们就把计算全部挪到服务器上。服务器会模拟一个流程，以50帧每秒的频率刷新，模拟一个真实的游戏内环境。发给客户端的话，按照10次每秒的频率，主要发一些球的坐标跟速度，还有吃与被吃，删球加球的逻辑。因为这种同步方式对流量要求比较大，所以为了优化传输流量，我们让客户端只发送对应视野里的数据。
客户端逻辑方面，话同步方式采用了影子追踪，只发送操作数据。服务器每秒十次发送到客户端的数据，会经过转化变成一个数据球，然后数据球是不参与渲染的，数据球会在Updete里面一直跑，如果网络延迟，这个球还在跑，就能保证客户端的球跟服务器对应的球是同步在运动，不会因为网络的停止而停止移动。
渲染球主要跟着这个数据球作为一个插入平滑，一直追着它跑。这样有一个好处就是，当网络波动的时候，数据球可能会抖动，但是渲染球一直在平滑，在玩家看来基本感觉不到。在网络延迟非常大的情况下，还是会因为卡顿和延迟，导致玩家的操作不太流畅，这块我们还在做深入的优化工作。
第二个问题就是卡顿问题。
卡顿问题，基本大家都遇到过，然后就是怎么优化的话，网上做优化的有很多的方案，这块就相同的优化点，我就不怎么详细说了。主要介绍一下我们这个球球在卡顿这块的一些，因为特殊原因造成的卡顿是怎么优化的。
如下图，球球主要卡顿点就在于，因为服务器是十次每秒刷新，因为是十次，不像客户端帧数比较高，所以你发一次的话，这个数据量里面球的数量其实非常大的，这就会导致发过来这一刻，要处理大量的数据，会造成卡顿。
还有就是美术方面的问题，因为我们球上面挂了很多组件，这些组件尤其光环和圣衣这个东西越做越炫，会引起卡顿，而且我们一局游戏，有50多个人，而且中途还会再加入新的玩家，如果在进这局游戏之前把所有东西都加载好，这个内存是肯定承受不了的。
而且我们的游戏是可以立即进入的，这就造成一个问题，我们必须要在玩的过程中来加载美术资源，这样也会引起卡顿。
