Unity5 如何做资源管理和增量更新
我的图书馆
Unity5 如何做资源管理和增量更新
Unity 中的资源来源有三个途径：一个是Unity自动打包资源，一个是Resources，一个是AssetBundle。
Unity自动打包资源是指在Unity场景中直接使用到的资源会随着场景被自动打包到游戏中，这些资源会在场景加载的时候由unity自动加载。这些资源只要放置在Unity工程目录的Assets文件夹下即可，程序不需要关心他们的打包和加载，这也意味着这些资源都是静态加载的。但在实际的游戏开发中我们一般都是会动态创建GameObject，资源是动态加载的，因此这种资源其实不多。
Resources资源是指在Unity工程的Assets目录下面可以建一个Resources文件夹，在这个文件夹下面放置的所有资源，不论是否被场景用到，都会被打包到游戏中，并且可以通过Resources.Load方法动态加载。这是平时开发是常用的资源加载方式，但是缺点是资源都直接打包到游戏包中了，没法做增量更新。
AssetBundle资源是指我们可以通过编辑器脚本来将资源打包成多个独立的AssetBundle。这些AssetBundle和游戏包是分离的，可以通过WWW类来加载。AssetBundle的使用很灵活：可以用来做分包发布，例如大多数页游资源是随着游戏的过程增量下载的，或者有些手游资源过大，渠道要求发布的包限制在100M以内，那只能把一开始玩不到的内容做成增量包，等玩家玩到的时候通过网络下载。AssetBundle 也可以用来做我们下面讨论的自动增量更新。
Unity5相比之前的版本，AssetsBundle的打包过程有所简化。之前打包需要通过代码来设置需要打入包的资源并自己建立包的依赖关系，Unity5可以通过每个资源Inspector底部的AssetBundle下拉来指定该资源要打入哪个包，不指定就是不打包。打包过程只需要BuildPipeline.BuildAssetBundles一句话就行了，Unity5会根据依赖关系自动生成所有的包。每个包还会生成一个manifest文件，这个文件描述了包大小、crc验证、包之间的依赖关系等等，通过这个manifest打包工具在下次打包的时候可以判断哪些包中的资源有改变，只打包资源改变的包，加快了打包速度。manifest只是打包工具自己用的，发布包的时候并不需要。
关于自动生成依赖关系这个有必要提下，Unity确实会自动给你建立依赖关系，前提是你依赖的资源必须已经在Inspector中设置了BundleName。如果没有，Unity会把这个公用的资源重复打到多个用到的包中，因为这个公用资源不在一个独立的包中，Unity也不会智能地给你发现它是公用的，然后生成一个公用包。更深的坑在于，如果你公用的是一个FBX模型，你只给这个模型设置BundleName还不行，它用到的贴图，材质都要设，否则模型是公用了，贴图没有公用，结果贴图还是被打包到多个包中了。所以设置BundleName这个工作最好还是由编辑器脚本来完成。
Unity提供的就这些了，下面就自己发挥：如何做一个方便的资源管理方案，既可以开发时方便，又可以方便发布更新包呢？开发过程全用AssetsBundle是不合适的，因为开发中资源经常添加和更新，每次添加或者更新都生成一下AssetsBundle才能运行是很麻烦的。而且我们要做的是自动更新而不是分包下载，这也就是说在发布游戏的时候这些资源应该都是在游戏包中的，所以他们也不该从AssetsBundle加载。
分析完需求，方案也就出来了：资源还是放在Resources下面，但是这些资源同时也会打包到AssetBundle中。代码中所有加载资源的地方都通过自己的ResourceManager来加载，由ResourceMananger来决定是调用Resources.Load来加载资源还是从AssetsBundle加载。在开发环境下(Editor)这些资源显然是直接从Resources加载的，发布的完整安装包资源也是从Resources加载，只有当有一个增量版本时，游戏主程序才会去服务器把增量的AssetBundle下载下来，然后从AssetBundle加载资源。
实现中我们首先要考虑的是AssetBundle的粒度，即每个AssetBundle包含多少资源。增量包的最小粒度就是AsssetBundle， 如果单个AssetBundle过大，只要这个AssetBundle中有一个资源改变了就需要重新下载整个AssetBundle，浪费流量和玩家的等待时间；如果单个AssetBundle过小，极端情况是每个资源一个AssetBundle，虽然实现了更新最小化，但是带来了额外开销：AssetBundle本身也是有大小的，而且查找加载AssetBundle也是需要时间的。大家都往U盘里面拷过东西，拷一个1G的文件比拷1千个1M的文件要快很多。比较合理的做法是根据逻辑来，例如每个角色可以有独立的AssetBundle，公用的一些UI资源可以打到一个AssetBundle里面，每个场景独立的UI资源可以打成独立的AssetBundle。这样做资源预加载的时候也方便，每个场景需要用到几个Bundle就加载几个Bundle,无关的资源不会被加载。
下面要考虑的是如何来确定一个资源是从Resources加载还是AssetBundle加载。为此我们需要一个配置文件resourcesinfo。这个文件随打包过程自动生成。里面包含了资源版本号version，所有包的名字，每个包的HashCode以及每个包里面包含的资源的名字。HashCode直接可以从Unity生成的manifest中得到（AssetBundleManifest.GetAssetBundleHash），用来检查包的内容是否发生变化。这个resourceinfo每次打包AssetBundle时都会生成一个，发布增量时将它和新的Bundle一起全部复制到服务器上。同时在Resources文件夹下也存一份，随完整安装包发布，这就保证了新安装游戏的玩家手机上也有一份完整的资源配置文件，记录了这个完整包包含的资源。
当游戏启动时，首先请求服务器检查版本号，前端用的版本号就是Resources下面的这个resourcesinfo中的version。服务器比对这个版本号来告诉前端是否需要更新。如果需要更新，前端就去获取服务器端的新resourcesinfo，然后比对里面每个bundle的HashCode，把HashCode不同的bundle记录下来，然后通过WWW类来下载这些发生改变的bundle，当然如果服务器版的resourcesinfo中包含了本地resourceinfo中所没有的Bundle，这些Bundle就是新增的，也需要下载下来。所有下载完成后，前端将这个新的resourceinfo保存到本地存储中，后面前端的所有操作都将以这个resourceinfo为准而不再是Resources下面的resourceinfo了。Resources下的resourceinfo可以退出历史舞台了，除非一种情况：本地存储的resourceinfo被认为删除了。手机端玩家清理应用的数据就会造成下载的bundle以及resourceinfo被删除。没关系，这时候前端由于找不到外部的resourceinfo了，还会使用Resources下面的resourceinfo和服务器比对，把新的bundle重新下载下来。
现在从哪里加载资源就很明确了：ResourceMananger先读取resourcesinfo，知道了游戏中所有的Bundle和每个Bundle包含的资源，然后去外部存储查找这些Bundle是否存在，如果存在，就记录下这个Bundle的资源应该从外部的AssetBundle加载，如果不存在，就从内部的Resources加载。在开发过程（Editor）中，由于不存在外部存储的bundle，资源自然都是从Resources加载的，达到了我们开发方便的目的。这个过程隐含了一点：不是所有的资源都需要有BundleName而被打包到AssetBundle中，游戏内不需要后续更新的资源就不要设置BundleName，它们不会被打包更新，这样的资源ResourceManager在resourceinfo中是找不到的，直接去Resources文件夹下面读取就行了。
加载AssetBundle，我们直接使用WWW类而不用WWW.LoadFromCacheOrDownload, 因为我们的资源在游戏开始的时候已经下载到外部存储了，不要再Download也不要再Cache。注意WWW类加载是异步的，在游戏中我们需要同步加载资源的地方就要注意把资源预加载好存在ResourceManager中，不然等用的时候加载肯定要写异步代码了。大部分时候我们应该在一个场景初始化时就预加载好所有资源，用的时候直接从ResourceManager的缓存取就可以了。
资源加载卸载
最后简单说下资源的加载卸载，这个网上也有很多文章介绍。
从我理解来看Resources是一个缺省自动打包的特殊AssetBundle。无论从WWW还是AssetBundle.CreateFromFile创建AssetBundle其实是创建了一个文件内存镜像。这时候是没有Asset的。AssetBundle.LoadAsset 和Resource.Load才真正创建出了Asset，而Instaniate复制了这个Asset。注意这个复制有两种，学C++的都知道浅拷贝和深拷贝，这里的复制有的是正真的复制，有的是引用。为什么要这样呢？因为有些游戏资源是只读的，像贴图Texture，这么大而且只读，当然不需要再去完全复制一份。但像GameObject这种资源它的属性是可以通过脚本改变的，必须要复制一份。所以一个资源从AssetBundle到场景中被实例化，其实有3块内存被创建，这3快内存的释放是有不同方法的。
文件内存镜像是通过AssetBundle.Unload(false)来释放的。
Instaniate出来的Object内存通过Object.Destory来释放。
AssetBundle.Unload(true)不单会释放文件内存镜像，还会释放AssetBundle.Load创建的Assets。这个方法是不安全的，除非你能保证这些Assets没有Object在引用，否则就出问题了。
Resources.UnloadAsset和Resources.UnloadUnusedAssets可以用来释放Asset。
下面这个图很直观：
这是老Unity的图，Unity5已经把AssetBundle.Load 改成了AssetBundle.LoadAsset。这个改动让我们更明确了Load出来的是Asset这块内存区域。什么时候把Resource.Load也改了吧。
注意事项（坑）
Resources.Load方法传入的资源路径需是从Resources文件夹下一级开始的相对路径且不能包含扩展名；而AssetBundle.LoadAsset方法传入的资源名需是从Assets文件开始的全路径且要包含扩展名。路径不区分大小写，建议全用小写，因为AssetBundle.GetAllAssetNames方法返回的资源名都是小写的。
Unity5打包AssetBundle时会自动处理依赖关系，但是在运行时加载的时候却不会，程序需要自己处理，先加载依赖包。
AssetBundle.CreateFromFile不能加载压缩过的AssetBundle，所以我们只能用WWW来异步加载AssetBundle。
目前我用的Unity5.0.2f1的Resources.Load方法在手机端比原来慢了很多，如果以前可以不缓存每次用的时候都调用Resource.Load现在就不行了。频繁的调用会导致明显的性能开销，不知道是不是Bug。
原文地址：
馆藏&21301
TA的推荐TA的最新馆藏[转]&[转]&[转]&[转]&[转]&[转]&[转]&[转]&[转]&[转]&[转]&[转]&
喜欢该文的人也喜欢Unity项目资源加载与管理
Unity项目资源加载与管理：将材质打包为AssetBundle，运行时使用LoadAsset加载材质也成功了，为什么还会出现材质丢失呢?这也是开发者经常会遇到的问题。一般情况都是，开发者先把被依赖AssetBundle中的资源加载出来，然后用Unload卸载掉这个被依赖的AssetBundle，最后发现从其它AssetBundle中加载出来的GameObject丢失了前面加载出来的资源。 要弄明白这个问题，我们需要了解AssetBundle中的Asset在加载时寻找其依赖资源的规则。其实很简单，现在AssetBundle实现的机制是只会在内存中寻找其依赖资源所在的AssetBundle，并自动从中加载出所需的资源。
那么现在我们知道，其实通过LoadAsset从被依赖资源的AssetBundle中加载出来的资源，除非我们手动绑定回主体资源中(例如把加载出来的材质通过代码绑定回GameObject的Renderer中)，否则是不会被自动索引到的。
也就是说，通过AssetBundle来动态加载资源时，我们并不需要自己加载被依赖的资源，而是只要保证主体在加载时被依赖资源所在AssetBundle依然处于开启状态就可以正常加载资源了。
为什么游戏切换到后台一段时间后再切换回来材质会变成粉色呢?
大家都应该知道，粉色材质在Unity中是Shader出错或丢失时的默认警示材质，而在这种情况下就是Shader丢失的问题。 首先我们要了解一个对于GPU资源管理的机制。在PC平台上，用户在锁屏一段时间后GPU会自动把部分后台程序的资源清除掉，而或者iOS这种移动平台系统一般会在切换到主界面或其它程序一段时间后进行类似的操作。 那么当Unity程序在GPU中的Shader和Texture等资源被清除之后再切换回该程序时，CPU端会接收到GPU Graphics Context 丢失的消息，然后Unity会尝试从内存中将丢失的资源重新加载到GPU端。
这时，如果原来的Shader和Texture资源是从AssetBundle中加载出来的，并且该AssetBundle已经被卸载掉的话，那么Unity就无法再从内存中加载到这些资源，从而导致GPU丢失Shader与Texture了。
可能有朋友会说，这些Shader和Texture不是曾经被加载到内存中吗?是的，但是它们在被加载到GPU之后会被从内存中清除掉。因此要防止这种问题的发生最稳健的办法就是Shader和Texture的AssetBundle在场景切换前都不要卸载掉。而如果担心AssetBundle本身消耗内存问题的话可以参考下一个问题的解答。
新的ChunkBasedCompression压缩方式相比原来的压缩方式有什么区别呢，应该如何取舍呢?
Unity默认的AssetBundle压缩方式是LZMA，这种压缩方式的AssetBundle在加载到内存时会马上执行解压过程，并在AssetBundle处于开启状态期间在内存中保留一个解压过后的Cache(例外情况：UnityWebRequest.GetAssetBundle与WWW.LoadFromCacheOrDownload均会在第一次解压LZMA AssetBundle时把解压后版本Cache到文件系统中，后续的调用就无需在内存中保留解压后的AssetBundle了)，因此内存占用会比较明显。
而Unity5.3以后提供的ChunkBasedCompression是一种基于Chunk的LZ4压缩方式，这种压缩方式可以让AssetBundle对单独的Asset进行压缩，而不是AssetBundle整体压缩。因此加载这种压缩方式的AssetBundle时，无需事先解压，只需在内存中保留一个头结构，然后在加载某个Asset的时候才即时从文件中读取该Asset所在的chunk并解压到内存中。
由于LZ4是公认的解压速度极快的压缩方式，并且需要即时解压的数据量一般不会很大，因此实时解压Asset带来的CPU时间消耗其实很小，另一方面把解压时间分散在不同地方也减轻了一次性解压带来的卡顿问题。当然，最重要的优点还是在于大大减轻了内存的压力，可以放心地让有可能被再次索引的AssetBundle常驻在内存中，因此我们非常推荐大家使用LZ4压缩方式的AssetBundle。
不过大家在使用过LZ4压缩方式后应该也会发现，在资源数比较多的情况下，LZ4格式的AssetBundle大小基本都要比LZMA格式的大一些，这也是分块压缩不可避免的缺陷。但考虑到它的内存消耗表现优秀，移动端的开发朋友应该可以忽略这一点吧。
Resources文件夹里的资源越多，程序的启动画面时间就越长。这是为什么呢?
要理解这个问题，我们需要知道Unity程序启动时的一个操作。在启动加载的过程中，Unity需要为Resources文件夹(此时其实就是一个序列化文件)中的所有资源构建一个查找树作为后面加载具体Asset时所需的索引数据，而这个结构的构造时间是非线性的(比线性稍高一点)，因此在Resources文件夹中的文件越多，启动加载的时间就越明显，基本10000个资源在一些低端手机上需要5到10秒的加载时间。
另一方面，考虑到Resources文件夹无法动态更新，也没有AssetBundle Variant这种设定不同资源版本的功能，因此我们极力推荐大家主要采用AssetBundle进行资源的动态加载，而Resources文件夹的使用可以只考虑这几种情况：
这些资源在整个游戏的运行期间都会用到;
这些资源无需为不同平台或硬件适配定制资源;
这些资源无需动态更新;
正在制作游戏的原型。
程序中主要使用AssetBundle.Unload(false)卸载AssetBundle，有时会发现AssetBundle中的资源在内存中会存在多份，这是为什么呢?
这种问题产生的根源在于从AssetBundle中加载出来的资源，在该AssetBundle卸载之后与此AssetBundle的联系就断开了。举个例子，我从AssetBundle A 中加载出来一个Prefab p1, 那么p1本身依赖的资源，例如一个Texture tex1也会自动加载到内存中。然后我用AssetBundle.Unload(false)来卸载AssetBundle A，此时p1与AssetBundle A已断开关系。之后过了一段时间，我需要从AssetBundle A中加载另一个Prefab p2 ，假设p2也依赖于Texture tex1，那么我再次加载AssetBundle A，从中加载p2时tex1会再次被加载到内存中，导致此时内存中存在两份tex1。
这个AssetBundle的资源索引策略我们官方在之后的版本中会进行修改以避免这种情况产生的内存消耗。而现阶段大家其实只要注意AssetBundle的卸载时机即可避免此情况的发生，即在保证当前场景中同一AssetBundle不会再被引用的时候卸载或者统一都在场景切换的时候使用Unload(true)进行卸载。
柳振东Unity官方平台
将材质打包为AssetBundle，运行时使用LoadAsset加载材质也成功了，为什么还会出现材质丢失呢?
这也是开发者经常会遇到的问题。一般情况都是，开发者先把被依赖AssetBundle中的资源加载出来，然后用Unload卸载掉这个被依赖的AssetBundle，最后发现从其它AssetBundle中加载出来的GameObject丢失了前面加载出来的资源。
要弄明白这个问题，我们需要了解AssetBundle中的Asset在加载时寻找其依赖资源的规则。其实很简单，现在AssetBundle实现的机制是只会在内存中寻找其依赖资源所在的AssetBundle，并自动从中加载出所需的资源。
那么现在我们知道，其实通过LoadAsset从被依赖资源的AssetBundle中加载出来的资源，除非我们手动绑定回主体资源中(例如把加载出来的材质通过代码绑定回GameObject的Renderer中)，否则是不会被自动索引到的。
也就是说，通过AssetBundle来动态加载资源时，我们并不需要自己加载被依赖的资源，而是只要保证主体在加载时被依赖资源所在AssetBundle依然处于开启状态就可以正常加载资源了。
为什么游戏切换到后台一段时间后再切换回来材质会变成粉色呢?
大家都应该知道，粉色材质在Unity中是Shader出错或丢失时的默认警示材质，而在这种情况下就是Shader丢失的问题。
首先我们要了解一个系统对于GPU资源管理的机制。在PC平台上，用户在锁屏一段时间后GPU会自动把部分后台程序的资源清除掉，而Android或者iOS这种移动平台系统一般会在切换到主界面或其它程序一段时间后进行类似的操作。 那么当Unity程序在GPU中的Shader和Texture等资源被清除之后再切换回该程序时，CPU端会接收到GPU Graphics Context 丢失的消息，然后Unity会尝试从内存中将丢失的资源重新加载到GPU端。
这时，如果原来的Shader和Texture资源是从AssetBundle中加载出来的，并且该AssetBundle已经被卸载掉的话，那么Unity就无法再从内存中加载到这些资源，从而导致GPU丢失Shader与Texture了。
可能有朋友会说，这些Shader和Texture不是曾经被加载到内存中吗?是的，但是它们在被加载到GPU之后会被从内存中清除掉。因此要防止这种问题的发生最稳健的办法就是Shader和Texture的AssetBundle在场景切换前都不要卸载掉。而如果担心AssetBundle本身消耗内存问题的话可以参考下一个问题的解答。
新的ChunkBasedCompression压缩方式相比原来的压缩方式有什么区别呢，应该如何取舍呢?
Unity默认的AssetBundle压缩方式是LZMA，这种压缩方式的AssetBundle在加载到内存时会马上执行解压过程，并在AssetBundle处于开启状态期间在内存中保留一个解压过后的Cache(例外情况：UnityWebRequest.GetAssetBundle与WWW.LoadFromCacheOrDownload均会在第一次解压LZMA AssetBundle时把解压后版本Cache到文件系统中，后续的调用就无需在内存中保留解压后的AssetBundle了)，因此内存占用会比较明显。
而Unity5.3以后提供的ChunkBasedCompression是一种基于Chunk的LZ4压缩方式，这种压缩方式可以让AssetBundle对单独的Asset进行压缩，而不是AssetBundle整体压缩。因此加载这种压缩方式的AssetBundle时，无需事先解压，只需在内存中保留一个头结构，然后在加载某个Asset的时候才即时从文件中读取该Asset所在的chunk并解压到内存中。
由于LZ4是公认的解压速度极快的压缩方式，并且需要即时解压的数据量一般不会很大，因此实时解压Asset带来的CPU时间消耗其实很小，另一方面把解压时间分散在不同地方也减轻了一次性解压带来的卡顿问题。当然，最重要的优点还是在于大大减轻了内存的压力，可以放心地让有可能被再次索引的AssetBundle常驻在内存中，因此我们非常推荐大家使用LZ4压缩方式的AssetBundle。
不过大家在使用过LZ4压缩方式后应该也会发现，在资源数比较多的情况下，LZ4格式的AssetBundle大小基本都要比LZMA格式的大一些，这也是分块压缩不可避免的缺陷。但考虑到它的内存消耗表现优秀，移动端的开发朋友应该可以忽略这一点吧。
Resources文件夹里的资源越多，程序的启动画面时间就越长。这是为什么呢?
要理解这个问题，我们需要知道Unity程序启动时的一个操作。在启动加载的过程中，Unity需要为Resources文件夹(此时其实就是一个序列化文件)中的所有资源构建一个查找树作为后面加载具体Asset时所需的索引数据，而这个结构的构造时间是非线性的(比线性稍高一点)，因此在Resources文件夹中的文件越多，启动加载的时间就越明显，基本10000个资源在一些低端手机上需要5到10秒的加载时间。
另一方面，考虑到Resources文件夹无法动态更新，也没有AssetBundle Variant这种设定不同资源版本的功能，因此我们极力推荐大家主要采用AssetBundle进行资源的动态加载，而Resources文件夹的使用可以只考虑这几种情况：
这些资源在整个游戏的运行期间都会用到;
这些资源无需为不同平台或硬件适配定制资源;
这些资源无需动态更新;
正在制作游戏的原型。
程序中主要使用AssetBundle.Unload(false)卸载AssetBundle，有时会发现AssetBundle中的资源在内存中会存在多份，这是为什么呢?
这种问题产生的根源在于从AssetBundle中加载出来的资源，在该AssetBundle卸载之后与此AssetBundle的联系就断开了。举个例子，我从AssetBundle A 中加载出来一个Prefab p1, 那么p1本身依赖的资源，例如一个Texture tex1也会自动加载到内存中。然后我用AssetBundle.Unload(false)来卸载AssetBundle A，此时p1与AssetBundle A已断开关系。之后过了一段时间，我需要从AssetBundle A中加载另一个Prefab p2 ，假设p2也依赖于Texture tex1，那么我再次加载AssetBundle A，从中加载p2时tex1会再次被加载到内存中，导致此时内存中存在两份tex1。
这个AssetBundle的资源索引策略我们官方在之后的版本中会进行修改以避免这种情况产生的内存消耗。而现阶段大家其实只要注意AssetBundle的卸载时机即可避免此情况的发生，即在保证当前场景中同一AssetBundle不会再被引用的时候卸载或者统一都在场景切换的时候使用Unload(true)进行卸载。Unity5 如何做资源管理和增量更新
时间： 15:47:24
&&&& 阅读：262
&&&& 评论：
&&&& 收藏：0
标签：&&&&&&&&&工具
Unity 中的资源来源有三个途径：一个是Unity自动打包资源，一个是Resources，一个是AssetBundle。
Unity自动打包资源是指在Unity场景中直接使用到的资源会随着场景被自动打包到游戏中，这些资源会在场景加载的时候由unity自动加载。这些资源只要放置在Unity工程目录的Assets文件夹下即可，程序不需要关心他们的打包和加载，这也意味着这些资源都是静态加载的。但在实际的游戏开发中我们一般都是会动态创建GameObject，资源是动态加载的，因此这种资源其实不多。
Resources资源是指在Unity工程的Assets目录下面可以建一个Resources文件夹，在这个文件夹下面放置的所有资源，不论是否被场景用到，都会被打包到游戏中，并且可以通过Resources.Load方法动态加载。这是平时开发是常用的资源加载方式，但是缺点是资源都直接打包到游戏包中了，没法做增量更新。
AssetBundle资源是指我们可以通过编辑器脚本来将资源打包成多个独立的AssetBundle。这些AssetBundle和游戏包是分离的，可以通过WWW类来加载。AssetBundle的使用很灵活：可以用来做分包发布，例如大多数页游资源是随着游戏的过程增量下载的，或者有些手游资源过大，渠道要求发布的包限制在100M以内，那只能把一开始玩不到的内容做成增量包，等玩家玩到的时候通过网络下载。AssetBundle 也可以用来做我们下面讨论的自动增量更新。
Unity5相比之前的版本，AssetsBundle的打包过程有所简化。之前打包需要通过代码来设置需要打入包的资源并自己建立包的依赖关系，Unity5可以通过每个资源Inspector底部的AssetBundle下拉来指定该资源要打入哪个包，不指定就是不打包。打包过程只需要BuildPipeline.BuildAssetBundles一句话就行了，Unity5会根据依赖关系自动生成所有的包。每个包还会生成一个manifest文件，这个文件描述了包大小、crc验证、包之间的依赖关系等等，通过这个manifest打包工具在下次打包的时候可以判断哪些包中的资源有改变，只打包资源改变的包，加快了打包速度。manifest只是打包工具自己用的，发布包的时候并不需要。
关于自动生成依赖关系这个有必要提下，Unity确实会自动给你建立依赖关系，前提是你依赖的资源必须已经在Inspector中设置了BundleName。如果没有，Unity会把这个公用的资源重复打到多个用到的包中，因为这个公用资源不在一个独立的包中，Unity也不会智能地给你发现它是公用的，然后生成一个公用包。更深的坑在于，如果你公用的是一个FBX模型，你只给这个模型设置BundleName还不行，它用到的贴图，材质都要设，否则模型是公用了，贴图没有公用，结果贴图还是被打包到多个包中了。所以设置BundleName这个工作最好还是由编辑器脚本来完成。
Unity提供的就这些了，下面就自己发挥：如何做一个方便的资源管理方案，既可以开发时方便，又可以方便发布更新包呢？开发过程全用AssetsBundle是不合适的，因为开发中资源经常添加和更新，每次添加或者更新都生成一下AssetsBundle才能运行是很麻烦的。而且我们要做的是自动更新而不是分包下载，这也就是说在发布游戏的时候这些资源应该都是在游戏包中的，所以他们也不该从AssetsBundle加载。
分析完需求，方案也就出来了：资源还是放在Resources下面，但是这些资源同时也会打包到AssetBundle中。代码中所有加载资源的地方都通过自己的ResourceManager来加载，由ResourceMananger来决定是调用Resources.Load来加载资源还是从AssetsBundle加载。在开发环境下(Editor)这些资源显然是直接从Resources加载的，发布的完整安装包资源也是从Resources加载，只有当有一个增量版本时，游戏主程序才会去服务器把增量的AssetBundle下载下来，然后从AssetBundle加载资源。
实现中我们首先要考虑的是AssetBundle的粒度，即每个AssetBundle包含多少资源。增量包的最小粒度就是AsssetBundle， 如果单个AssetBundle过大，只要这个AssetBundle中有一个资源改变了就需要重新下载整个AssetBundle，浪费流量和玩家的等待时间；如果单个AssetBundle过小，极端情况是每个资源一个AssetBundle，虽然实现了更新最小化，但是带来了额外开销：AssetBundle本身也是有大小的，而且查找加载AssetBundle也是需要时间的。大家都往U盘里面拷过东西，拷一个1G的文件比拷1千个1M的文件要快很多。比较合理的做法是根据逻辑来，例如每个角色可以有独立的AssetBundle，公用的一些UI资源可以打到一个AssetBundle里面，每个场景独立的UI资源可以打成独立的AssetBundle。这样做资源预加载的时候也方便，每个场景需要用到几个Bundle就加载几个Bundle,无关的资源不会被加载。
下面要考虑的是如何来确定一个资源是从Resources加载还是AssetBundle加载。为此我们需要一个配置文件resourcesinfo。这个文件随打包过程自动生成。里面包含了资源版本号version，所有包的名字，每个包的HashCode以及每个包里面包含的资源的名字。HashCode直接可以从Unity生成的manifest中得到（AssetBundleManifest.GetAssetBundleHash），用来检查包的内容是否发生变化。这个resourceinfo每次打包AssetBundle时都会生成一个，发布增量时将它和新的Bundle一起全部复制到服务器上。同时在Resources文件夹下也存一份，随完整安装包发布，这就保证了新安装游戏的玩家手机上也有一份完整的资源配置文件，记录了这个完整包包含的资源。
当游戏启动时，首先请求服务器检查版本号，前端用的版本号就是Resources下面的这个resourcesinfo中的version。服务器比对这个版本号来告诉前端是否需要更新。如果需要更新，前端就去获取服务器端的新resourcesinfo，然后比对里面每个bundle的HashCode，把HashCode不同的bundle记录下来，然后通过WWW类来下载这些发生改变的bundle，当然如果服务器版的resourcesinfo中包含了本地resourceinfo中所没有的Bundle，这些Bundle就是新增的，也需要下载下来。所有下载完成后，前端将这个新的resourceinfo保存到本地存储中，后面前端的所有操作都将以这个resourceinfo为准而不再是Resources下面的resourceinfo了。Resources下的resourceinfo可以退出历史舞台了，除非一种情况：本地存储的resourceinfo被认为删除了。手机端玩家清理应用的数据就会造成下载的bundle以及resourceinfo被删除。没关系，这时候前端由于找不到外部的resourceinfo了，还会使用Resources下面的resourceinfo和服务器比对，把新的bundle重新下载下来。
现在从哪里加载资源就很明确了：ResourceMananger先读取resourcesinfo，知道了游戏中所有的Bundle和每个Bundle包含的资源，然后去外部存储查找这些Bundle是否存在，如果存在，就记录下这个Bundle的资源应该从外部的AssetBundle加载，如果不存在，就从内部的Resources加载。在开发过程（Editor）中，由于不存在外部存储的bundle，资源自然都是从Resources加载的，达到了我们开发方便的目的。这个过程隐含了一点：不是所有的资源都需要有BundleName而被打包到AssetBundle中，游戏内不需要后续更新的资源就不要设置BundleName，它们不会被打包更新，这样的资源ResourceManager在resourceinfo中是找不到的，直接去Resources文件夹下面读取就行了。
加载AssetBundle，我们直接使用WWW类而不用WWW.LoadFromCacheOrDownload, 因为我们的资源在游戏开始的时候已经下载到外部存储了，不要再Download也不要再Cache。注意WWW类加载是异步的，在游戏中我们需要同步加载资源的地方就要注意把资源预加载好存在ResourceManager中，不然等用的时候加载肯定要写异步代码了。大部分时候我们应该在一个场景初始化时就预加载好所有资源，用的时候直接从ResourceManager的缓存取就可以了。
资源加载卸载
最后简单说下资源的加载卸载，这个网上也有很多文章介绍。
从我理解来看Resources是一个缺省自动打包的特殊AssetBundle。无论从WWW还是AssetBundle.CreateFromFile创建AssetBundle其实是创建了一个文件内存镜像。这时候是没有Asset的。AssetBundle.LoadAsset 和Resource.Load才真正创建出了Asset，而Instaniate复制了这个Asset。注意这个复制有两种，学C++的都知道浅拷贝和深拷贝，这里的复制有的是正真的复制，有的是引用。为什么要这样呢？因为有些游戏资源是只读的，像贴图Texture，这么大而且只读，当然不需要再去完全复制一份。但像GameObject这种资源它的属性是可以通过脚本改变的，必须要复制一份。所以一个资源从AssetBundle到场景中被实例化，其实有3块内存被创建，这3快内存的释放是有不同方法的。
文件内存镜像是通过AssetBundle.Unload(false)来释放的。
Instaniate出来的Object内存通过Object.Destory来释放。
AssetBundle.Unload(true)不单会释放文件内存镜像，还会释放AssetBundle.Load创建的Assets。这个方法是不安全的，除非你能保证这些Assets没有Object在引用，否则就出问题了。
Resources.UnloadAsset和Resources.UnloadUnusedAssets可以用来释放Asset。
下面这个图很直观：
这是老Unity的图，Unity5已经把AssetBundle.Load 改成了AssetBundle.LoadAsset。这个改动让我们更明确了Load出来的是Asset这块内存区域。什么时候把Resource.Load也改了吧。
注意事项（坑）
Resources.Load方法传入的资源路径需是从Resources文件夹下一级开始的相对路径且不能包含扩展名；而AssetBundle.LoadAsset方法传入的资源名需是从Assets文件开始的全路径且要包含扩展名。路径不区分大小写，建议全用小写，因为AssetBundle.GetAllAssetNames方法返回的资源名都是小写的。
Unity5打包AssetBundle时会自动处理依赖关系，但是在运行时加载的时候却不会，程序需要自己处理，先加载依赖包。
AssetBundle.CreateFromFile不能加载压缩过的AssetBundle，所以我们只能用WWW来异步加载AssetBundle。
目前我用的Unity5.0.2f1的Resources.Load方法在手机端比原来慢了很多，如果以前可以不缓存每次用的时候都调用Resource.Load现在就不行了。频繁的调用会导致明显的性能开销，不知道是不是Bug。
标签：&&&&&&&&&原文：http://blog.csdn.net/ring0hx/article/details/
教程昨日排行
&&国之画&&&& &&&&&&
&& &&&&&&&&&&&&&&
鲁ICP备号-4
打开技术之扣，分享程序人生！