在Unity游戏中汇集常规(非GameObject)C#参考类型



大多数Unity开发人员都知道,重复实例化和销毁GameObjects是需要避免的,因为它会产生一些垃圾。但有人讨论了将经常实例化和发布的常规C#类(非GameObject类型(集中在一起是否更有效。它与一场关于RTS游戏的讨论有关,该游戏使用单位命令的命令模式,即命令由游戏中的单位排队和执行。在游戏过程中,你可以预期命令(实现ICommand接口(将被创建和销毁:

unit.Commands.Enqueue( new MoveCommand( goal, MovementSpeed.Fast );

命令由CommandProcessor执行,然后当IsFinished或Cancel为true时,它被设置为null,处理器将下一个命令排成队列并运行它。

在游戏中集中这样的常规C#类有什么好处吗?从我在微软文档中看到的情况来看,它只建议对创建和销毁成本高昂的对象进行池化(Unity GameObjects就是一个典型的例子(。游戏中的命令不消耗任何本地资源(也不需要实现IDisposable(,而且它们非常轻量级,通常只包含几个Vector3位置、对单位或组的引用以及一些属性,如IsFinished和Cancel。

我在辩论中的立场是,它们不需要池化,CLR处理所有这些都很好,池化应该保留用于快速创建/销毁GameObjects和任何消耗本地资源、具有昂贵的初始化和销毁过程或生成任何类型的";垃圾";这是遗留下来的。然而,我以前从未真正考虑过这一点,我也不确定在哪里可以找到关于这个话题的更深入的信息。我真的只想知道这是否值得考虑/做,以及我如何向他人解释为什么值得或不值得。

编辑:我还认为,池化命令和类似的事情可能比允许CLR做它的事情效率低,因为我们将不断地拥有比在RAM中存储池所需的更多的内存。。。有什么想法吗?

如果您正在使用Unity,Unity Profiler中有一些非常好的工具可以帮助您确定垃圾收集是否会导致性能问题。在使用对象池增加复杂性之前,最好先检查一下是什么使项目速度减慢得最慢。就我个人而言,除了GameObjects需要合并之外,我还没有遇到过其他情况。在很大程度上是以个案为基础的。

相关内容

最新更新