有时您会看到人们建议这样做，而不是使用图形/声音文件/等。像这样...
// Game code
Image myImage = new Image("path/to/image.png");
...您应该使用清单文件作为间接级别：
// Manifest file
MY_IMAGE: path/to/image.png
// Game code
Manifest myManifest = new Manifest("path/to/manifest");
Image myImage = myManifest.getImage("MY_IMAGE");
我采用这种方法会有什么原因？如果我不使用编译语言，还会有理由这样做吗？
Answers:
大多数时间清单文件与某种存档文件格式相关联。例如，Java中的JAR文件只是一个带有清单文件的zip文件，该清单文件列出了zip文件中的资产以及在何处找到它们。在这种情况下，“ path / to / image.png”不是真实的文件系统路径，而是有关如何在压缩档案中查找对象的信息。除了压缩具有磁盘空间优势外，使用文件归档文件还可以提高性能，因为Windows很难处理少量目录中的成千上万个单独文件。
通过使用这种清单文件，您可以完全抽象出给定数据块的来源。也许您的文件在DVD上，或者从Internet流传输，或者在zip文件中。您必须编写一些其他代码来处理这些情况，但是通过使用清单文件，您的游戏逻辑根本不必关心从何处加载东西。
现在，如果您使用的是非编译语言，则此清单文件肯定可以是C＃源文件，但是如果您可以根据注册表设置或类似方法轻松地在客户端执行时修改正在使用的清单文件，那就很好了。例如，您可以在执行过程中检查是否存在硬盘驱动器缓存，或者仅DVD可用。然后，您可以根据可用设置来切换要使用的清单。
原因之一：数据驱动的编程。
您的代码可能只想知道它需要“ LightWood”纹理，并让资源管理器使用此键来找到文件的正确路径。更进一步，在脚本中，人们不想记住文件路径。它们很乱，可能不正确。让清单确定文件的位置，让人员根据文件名而不是文件名来确定所需的材料。
<material name="wood">
<diffuse color="1,1,1,1">environment.zip/wood_diffuse.jpg</diffuse>
<normals>environment.zip/wood_normals.jpg</normals>
<shader>environment.zip/wood.fx</shader>
<specular color="1,1,1,1" power="0.5" flat="yes" />
</material>作为一般的设计模式，当您要将有关不同对象集的所有信息收集到一个地方时，清单很有用。它不必与存档/打包的文件有关，也不必与允许在不重新编译/更新原始引用的情况下移动内容的间接引用有关。实际上，后者会带来比解决方案更多的问题，因此只有在解决了您的特定需求时，您才这样做。
清单的最大优势在于，它们可作为单个紧凑位置中大量数据的索引。这样，它们可以提高性能（因为您可以简单地从磁盘加载整个清单并将其保留在内存中），尤其是在需要迭代多个对象但事先不知道这些对象是什么的情况下。如果对象在磁盘上，尤其是在多个位置，则每次要遍历文件时都必须触摸文件系统。对于基于磁盘的文件系统，触摸文件系统所需的时间太长了，因此遍历目录中的文件会耗费大量成本。通过在构建时（NB：非编译时）预构建文件清单，您可以将该成本用于内存使用。
存档文件需要使用清单，这仅仅是因为存档的目录本质上是清单本身，因此您可以免费获得该行为。而且，如果您需要在一个位置对资产使用清单，则坚持通过清单引用所有资产会更清洁。使您可以从代码中的引用到资产的抽象资产的实际存储位置/机制。这样，您可以在代码中使用单一资产引用类型，而不必在文件路径，归档文件路径+偏移量或子资产之间进行区分。
清单文件在资源名称及其位置之间提供了一个间接层。过多的间接层只是设计过度的标志。但是，有时候，额外的层正是构建优雅而有效的解决方案所需要的。
这是一个简单的具体示例，其中资源名称/位置分离对我有所帮助。在开发过程中，我的艺术资产受源代码的修订控制。这非常方便，可以让我快速迭代。通常，资源名称反映了它的位置。开发清单非常简单。
我不想分发资产分散的游戏。因此，当我准备分发它时，我可以轻松地将资产压缩到资源文件中并构建一个新的清单。
同样，纹理图集是从图形系统中获得更多性能的好方法。地图集速度很快，但是在艺术仍处于发展阶段时，使用它们就很痛苦。我的解决方案是仅在优化游戏时最后构建地图集。由于我正在使用清单，所以我要做的就是更新清单以指向地图集位置和外观，游戏现在使用的是地图集，而不是直线文件。