游戏性能优化杂谈（四）
source link: https://zhuanlan.zhihu.com/p/268425759
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
对于当代游戏，尤其是大制作来说，IO往往是一个非常主要的性能瓶颈。不仅仅是CPU读取游戏资源的方式，游戏资源的打包方式本身也会极大地影响CPU性能。
常规的文件操作，是一个多个步骤连锁的过程：需要按层级遍历目录，需要对比文件名，需要打开文件，而且这里面每个步骤往往都是一次系统调用。当代游戏的资源文件数常常都在数万至数十万这个数量等级，即便在一帧当中需要参照的资源很可能就数百上千，那么多文件每帧都去open-close一次显然是不聪明的。
事实上，游戏的资源文件一般只有游戏本身会去访问，而且是只读访问。它们在游戏的运行过程当中一般并不会发生任何更改，也不太需要诸如文件级别安全性、访问日志等功能。因此，通常的操作系统层面的文件和文件系统，对于游戏资源来说，是有些过于臃肿的。在文件系统所提供的众多功能当中，游戏资源文件所需要的，其实只是：能找到，能读取。
所以，当代的游戏引擎一般都会对零散的资源进行某种形式的归档，将这些零散的资源组织在一个或者数个大文件当中，这样可以大大减少文件的总数，从而减少需要open-close的文件数，并且避免各种不必要的文件系统开销，提高文件访问性能。
不过，这种方法的采用同时也带来了新的问题：如何有效地在归档文件当中组织资源。也就是，要创建多少个归档文件，每个文件当中要包括哪些资源，这些资源在归档文件当中应该如何排列，如何在读取的时候实现快速定位的问题。
同时，我们甚至还需要考虑游戏版本打补丁的时候，补丁大小的问题。如果归档文件很大，那么对其进行的一点点改变，比如替换其中一个资源，都有可能导致很大的补丁。
对于传统的线性流程游戏或者关卡式游戏，资源间的关系比较一目了览，引擎可以直接按照关卡或者游戏故事推进的方向组织资源。
但是在开放世界游戏当中，或者说非线性流程游戏当中，资源间的关系就变得更加复杂了。通常最容易想到的是按照地图分块来组织，但是这对于静态的资源还相对容易（但是依然有重复资源以及跨分块资源如何归属的问题），对于动态资源则更加难以按此处理。
所以对于这种情况我们往往需要将资源分别组织在不同的层面（地图）上，各自依据其特性进行不同的管理。
当然，这个问题还远不止如此。我们还需要考虑游戏内容制作上的便利。我们不能因为性能上的各种考虑导致美术要改个素材需要重复改很多拷贝或者变种。而实现这个，需要建立一条完整的内容生产流水线，包括很多内容制作工具的插件，也包括资源管理数据库、自动构建服务器、以及各种调试测试工具。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK