[Unity Mirror] FixedUpdate、网络周期和Mirror Networking

英文原文：

https://www.coburnsdomain.com/2020/04/fixedupdate-networking-cycles-and-mirror-networking/

  好吧，是时候更新博客了，这一次可能有点大材小用。本来，我想写一篇关于一些 "微观优化 "被Mirror拒绝的文章，但那将是另一天的事。

  对于那些不熟悉 Mirror Networking 的人来说，它是一个免费的网络库，可以直接插入 Unity，而我恰好是 Mirror Networking 开发团队的一员。

  我们经历了通常的戏剧性事件，一些内部开发冲突总是存在于你们相互冲突的每个开发组中。克服这些问题的唯一方法是退缩或妥协并以不同的方式处理问题。

  然而，我将要讨论的这个问题是围绕着如何处理网络逻辑，以及从我的角度来看，可以做些什么来改进它。

  现在，在Mirror Networking中，有两个版本的Mirror。一个是GitHub和Unity资产商店发布的Mirror，还有一个是MirrorNG，开发者之一Paul在他自己的游戏（Cubica）中使用的。

  MirrorNG应该是 “下一代”，并进行了大量的重构，然而由于它简直就是一个大锅饭，而且不稳定，使用它的用户群非常少。说实话，这听起来很刺耳，但我并不真正关心MirrorNG。

 那是保罗的孩子，如果他忙着砍掉它的四肢，缝合改进或改写的部件来代替这些四肢，那么对他来说是好事。对我来说，感觉它的开发只考虑到了一个人（他自己）。Mirror 的 Master 版本也会发生同样的事情。不幸的是，这让我心中充满了迷雾，"主导 "的开发者并没有考虑到寄宿社区的联网问题，而是过于关注自己的需求。这一点在可以增强和加速核心的微观优化被拒绝时很明显–由于触发并合并 PR 的开发人员的需要/想要，它被拒绝了。

  简而言之，有时“领导”开发人员的目标不符合其他开发团队成员的最佳利益。

  对于我来说，我的Mirror树是从主分支分叉出来的；主分支主要是开发团队改进、修复错误和接受PR的地方。为了清楚起见，我们将专注于主分支，也就是本文中的 "原始 "分支。

  因此，让我们进入这篇博文的主要内容，即网络是如何被抽调的。免责声明：我不是网络专业人员，我可能会在这里胡说八道。随时在评论中纠正我。

  现在，Mirror的网络操作主要是在LateUpdate里面完成的，如果我们看一下Unity脚本的生命周期，我们可以看到它是生命周期中场景渲染阶段开始前的最后一件事。

然而，如果我们从 Unity Scripting Reference 中查看 LateUpdate 的定义：

如果启用了 Behavior，则每帧都会调用 LateUpdate。
  在调用所有Update函数之后调用 LateUpdate。这对于命令脚本执行很有用。例如，跟随相机应该始终在 LateUpdate 中实现，因为它跟踪可能在 Update 中移动的对象。

  仅此一项就应该告诉您 Mirror 正在 LateUpdate 中进行所有网络处理。这意味着 Mirror 始终落后于 8 个球 1 帧，因为实际场景可能在它开始之前已经发生了变化，并处理网络数据以保持一切同步。

  我和其他网络工程师谈过，包括来自Flying Squirrel Entertainment的一位成员和另一位目前在一家公司担任总监级职务的网络大师，他们都认为LateUpdate对网络来说太晚了（哈哈，看看我在那里做了什么？）

  他们建议都为网络做FixedUpdate处理，这样网络方面的事情就会在渲染方面的事情发生之前完成。

解决死锁

  让我们来解决这个死锁–一个我与之交谈过的网络工程师都同意的解决方案，从我看来也是最简单的解决方案，就是设置一个布尔值，控制网络是否会在这一帧被处理。让我们把这个新的布尔值称为networkIsDone。

  这个布尔值将在FixedUpdate结束时被设置为 “真”，以表示网络已经被更新，并且在做任何网络相关的工作之前，通过检查确保networkIsDone为 “假”，跳过任何由于游戏滞后而导致的同帧额外FixedUpdates。

  在LateUpdate中，networkIsDone被重置为false，所以下一帧就可以接收网络数据了。一旦该帧完成，LateUpdate会再次被调用，由于一帧可能需要很长的时间来渲染，网络不应该连续更新，因为那会导致死锁。

  所以，现在有了这个实现，理论上，联网现在是基于FixedUpdate周期的。当FixedUpdate到来时，它会立即检查我们是否已经完成了这一帧的联网。如果是，就跳过与联网有关的任何操作。如果没有，就继续更新网络子系统，并将变化应用到场景中。最后，把它需要的所有东西都拿到传送装置的门外，为下一轮做好准备。

事后思考

  当然，这远远不是解决一切问题的灵丹妙药。我将不得不去确保Mirror本身能够适应这些变化，并看看LateUpdate在Mirror的核心中的根基有多深。

  但对我来说，我个人希望看到Mirror成为一个更多基于tick的网络解决方案，因为它是一个伟大的网络解决方案。然而，在这一点上，我们不能总是落后一格。

  也许在MMORPG中这是可以接受的，但对于我的游戏，也就是射击游戏，一帧中可以发生很多事情。

  一如既往，感谢您的阅读，并在评论中告诉我您的想法。