Addressables

之前大致的了解了Addressalbe这个插件的大致功能和原理，并没有深入的使用。刚好这段时间有时间，就按照具体的项目场景搭建了一个简单的框架来体验。我是用它跟XLua来搭建整个游戏的框架的。Addressables的版本是1.22.3。我的体验也是围绕这个版本来讲的。使用的过程中发现它的下面几个问题，让我觉得目前还是不要在项目中使用它。 1.性能问题 通过标签一次性加载大量粒度很细的文件，会非常的慢。 Adressables可以通过lable标签来加载同一类型的资源。比如在项目中，把所有类型的lua文件都打上 <Lua> 标签。你可以选择 Addressables.LoadResourceLocationsAsync 先获取所有打了该标签的文件地址，然后再用一个循环去加载每一个地址的lua文件，然后把文件按照Key-Value的方式存在一个字典中。也可使用 Addressables.LoadAssetsAsync<Type>("key"), (asset)=>{} 方式按照标签加载所有的资源，然后在它里面的回调中去处理每一个lua文件，并保存到字典。这个回调每加载一个该标签下的文件，都会回调一次。 很显然，这个加载循环无法避免。由于lua文件的数量巨大，导致这个循环完成非常的耗时，比如在这次测试的项目中，总共有接近400个lua文件，总耗时在webgl平台达到惊人的 5.89 秒，并且随着功能的增多，这个数量只会往上加。这是很难接受的。android和IOS我没有测试，不过由于多线程的加持，估计是会比较快的。我们的主要平台是webgl. 2.工具黑盒 这个插件并不是开源的，对于用户来说，资源的下载，打包过程都是不受用户控制的。也就是说，它对用户来说是一个黑盒。他在官网有用户手册和API说明，但也就仅仅是那些而已。我甚至觉得这个东西不是为游戏开发者准备的，更像是一个功能说明。它的加载API少的非常的可怜，估计也就3个左右吧，不知道是不是我看的不够仔细，我真的没有再发现别的加载API了。而且API设计的很模糊，太多的功能细节集中到一个API上了，然后例子又少。虽然GitHub上有官方的示例，但我真的还是第一次见到如此模糊的API设计，我真的无法通过参数去了解该API到底能做什么事情。 用户没有办法了解其中具体的细节，也没有办法去定制项目需要的功能，万一有一些东西满足不了项目的需求需要修改，就只能干着急，你做不了任何事情。它的封装级别很高，但是对于游戏开发者来说，这过头了。这个插件更像是面向产品用来设计快速原型的产物。就拿上面的第一个问题来说，所有的lua其实已经打在一个AB包里面了，那么AB包下载之后，再从AB包中去加载lua文件，应该是非常的快的（毫秒级别），但不知道为什么，400多个文件加载居然要5.89秒，它里面是不是每一个文件加载都去走了什么特殊流程导致非常的慢。然后勾选了缓存，第二次，第三次，第四次的时间也是一样的，居然没有任何的时间减少。用户知道的太少了。 3.各种的小问题 我这里例举一个下载进度的问题。 public IEnumerator LoadAssetAsyn(string key, Action<Object> completeCB, Action<float> pgrFunc = null) { AsyncOperationHandle<Object> opHandle; opHandle = Addressables.LoadAssetAsync<Object>(key); while (opHandle.Status == AsyncOperationStatus.None) { Log.Error("Percent=" + opHandle.GetDownloadStatus().Percent + " pp=" + opHandle.PercentComplete); if (pgrFunc != null) { pgrFunc(opHandle.GetDownloadStatus().Percent); } yield return null; } yield return opHandle; if (opHandle.Status == AsyncOperationStatus.Succeeded) { Object instObj = Object.Instantiate(opHandle.Result); completeCB(instObj); if (pgrFunc != null) { pgrFunc(1); } } yield return null; } 上面的这个方法去加载一个资源，然后通过回调告诉目前的下载进度。opHandle.GetDownloadStatus().Percent 和 opHandle.PercentComplete 都不准确。前者是通过大小计算百分比，后者是通过数量计算百分比。 下面是文档的原话： AsyncOperationHandle.PercentComplete: Reports the percentage of sub-operations that have finished. For example, if an operation uses six sub-operations to perform its task, the PercentComplete indicates the entire operation is 50% complete when three of those operations have finished (it doesn’t matter how much data each operation loads). AsyncOperationHandle.GetDownloadStatus: Returns a DownloadStatus struct that reports the percentage in terms of total download size. For example, if an operation has six sub-operations, but the first operation represented 50% of the total download size, then GetDownloadStatus indicates the operation is 50% complete when the first operation finishes. ...

1.构建Player的时候，项目的资产数据是如何放进Player中的 由下图可以看出来Unity中的资产分成了4个主要类别： 1.被场景引用的资源 2.放在Resources文件夹中的资源 3.标记为了Addressables Group的资源 4.放在了StreamingAssets文件夹中的资源 2.如果同一个资产被划分到了不止一个类别上，那么该资产在构建的时候就会产生重复，划分了多少个就会复制多少个 3.Addressables Groups中的共享资产 对于一个标记为非Adressables的资产，如果有不止一个Adressablees的资产引用了它，那么它会在每个引用了它的Addressables的bundle中都复制一份。如下图所示： 为了消除这种复制，那么可以将这个共有的资产也标记为Addressables。然后把它引入到一个已存在的bundle中就可以了。如果此时一个bundle要引用它，那么必须在该bundle实例化前，将引入了共有资产的bundle先加载才可以。 4.Sprite的依赖 图集的引用跟其他资产不一样。 情形一 三张纹理，分别在三个不同的group中，它们会分别进入三个不同的ab包，彼此之间没有依赖，每个ab中图片的大小是500KB 情形二 还是这三张图片，它们被放进了一个图集，这个图集没有被标记为Addressables。那么包含这个图集的ab包将有图集的1500KB的大小。而另外两个ab包则只包含Sprite的元数据（只有很小的几KB），并且将包含图集的ab包列为自己的依赖。无论是哪个ab包包含这个图集，在重新构建之后都是跟前面一样的结果，这个过程由Unity控制，用户决定不了。这是跟标准的处理依赖重复资源过程的最大不同。Sprites的加载依赖它的图集，而图集的加载只依赖包含它的ab包的加载。 情形三 在上面的情形二的基础上，图集被标记成了Addressables并且单独放在它自己的图集中。这时候就会创建4个ab包。如果使用的是Unity2020.x或者更新的版本，那么在构建之后，4个ab包之间的依赖关系会和期待的一样，即图集资源在图集的这个ab包，有1500KB。另外三个ab包把图集的ab包作为依赖，只有几KB的引用数据而已。如果使用的是Unity2019.x或者更旧的版本，那么纹理资源就可能存在于这4个ab包中的某一个。另外三个ab包依然把图集所在的ab包作为依赖。然而此时图集所在的ab包可能仅仅只包含了图集的一些元数据，而真正的纹理资源可能在其他的另外3个ab包中。 5.Addressable预制体跟Sprite的依赖 情形一 跟三个标记为Addressables的纹理不同的是，这里是三个标记为Addressables的Sprite的预制体。每个预制体包含它独自的Sprite。在构建之后，三个ab包的大小如期望的那样，都是500KB。 情形二 跟情形一类似，3个预制体分别引用不同的Sprite，只不过所有的3个Sprite添加到一个图集中，但是这个图集没有标记为Addressables。在这种情形下，图集的纹理机会产生重复。在构建之后，三个ab包都大概有1500KB。这个重复资源的规则类似于一般的Addressables重复资源规则，但是跟前面介绍的 Sprite的依赖 中的情形二又不一样。 情形三 基于上面的情形二的预制体，纹理和图集，不过这里把图集标记为Addressables。此时图集纹理就仅仅只存在在包含图集的ab包中。另外的三个预制体的ab包就把这个图集的ab包作为依赖。 6.ab包的分包规则 1.可以将一个group中所有Addressables的资源都打进一个ab包中 2.可以将一个group中的每个Addressables资源分别打进它独自的ab包中 3.可以将使用同一个label的所有的Addressables资源打包进一个ab包中 7.同一个group中的场景资源会跟其他的Addressables资源分开打包 也就是说一个group中如果含有场景资源和其他非场景资源，那么构建之后，至少会得到两个bundle，一个包含场景资源，一个是除了场景外的其他资源。