在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的执行流程通常是这样的。
如果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不默认提供一套标准的全自动化资源管理方案的根本原因吧。
受方案一的启发,我觉得可以通过如下接口做一个半自动化的资源管理器。
void level.open();
void level.close();
void level.dispose();
void stack.push() {
level l = new level()
l.open()
push l in to stack
}
void stack.pop() {
pop l from stack
l.dispose()
}
每一个level对象都会记录在level.open()和level.close()之间所有加载过的资源,加过载多少次就记录多少次,这些资源会在执行level.dispose()时如实的进行释放。
其中stack在管理UI资源方面几乎已经达到了全自动化,当你打开一个UI时调用stack.push,在退出此UI时调用stack.pop会自动释放在此UI期间你所加载的全部资源。
而在其他不具有栈式加载资源特征的地方,level类也提供了一种方便的半自动化管理方案。
最重要的是,此种方案的开销和复杂度,都要远低于全自动化管理方案。