【面经】腾讯U3d面试面经 帧同步方向（总）

近期拿到了一个腾讯的offer，记录一下面试过程。

我找的内推，面试的流程如下：

上传内推简历，接着马上被HR转到项目组里面，一个小时左右面试官电话过来约面，接着电话面，然后去科兴面，最后HR面，OFFER到手。

总的来说腾讯的面试流程还是挺简洁的，听说有人面了很多很多面，我没有遇到这种情况，不过最后给offer时间间隔太久了，一周半才确认。

 

两轮技术面试都是在问帧同步相关的问题，所以就一起写了，也是对帧同步做一个总结吧。（PS：其实我简历很多其他方向也很希望面试官能问到啊...）

由于时间比较久了 所以面试的问题可能不是特别准确。

PS。A并不是我面试的时候说的，因为并不可能在面试的情况下说出那么完善的逻辑，而是回来复盘之后，才想起来然后整理出来的。

Q：帧同步如何解决不同步的问题？

A：https://blog.csdn.net/nxshow/article/details/88382085

Q：帧同步怎么做到流畅的战斗？

A：

首先，定义一下流畅的战斗，流畅的战斗并不是代表着游戏的帧数一定要多高多高，而是说游戏的帧数在某一个帧数范围内小规模的变动，例如稳定在30帧这样。

对于单机游戏来说，如果要保证稳定在30帧，每一帧的逻辑、渲染等耗时不能高于33MS，所以需要小心的规划每一个函数的使用，采用分帧执行、算法优化等手段优化卡顿点。

而对于帧同步来说，不仅仅需要完成单机游戏的优化、还要针对网络波动进行针对的优化。我们知道，网络传输无法保证每一次传输的延迟都是一定的，有时候10MS就能完成一次传输，有时候1000MS才能完成一次传输，那么客户端如何保证网络传输不稳定的情况下，逻辑帧的运行还是相对稳定的呢？下面是给到的两种解决方案。

1. 收到逻辑帧消息之后，不立即去播放，而是存着，播放使用固定的延迟进行播放，表现上就是玩家每次进行操作的时候，并不是马上生效的，而是有一小段固定延迟，这样网络在我们设置的延迟内波动的话，玩家是感受不出来卡顿的。但是缺点也很明显，每一个玩家都会有一段延迟。
2. 另外一个处理方式就是，逻辑和表现进行分离，表现帧由玩家和逻辑帧进行驱动，逻辑帧卡顿并不影响表现帧，表现帧由玩家进行控制播放，一旦收到了新的逻辑帧，立即去做校验，如果说表现帧的播放轨迹和逻辑帧有出入，立即进行纠正。如果说新的逻辑帧并没有和表现帧有差异，但是表现帧相对逻辑帧差距很大，例如逻辑帧才到100帧，表现帧就已经到了200帧，这时候就对输入进行限制，比如移动速度放慢等操作。等待逻辑帧追上表现帧。对于其他玩家，采用AI预测的方式进行预测，一旦预测结果与新收到的逻辑帧不一致，就立即回退；同时，随着逻辑帧和表现帧的差距越来越大，相应的减缓预测的效果，最终停止预测。如果说逻辑帧突然来了一大波，应该适当的进行加速播放逻辑帧，尽量去追上表现帧。

Q：帧同步环境下如何做网络流量优化？

A：网络流量的优化，实际上就是网络包大小、数量的优化；首先，尽量去减小发送的数据，合理的规划每一个byte的作用，数量上尽量去合并同一批发送的数据包，减小由于包头造成的流量损失。

Q: 如何解决UDP丢包问题？

A：

首先明确一点，丢包问题是不可能解决的，在TCP和UDP下都会存在丢包的情况，那么为什么TCP号称是可靠的传输协议呢？这是由于TCP处理了丢包的情况，而UDP是无连接的，每次发出一个数据包之后就不管了，所以丢包的情况是需要我们自己去处理的。

首先，丢包是不可避免的，但是我们应该尽量去避免代码逻辑造成的丢包，还有就是完善丢包重传机制。

代码逻辑造成的丢包，具体来说，是以下几点：

1. 发送端发送的数据堆积导致的丢包，也就是发送缓存被填满了导致的丢包，处理方式就是，控制发送频率，避免同时发送过多、过大的数据包。
2. 数据包过大导致的丢包，internet协议规定的MTU大小为576，也就是目前最差的路由器支持的最小包大小就是576，如果大于这个数字，路由器就有可能对数据包进行分包，这样就一个包变成了两个包，两个包只要有其中一个包丢掉了，就代表这个数据包丢了，所以我们要严格控制数据包的大小，去掉UDP包头20个字节的大小，我们可用的还有556，我们程序中定义为512，只要超过这个数字，就会强制进行分包发送，接收方接收到数据包的时候，再进行重组。
3. 接收端卡顿导致的丢包，接收端运行卡顿，导致数据包到接受端的时候Recv函数并没有在执行，处理方式就是使用多线程去执行Recv函数，这个线程里面只处理Recv，然后将接收到的数据缓存起来。

 

但是就算这样处理了之后，由于网络问题导致的丢包是没法解决的，所以我们必然要建立可靠的UDP传输。也就是实现丢包重传机制。

1. 给每一个包规定一个自增的唯一序号，通过ACK确认双方发送到了那个数据包。
2. 合理设置RTO（重传超时时间），TCP貌似是2*RTO, KCP采用的是1.5*RTO。

然后这里面试官追问，如果说这个包丢了，你一定要等到确认丢包之后重传吗？

答案是不会，格斗游戏既然使用了帧同步，就是要求实时性能，所以在重传机制上，还做了冗余发送的机制，就是在发送当前帧的时候，把前面几帧的数据一起合并起来发过去，相当于这几个消息中，只要收到了其中一个消息，就能流畅的播下去。

Q：如何保证在UDP环境下接收逻辑顺序一致性？

A：针对每一个数据包进行编号，后发的数据包如果先到了客户端，就存着，直到接收到的数据包是顺序的，才发生到逻辑层进行顺序处理

Q：如何实现帧同步环境下的断线重连？

A：

因为UDP是无连接的，所以断线只能通过上次收到的消息时间超时了多久进行判断，断线之后客户端逻辑帧停止，表现帧停止预测。

重连就比较麻烦了，重连回来之后，将逻辑帧、状态帧拉回来，服务器一次性将断线之后的消息发给客户端，客户端加速播放。

但是如果断线时间比较久，重连回来之后，消息数据量非常大，需要播放的帧数很多，有没有优化方法呢？有的，帧同步因为逻辑是在客户端运算的，所以帧同步的作弊也比较容易，我们通常会采用专门的验证服务器去验证，这个服务器同样接收客户端的操作指令，运行战斗逻辑，所以我们断线时间比较久的话，可以去验证服取到最新的现场数据，再发送现场数据到最新的逻辑帧给客户端，即可实现快速重连

Q：怎么去做战斗预测？

A：

Q：在帧同步的环境下怎么防止作弊的情况？

A:

Q:帧同步和状态同步的区别？为什么我们游戏要用到帧同步？

A：

帧同步和状态同步都不是新东西，很早以前就有了，以前由于网络问题，帧同步只存在于局域网游戏中。帧同步的逻辑放在客户端，服务器只管转发；状态同步的逻辑放在服务端，客户端只管表现。由于帧同步逻辑是客户端计算的，所以帧同步的每一个客户端都要知道场上的所有信息，才能正确的进行计算。而状态同步的逻辑都在服务端，所以状态同步不需要每一个客户端都知道所有的信息，只需要知道这个客户端所关心的信息就可以了。

因此状态同步更适合MMORPG这样的同步客户端数量较多，信息较为复杂的情况；而帧同步更适合MOBA这样的，客户端数量固定，更关注实时性的情况。

为什么我们游戏需要用到帧同步？我们游戏是一个格斗类型的游戏，对于打击感、实时性要求较高，而且参与战斗的只有两个客户端，战斗的场景非常简单，是一个典型的适合使用帧同步的场景。如果我们使用的是状态同步，每一个客户端在同一帧的表现不一致，就非常难调打击感，那么对于格斗游戏来说，没有打击感这个游戏就没有了灵魂。还有一点，帧同步的逻辑都在客户端，所以如果需要新增加战斗机制，只需要在客户端修改就可以了，不需要像状态同步那样，服务端增加计算逻辑，客户端增加表现逻辑。开发上非常简单，逻辑上也非常清晰。

 

除开帧同步 还少量的问了一些其他问题

Q：ETC压缩算法原理

A：

Q：大地图下的地图加载方式？

A：

Q：MMORPG游戏中多人、多时装渲染优化方案？

A：

 

问题不止这些，不过面试时间有点久，有些问题已经忘了，这里先做一个记录，后面有空再把回答补上