一种资源处理方法及装置

技术领域

本发明涉及数据处理技术领域，特别涉及一种资源处理方法及装置。

背景技术

随着媒体互联网的迅速发展，数字互动延伸到许多新的领域，例如，VR技术现如今已不仅仅局限于游戏，在建筑、汽车、医疗等领域都得到了迅速发展。

Unity是实时数字互动内容创作和运营平台，AssetBundle是Unity推崇的资源更新方案，具体地，是一种用来存储资源的文件格式，它可以存储任意一种Unity引擎能够识别的资源，比如Scene、Mesh、Material、Texture、Audio、noxss等等，同时，AssetBundle也可以包含开发者自定义的二进制文件，只需要将自定义文件的拓展名改为.bytes，Unity就可以把它识别为TextAsset，进而就可以被打包到AssetBundle中。Unity引擎所能识别的资源我们称之为Asset，可见，AssetBundle是Asset的一个集合。

基于AssetBundle上述良好的性能，游戏、医疗、建筑、汽车等领域的很多公司都会采用AssetBundle进行打包。一般当需要打包的AssetBundle的资源不多时，可以通过AssetLabels窗口手动命名，然后再打包，但是当需要打包的资源过多时，一个个去手动编辑很麻烦，并且有可能在设置AssetBundleName时忽略了资源之间的依赖关系，导致在打包AssetBundle时依然会产生重复打包的资源。

发明内容

本发明的目的在于提供一种资源处理方法及装置，以解决上述技术问题。

为达此目的，本发明提供一种资源处理方法，其改进之处在于，包括：

获取资源；

确定资源间的依赖关系；

根据资源间的依赖关系，对资源进行分类处理。

为达此目的，本发明还提供一种资源处理装置，其改进之处在于，包括：

获取模块，用于获取资源；

确定模块，用于确定资源间的依赖关系；

处理模块，用于根据资源间的依赖关系，对资源进行分类处理。

本发明通过分析资源之间的依赖关系，并根据资源的依赖关系来设置资源的AssetBundleName，从而能够避免资源重复打包，大大提高了工作效率和质量。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一实施例提供的资源处理方法的流程图；

图2是本发明一实施例提供的资源信息具备的属性图；

图3是本发明一实施例提供的资源依赖关系图；

图4是本发明一实施例提供的资源加载和卸载流程图；

图5是本发明一实施例提供的资源信息功能集图；

图6是本发明一实施例提供的加载管理的功能集图；

图7是本发明一实施例提的资源处理装置的结构示意图。

具体实施方式

下面结合附图并通过具体实施方式来进一步说明本发明的技术方案。

其中，附图仅用于示例性说明，表示的仅是示意图，而非实物图，不能理解为对本专利的限制；为了更好地说明本发明的实施例，附图某些部件会有省略、放大或缩小，并不代表实际产品的尺寸；对本领域技术人员来说，附图中某些公知结构及其说明可能省略是可以理解的。

本发明一实施例提供的资源处理方法，如图1所示，包括：

获取资源；

确定资源间的依赖关系；

根据资源间的依赖关系，对资源进行分类处理。

其中，如图2所示，获取资源中的资源信息具备的属性有不重复的父节点资源、不重复的子节点资源、资源的路径，且父节点资源和子节点资源都采用HashSet存储，由于HashSet只能存储不重复的对象，基于此，能够避免重复将资源添加到资源集中而导致重复资源打包的问题。

在一些实施例中，确定资源间的依赖关系，包括：

一个资源可能被其它资源引用一次，也可能被其它资源引用多次，而通过资源间的引用关系，可以构建出资源之间的依赖树，而通过资源之间的依赖树既能直观了解某个资源被多少颗树引用，又能体现出资源间的依赖关系；

据此，本发明实施例设置的方案为：

通过资源深度遍历算法，遍历资源，获取资源间的引用关系数据；

根据引用关系数据，确定资源间的依赖关系。

在一些实施例中，根据资源间的依赖关系，对资源进行分类处理，包括：

根据资源间的依赖关系，对目标资源进行分类打包，具体包括：

当目标资源被引用次数为1时，将目标资源的AssetBundleName置空不设置，并将引用目标资源的资源和目标资源合并打包成一个AssetBundle，以减少打包碎片；

当目标资源被引用次数为2次以上时，将目标资源独立设置AssetBundleName，从而避免被重复打包到几个依赖它的资源包内；

为便于理解，结合图3进行举例说明：

目标资源A被其他地方资源B引用仅1次，那么就将目标资源A的AssetBundleName置空不设置，如此打包，此目标资源A就会自动和资源B打包到一起合成一个AssetBundle，显然，能够减少打包碎片；

假设目标资源A被引用超过2次以上，那么就为目标资源A独立设置AssetBundleName，从而避免目标资源A被重复打包到几个依赖它的资源包；

需要说明的是，上述代码中的主要功能函数都设置成编辑器脚本形式，其操作在编辑器的指定路径下点击，会生成对应的接口，选择Asset中的资源，然后在菜单栏中SetAssetBundleName之后，资源就都会被正确设置AssetBundleName，依此，将整个项目的资源标记好后，即可实现自动化一键打包。

另外，将工程中的资源转化为Prefab后，再打包成AssetBundle，可以大幅降低资源的空间占有度，并且提高资源加载的效率。

在一些实施例中，确定资源间的依赖关系，包括：

通过归类首界面的资源、首界面和各子场景的共享资源、各子场景的资源，确定资源间的依赖关系，其中，可以将同一子场景的资源设置相同的标识，以便后续进行处理，例如，以便打包脚本分辨，在打包时，一起打入一个包中，以备软件中的加载。

在一些实施例中，根据资源间的依赖关系，对资源进行分类处理，包括：

根据不同的软件进程，对首界面的资源、首界面和各子场景的共享资源、各子场景的资源，进行实时的分块加载和卸载，以避免资源重复打包和降低内存负荷。

为便于理解，结合图4进行举例说明：

在进入软件时，将首界面的资源，以及首界面和各子场景的共享资源加载到内存中；

当从首界面进入子场景1时，内存区将首界面的资源卸载，保存首界面和子场景的共享资源，然后再加载子场景1的资源以及各子场景的共享资源，同理，在进入每一个子场景时，内存区都会将首界面的资源卸载，保存首界面和子场景的共享资源，然后再加载该子场景的资源以及各子场景的共享资源；

当返回首界面时，依旧会保留首界面和子场景的共享资源，然后卸载当前场景的资源以及各子场景的共享资源，然后加载首界面的资源。

显然，通过以上方案，将包中的资源合理的进行分块加载和卸载，减少了资源包加载的负荷。

在一些实施例中，获取资源，具体为，获取Asset路径下的对象，更具体为，采用访问资源和对资源执行操作的接口，获取Asset路径上的主要资源对象。

在一些实施例中，确定资源间的依赖关系，包括：

分析构建资源依赖树，具体为：

在分析时进行判断，当该资源信息是自己本身或者该资源信息是空值，或者此父节点已为其他节点的父节点时，不对其进行资源依赖树的构建；否则就将其添加到父节点资源集中，将自己本身作为该资源信息的子节点，同时，清除自己本身的父节点对自己子节点的重复引用和子节点对父节点的重复引用，以保证树形结构；

判断父节点中是否有该资源信息，具体为：进行一个bool值的计算，当父节点资源集中有需判断的资源信息时，会得到一个true值，反之，则相反。

在一些实施例中，根据资源间的依赖关系，对资源进行分类处理，包括：

根据资源间的依赖关系，对资源进行分类打包，其中，打包的碎片粒度包括：

对UGUI图集进行处理，以文件为单位打AssetBundle包，其中，AssetBundle的包名和Sprite的标签保持一致；

资源不是图集而且父节点资源集的数量要大于阀值(阀值：使用时自定义大小的数值)，设置这些资源包的名称；

此资源是根节点，设置根资源的AssetBundle的包名；

其余的子资源，因为只有一个引用，所以，清除AssetBundle包名。

以上可以设置为资源信息的功能集，如图5所示。

在一些实施例中，获取资源，其中，资源信息集具备有资源信息的不重复的父节点资源、不重复的子节点资源、资源的路径属性和资源信息功能集；

设置AssetBundleName，具体为，

在设置AssetBundle的包名时，先判断是否有选择文件夹，如果当前的操作中并未选中文件夹，则提醒操作者选择目标文件夹，如果已经选择好文件夹，就开始获取所有的资源；

清除AssetBundleName，具体为，

先从资源中获取所有的AssetBundleName，然后将这些AssetBundleName逐一删除；

获取所有资源，具体为，首先清空资源信息集，然后逐步分析Asset文件夹下的资源的依赖关系，当该资源是文件夹下的根资源时，对其进行标记；接着卸载掉未使用的资源；最后，设置AssetBundleName，再次卸载未使用的资源，并将所有未保存的资源更改写入磁盘。

在一些实施例中，确定资源间的依赖关系，包括：

递归分析每个被依赖到的资源，具体为：

父节点中有此资源信息时，将跳过此分析操作；在资源信息中找不到自己的资源路径时，把自己和自己的资源路径添加到资源信息集中，然后给自己分析资源依赖关系；接着计算Asset目录中列出的资源所依赖的所有资源的列表，此列表中的资源五花八门，对其归类分析：

列表对象是脚本资源或者是场景中使用的实时灯光资源、资源信息的路径已经在所依赖的资源中、该对象的资源路径时Asset文件夹下的时，将跳过再次递归分析被依赖到的资源的步骤；当资源信息集中有此资源时，就拿此资源信息进行递归分析被依赖到的资源，当资源信息集中没有此资源时，将此资源添加到资源信息集中，并对此资源信息进行递归分析被依赖到的资源。

在一些实施例中，根据资源间的依赖关系，对资源进行分类处理，包括：

获取选择的资源的路径，具体为：

先获取编辑器中所访内容的激活的对象，即实际选择的对象，其中包括预制体和不可修改的对象，虽然此处进行了一次获取，但是还是再进行了一次有没有选择对象的判断，当没有选择对象时，当然获取到的资源的路径也是空地址；如果有选择的对象时没有特定类型的资源，就是我们俗称的默认资源，就会得到该资源的路径；选择的对象是其他类型的资源时，就和未选择一样，得到空地址。

以上可以设置为加载管理的功能集，如图6所示。

基于同样的发明构思，本发明实施例还提供一种资源处理装置，如图7所示，包括：

获取模块1，用于获取资源；

确定模块2，用于确定资源间的依赖关系；

处理模块3，用于根据资源间的依赖关系，对资源进行分类处理。

在一些实施例中，确定模块2包括：

遍历模块，用于通过资源深度遍历算法，遍历资源，获取资源间的引用关系数据；

执行模块，用于根据引用关系数据，确定资源间的依赖关系。

在一些实施例中，处理模块3包括：

第一打包模块，用于当目标资源被引用次数为1时，将目标资源的AssetBundleName置空，并将引用目标资源的资源和目标资源合并打包成一个AssetBundle；

第二打包模块，用于当目标资源被引用次数为2次以上时，将目标资源独立设置AssetBundleName。

需要声明的是，上述具体实施方式仅仅为本发明的较佳实施例及所运用技术原理。本领域技术人员应该明白，还可以对本发明做各种修改、等同替换、变化等等。但是，这些变换只要未背离本发明的精神，都应在本发明的保护范围之内。另外，本申请说明书和权利要求书所使用的一些术语并不是限制，仅仅是为了便于描述。