在穿插了内存优化之后，我们回到内存分配与跟踪。接上次所说，我想针对AAA游戏发布做必要的内存分配和跟踪，而不需大量时间来做内存优化。
方案需求
大多数AAA游戏有大量资源需要频繁调入调出系统内存和显存。在沙盒游戏中更严重，而大场景游戏（例如《NBA2015》）稍好些。不管怎样，解决方案需要快速并提供正确的数据给所有的分配。一个快速但不提供适当跟踪工具的解决方案是不可取的，或提供了合适的跟踪工具但速度很慢也是不行的。两项在衡量中都是很重要的。同时，所有分配必须通过它，也就是说客户端代码或第三方库不自己分配内存，全局的new和delete操作应该override(重写)。
跟踪信息
解决方案必须提供相关的内存跟踪信息。其中，信息应包括所有的内存占用，具体到某段内存对应的分配地址，包括所有内存的。任何内存分配都需要有相关的跟踪信息，什么时候分配的，并可被程序员用来检测问题。
常规信息
提供的常规信息应该非常简练。包括如下内容：
分配字节数
分配次数
分配字节数峰值
分配次数峰值
内存分配分组
就像有不同的小组或团队一样，说到游戏的不同功能时，需要按组进行分配。一些组用来渲染，游戏设置，UI，音频等等。不同分组有不同的内存分配模式和需求。正因如此，标准的内存分组分配是个好主意，优点如下：
优化内存分配设置。并不是所有分组都有同样的分配需求，所以最好是每组都可进行分配设置。也就是说比如：并不是所有组都需要互斥的分配器，并不是所有组都用同一个小块分配器等等。
预算跟踪与强制执行.每组分别拥有一定量RAM用来实现跟踪，系统程序员可在不同组协调分配。基本上，这就可以保证它们共享事务，所有内存都在掌控之中。
便于检测崩溃问题。由于所有分配都有与组相对应的分配器设置，这就容易解决崩溃或在分配中出现的问题。分组提供了良好的初始环境。
性能表现更优。由于并不是所有的分组或分配都需要互斥，这些开销可以避免。对于需要互斥分配器的组也会降低发生冲突的可能性，因为并不只有一个互斥分配器（比如：全局分配器）加锁。在决定内存分配方式时，要权衡绝对性能与内存峰值二者。
分配命名
为识别不同的分配，应该为所有的分配“命名”。名字表示谁需要内存，也许可以强制命名规则，但为了跟踪内存分配，这些标签应该是可以访问的。为提高性能，这些标签应该只在非发布版本上有效。
分配域
解决方案必须可以为每个线程的分配域的堆提供更多的上下文信息。它比使用堆栈的分配提供更好的上下文信息，并且很容易获取调用堆栈。在虚幻一个示例中，在UObject创建过程中创建域，这样该Object相关的所有分配都在该域内。所有非域内的分配仍属于全局域。下面是作为叶节点分配域的示例和相关数据：
Main Thread Pointer Bytes Group
Global Scope
UGameEngine::Init
/Game/Maps/LandscapeMap.umap
AddToWorld
PersistentLevel
ConstructObject
FPhysXAllocator::allocate 0x000000000b093fe0 131720 Physics
分配标志
分配可根据分配器不同的含义来提供可选标志。比如:
生命周期标志。提供关于分配的生命周期的提示。当减少分配的内存碎片时，分配器会更加智能。
分配清空标志。分配器就可以在返回之前清空已分配的内存。
性能
即便是带可跟踪功能的非发布版本，解决方案也必需达到可被接受的性能。可接受就意味着在有内存跟踪的情况下，每帧耗时不能超过50ms。若超过这个值，用户就会尽量避免使用跟踪功能了，这是滑坡，不得不在最糟糕的时候即版本发布时恢复。当然，性能损失和常规消耗应该在发布版本时降到零。
分配分组
为实现可能的最佳分配方法而不必大大提高客户端代码复杂度，为每组定义多个分配器就是顺理成章的。这些分配器可被顺序调用，每个分配器都会成功返回分配的内存。比如：常规组有三个分配器：
静态小块分配器（SSBA）。它是静态分配小块的分配器，不会增长，接受最大分配空间为256字节。
动态小块分配器（DSBA）。它是动态分配小块的分配器，可根据需要动态增长，最大空间为1024字节。
全局分配器（SA）。系统标准分配器，可分配任意大小内存。
若需要1032个字节的内存，就会先尝试SSBA，DSBA，最好向SA请求内存。若一个分配器就可以满足需求，那就只用一个好了。比如：使用jemalloc（译者注：开源的内存分配库），它使用合理的加锁机制可实现不同大小的内存分配。
联系方式：0755-81699111
课程网址： http://www.vrkuo.com/course/vr.html
