在公司项目开发中，用到了assetbundle，由于是webplayer不像手机，流量限制几乎没有，所以场景都是用assetbundle打包后动态加载的，但是这个过程中，遇到不少坑：

这个问题描述起来很简单：比如：老板原来让你用4.1打包(BuildAssetBundle)开发，开发完毕后，下半年，unity升级了，于是老板要求与时俱进，让你用4.3开发维护，这时，问题就出现了：4.1下的editor打包的assetbundle在editor下不能被4.3读取，会报错。

那么解决方法是啥呢？把所有资源重新在4.3下打包。很坑吧？但是，这问题仅仅只是在editor下会出现，webplayer不会出现。但你恐怕很少说调试程序不走editor吧？

 

当你把assetbundle资源用www下载下来后，往往都会使用“wwwResource.assetbundle”，但是注意，这个函数调用assetbundle的时候，只能调用一遍。意思是，当你要再次读取的时候，会报错。这时候，需要你写一套对于assetbundle的控制程序，保证第一次读取资源的时候是使用wwwResource.assetbundle，第二次再次利用，则要用已经读取出来的资源。

 

在我们的项目中，打包时，用到了BuildPipeline.PushAssetDependencies()和BuildPipeline.PopAssetDependencies()的功能，这是unity里比较好的一项功能，它可以把unity里的依赖关系比较好的保存下来，并正常读取就可以还原。比如：一个模型用到了贴图1，贴图2，贴图3，这时，我们可以用这种依赖关系的方式，把模型单独打出来，同时把贴图1贴图2贴图3也单独打包出来，这样的话，如果有别的模型也用到了贴图123，只需要下载一次，然后在读进工程的时候，贴图自动找到模型，并贴上去。听起来很美，但是也有问题：严格根据依赖关系按顺序下载资源。否则，留给你的是一个个白模。我们被这个问题坑了好久。

 

听起来是不是好惊讶？webplayer下的免费cache居然这么少？意味着，在webplayer下，你的LoadFromCacheOrDownload用处并不是非常大。因为你的资源需要一遍又一遍的下载，cache的作用大大缩小了。而如果你想扩展，需要联系他们的销售部，据说价格不菲。不过针对这个问题，现在有人已经利用游览器的缓存绕过了这个问题，思路比较巧妙，但是涉及到unity官方利益，我在这里就不介绍了。

 

这个现象比较难以表述，举个例子会比较好：美工给我们两个模型，一个是黑色的椅子，一个是蓝色椅子，这个椅子都用了红色的椅背。但是美工给的是两个unity工程。这时候，我们为了共用红色椅背的贴图，进行依赖的建立。如果不把这两个椅子移动到同一个工程下进行带依赖关系的assetbundle打包的话，则会共用失败。不是下载两次红色椅背贴图就是其中一个出现白模，这个具体要看你怎么处理了。

为什么呢？咨询过unity公司，他们告诉我们，在unity里面，每个资源都有个自己的内部id，就算是相同的资源，id在不同工程下也会不同。这样的话，不同工程下的资源自然无法建立依赖关系。

其实我觉得这是一个正常的现象，但是我想说的是，所有的模型都要导入到一个unity工程里面进行打包，这个untiy工程会越来越大，最后乱七八糟难以维护。这就是assetBundle的依赖功能的小小局限。所以，如果你要打包的assetbundle比较多，比较杂，可能还是自己去实现依赖会比较好。

 

另外在开发中还遇到一些其他问题，我会在以后的帖子里继续介绍。