谈谈Unity的资源管理

作者

在Unity最佳实践明确指出, 要使用AssetBundle而不是Resources目录来管理资源。

然而，事情并不像Unity官方描述的那么美好。因为使用AssetBundle我们甚至无法实现一个高效易用的，完全自动化资源管理方案。

据Unity官方说，一般有两种方案。

方案一，如果你的游戏是关卡性质的，可以在一个关卡里加载所有AssetBundle，然后在进入下一关卡时，卸载本关卡中加载的所有AssetBundle. 但这种机制似乎只对愤怒的小鸟这种小游戏才适用吧:D。

方案二，如果你的游戏不是关卡类的，那么Unity推荐做一个资源对AssetBundle引用计数。

如果一个对象（Asset或其他AssetBundle)引用此AssetBundle则其引用计数加1. 如果此AssetBundle首次加载（即加载前引用计数为0), 还需要递归对其依赖引用计数加1。

如果一个AssetBundle的引用计数为0则释放这个AssetBundle，同时还需要递归对其依赖引用计数减1.

除非，我们做像愤怒小鸟一样的通关游戏，不然似乎只有方案二给我们用。而且方案二乍一看是完备的，因为这正是GC算法的一种实现。

但是如果稍微仔细思考一下就会发现，这个方案只是AssetBundle的管理方案，是个半成品，要如何管理资源之间的依赖，Unity却只字未掉，看起来是让用户自己想办法，这似乎与其易学易用的宗旨不太相符。

下面来分析一下Unity中资源之间的关系。

在Unity中资源大约分为以下几种：

纹理(Texture）、网格(Mesh)、动画片段（AnimationClip)、音频片段(AudioClip)、材质(Material)、着色器(Shader)、字体资源（Font)以及文本资源(TextAsset)。

AssetBundle中还有一个极其特殊的存在，那就是Prefab， AssetBundle.LoadAsset时返回的是GameObject, 但是又必须经过Instantitate之后变成另外一个GameObject才能使用。此后所说的GameObject均是Instantitate之后的GameObject。

GameObject可以添加各种Component来引用上述资源，还可以通过代码动态增减某个GameObject上的Component或者修改Component对资源的引用。这种灵活性给资源管理带来了巨大麻烦，而没有这种灵活性，逻辑的实现就会更麻烦。

下面，举例来说明一下，要正确管理GameObject和资源之间的引用关系有多么艰难。

Prefab P能过Instantitate生成A,B,C,D四个GameObject.

执行如下代码之后，A引用{P,T1}, B引用{P,T1}, C引用{P,T3}。并且T2应该被Unload。

1: A.GetComponent<SpriteRender>().sprite = (Sprite)T1;
2: B.GetComponent<SpriteRender>().sprite = (Sprite)T1;
3: C.GetComponent<SpriteRender>().sprite = (Sprite)T2;
4: C.GetComponent<SpriteRender>().sprite = (Sprite)T3;

要想自动正确的管理GameObject和资源的引用关系，就必须要感知到对GameObject的赋值操作。

例如：所有的sprite赋值都必须使用类似SpriteAssign(SpriteRender sr, Sprite s)的接口。

SpriteAssign的执行流程通常是这样的。

  1. 检查sprite的值是不是T1相同，如果是相同则不做处理
  2. 检查sprite的值是不是从P中clone过来的，如果不是，将此sprite的引用计数减1
  3. 将T1的引用计数加1

如果P是一个树状态结构，即有P–(child)–>p1–(child)–>p2。

1: A.p1.p2.GetComponent<SpriteRender>().sprite = (Sprite)T1;
2: B.p1.p2.GetComponent<SpriteRender>().sprite = (Sprite)T1;
3: C.p1.p2.GetComponent<SpriteRender>().sprite = (Sprite)T2;
4: C.p1.p2.GetComponent<SpriteRender>().sprite = (Sprite)T3;

SpriteAssign接口中的步骤2就显得格外复杂，它必须修正引用关系如下：A引用{P,T1}, B引用{P,T1}, C引用{P,T3}。

同时Destory操作也要被感知，如果Destory(A)则需要释放A引用的资源，而如果Destory(A.p1.p2)则需要修正A对资源的引用情况。因为此时的引用关系是，A引用{P}。换句话说Destroy的开销也会变大。

而赋值和Destory都算不上低频操作，尤其是赋值操作。这样的开销已经足够让程序慢上好几倍了。如果不能承受这些开销，全自动化资源管理是不可能实现的。

我想这也是Unity不默认提供一套标准的全自动化资源管理方案，而是让用户根据实际情况来自己做trade-off的根本原因吧。

受方案一的启发，我觉得可以通过如下接口做一个半自动化的资源管理器。

void frame.record(asset);
void frame.dispose();
void stack.open(frame f);
frame stack.close();
void stack.push() {
    frame l = new frame()
    stack.open(l)
}
void stack.pop() {
    frame f = stack.close()
    f.dispose()
}

每一个frame对象都会记录在stack.open()和stack.close()之间所有加载过的资源，加过载多少次就记录多少次，这些资源会在执行frame.dispose()时如实的进行释放。

其中stack在管理栈式UI资源方面几乎已经达到了全自动化，当你打开一个UI时调用stack.push,在退出此UI时调用stack.pop会自动释放在此UI期间你所加载的全部资源。

而在其他不具有栈式加载资源特征的地方，frame类也提供了一种方便的半自动化管理方案。在加载资源之前调用stack.open(frame),在加载资源之后调用stack.close()。

最重要的是，此种方案的开销和复杂度，都要远低于全自动化管理方案。

发表评论

twenty eight − twenty three =