Question

我正在用Java构建一个新的实体系统。我想知道我提出的方法是否会导致任何问题，无论是体系结构还是性能方面。

我想：

...

for (Entity entity : entities)
{
    for (Entry<String, Component> entry : entity.components.entrySet()) //collection is a Map
    {
        Component component = entry.getValue();
        component.update(deltaTime);
    }
}

...

VS。不受欢迎的选择：

...


for (Entity entity : entities)
{
    if (entity.componentA != null)
        entity.componentA.update(deltaTime);

    if (entity.componentB != null)
        entity.componentB.update(deltaTime);

    //etc. for as many components as the entity has. Finite, but possibly many.
}

...

使用第一种方法，我已经考虑过有关HashMap方法的一些事情：

我会避免不必要的条件（当成千上万的实体调用update()时非常重要）;
读取访问时间平均为O（1）（唯一一次您可能无法获得哈希冲突）;
HashMap.entrySet()来迭代集合。正如我从文档中理解的那样，“集合[集合]由地图支持”。但是，每次调用entrySet()时，这都不会告诉我HashMap是否在内部创建集合。

Answer 1

读取访问时间平均为O（1）（唯一一次您可能无法获得哈希冲突）;

在for entry中的每个循环中，您无需调用map.get()。

但是，每次调用entrySet（）时，这都不会告诉我HashMap是否在内部创建集合。

不，每次都不会创建新的设置。

您应该编写最干净，最容易阅读和维护的代码。如果性能不够好（即您已对应用程序进行了分析并确定性能问题是由该部分代码引起的），请开始优化。

==＆GT;每个循环使用一个。

Answer 2

第一个版本几乎可以肯定是最好的设计：

更多通用代码 - 涵盖所有可能的组件配置
更简洁的代码和可维护 - 避免所有条件
在运行时更灵活 - 您可以动态更改组件列表
快 - 假设entity.components是一个具有良好迭代器的合理数据结构，每个组件应为O（1）

如果您真的关心性能并且已经分析这是一个重要的特殊情况，您可能需要考虑为entity.components编写自定义数据结构（例如ComponentList），这将有一个额外的方法updateAll(deltaTime)来有效地执行所有包含的组件的更新操作。这有几个好处：

您可以避免分配Iterator对象（如果您使用HashMap或ArrayList会发生这种情况）
您可以通过专注于组件类型

实体：条件+组件成员与O（1）策略的哈希查找

2 个答案: