CN110152299A - 一种游戏资源的构建方法和装置 - Google Patents

Abstract

本申请实施例公开了一种游戏资源的构建方法和装置，在需要对游戏的包外资源进行打包时，获取游戏对应的游戏资源，根据依赖关系，从该游戏对应的游戏资源中读取出具有该依赖关系的游戏资源。基于依赖关系将读取的游戏资源分为至少两级资源，例如第一级资源和第二级资源，第一级资源对第二级资源具有依赖关系。在打包时，根据依赖关系确定出第一级资源所对应第一资源文件对第二级资源所对应第二资源文件的文件依赖关系，根据文件依赖关系准确调用公用的游戏资源对应的资源文件，使得不同级资源不会被打包到一起成为可能，避免了公用的游戏资源例如第二级资源被重复打包的情况，降低了打包后资源文件中资源冗余的程度，提高了存储资源的利用率。

Description

一种游戏资源的构建方法和装置

技术领域

本申请涉及数据处理领域，特别是涉及一种游戏资源的构建方法和装置。

背景技术

在运行游戏时，需要调用当前游戏所需的游戏资源，这里提到的游戏资源可以是游戏中的角色模型、贴图、动作、技能、音效等。由于游戏中所需使用的游戏资源数据量很大，故一部分游戏资源保存在安装游戏的设备本地存储空间，这部分游戏资源可以称为包外资源。在运行游戏时，可以调用设备本地保存的包外资源，但是需要使用符合调用要求的内部格式，即需要将包外资源打包成符合内部格式的资源文件后才能进行调用。

包外资源中具有较大比例的用于公用的游戏资源，即当调用某个或某些游戏资源时，这个或这些游戏资源的正常加载运行依赖于公用的游戏资源。例如游戏资源中包括游戏人物A和游戏人物B，这两个游戏人物都可以做出动作C，故当调用游戏人物A和游戏人物B时，还需要调用动作C的游戏资源，故动作C的游戏资源可以视为公用的游戏资源。故在一种传统的游戏资源构建方式中，针对任一游戏资源，会将该游戏资源与其依赖的公用的游戏资源放在一起打包成为资源文件，这种完整性打包可以便于调用游戏资源。

由于不同的游戏资源可能会依赖同一个公用的游戏资源，故导致同一个公用的游戏资源可能存在于不同的资源文件中，使得大量资源文件中出现资源冗余，在游戏资源较多的游戏中尤其严重，造成了存储资源的浪费。

发明内容

为了解决上述技术问题，本申请提供了一种游戏资源的构建方法和装置，可以将第一级资源和第二级资源分开打包，避免了公用的游戏资源例如第二级资源被重复打包的情况，降低了打包后资源文件中资源冗余的程度，提高了存储资源的利用率。

本申请实施例公开了如下技术方案：

第一方面，本申请实施例提供一种游戏资源的构建方法，所述方法包括：

获取游戏对应的游戏资源；

从所述游戏对应的游戏资源中读取出具有依赖关系的游戏资源，并根据读取出的游戏资源确定出第一级资源和第二级资源；其中，所述依赖关系是根据所述游戏确定的，所述第一级资源对所述第二级资源具有依赖关系；

对从所述第一级资源中确定出的第一级打包对象进行打包，得到所述第一级资源对应的第一资源文件；以及对从所述第二级资源中确定出的第二级打包对象进行打包，得到所述第二级资源对应的第二资源文件；

根据所述第一级打包对象对所述第二级打包对象的依赖关系，确定所述第一资源文件对所述第二资源文件的文件依赖关系。

第二方面，本申请实施例提供一种游戏资源的构建装置，所述装置包括获取单元、读取单元、打包单元和确定单元：

所述获取单元，用于获取游戏对应的游戏资源；

所述读取单元，用于从所述游戏对应的游戏资源中读取出具有依赖关系的游戏资源，并根据读取出的游戏资源确定出第一级资源和第二级资源；其中，所述依赖关系是根据所述游戏确定的，所述第一级资源对所述第二级资源具有依赖关系；

所述打包单元，用于对从所述第一级资源中确定出的第一级打包对象进行打包，得到所述第一级资源对应的第一资源文件；以及对从所述第二级资源中确定出的第二级打包对象进行打包，得到所述第二级资源对应的第二资源文件；

所述确定单元，用于根据所述第一级打包对象对所述第二级打包对象的依赖关系，确定所述第一资源文件对所述第二资源文件的文件依赖关系。

第三方面，本申请实施例提供一种用于游戏资源构建的设备，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行第一方面中所述的游戏资源的构建方法。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行第一方面中所述的游戏资源的构建方法。

由上述技术方案可以看出，在需要对游戏的包外资源进行打包时，可以获取包外资源中该游戏对应的游戏资源，并根据该游戏确定出的资源依赖关系，从该游戏对应的游戏资源中读取出具有该依赖关系的游戏资源，基于依赖关系读取出的游戏资源均与该游戏相关，降低了之后打包过程中会打包与该游戏无关的游戏资源的可能。由于依赖关系可以明确在该游戏运行时，调用游戏资源时，哪些游戏资源需要依赖其他游戏资源才能正常加载，故可以基于该依赖关系将读取的游戏资源分为至少两级资源，例如第一级资源和第二级资源，第一级资源对第二级资源具有依赖关系。在打包时，打包对象均是根据同一级资源确定的，而且，由于根据依赖关系确定出了第一级资源所对应第一资源文件对第二级资源所对应第二资源文件的文件依赖关系，使得在调用资源文件时，可以根据文件依赖关系准确调用公用的游戏资源对应的资源文件，使得不同级资源不会被打包到一起成为可能，从而避免了公用的游戏资源例如第二级资源被重复打包的情况，降低了打包后资源文件中资源冗余的程度，提高了存储资源的利用率。

附图说明

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

图1为本申请实施例提供的一种游戏资源的构建方法的应用场景示意图；

图2为本申请实施例提供的一种游戏资源的构建方法的流程图；

图3为本申请实施例提供的一种以资源集合作为打包对象打包得到资源文件的流程图；

图4为本申请实施例提供的一种以资源集合作为打包对象打包得到资源文件的示例图；

图5为本申请实施例提供的一种游戏资源的构建方法的流程图；

图6为本申请实施例提供的一种资源依赖栈的示例图；

图7为本申请实施例提供的一种游戏资源的构建方法的流程图；

图8a为本申请实施例提供的一种游戏资源的构建装置的结构图；

图8b为本申请实施例提供的一种游戏资源的构建装置的结构图；

图8c为本申请实施例提供的一种游戏资源的构建装置的结构图；

图9为本申请实施例提供的一种服务器的结构图；

图10为本申请实施例提供的一种终端设备的结构图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

传统的游戏资源打包方式中，为了便于游戏资源的调用，将游戏资源与其依赖的公用的游戏资源放在一起打包成为资源文件。但是，由于不同的游戏资源可能会依赖同一个公用的游戏资源，这种完整性打包可能导致同一个公用的游戏资源重复的被打包在不同的资源文件中，使得大量资源文件中出现资源冗余，造成了存储资源的浪费。

例如，游戏资源A1所依赖的公用的游戏资源为B1、B2和B3，而游戏资源A2所依赖的公用的游戏资源为B1、B3和B4，采用传统的游戏资源打包方式时，会将游戏资源A1与公用的游戏资源B1、B2、B3打包成一个资源文件，例如是资源文件1，将游戏资源A2与公用的游戏资源B1、B3、B4打包成一个资源文件，例如是资源文件2。其中，公用的游戏资源B1和B3既被游戏资源A1所依赖，又被游戏资源A2所依赖，使得资源文件1和资源文件2中都包括了公用的游戏资源B1和B3，公用的游戏资源B1和B3被重复打包，从而出现资源冗余现象。

需要说明的是，本申请实施例所提到的游戏是指通过在设备上执行应用程序所运行的游戏，通过执行配置在设备中的应用程序可以运行游戏。游戏资源是指运行游戏时，需要调用的资源，这里提到的游戏资源可以是游戏中的角色模型、贴图、动作、技能、音效等。

为此，本申请实施例提供一种游戏资源的打包方法，在打包时将具有依赖关系的不同级资源例如第一级资源和第二级资源分开打包得到各自对应的资源文件，从而避免了公用的游戏资源例如第二级资源被重复打包的情况，降低了打包后资源文件中资源冗余的程度，提高了存储资源的利用率。

为了便于理解本申请的技术方案，下面结合实际应用场景对本申请实施例提供的游戏资源的打包方法进行介绍。

参见图1，图1为本申请实施例提供的游戏资源的打包方法的应用场景示意图，该应用场景以游戏资源的构建方法应用于终端设备为例进行介绍。该应用场景中包括终端设备101，终端设备101可以是例如可以是智能手机等智能终端、计算机、个人数字助理(Personal Digital Assistant，简称PDA)、平板电脑等。

其中，终端设备101中可以安装有至少一个游戏，以终端设备101是智能手机为例，终端设备101中可以安装至少一个手游，为了便于在终端设备101运行某个游戏时，可以调用相应的包外资源，终端设备101需要对游戏的包外资源进行打包以构建游戏资源。

当需要对游戏的包外资源进行打包时，终端设备101可以获取该游戏对应的游戏资源，参见图1中102所示，某一游戏运行时需要调用游戏资源A1和A2，而正常运行游戏资源A1需要再调用游戏资源B1和B3，而游戏资源B1位于文件1中，游戏资源B3位于文件2中，正常运行游戏资源A2还需要调用游戏资源B2，游戏资源B2位于文件1中。因此，获取该游戏对应的游戏资源时，实际上获取的是游戏资源A1所在文件，游戏资源A2所在文件，以及文件1和文件2。

其中，A1、A2、B1-B3分别表示游戏资源，对于一个游戏来说，针对其调用的游戏资源可以预先设置好依赖关系，不同的游戏所对应的游戏资源依赖关系可以不同。

通过该游戏可以确定出该游戏对应的依赖关系，具体可以通过编辑器工具.收集依赖关系(Editor Utility.Collect Dependencies)接口来确定依赖关系。图1的102中箭头可以表示某一游戏的游戏资源之间的依赖关系。

在游戏正常运行时，当调用某个或某些游戏资源时，这个或这些游戏资源可能需要调用其他游戏资源，才能完成应有的功能，这种调用关系可以称为依赖关系。

可以理解的是，依赖关系可以连接两个游戏资源，依赖关系所连接的两个游戏资源都可以作为具有依赖关系的游戏资源。例如，102中游戏资源A1需要调用游戏资源B1和B3，则游戏资源A1对游戏资源B1具有依赖关系，游戏资源A1对游戏资源B3具有依赖关系，游戏资源A1、游戏资源B1和游戏资源B3都是具有依赖关系的游戏资源。游戏资源A2需要调用游戏资源B2，则游戏资源A2对游戏资源B2具有依赖关系，游戏资源A2和游戏资源B2都是具有依赖关系的游戏资源。

需要说明的是，该游戏对应的游戏资源是以文件的形式获取的，而在一个文件中，可能不仅包括了具有该依赖关系的游戏资源，可能还包括了其他游戏的游戏资源，因此，若具有所述依赖关系的游戏资源与不具有依赖关系的游戏资源处于同一个文件中，终端设备101可以通过读取的方式从游戏对应的游戏资源中读取出具有依赖关系的游戏资源。例如，从102中读取出具有依赖关系的游戏资源A1、A2、B1、B2、B3，而不会读取出与游戏资源B3同处于文件2的游戏资源B4。

终端设备101根据依赖关系例如102中的箭头，可以确定出具有依赖关系的游戏资源，从而确定出哪些游戏资源是依赖于其他游戏资源启动的，以及被依赖的游戏资源有哪些。将依赖于其他游戏资源启动的游戏资源作为一级资源，将被依赖的游戏资源作为另一级资源，这样，根据依赖关系可以将所读取的游戏资源分为多级资源。

在本申请实施例中，主要以得到的多级资源中的两级资源，即第一级资源和第二级资源为例进行介绍，介绍如何实现将第一级资源和第二级资源分开打包，以避免出现游戏资源重复打包的问题。其中，第一级资源对第二级资源具有依赖关系，即被标识为第一级资源的游戏资源需要依赖于被标识为第二级资源的游戏资源才能正常启动。

参见图1中103所示，其中，游戏资源A1和A2是需要依赖于其他游戏资源启动的游戏资源，游戏资源B1和B3被游戏资源A1所依赖，游戏资源B2被游戏资源A2所依赖，因此，游戏资源A1和A2可以作为第一级资源，游戏资源B1、B2和B3可以作为第二级资源。

在将第一级资源和第二级资源分开打包时，可以对从第一级资源中确定出的第一级打包对象进行打包，得到第一级资源对应的第一资源文件；以及对从第二级资源中确定出的第二级打包对象进行打包，得到第二级资源对应的第二资源文件。由于打包对象均是根据同一级资源确定的，而且，由于根据依赖关系能够确定出第一资源文件对第二资源文件的文件依赖关系，使得在调用资源文件时，可以根据文件依赖关系准确调用公用的游戏资源对应的资源文件，使得不同级资源不会被打包到一起成为可能。

其中，同一级资源可以包括多个游戏资源，同一级资源可以整体作为打包对象，也可以以同一级资源中每个游戏资源作为打包对象，还可以将同一级资源分成多个部分，以每部分包括的游戏资源作为打包对象，本实施例对此不做限定，具体如何从同一级资源中确定打包对象进行打包将在后续进行介绍。

接下来，将结合附图对本申请实施例提供的游戏资源的打包方法进行介绍。

在本实施例中，将主要以多级资源中包括的第一级资源和第二级资源为例进行介绍。参见图2，图2示出了一种游戏资源的构建方法的流程图，所述方法包括：

S201、获取游戏对应的游戏资源。

S202、从所述游戏对应的游戏资源中读取出具有依赖关系的游戏资源，并根据读取出的游戏资源确定出第一级资源和第二级资源。

由于终端设备101上可能安装有多个游戏，这些游戏可以是基于游戏引擎例如Unity3D(简称Unity)进行运行的，因此，包外资源可以包括这些游戏所需调用的游戏资源，针对某个游戏，该游戏所需调用的游戏资源可能与其他游戏所需调用的游戏资源保存在同一文件中，获取该游戏对应的游戏资源时，实际上获取的是该游戏所需调用的游戏资源所在的文件，对于Unity游戏来说，这些文件一般是预设(prefab)文件、场景文件等。因此，获取到的游戏对应的游戏资源102中可能包括了该游戏所需的游戏资源以及其所在文件中其他游戏所需的游戏资源。

以图1中102为例，其中，游戏资源A1和游戏资源A2是游戏1所需调用的游戏资源，在运行游戏1时，游戏资源A1还需要调用游戏资源B1和B3，游戏资源B1位于文件1中，游戏资源B3位于文件2中，游戏资源A2还需要调用游戏资源B2，游戏资源B2位于文件1中。因此，获取到的游戏对应的游戏资源实际上是游戏资源A1和游戏资源A2所在文件、文件1和文件2包括的所有游戏资源。其中，文件2中包括了游戏1所不需调用的游戏资源B4。

当然，如果该游戏所需的游戏资源单独保存在一个文件中，那么，获取到的游戏对应的游戏资源中仅包括该游戏所需的游戏资源。

在本实施例的一种实现方式中，若具有依赖关系的游戏资源与不具有依赖关系的游戏资源处于同一个文件中，例如处于同一个FilmBoX(简称FBX)文件中，终端设备101并非针对获取的游戏对应的游戏资源102进行打包，而是从该游戏对应的游戏资源102中读取出具有该依赖关系的游戏资源。例如，对于游戏1来说，通过读取的方式，从102中读取出具有依赖关系的游戏资源A1、A2、B1、B2、B3，而不会读取出与游戏资源B3同处于文件2的游戏资源B4。

读取出的游戏资源为具有依赖关系的游戏资源，根据依赖关系可以确定出第一级资源和第二级资源，例如，图1中103所示。其中，第一级资源对第二级资源具有依赖关系，第一级资源可以被称为上层资源，第二级资源可以被称为公用的游戏资源。

在读取具有依赖关系的游戏资源时，可以读取被依赖的游戏资源的名字、所属的文件的路径和名字、资源类型。通过这三个纬度，可以精准地定位到被依赖的某个文件中的某个资源类型的某个名字的游戏资源。

由于基于依赖关系读取出的游戏资源均与该游戏相关，从而降低了之后打包过程中会打包与该游戏无关的游戏资源的可能。

需要说明的是，依赖关系是根据游戏确定的，针对不同的游戏确定出来的依赖关系可能不同，一个游戏资源对于游戏1来说具有依赖关系，但是该游戏资源对于游戏2来说不一定具有依赖关系，那么，针对不同游戏，读取出的具有依赖关系的游戏资源也可能有所不同。

例如若游戏1所对应的游戏资源中包括游戏资源A、B、C和D，游戏2所对应的游戏资源中包括游戏资源D和E，若根据游戏1确定依赖关系，则确定出游戏资源A对游戏资源B和C具有依赖关系，但是对游戏资源D不具有依赖关系。若根据游戏2确定依赖关系，则确定出游戏资源E对游戏资源D具有依赖关系。可见，根据不同的游戏确定出来的依赖关系可能会有所不同，对于游戏资源D来说，根据游戏1确定出的依赖关系，游戏资源D不是具有依赖关系的游戏资源，但是根据游戏2确定出的依赖关系，游戏资源D是具有依赖关系的游戏资源。

需要说明的是，在一些情况下，例如，某些游戏资源在指定场景中处于热更新情况下，而在其它场景下保持不变。在这种情况下，针对同一游戏资源，若该游戏资源在不同的场景下更新需求不同，为了保证该游戏资源能够满足不同场景的更新需求，在读取具有依赖关系的游戏资源时，可以将具有依赖关系的该游戏资源对应不同更新需求的场景分别读取、打包，从而保证热更新的游戏资源仅在指定场景下进行热更新，而不会影响使用该游戏资源的其他场景。

例如，在场景1下需要调用游戏资源B1，在场景2也需要调用游戏资源B1，但是，游戏资源B1在场景1下需要不断的更新，而在场景2下保持不变，因此，可以将场景1下具有依赖关系的游戏资源B1与场景2下具有依赖关系的游戏资源B1分别读取、保存，并且分别作为打包对象进行打包，而不是将游戏资源B1作为场景1和场景2公用的游戏资源，仅打包一个游戏资源B1。当场景1下的游戏资源B1需要更新时，可以只更新针对场景1保存的游戏资源B1，保证场景2下的游戏资源B1保持不变。

S203、对从所述第一级资源中确定出的第一级打包对象进行打包，得到所述第一级资源对应的第一资源文件；以及对从所述第二级资源中确定出的第二级打包对象进行打包，得到所述第二级资源对应的第二资源文件。

在打包时，打包对象均是根据同一级资源确定的，从而实现将第一级资源和第二级资源分开打包。其中，一个打包对象可以包括同一级资源中至少一个游戏资源。相应的，通过打包得到的第一资源文件可以包括一个或多个，通过打包得到的第二资源文件也可以包括一个或多个，各级资源对应的资源文件的个数可以基于确定的打包对象的个数而定。

需要注意的是，本申请实施例中所提出的资源文件(例如第一资源文件和第二资源文件)与前述包括有游戏资源的文件属于不同概念，阅读时应该进行区别理解。前述的文件为在未对包外资源中游戏资源进行打包时，包外资源中游戏资源的保存形式，一个文件中可以包括一个或多个游戏资源。而资源文件为对包外资源中游戏资源进行打包后的文件，以使得打包得到的资源文件能够符合调用格式，便于调用。

例如，在基于Unity游戏引擎开发运行的游戏中，可以通过Unity内部的接口对打包对象进行打包。由于Unity需要使用Unity内部的资源格式例如assetbundle(简称ab)调用游戏资源，因此，打包后得到的资源文件为符合Unity内部的资源格式的ab文件，ab文件的后缀名为“.unity3d”或者“.assetbundle”。

S204、根据所述第一级打包对象对所述第二级打包对象的依赖关系，确定所述第一资源文件对所述第二资源文件的文件依赖关系。

虽然第一级资源与第二级资源分开打包，但是，根据依赖关系可以确定出第一资源文件对第二资源文件的文件依赖关系，使得在调用资源文件时，可以根据文件依赖关系准确调用公用的游戏资源对应的资源文件，使得不同级资源不会被打包到一起成为可能。

以图1为例，根据102中知晓游戏资源间的依赖关系。A1依赖于游戏资源B1，B3，A2依赖于游戏资源B2。将游戏资源A1作为一个第一级打包对象进行打包得到第一级资源对应的一个第一资源文件，例如ab文件1；将游戏资源A2作为一个第一级打包对象进行打包得到第一级资源对应的一个第一资源文件，例如ab文件2。将游戏资源B1和B3作为一个第二级打包对象进行打包得到第二级资源对应的一个第二资源文件，例如ab文件3；将游戏资源B2作为一个第二级打包对象进行打包得到第二级资源对应的一个第二资源文件，例如ab文件4。由于游戏资源A1依赖于游戏资源B1和B3，那么，根据A1打包得到的ab文件1也会依赖于根据B1和B3打包得到的ab文件3；由于游戏资源A2依赖于游戏资源B2，那么，根据A2打包得到的ab文件2也会依赖于根据B2打包得到的ab文件4。从而可以根据第一级打包对象对第二级打包对象的依赖关系，确定出第一资源文件对第二资源文件的文件依赖关系，例如ab文件1对ab文件3具有文件依赖关系；ab文件2对ab文件4具有文件依赖关系。将确定出的文件依赖关系进行保存，在游戏运行时可以使用保存的该文件依赖关系在调用资源文件时知晓还需调用哪些其他资源文件。

由上述技术方案可以看出，在需要对游戏的包外资源进行打包时，可以获取包外资源中该游戏对应的游戏资源，并根据该游戏确定出的资源依赖关系，从该游戏对应的游戏资源中读取出具有该依赖关系的游戏资源，基于依赖关系读取出的游戏资源均与该游戏相关，降低了之后打包过程中会打包与该游戏无关的游戏资源的可能。由于依赖关系可以明确在该游戏运行时，调用游戏资源时，哪些游戏资源需要依赖其他游戏资源才能正常加载，故可以基于该依赖关系将读取的游戏资源分为至少两级资源，例如第一级资源和第二级资源，第一级资源对第二级资源具有依赖关系。在打包时，打包对象均是根据同一级资源确定的，而且，由于根据依赖关系确定出了第一资源文件对第二资源文件的文件依赖关系，使得在调用资源文件时，可以根据文件依赖关系准确调用公用的游戏资源对应的资源文件，使得不同级资源不会被打包到一起成为可能，从而避免了公用的游戏资源例如第二级资源被重复打包的情况，降低了打包后资源文件中资源冗余的程度，提高了存储资源的利用率。

在一种可能的实现方式中，若读取出的具有依赖关系的游戏资源中包括相同的游戏资源，在执行S202之前，还可以将读取出的具有依赖关系的游戏资源中相同的游戏资源进行去重，从而避免同一级资源中可能具有重复的游戏资源而导致后续打包得到的资源文件中出现冗余，进一步避免了存储资源的浪费。

例如，游戏资源A1对游戏资源B1具有依赖关系，若游戏资源A2对游戏资源B1也具有依赖关系，在读取具有依赖关系的游戏资源时可能会读取出游戏资源A1和游戏资源B1，游戏资源A2和游戏资源B1，游戏资源B1被读取两次，S202根据依赖关系读取游戏资源中可能出现两个游戏资源B1。

又例如，游戏资源A1所依赖的游戏资源B1处于文件1中，游戏资源A2所依赖的游戏资源B1处于文件2中，那么在S202根据依赖关系读取游戏资源中也可能出现两个游戏资源B1。因此，为了避免游戏资源B1重复，可以仅保存一个游戏资源B1。

在本实施例中，对第一级资源和第二级资源分开打包，以及通过对读取出的具有依赖关系的游戏资源中相同的游戏资源进行去重，可以避免重复游戏资源导致的可能冗余，避免存储资源的浪费。另外，通过读取的方式，从游戏对应的游戏资源中读取出具有该依赖关系的游戏资源，可以保证读取出的游戏资源均与该游戏相关，避免了将与游戏无关的游戏资源打包到资源文件中而造成的存储资源的浪费。这样，本申请实施例的方法不仅能去除重复的游戏资源，又能去除无用的游戏资源，从而实现打包后的资源文件的零冗余。

在游戏运行调用每个资源文件时都会持有相应的句柄，而终端设备持有句柄的数量是有限的，当游戏运行过程中需要调用的游戏资源较多时，可能会导致需要调用的资源文件数量超出终端设备能够持有句柄的数量限制，从而造成调用出错。为了避免上述问题，而本申请实施例所提供了对应的确定打包对象方式来限制资源文件的数量。

在本申请实施例中，用于得到资源文件的打包对象是根据同一级资源确定的，而打包对象的确定方式可以包括多种，打包对象的确定方式不同，S203的具体实现方式也会有所不同。接下来，将对以不同方式确定打包对象的情况下，S203的具体实现方式进行详细介绍。

本申请实施例主要提供两种确定打包对象的方法其中，第一种确定方法是将同一级资源整体作为打包对象，这样，S203的具体实现方式可以是：将第一级资源整体作为第一级打包对象，对该第一级打包对象进行打包，得到第一级资源对应的一个第一资源文件；将第二级资源整体作为第二级打包对象，对该第二级打包对象进行打包，得到第二级资源对应的一个第二资源文件。

通过将同一级资源整体作为打包对象，针对每一级资源仅得到一个资源文件，大大减少了资源文件的数量，这样，在调用游戏资源时，仅需调用一个资源文件，需要调用的资源文件数量远小于终端设备能够持有句柄的数量，进而避免调用出错。

第二种确定方法是将同一级资源分成多个资源集合，将包括了一个或多个游戏资源的资源集合作为打包对象。在这种情况下，S203的具体实现方式可以参见图3，包括：

S301、根据预设条件将所述第一级资源分为多个第一资源集合，其中任一个第一资源集合作为一个第一级打包对象。

S302、对多个第一级打包对象分别进行打包，得到所述第一级资源对应的多个第一资源文件。

S303、根据所述预设条件将所述第二级资源分为多个第二资源集合，其中任一个第二资源集合作为一个第二级打包对象。

S304、对多个第二级打包对象分别进行打包，得到所述第二级资源对应的多个第二资源文件。

参见图4所示，第一级资源包括游戏资源A1、A2、A3、A4、A5、A6、A7、……，第二级资源包括B1、B2、B3、B4、B5、B6、……，根据预设条件可以将第一级资源分为第一资源集合1、第一资源集合2等，其中，第一资源集合1中包括了游戏资源A1、A3、A4、A7、……，第一资源集合2中包括了游戏资源A2、A5、A6……，这样，可以将第一资源集合1作为一个第一级打包对象进行打包，得到第一级资源对应的一个第一资源文件，对第一资源集合2作为一个第一级打包对象进行打包，得到第一级资源对应的一个第一资源文件。根据预设条件可以将第二级资源分为第二资源集合1、第二资源集合2等，其中，第二资源集合1中包括了游戏资源B1、B2、B3、……，第二资源集合2中包括了游戏资源B4、B5、B6、……，这样，可以将第二资源集合1作为一个第二级打包对象进行打包，得到第二级资源对应的一个第二资源文件，对第二资源集合2作为一个第二级打包对象进行打包，得到第二级资源对应的一个第二资源文件。

图4中箭头表示第一资源文件对第二资源文件的文件依赖关系，该文件依赖关系是根据打包对象间游戏资源的依赖关系确定，例如图4中，作为第一级打包对象的第一资源集合1中的游戏资源对作为第二级打包对象的第二资源集合1中的游戏资源具有依赖关系，由此确定根据第一资源集合1打包得到的第一资源文件对根据第二资源集合1打包得到的第二资源文件具有文件依赖关系。作为第一级打包对象的第一资源集合2中的游戏资源对作为第二级打包对象的第二资源集合1和第二资源集合2中的游戏资源均部分或全部具有依赖关系，由此确定根据第一资源集合2打包得到的第一资源文件对根据第二资源集合1和第二资源集合2分别打包得到的两个第二资源文件具有文件依赖关系。

例如，图4中游戏资源A1位于第一资源集合1打包得到的第一资源文件中，第一资源集合1打包得到的第一资源文件对第二资源集合1打包得到的第二资源文件具有文件依赖关系，当调用游戏资源A1时，根据文件依赖关系，还需调用第二资源集合1打包得到的第二资源文件。

通过将游戏资源以资源集合的形式进行打包，使得最终得到的资源文件数量是可控的，即可以通过改变资源集合的数量来改变资源文件的数量，并且以资源集合打包得到的资源文件的数量远低于将每个资源文件进行打包得到的资源文件的数量，这样，在调用游戏资源时，需调用的资源文件的数量是可控的，避免了需要调用的资源文件数量超出终端设备能够持有句柄的数量限制，进而避免调用出错。

由于通过本申请实施例提供的游戏资源构建方法得到的资源文件的数量是可控的，即通过控制资源集合中的内容使得资源文件的数量能够在预期范围内，减少了资源文件的数量，这样，游戏运行时不会出现需要调用大量资源文件的情况，需要调用的资源文件数量可以远小于终端设备能够持有句柄的数量限制。也就是说，相对于现有技术，本实施例中，终端设备能够持有句柄的数量是足够的，无需将不使用的资源文件立刻删除，为后续调用的资源文件做准备。因此，在加载后的资源文件不使用时，可以将不使用的资源文件进行缓存，当后续再需要调用该资源文件时，可以直接从缓存中调用该资源文件，而无需从该资源文件的包外资源所在的存储空间进行调用，从而提高了资源文件的加载速度。

在图3对应的实施例中，可以根据预设条件对同一级资源划分资源集合，预设条件可能包括不同的情况。接下来，对预设条件的几种可能的情况进行介绍。

第一种情况下预设条件可以是：一个资源集合的总数据量小于等于预设数据量。

为了避免游戏运行时调用的资源文件过大，每个资源集合所能容纳的数据量是有一定限制的，在向资源集合中添加游戏资源前，可以预先计算好每个游戏资源的大小，不断向资源集合中添加游戏资源，直到资源集合中游戏资源的总数据量超过预设数据量，完成一个资源集合的划分，继续划分下一个资源集合，以此类推。其中，预设数据量可以是以兆(M)为单位，例如，20M。

第二种情况下预设条件可以是：一个资源集合中游戏资源的数量小于等于预设数量。

游戏资源在运行时，若加载的一个资源文件中包括过多数量的游戏资源，可能会造成游戏瘫痪，因此，为了避免一个资源文件中包括的游戏资源数量过多，可以对每个资源集合所包括的游戏资源的数量进行限制，在向资源集合中添加游戏资源时，不断向资源集合中添加游戏资源，直到资源集合中游戏资源的数量超过预设数量，完成一个资源集合的划分，继续划分下一个资源集合，以此类推。

第三种情况下预设条件可以是：将相同类型的游戏资源放在一个资源集合中。

可以理解的是，在一个游戏中，游戏可能包括不同类型的游戏对象，例如游戏角色、游戏装备、怪物等，同一类型游戏对象对应的游戏资源可以认为是相同类型的游戏资源，例如，游戏角色对应的游戏资源为相同类型的游戏资源，游戏装备对应的游戏资源为相同类型的游戏资源。很多情况下，相同类型的游戏资源可能需要一起加载，因此，为了避免在加载同一类型的游戏资源时需要调用多个资源文件，导致调用了过多的资源文件造成游戏瘫痪，可以将相同类型的游戏资源放在一个资源集合中。这样，可能加载一个资源文件，就可以获取到相同类型所有游戏资源，提高了加载游戏资源的命中率，减少加载资源文件的数量。

第四种情况下预设条件可以是：根据游戏资源所具有依赖关系的数量划分资源集合，或者，根据游戏资源所具有被依赖关系的数量划分资源集合。

其中，所述被依赖关系是根据所述依赖关系反向确定的，依赖关系反向例如图1中102箭头的反向，游戏资源B1对游戏资源A1具有被依赖关系。

可以理解的是，在游戏中可能有一些游戏资源具有依赖关系的数量较多，即在调用这些游戏资源时，很容易调用其他游戏资源，或有一些游戏资源具有被依赖关系的数量较多，即在调用其他游戏资源时，这些游戏资源很容易被调用。

如果不将具有依赖关系的数量较多或具有被依赖关系的数量较多的游戏资源放在同一资源文件中，而是分散的放在多个资源文件中，由于运行该游戏时调用这些游戏资源所在资源文件的概率很高，那么，每次启动该游戏时，都需要调用数量可观的这类资源文件。

为了避免每次调用这些游戏资源时有很高概率需要调用上述数量可观的资源文件，可以将具有依赖关系的数量较多或具有被依赖关系的数量较多的游戏资源集中放在一个或几个资源集合中，从而在打包后，这些容易被调用的游戏资源可以处在一个或几个资源文件中。这样，在游戏运行时，调用了一次包括了这些容易调用的游戏资源的资源文件后，每次再调用这些游戏资源时，由于这些游戏资源都在这个已经被调用的资源文件中，从而减少了需要调用资源文件的数量，而且无需经常从包外资源中加载新的资源文件，提高***的处理效率。

上述四种预设条件可以独立使用，也可以结合使用，本实施例对此不做限定。

在一种实现方式中，游戏资源的打包依赖于游戏引擎，游戏引擎可以包括很多种，根据不同游戏引擎的不同特性，游戏资源的打包方式可以有所不同。基于图2对应的实施例，在本实施例中，将以游戏引擎为Unity为例，对游戏资源的打包方法进行介绍。

参见图5，所述方法包括：

S501、获取游戏对应的游戏资源。

S502、从游戏对应的游戏资源中读取出具有依赖关系的游戏资源，并根据读取出的游戏资源确定出第一级资源和第二级资源。

其中，S501-S502依次对应于S201-S202，此处不再赘述。

S503、创建资源依赖栈。

根据unity的特性，需要创建资源依赖栈对游戏资源进行打包，具体的，可以调用BuildPipeline.PushAssetDependencies()创建资源依赖栈。资源依赖栈是一种数据存储结构，具有先进后出的特点，即先进行压栈的数据被压入栈底，最后被压栈的数据被压入栈顶，需要读数据的时候从栈顶开始读取数据。

S504、通过资源依赖栈将第二级资源压栈，并通过资源依赖栈对从第二级资源中确定出的第二级打包对象进行打包，得到第二级资源对应的第二资源文件。

S505、通过资源依赖栈将第一级资源压栈，并通过资源依赖栈对从第一级资源中确定出的第一级打包对象进行打包，得到第一级资源对应的第一资源文件。

根据资源依赖栈先进后出的特点，由于第一级资源对第二级资源具有依赖关系，游戏运行时需要先调用第一级资源，再调用第二级资源，因此，可以先通过资源依赖栈将第二级资源压栈，资源依赖栈对从第二级资源中确定出的第二级打包对象进行打包，得到第二级资源对应的第二资源文件。再通过资源依赖栈将第一级资源压栈，资源依赖栈对从第一级资源中确定出的第一级打包对象进行打包，得到第一级资源对应的第一资源文件。这样，在资源依赖栈中，第一资源文件将位于第二资源文件上一层，保证先调用第一级资源，再调用第二级资源。

资源依赖栈中打包得到第一资源文件和第二资源文件可以参见图6所示，其中，箭头方向为资源依赖栈的底层到资源依赖栈的顶层，第一资源文件分别为AB1、AB2、AB3等，第二资源文件分别为ab1、ab2、ab3等，AB1、AB2、AB3位于资源依赖栈的同一层，ab1、ab2、ab3位于资源依赖栈的同一层，且位于AB1、AB2、AB3所在层的下一层，上一层的资源文件对下一层的资源文件具有依赖关系。图6中利用ab的大小写来区分第一资源文件和第二资源文件。

S506、根据第一级打包对象对第二级打包对象的依赖关系，确定第一资源文件对第二资源文件的文件依赖关系。

其中，S506对应于S204，此处不再赘述。

接下来，将结合具体场景对本申请实施例提供的游戏资源的构建方法进行介绍，该场景为针对Unity的游戏中，将游戏资源打包成assetbundle文件。参见图7，游戏资源的打包方法包括：

S701、获取游戏对应的游戏资源。

S702、从所述游戏对应的游戏资源中读取出具有依赖关系的游戏资源，并根据读取出的游戏资源确定出第一级资源和第二级资源。

S703、对第一级资源和第二级资源中相同的游戏资源进行去重。

S704、确定具有被依赖关系的游戏资源。

S705、根据具有依赖关系的游戏资源的数量和具有被依赖关系的游戏资源的数量划分多个第一资源集合和多个第二资源集合。

S706、创建资源依赖栈。

S707、通过资源依赖栈将第二级资源压栈，并通过资源依赖栈对从第二级资源中确定出的第二级打包对象进行打包，得到第二级资源对应的第二资源文件。

S708、通过资源依赖栈将第一级资源压栈，并通过资源依赖栈对从第一级资源中确定出的第一级打包对象进行打包，得到第一级资源对应的第一资源文件。

S709、确定第一资源文件对第二资源文件的文件依赖关系，并保存文件依赖关系。

其中，S701-S705可以作为游戏资源打包前的计算步骤，S706-S709可以作为游戏资源的打包中资源文件的构建步骤。

由上述技术方案可以看出，在需要对游戏的包外资源进行打包时，可以获取包外资源中该游戏对应的游戏资源，并根据该游戏确定出的资源依赖关系，从该游戏对应的游戏资源中读取出具有该依赖关系的游戏资源，基于依赖关系读取出的游戏资源均与该游戏相关，降低了之后打包过程中会打包与该游戏无关的游戏资源的可能。由于依赖关系可以明确在该游戏运行时，调用游戏资源时，哪些游戏资源需要依赖其他游戏资源才能正常加载，故可以基于该依赖关系将读取的游戏资源分为至少两级资源，例如第一级资源和第二级资源，第一级资源对第二级资源具有依赖关系。在打包时，打包对象均是根据同一级资源确定的，而且，由于根据依赖关系确定出了第一级资源所对应第一资源文件对第二级资源所对应第二资源文件的文件依赖关系，使得在调用资源文件时，可以根据文件依赖关系准确调用公用的游戏资源对应的资源文件，使得不同级资源不会被打包到一起成为可能，从而避免了公用第游戏资源例如第二级资源被重复打包的情况，降低了打包后资源文件中资源冗余的程度，提高了存储资源的利用率。

基于前述实施例提供的一种游戏资源的构建方法，本申请实施例还提供一种游戏资源的构建装置，参见图8a，所述装置包括获取单元801、读取单元802、打包单元803和确定单元804：

所述获取单元801，用于获取游戏对应的游戏资源；

所述读取单元802，用于从所述游戏对应的游戏资源中读取出具有依赖关系的游戏资源，并根据读取出的游戏资源确定出第一级资源和第二级资源；其中，所述依赖关系是根据所述游戏确定的，所述第一级资源对所述第二级资源具有依赖关系；

所述打包单元803，用于对从所述第一级资源中确定出的第一级打包对象进行打包，得到所述第一级资源对应的第一资源文件；以及对从所述第二级资源中确定出的第二级打包对象进行打包，得到所述第二级资源对应的第二资源文件；

所述确定单元804，用于根据所述第一级打包对象对所述第二级打包对象的依赖关系，确定所述第一资源文件对所述第二资源文件的文件依赖关系。

在一种实现方式中，所述读取单元802具体用于：

若具有所述依赖关系的游戏资源与不具有所述依赖关系的游戏资源处于同一个文件中，从所述文件中单独读取出具有所述依赖关系的游戏资源。

在一种实现方式中，所述打包单元803具体用于：

根据预设条件将所述第一级资源分为多个第一资源集合，其中任一个第一资源集合作为一个第一级打包对象；

对多个第一级打包对象分别进行打包，得到所述第一级资源对应的多个第一资源文件；

根据所述预设条件将所述第二级资源分为多个第二资源集合，其中任一个第二资源集合作为一个第二级打包对象；

对多个第二级打包对象分别进行打包，得到所述第二级资源对应的多个第二资源文件。

在一种实现方式中，所述预设条件包括如下一种或多种的组合：

将相同类型的游戏资源放在一个资源集合中；

一个资源集合的总数据量小于等于预设数据量；

一个资源集合中游戏资源的数量小于等于预设数量；

根据游戏资源所具有依赖关系的数量划分资源集合，或者，根据游戏资源所具有被依赖关系的数量划分资源集合；其中，所述被依赖关系是根据所述依赖关系反向确定的。

在一种实现方式中，在所述游戏运行时，参见图8b，所述装置还包括缓存单元805：

所述缓存单元805，用于若调用的资源文件在加载后不使用，将不使用的资源文件进行缓存。

在一种实现方式中，参见图8c，所述装置还包括创建单元806：

所述创建单元806，用于创建资源依赖栈；

所述打包单元803具体用于：

通过所述资源依赖栈将所述第二级资源压栈，并通过所述资源依赖栈对从所述第二级资源中确定出的第二级打包对象进行打包，得到所述第二级资源对应的第二资源文件；

通过所述资源依赖栈将所述第一级资源压栈，并通过所述资源依赖栈对从所述第一级资源中确定出的第一级打包对象进行打包，得到所述第一级资源对应的第一资源文件。

本申请实施例还提供了一种服务器，下面将结合附图对该服务器进行介绍。请参见图9所示，服务器900，可因配置或性能不同而产生比较大的差异，可以包括一个或一个以***处理器(Central Processing Units，简称CPU)922(例如，一个或一个以上处理器)和存储器932，一个或一个以上存储应用程序942或数据944的存储介质930(例如一个或一个以上海量存储设备)。其中，存储器932和存储介质930可以是短暂存储或持久存储。存储在存储介质930的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器922可以设置为与存储介质930通信，在服务器900上执行存储介质930中的一系列指令操作。

服务器900还可以包括一个或一个以上电源926，一个或一个以上有线或无线网络接口950，一个或一个以上输入输出接口958，和/或，一个或一个以上操作***941，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述实施例中由服务器900所执行的步骤可以基于该图9所示的服务器结构。

其中，CPU 922用于执行如下步骤：

获取游戏对应的游戏资源；

从所述游戏对应的游戏资源中读取出具有依赖关系的游戏资源，并根据读取出的游戏资源确定出第一级资源和第二级资源；其中，所述依赖关系是根据所述游戏确定的，所述第一级资源对所述第二级资源具有依赖关系；

对从所述第一级资源中确定出的第一级打包对象进行打包，得到所述第一级资源对应的第一资源文件；以及对从所述第二级资源中确定出的第二级打包对象进行打包，得到所述第二级资源对应的第二资源文件；

根据所述第一级打包对象对所述第二级打包对象的依赖关系，确定所述第一资源文件对所述第二资源文件的文件依赖关系。

请参见图10所示，本申请实施例提供了一种终端设备，该终端设备可以作为用于游戏资源打包的设备，该终端设备可以为包括手机、平板电脑、个人数字助理(PersonalDigital Assistant，简称PDA)、销售终端(Point of Sales，简称POS)、车载电脑等任意终端设备，以终端设备为手机为例：

图10示出的是与本申请实施例提供的终端设备相关的手机的部分结构的框图。参考图10，手机包括：射频(Radio Frequency，简称RF)电路1010、存储器1020、输入单元1030、显示单元1040、传感器1050、音频电路1060、无线保真(wireless fidelity，简称WiFi)模块1070、处理器1080、以及电源1090等部件。本领域技术人员可以理解，图10中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图10对手机的各个构成部件进行具体的介绍：

RF电路1010可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1080处理；另外，将设计上行的数据发送给基站。通常，RF电路1010包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low NoiseAmplifier，简称LNA)、双工器等。此外，RF电路1010还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯***(Global System of Mobile communication，简称GSM)、通用分组无线服务(GeneralPacket Radio Service，简称GPRS)、码分多址(Code Division Multiple Access，简称CDMA)、宽带码分多址(Wideband Code Division Multiple Access，简称WCDMA)、长期演进(Long Term Evolution，简称LTE)、电子邮件、短消息服务(Short Messaging Service，简称SMS)等。

存储器1020可用于存储软件程序以及模块，处理器1080通过运行存储在存储器1020的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器1020可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1020可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1030可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元1030可包括触控面板1031以及其他输入设备1032。触控面板1031，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1031上或在触控面板1031附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板1031可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1080，并能接收处理器1080发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1031。除了触控面板1031，输入单元1030还可以包括其他输入设备1032。具体地，其他输入设备1032可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1040可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1040可包括显示面板1041，可选的，可以采用液晶显示器(LiquidCrystal Display，简称LCD)、有机发光二极管(Organic Light-Emitting Diode，简称OLED)等形式来配置显示面板1041。进一步的，触控面板1031可覆盖显示面板1041，当触控面板1031检测到在其上或附近的触摸操作后，传送给处理器1080以确定触摸事件的类型，随后处理器1080根据触摸事件的类型在显示面板1041上提供相应的视觉输出。虽然在图10中，触控面板1031与显示面板1041是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板1031与显示面板1041集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器1050，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板1041的亮度，接近传感器可在手机移动到耳边时，关闭显示面板1041和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路1060、扬声器1061，传声器1062可提供用户与手机之间的音频接口。音频电路1060可将接收到的音频数据转换后的电信号，传输到扬声器1061，由扬声器1061转换为声音信号输出；另一方面，传声器1062将收集的声音信号转换为电信号，由音频电路1060接收后转换为音频数据，再将音频数据输出处理器1080处理后，经RF电路1010以发送给比如另一手机，或者将音频数据输出至存储器1020以便进一步处理。

WiFi属于短距离无线传输技术，手机通过WiFi模块1070可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图10示出了WiFi模块1070，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器1080是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器1020内的软件程序和/或模块，以及调用存储在存储器1020内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器1080可包括一个或多个处理单元；优选的，处理器1080可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作***、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1080中。

手机还包括给各个部件供电的电源1090(比如电池)，优选的，电源可以通过电源管理***与处理器1080逻辑相连，从而通过电源管理***实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本实施例中，该终端设备所包括的处理器1080还具有以下功能：

获取游戏对应的游戏资源；

从所述游戏对应的游戏资源中读取出具有依赖关系的游戏资源，并根据读取出的游戏资源确定出第一级资源和第二级资源；其中，所述依赖关系是根据所述游戏确定的，所述第一级资源对所述第二级资源具有依赖关系；

对从所述第一级资源中确定出的第一级打包对象进行打包，得到所述第一级资源对应的第一资源文件；以及对从所述第二级资源中确定出的第二级打包对象进行打包，得到所述第二级资源对应的第二资源文件；

根据所述第一级打包对象对所述第二级打包对象的依赖关系，确定所述第一资源文件对所述第二资源文件的文件依赖关系。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行图1-图7对应的实施例中任一所述的游戏资源的构建方法。

本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

在本申请所提供的几个实施例中，应该理解到，所揭露的***，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (14)

1.一种游戏资源的构建方法，其特征在于，所述方法包括：

获取游戏对应的游戏资源；

从所述游戏对应的游戏资源中读取出具有依赖关系的游戏资源，并根据读取出的游戏资源确定出第一级资源和第二级资源；其中，所述依赖关系是根据所述游戏确定的，所述第一级资源对所述第二级资源具有依赖关系；

对从所述第一级资源中确定出的第一级打包对象进行打包，得到所述第一级资源对应的第一资源文件；以及对从所述第二级资源中确定出的第二级打包对象进行打包，得到所述第二级资源对应的第二资源文件；

根据所述第一级打包对象对所述第二级打包对象的依赖关系，确定所述第一资源文件对所述第二资源文件的文件依赖关系。

2.根据权利要求1所述的方法，其特征在于，所述从所述游戏对应的游戏资源中读取出具有依赖关系的游戏资源，包括：

若具有所述依赖关系的游戏资源与不具有所述依赖关系的游戏资源处于同一个文件中，从所述文件中单独读取出具有所述依赖关系的游戏资源。

3.根据权利要求1所述的方法，其特征在于，所述对从所述第一级资源中确定出的第一级打包对象进行打包，得到所述第一级资源对应的第一资源文件，包括：

根据预设条件将所述第一级资源分为多个第一资源集合，其中任一个第一资源集合作为一个第一级打包对象；

对多个第一级打包对象分别进行打包，得到多个所述第一资源文件；

所述对从所述第二级资源中确定出的第二级打包对象进行打包，得到所述第二级资源对应的第二资源文件，包括：

根据所述预设条件将所述第二级资源分为多个第二资源集合，其中任一个第二资源集合作为一个第二级打包对象；

对多个第二级打包对象分别进行打包，得到多个所述第二资源文件。

4.根据权利要求3所述的方法，其特征在于，所述预设条件包括如下一种或多种的组合：

将相同类型的游戏资源放在一个资源集合中；

一个资源集合的总数据量小于等于预设数据量；

一个资源集合中游戏资源的数量小于等于预设数量；

根据游戏资源所具有依赖关系的数量划分资源集合，或者，根据游戏资源所具有被依赖关系的数量划分资源集合；其中，所述被依赖关系是根据所述依赖关系反向确定的。

5.根据权利要求3所述的方法，其特征在于，在所述游戏运行时，所述方法还包括：

若调用的资源文件在加载后不使用，将不使用的资源文件进行缓存。

6.根据权利要求1-5任意一项所述的方法，其特征在于，所述方法还包括：

创建资源依赖栈；

所述对从所述第一级资源中确定出的第一级打包对象进行打包，得到所述第一级资源对应的第一资源文件；以及对从所述第二级资源中确定出的第二级打包对象进行打包，得到所述第二级资源对应的第二资源文件，包括：

通过所述资源依赖栈将所述第二级资源压栈，并通过所述资源依赖栈对从所述第二级资源中确定出的第二级打包对象进行打包，得到所述第二资源文件；

通过所述资源依赖栈将所述第一级资源压栈，并通过所述资源依赖栈对从所述第一级资源中确定出的第一级打包对象进行打包，得到所述第一资源文件。

7.一种游戏资源的构建装置，其特征在于，所述装置包括获取单元、读取单元、打包单元和确定单元：

所述获取单元，用于获取游戏对应的游戏资源；

所述读取单元，用于从所述游戏对应的游戏资源中读取出具有依赖关系的游戏资源，并根据读取出的游戏资源确定出第一级资源和第二级资源；其中，所述依赖关系是根据所述游戏确定的，所述第一级资源对所述第二级资源具有依赖关系；

所述打包单元，用于对从所述第一级资源中确定出的第一级打包对象进行打包，得到所述第一级资源对应的第一资源文件；以及对从所述第二级资源中确定出的第二级打包对象进行打包，得到所述第二级资源对应的第二资源文件；

所述确定单元，用于根据所述第一级打包对象对所述第二级打包对象的依赖关系，确定所述第一资源文件对所述第二资源文件的文件依赖关系。

8.根据权利要求7所述的装置，其特征在于，所述读取单元具体用于：

若具有所述依赖关系的游戏资源与不具有所述依赖关系的游戏资源处于同一个文件中，从所述文件中单独读取出具有所述依赖关系的游戏资源。

9.根据权利要求7所述的装置，其特征在于，所述打包单元具体用于：

根据预设条件将所述第一级资源分为多个第一资源集合，其中任一个第一资源集合作为一个第一级打包对象；

对多个第一级打包对象分别进行打包，得到多个所述第一资源文件；

根据所述预设条件将所述第二级资源分为多个第二资源集合，其中任一个第二资源集合作为一个第二级打包对象；

对多个第二级打包对象分别进行打包，得到多个所述第二资源文件。

10.根据权利要求9所述的装置，其特征在于，所述预设条件包括如下一种或多种的组合：

将相同类型的游戏资源放在一个资源集合中；

一个资源集合的总数据量小于等于预设数据量；

一个资源集合中游戏资源的数量小于等于预设数量；

根据游戏资源所具有依赖关系的数量划分资源集合，或者，根据游戏资源所具有被依赖关系的数量划分资源集合；其中，所述被依赖关系是根据所述依赖关系反向确定的。

11.根据权利要求9所述的装置，其特征在于，在所述游戏运行时，所述装置还包括缓存单元：

所述缓存单元，用于若调用的资源文件在加载后不使用，将不使用的资源文件进行缓存。

12.根据权利要求7-11任意一项所述的装置，其特征在于，所述装置还包括创建单元：

所述创建单元，用于创建资源依赖栈；

所述打包单元具体用于：

通过所述资源依赖栈将所述第二级资源压栈，并通过所述资源依赖栈对从所述第二级资源中确定出的第二级打包对象进行打包，得到所述第二资源文件；

通过所述资源依赖栈将所述第一级资源压栈，并通过所述资源依赖栈对从所述第一级资源中确定出的第一级打包对象进行打包，得到所述第一资源文件。

13.一种用于游戏资源构建的设备，其特征在于，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行权利要求1-6任一项所述的游戏资源的构建方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行权利要求1-6中任一项所述的游戏资源的构建方法。