一个单一的 MonoBehavior 类有什么好处?

Spa*_*ibo 6 c# unity-game-engine

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

Men*_*yus 9

这是我在论文中分析的优化技术之一。

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

public class Example1 : MonoBehaviour
{
    private void Update() { }
}
public class Example2: MonoBehaviour
{
    public void Update() { }
}
Run Code Online (Sandbox Code Playgroud)

以上两个都达到了相同的结果,但天知道哪个会先被调用。

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

测试 上图说明了两种方法的区别。

让我们用 Unity 的性能工具做一个基准测试。基准测试将产生 10 000 个游戏对象,每个游戏对象都有一个移动脚本,可以上下移动这些立方体。

测试 使用传统方法的示例场景的插图。

现在让我们看看基准测试的结果。 在此处输入图片说明

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