赞
踩
https://gameinstitute.qq.com/community/detail/128107
一、关于Bundle加载速度图示:
二、设计方案:
有两种方案可供选择:
第一种是用完全bundle的管理方式,以每个文件夹作为独立的bundle,项目管理过程中需要注意分包处理、在加载Object和场景之前先加载其相关依赖的bundle,场景切换前卸载上个场景不需要的bundle。然后在加载和卸载的过程自己去给每个文件单独计算引用计数。最后提供当某些资源不用之后,可以卸载其缓存资源和bundle。特点是原生的bundle加载方式便于理解和管理,但是引用计数(不一定和Unity的计数完全一致)存在隐患。
第二种方式,是用自定义文件格式去处理,打包bundle的时候,把每一个资源单独打包成bundle,然后再根据自定义把所有bundle打成一个或多个Page包,然后通过id length offset去读取每个bundle文件的内容。在加载的时候可以用多线程去读取资源,然后在主线程创建bundle和资源。特点:复杂度稍微高一点,bundle分的很散便于引用计数的计算和内存管理,但同时过散的资源也可能导致速度问题。另外后台多线程会提高文件的读取速度,但同时增加缓存读取和内存创建bundle 可能带来额外的内存开销。
三、其他:
LZMA:Unity打包成AssetBundle时的默认格式。优点是打包后体积小,缺点是解包时间长导致加载时间长。
LZ4:相较LZMA会生成更大的压缩文件,但优点是使用时不需要整体解压
BuildAssetBundleOptions.None|默认LZMA方式压缩
BuildAssetBundleOptions.UncompressedAssetBundle |不压缩资源,最后可以使用自己的压缩方式
BuildAssetBundleOptions.CollectDependencies | Unity5.3不用了
BuildAssetBundleOptions.CompleteAssets |Unity5.3不用了
BuildAssetBundleOptions.DisableWriteTypeTree | 不能无视TypeTree的改变,如果TypeTree发生了改变
BuildAssetBundleOptions.DeterministicAssetBundle |编译资源包使用一个哈希表储存对象ID在资源包中。
BuildAssetBundleOptions.ForceRebuildAssetBundle | 强制重现生成bundle,即使bundle没有改变。
BuildAssetBundleOptions.IgnoreTypeTreeChanges | 可以无视TypeTree的改变,即使TypeTree发生了改变
BuildAssetBundleOptions.AppendHashToAssetBundleName |把Hash导在bundle的名字中
BuildAssetBundleOptions.ChunkBasedCompression |用Lz4的方式进行压缩
BuildAssetBundleOptions.StrictMode |严格模式,有任何错误产生 马上终止打包。
BuildAssetBundles的AssetBundleBuild[]参数和面板上的AssetImporter参数差不多 , 都是提前设好bundle名字和Variant名字。
内存来说loadbundle比loadAsset远小
设置相同assetBundleName的打包到同一个bundle资源里边。设置相同的assetBundleName和assetBundleVariant打包到同一个assetBundleName.assetBundleVariant资源里边。
设置相同assetBundleName和不同assetBundleVariant的 会被认为是同一个bundle 不能重复加载(只能先卸载) 他们之间不能有依赖关系,但是bundle文件分开是多个。常用来做不同精度的模型或者贴图分开显示。
依赖关系只跟assetBundleName有关。可以只使用assetBundleName进行bundle分包,只有把prefab material texture shader等全部分开打成bundle才能不会资源重复,否则一个bundle会将所有依赖的资源打在一个包里。
注意IOS文件限制和每个bundle包的大小,不能太大。
加载策略:
采用多种策略加载:慢速加载:纯异步:load bundle和loadAsset都异步,Resource异步加载
快速加载:半异步:load bundle同步和loadAsset异步,Resource同步步加载
正常情况,快速加载比较快,但是大资源Resource内文件异步比同步速度快,小资源相反。(说明异步加载确实是多线程了)
缓存策略:
bundle模式有三种文件缓存,分别是:
bundle文件:可以理解为文件系统的原始二进制数据,加载速度很快内存消耗比较小。缓存在bundleManger
Asset文件:经过二进制文件创建出来的资源文件,包括声音图形mesh等缓存文件,加载速度根据创建对应资源的类型不同会慢一点。缓存在ResourceMgr
场景文件:实例化的场景文件及其引用,缓存在游戏中
卸载特点:
1.bundle的加载几乎没什么消耗只是部分依赖数据的加载。所以内存优化重点是ResourceDB
2.bundle.unload(false)只卸载bundle会导致缓存资源冗余,bundle.unload(true)会完全卸载 但是如果场景中还有引用,资源会丢失。
3.GetAllDependencies 会把该bundle内全部资源的全部依赖的bundle加载进来,如果bundle划分不是很细的话会加载冗余数据,依赖关系最好自己维护。
4.bunlde中缓存资源一旦加载,若其依赖的资源被卸载后再加载 该资源依赖丢失不可用,若只是本身bundle卸载再创建,可用重复加载资源,因为每个资源的依赖资源是存在本身身上的。
5.Unity正常切换场景会把下个场景没有引用的资源卸载掉,引用包括bundle引用,ResourceDB引用,场景不卸载的OBJ引用。
6.我们的逻辑切换场景的时候会把下个场景不用的所有资源和bundle卸载掉,但是对于下个场景要用的bundle但是其中的某个资源已经不用了,无法卸载(就算场景和ResourceDB引用置空也无法卸载),这种时候建议分成不同bundle。
卸载策略:
1.场景文件加载后其和依赖的bundle不能卸载,否则容易内存冗余和出错。直到再次切换场景把上一个场景中的所有存在bundle根据条件给卸载掉。
2.对于全局存在不被依赖的Prefab,可以加载后存在场景中设置DontDestroy,然后把ResourceDB置空,把该prefab的bundle.unload(true)卸载该prefab。这样内存最优,但是不能卸载其依赖的bundle,然后要保证其他地方不会再load该资源。
3.主要优化是卸载ResourceMgr的数据 ?而不是bundle,bundle的内存占用很小。采样unload(true)策略。
4.场景加载后的场景bundle和其依赖bundle一定不能unload(false),单纯卸载bundle的意义不大,最好是直接操作unload(true),但是要管理好资源,容易出错。
5.相同多的Object,放在场景里加载比单独加载Prefab快。
6. Resources.UnloadAsset(mat);这个只能卸载Texture等资源,prefab等实例资源 只能Destroy(obj),缓存Obj资源无法手动卸载,只能把引用置空切换场景和bundle.unload(true)卸载掉,然后Unity就会自动释放。
7.建立一张单个资源的依赖和被依赖资源
8.要么unload(true),要么所有bundle都不要卸载。想卸载资源就要解决依赖问题。unload(false)比不卸载更可怕。
优化策略:
1.对于特定资源比如主角职业相关的技能技能特效装备等,在整个游戏过程中会反复加载的,那么在高内存机器上设置不卸载,bundle和ResourceDB都不卸载。预加载并且不卸载。
2.对于全局UI和全局主角,加载后,把其Object的bundle和ResourceDB给卸载掉,然后GameObjec设置DontDestroy永远存在,其依赖的资源不能处理。
3.设置bundle的不卸载会导致该bundle所有资源和所有依赖的资源都不卸载,如果把其依赖给卸载了,就算再加载 该bundle的依赖也是丢失的,只能把该bundle再卸载了重新加载。?
4.不卸载的优化只能从美术规范上去规避,只能单独的少量资源设置不卸载。要保证bundle内全部资源都是可以不卸载的。
5.设计通用UI管理器,跟EffectPool方式一样去管理。
依赖测试:
1.prefab依赖测试:
2.场景和prefab的依赖
……So……bundle的增量打包一定要定期清理bundle,全部删除重新打。
3.场景和普通资源的依赖
结论就是:不能采用prefab依赖的方式打包,一定要采用细分原则,把所有用到的资源都标记独立打包。
参考:我们以前游戏是使用美元符号$来标记,该资源或者该文件夹内资源独立打包成一个bundle。另外要定期清理所有bundle。
来自:https://blog.csdn.net/gy373499700/article/details/79508842
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。