c# - 一个单一的 MonoBehaviour 类有什么好处？

Question

有时我会看到 Unity 程序员如何使用一个脚本来继承几乎整个项目的 MonoBehavior。所谓的“更新管理器”。所有脚本都订阅到队列中执行，管理器运行所有函数，并在执行后将它们从队列中移除。
这真的对优化有任何影响吗？

Answer 1

这是我在论文中分析的优化技术之一。
Unity 引擎有一个消息系统，它允许开发人员定义由内部系统根据其功能调用的方法。最常用的消息之一是 Update信息。 Unity 正在检查每个 MonoBehaviour第一次访问该类型(独立于脚本后端(mono，il2cpp))并检查是否定义了任何 Message 方法。如果定义了 Message 方法，则引擎将缓存此信息。然后，如果实例化了此类型的实例，则引擎会将其添加到适当的列表中，并在需要时调用该方法。这也是 Unity 不关心我们 Message 方法的可见性的关键原因，并且它们不是以确定性的顺序调用的。

public class Example1 : MonoBehaviour
{
    private void Update() { }
}
public class Example2: MonoBehaviour
{
    public void Update() { }
}

以上两个都达到了相同的结果，但天知道哪个会先被调用。
这种方法的主要问题之一是，每次引擎调用 Message 方法时，都必须进行互操作调用(从 c/c++ 端到托管 c# 端的调用)。如果是 Update幸运的是不需要编码，所以这个开销要小一些。然而，如果我们的游戏处理数千或数万个对象，这些对象都有一个需要 Message 调用的脚本，那么这种开销可能会很大。对此的解决方案是避免互操作调用。一个很好的方法是行为分组。如果我们有一个 MonoBehaviour 附加到大量游戏对象，我们可以通过引入更新管理器将互操作调用的数量减少到一个。由于更新管理器也是运行托管代码的托管对象，因此唯一的互操作调用将发生在更新管理器的更新消息和 Unity 引擎的内部消息处理程序之间。我们必须注意的是，这种优化技术仅适用于大型项目，并且在使用 Mono 脚本后端时，通过这种技术节省的帧时间更有效。 (记住 IL2CPP 转译为 C++)。

上图说明了两种方法的区别。
让我们用 Unity 的性能工具做一个基准测试。基准测试将产生 10 000 个游戏对象，每个游戏对象都有一个移动脚本，可以上下移动这些立方体。

使用传统方法的示例场景的插图。
现在让我们看看基准测试的结果。

毫不奇怪，IL2CPP 到目前为止领先于竞争对手，但有趣的是，更新管理器的速度仍然是传统方式的两倍。如果我们分析了传统方法的 IL2CPP 构建的执行，我们会发现许多 Unity 特定调用，例如在调用组件方法之前检查游戏对象是否存在等。这些将解释较长的执行时间。我们还可以得出结论，在这种情况下，IL2CPP 比 Mono 快得多，通常快两倍左右。基准测试在 5 秒预热之前运行了 1 分钟，并且两个脚本后端都有理想的编译器设置。