我正在进行本地化游戏。我有大约1％的游戏资产（大约200个20k文件）需要用不同的资产替换每个语言，1比1.我正在考虑在一个非常RAM的饥饿环境中执行此操作的“最佳”方式。这是我目前的想法列表：
将文件ID哈希，以便在几乎恒定的时间1转换为另一个。优点是速度。缺点是这可能是内存耗尽，并不像其他方法那样具有内存效率。
输入要翻译成地图的每个文件ID。记录时间查找，但可能更高效的内存？我不像其他解决方案那样有经验，所以我不能说这有多好用。
将每个文件ID作为一对输入到矢量中，完成后对矢量进行排序，然后对其进行搜索。记录时间查找，可能比地图更有效？
在任何步骤中，如果资产不变，请在前端将kIsThisAssetTranslated []的位布尔表添加到提前的时间保释。
只是寻找社区会考虑哪些方法（或我错过的）的经验和意见。我倾向于哈希，因为这将被调用每个文件访问，但一如既往，拉姆与性能的问题是一个有趣的问题。
答案 0 :(得分：1)
您可以预先计算需要转换的FileID。查找完美的哈希;这可能就是你所需要的。但是，2log（200）只有8个。散列的开销很大，对于完美的散列更是如此。
请记住文件很慢 - 二进制搜索的8次内存访问可能需要一微秒，甚至闪存也不会那么快。
答案 1 :(得分：0)
取决于你有多少RAM。具有200到20k条目的哈希表并不会占用太多内存（通过台式PC标准）。如果必须在运行时确定文件是否已翻译，那么为什么不创建包含所有已翻译文件的地图，并为所有可用语言创建子目录。然后在执行查找之后，只需从语言环境目录（例如en-US）加载它，或者在文件名中添加前缀/后缀。