谈谈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()。

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



发表评论