标签:android http 使用 os io 文件 问题 算法
Unity3D动态下载资源,有没有解?有,AssetBundle就是通用解,任何一本书都会花大幅篇章来介绍AssetBundle.
我们试全面的分析一下Unity3D提供的资源加载机制
1.Resources//内嵌资源,使用方法Resources.Load,可以加载任意种类的资源,不能动态修改,卒。
2.StreamingAssets//随包资源,使用方法IO或WWW.Load。WWW.Load可以加载任意种类资源,IO仅限bytes 和 text。
3.WWW 从网络下载并加载
4.WWW 从网络加载AssetBundle
一和二显然不具有热更新的效果,这里就不做讨论。
3 4都是从网络加载,他们有什么区别呢。
首先说3,这是没有缓存的,我们显然不想让用户重复的浪费流量,不可取。
然后是4,assetBundle提供了一个版本号来做缓存比对,可以比较好的起到更新的目标
assetBundle原来就是Unity3D为我们准备的解决方案,难怪每本书都会大篇介绍AssetBundle,后文简称AB。
每本书都告诉你,AB很强大,AB帮你解决了跨平台问题,帮你解决了依赖关系。
而这个系列,不打算只讲别人讲的东西,我们要告诉你一些小秘密。
首先AB的确很好很强大,他能收纳Unity自己的所有资源种类,贴图、材质、shader、预设。
然后可以每平台支持,这就是第一个陷阱,注意是每平台支持,不是多平台支持。
每个平台要单独导出,而每个平台到底差了些什么呢?答案是,nothing。
那么为什么每个平台要单独导出呢?因为Unity考虑到每个平台的质量关系,进行了质量相关的差异化。
而最大的质量差异,源自贴图。
有些平台贴图不压缩,有些平台贴图要压缩,而且根据不同的平台特性,套用不同的压缩算法,先压过再存到包里。
这就是AB帮你干的最主要的事情。
听起来很贴心呢,等等,你是不是忘了一个特定的命题,这个命题叫做UI。
压缩的图片会有质量损失,UI贴图我们通常是不压缩的。
然后UI还会触及到AB的另一个问题
以NGUI为例,NGUI的资源关系比较复杂,有贴图-》图集-》布局
不同布局经常交叉引用贴图
如果用AB想把每个界面分开打包,给用户最小的资源更新量,这个任务可以用灾难来形容。
最终热更新推送给用户的东西是以文件为单位的,而AB在小粒度文件并且之间有较为复杂的引用关系这种需求下的使用是一场灾难。
AB对每个平台的差异编译不是可选的,而是强制的,假如你有web、ios、android三个平台,无论如何你都要导出三次。
把碎片文件下载回来,并且组装
对于UI这个情境,是完全可行的。把布局和图集保存为文本形式,把文本和贴图下载回来,然后组装。
对于其他的场景片段,在有动画和贴图需要压缩的情况下,AB依然是唯一选择。
unity没有提供在运行时压缩贴图的手段,动画也不容易存取,只能在运行时压缩DXT,只有pc和wp8支持。
对于各种各样的资源加载会特别的凌乱么?不会。
其实本质上可以统一成Bytes的处理
Texture可以从Bytes加载
字符串 可以从Bytes加载
AB可以从Bytes加载
自定义二进制存储,嘛本身就是bytes
所以只要我们的下载系统提供下载bytes并缓存,之后所有的资源加载都从Bytes进行,就可以统一起来。
下载部分我们在另一个专题介绍。
下一篇介绍将UI布局保存到文件与恢复。
Unity3d热更新全书-资源加载(一)从AssetBundle说起,布布扣,bubuko.com
Unity3d热更新全书-资源加载(一)从AssetBundle说起
标签:android http 使用 os io 文件 问题 算法
原文地址:http://www.cnblogs.com/crazylights/p/3896099.html