云风的 BLOG

我们一开始实现了一个中规中矩的引用计数方案。资源永远都被 ECS 中的 C 引用，且永远没有对外引用，所以并没有循环引用的问题。引用计数一定可以正确的管理资源的生命周期。一旦引用计数为 0 ，把课回收资源放到一个集合里，交给一个 system 处理即可。

但我直觉上不喜欢在一个基于 lua 这样自带 gc 的语言构建的框架中使用一个蹩脚的引用计数机制。而且，移动设备是一个内存受限的环境，我认为基于业务上不再对资源引用与否来觉得是否可以释放资源不是最好的管理方式。

我认为可以把资源分为两类：一，从 IO 获取的资源，它们有唯一的名字（文件名）。这类资源即使从内存释放，也可以重新加载回内存。二，根据其它数据由代码生成的资源，如果销毁不太容易重建。

第一类资源是大头，我认为它们实际上可以随时从内存销毁，释放内存供其它使用。部分资源类型还有替代方案：例如贴图，我们可以用统一空白贴图临时顶替使用。

针对第一类资源，生命期管理就不必基于它是否在内存中还有引用决定，而应该由是否很久没有使用决定。一个长期未使用的资源对象，无论在 ECS 中是否还有 C 对其引用，资源管理模块都有权销毁它，直到下次使用它时再通过异步加载模块读回。

而第二类资源就麻烦一些。如果我们随意删除，就很难重建（因为失去了当初创建它的上下文）。我们决定在内存富裕的情况下，永远保留这类资源。在迫不得已的时候，再在条件允许时删除它。最早的实现又用回了引用计数方案，但很快又去掉了。我们的 ECS 框架很容易遍历所有的资源，所以在必要的时候确定一个资源对象是否还有 C 在引用并不复杂。所以不必额外做繁杂的加减引用操作。

后来，在经过一些讨论后。我又从 imgui 的设计中得到了新的灵感：

其实，当初我们也考虑过给每种第二类资源提供一个回调函数，在销毁后调用一下就能重建回来。但并不是总能简单的写出这个创建函数。例如，如果一张贴图是用场景上的一个摄像机渲染出来的，那么这个回调函数就涉及相关场景对象了。一个简单的闭包函数很可能破坏掉 ECS 的设计原则。

但是，如果我们反过来想，如果每帧都主动创建这种资源呢？好比 imgui 并不保存控件的状态，每帧都去画一下那个控件一样。这样就不会影响 ECS 的设计原则，可以用自然的方式去创建动态资源。之后，我们就可以再这个基础上 cache 上一帧的结果，而避免每帧都创建。

这样设计后，第二类资源对象就和第一类对象一样，可以在任意时刻销毁。资源管理模块只需要按 LRU 算法淘汰超出内存阙值的资源就够了。