资源加载、资源文件的生成方法及装置与流程

本发明涉及计算机领域，具体而言，涉及一种资源加载、资源文件的生成方法及装置。

背景技术：

unity游戏对资源进行增量更新需要用到assetbundle机制，即将游戏资源打包成.unity3d格式文件，于游戏运行时加载。但游戏资源间存在非常复杂的依赖关系。现有的unity资源打包方案一般是利用打包资源时默认的完整性打包，即将所依赖的资源都默认构建在同一个文件中，以使得此资源完整可用。或者是区分目录，将部分路径下的资源独立构建后，再通过依赖关系构建依赖这些独立构建的资源的资源。但这种简单的依赖关系会导致资源的碎片化，在提升加载资源io的消耗的同时不一定能有效地精简资源占用，但带来的加载释放时卡顿现象会很严重，影响了玩家的体验度。

针对上述的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种资源加载、资源文件的生成方法及装置，以至少解决现有技术中游戏运行流畅度低的技术问题。

根据本发明实施例的一个方面，提供了一种资源加载方法，包括：在游戏应用运行的过程中，检测是否跳转到所述游戏应用中的ui系统，或，是否进入游戏应用中的场景系统；在检测到跳转到所述游戏应用中的ui系统的情况下，获取所述ui系统所需的一个第一资源文件，并加载所述第一资源文件中的资源，其中，所述第一资源文件中包括所述ui系统所需的资源以及所述ui系统所需的资源所依赖的资源；在检测到进入游戏应用中的场景系统的情况下，获取所述场景系统所需的多个第二资源文件，并根据所述多个第二资源文件之间的依赖关系对所述多个第二资源文件中的资源进行加载，其中，每个所述第二资源文件包括一个或多个资源。

根据本发明实施例的另一方面，还提供了一种资源文件的生成方法，其特征在于，包括：检测是否需要为游戏应用中的ui系统生成资源文件，或者，是否需要为所述游戏应用中的场景系统生成资源文件；在检测出需要为所述游戏应用中的ui系统生成资源文件的情况下，生成所述ui系统所需的一个第一资源文件，其中，所述第一资源文件中包括所述ui系统所需的资源以及所述ui系统所需的资源所依赖的资源；在检测出需要为所述游戏应用中的场景系统生成资源文件的情况下，生成所述场景系统所需的多个第二资源文件，其中，所述多个第二资源文件之间在加载时存在依赖关系，每个所述第二资源文件包括一个或多个资源。

根据本发明实施例的另一方面，还提供了一种资源加载装置，包括：第一检测模块，用于在游戏应用运行的过程中，检测是否跳转到所述游戏应用中的ui系统，或，是否进入游戏应用中的场景系统；第一处理模块，用于在检测到跳转到所述游戏应用中的ui系统的情况下，获取所述ui系统所需的一个第一资源文件，并加载所述第一资源文件中的资源，其中，所述第一资源文件中包括所述ui系统所需的资源以及所述ui系统所需的资源所依赖的资源；第二处理模块，用于在检测到进入游戏应用中的场景系统的情况下，获取所述场景系统所需的多个第二资源文件，并根据所述多个第二资源文件之间的依赖关系对所述多个第二资源文件中的资源进行加载，其中，每个所述第二资源文件包括一个或多个资源。

根据本发明实施例的另一方面，还提供了一种资源文件的生成装置，包括：第三检测模块，用于检测是否需要为游戏应用中的ui系统生成资源文件，或者，是否需要为所述游戏应用中的场景系统生成资源文件；第一生成模块，用于在检测出需要为所述游戏应用中的ui系统生成资源文件的情况下，生成所述ui系统所需的一个第一资源文件，其中，所述第一资源文件中包括所述ui系统所需的资源以及所述ui系统所需的资源所依赖的资源；第二生成模块，用于在检测出需要为所述游戏应用中的场景系统生成资源文件的情况下，生成所述场景系统所需的多个第二资源文件，其中，所述多个第二资源文件之间在加载时存在依赖关系，每个所述第二资源文件包括一个或多个资源。

在本发明实施例中，在游戏应用运行的过程中，检测是否跳转到游戏应用中的ui系统，或，是否进入游戏应用中的场景系统；在检测到跳转到游戏应用中的ui系统的情况下，获取ui系统所需的一个第一资源文件，并加载第一资源文件中的资源，其中，第一资源文件中包括ui系统所需的资源以及所需的资源所依赖的资源；在检测到进入游戏应用中的场景系统的情况下，获取场景系统所需的多个第二资源文件，并根据多个第二资源文件之间的依赖关系对多个第二资源文件中的资源进行加载，其中，每个第二资源文件包括一个或多个资源。也就是说，在游戏应用的运行过程中，对游戏中系统的切换进行检测，比如检测是否跳转到游戏应用中的ui系统，或，是否进入游戏应用中的场景系统，对于跳转到游戏应用中的ui系统的情况，由于该ui系统所需的资源以及所需的资源所依赖的资源均构建在了一个第一资源文件中，只需获取这一个第一资源文件并加载其中的资源即可跳转到该ui系统，对于进入游戏应用中的场景系统的情况，可以获取该场景系统所需的具有依赖关系的多个第二资源文件，并根据依赖关系加载多个第二资源文件中的资源，可见，对于ui系统将需要的资源通过一个第一资源文件加载，可以减少读取资源的次数，从而提高了游戏运行的流畅度，而对于场景系统则根据多个第二资源文件之间的依赖关系加载资源，减少了场景系统下资源的冗余度，从而也减少了场景系统下资源对磁盘的占用，提高了游戏运行的流畅度，进而克服现有技术中游戏运行流畅度低的问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的一种可选的资源加载方法的应用环境示意图；

图2是根据本发明实施例的一种可选的资源加载方法的示意图；

图3是根据本发明实施例的一种可选的为ui系统的示意图；

图4是根据本发明实施例的一种可选的为场景系统的示意图；

图5是根据本发明实施例的一种可选的为场景系统加载界面的示意图；

图6是根据本发明实施例的一种可选的资源文件的生成方法的应用环境示意图；

图7是根据本发明实施例的一种可选的资源文件的生成方法的示意图；

图8是根据本发明实施例的一种可选的为ui系统资源文件生成的示意图；

图9是根据本发明实施例的一种可选的为场景系统资源文件生成的示意图；

图10是根据本发明实施例的一种可选的资源加载装置的示意图；

图11是根据本发明实施例的一种可选的资源文件的生成装置的示意图；

图12是根据本发明实施例的一种可选的资源加载设备的示意图；以及

图13是根据本发明实施例的一种可选的资源文件的生成设备的示意图。

具体实施方式

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

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

实施例1

在本发明实施例中，提供了一种上述资源加载方法的实施例。作为一种可选的实施方式，该资源加载方法可以但不限于应用于如图1所示的应用环境中，终端102中安装有游戏应用的客户端，终端102用于在游戏应用运行的过程中，检测是否跳转到游戏应用中的ui系统，或，是否进入游戏应用中的场景系统；在检测到跳转到游戏应用中的ui系统的情况下，获取ui系统所需的一个第一资源文件，并加载第一资源文件中的资源，其中，第一资源文件中包括ui系统所需的资源以及所需的资源所依赖的资源；在检测到进入游戏应用中的场景系统的情况下，获取场景系统所需的多个第二资源文件，并根据多个第二资源文件之间的依赖关系对多个第二资源文件中的资源进行加载，其中，每个第二资源文件包括一个或多个资源。

在本实施例中，终端102在游戏应用的运行过程中，对游戏中系统的切换进行检测，比如检测是否跳转到游戏应用中的ui系统，或，是否进入游戏应用中的场景系统，对于跳转到游戏应用中的ui系统的情况，由于该ui系统所需的资源以及所需的资源所依赖的资源均构建在了一个第一资源文件中，只需获取这一个第一资源文件并加载其中的资源即可跳转到该ui系统，对于进入游戏应用中的场景系统的情况，可以获取该场景系统所需的具有依赖关系的多个第二资源文件，并根据依赖关系加载多个第二资源文件中的资源，可见，对于ui系统将需要的资源通过一个第一资源文件加载，可以减少读取资源的次数，从而提高了游戏运行的流畅度，而对于场景系统则根据多个第二资源文件之间的依赖关系加载资源，减少了场景系统下资源的冗余度，从而也减少了场景系统下资源对磁盘的占用，提高了游戏运行的流畅度，进而克服现有技术中游戏运行流畅度低的问题。

可选地，在本实施例中，上述终端可以包括但不限于以下至少之一：手机、平板电脑、笔记本电脑、台式pc机、数字电视及其他进行资源加载的硬件设备。上述只是一种示例，本实施例对此不做任何限定。

可选地，在本实施例中，终端102用于：通过一次io读取来获取一个第一资源文件。

可选地，在本实施例中，终端102用于：在进入游戏应用中的场景系统之前，获取场景系统所需的多个第二资源文件，并根据多个第二资源文件之间的依赖关系对多个第二资源文件进行加载。

可选地，在本实施例中，终端102用于：检测是否需要加载通用资源，其中，通用资源被设置为用于ui系统和场景系统；在检测到需要加载通用资源时，获取根据通用资源和通用资源所依赖的资源生成的多个第三资源文件；加载多个第三资源文件中的资源。

可选地，在本实施例中，终端102用于：对多个第三资源文件中的第一部分资源文件中的资源进行加载，其中，每个第一部分资源文件包括一个通用资源所依赖的资源；按照通用资源与通用资源所依赖的资源之间的依赖关系，对多个第三资源文件中的第二部分资源文件中的资源进行加载，其中，每个第二部分资源文件包括一个通用资源，通用资源之间没有依赖关系，第二部分资源文件中包括的通用资源依赖于第一部分资源文件中的资源。

可选地，在本实施例中，上述应用环境中还可以包括：服务器和网络，其中，上述终端102通过网络与服务器连接，服务器用于：通过网络为终端102提供ui系统所需的一个第一资源文件或者场景系统所需的多个第二资源文件。

可选地，在本实施例中，上述网络可以包括但不限于以下至少之一：广域网、城域网、局域网。上述只是一种示例，本实施例对此不做任何限定。

根据本发明实施例，提供了一种资源加载方法，如图2所示，该方法包括：

s202，在游戏应用运行的过程中，检测是否跳转到游戏应用中的ui系统，或，是否进入游戏应用中的场景系统；

s204，在检测到跳转到游戏应用中的ui系统的情况下，获取ui系统所需的一个第一资源文件，并加载第一资源文件中的资源，其中，第一资源文件中包括ui系统所需的资源以及所需的资源所依赖的资源；

s206，在检测到进入游戏应用中的场景系统的情况下，获取场景系统所需的多个第二资源文件，并根据多个第二资源文件之间的依赖关系对多个第二资源文件中的资源进行加载，其中，每个第二资源文件包括一个或多个资源。

可选地，在本实施例中，上述资源加载方法可以但不限于应用于游戏应用客户端运行过程中加载资源的场景。其中，上述游戏应用客户端可以但不限于为各种类型的游戏，例如，对战类游戏、消除类游戏、角色扮演类游戏、射击类游戏等等。上述仅是一种示例，本实施例中对此不做任何限定。

可选地，在本实施例中，上述ui系统可以但不限于包括游戏中的菜单界面、状态界面、技能界面、商城界面、游戏模式选择界面、关卡选择界面等等。

例如：以关卡选择界面为例，如图3所示，该对战模式的选择界面的ui系统所需的资源包括各个关卡的选项卡，游戏模式选项“自动”和“战斗”等等，该对战模式的选择界面的ui系统所需的资源所依赖的资源包括各个关卡的选项卡中的贴图、文字描述、关卡难易程度的标签(例如：关卡2对应标签“困难”)等等，这些资源都被打包在第一资源文件中，也就是说，加载了第一资源文件就相当于加载了跳转到该ui系统所需的全部资源。

可选地，在本实施例中，上述场景系统可以但不限于包括射击游戏中的战斗场景、对战游戏中的对战场景、竞速类游戏中的竞技场景、体育类游戏中的比赛场景等等。

例如：以射击游戏中的战斗场景为例，如图4所示，场景系统中包括了各种资源，例如：场景、树木、麻袋、箱子等等，这些资源被打包在多个第二资源文件，这多个第二资源文件之间具有依赖关系，比如，该场景系统下的多个场景中均有树木、麻袋和箱子，那么获取的多个第二资源文件中可以包括多个打包有不同场景资源的第二资源文件以及打包有树木资源的第二资源文件、打包有麻袋资源的第二资源文件和打包有箱子资源的第二资源文件各一个，那么在加载的过程中，可以先加载树木、箱子、麻袋的第二资源文件，再在需要进入各个场景时分别加载对应场景的第二资源文件。

可见，通过上述步骤，在游戏应用的运行过程中，对游戏中系统的切换进行检测，比如检测是否跳转到游戏应用中的ui系统，或，是否进入游戏应用中的场景系统，对于跳转到游戏应用中的ui系统的情况，由于该ui系统所需的资源以及所需的资源所依赖的资源均构建在了一个第一资源文件中，只需获取这一个第一资源文件并加载其中的资源即可跳转到该ui系统，对于进入游戏应用中的场景系统的情况，可以获取该场景系统所需的具有依赖关系的多个第二资源文件，并根据依赖关系加载多个第二资源文件中的资源，可见，对于ui系统将需要的资源通过一个第一资源文件加载，可以减少读取资源的次数，从而提高了游戏运行的流畅度，而对于场景系统则根据多个第二资源文件之间的依赖关系加载资源，减少了场景系统下资源的冗余度，从而也减少了场景系统下资源对磁盘的占用，提高了游戏运行的流畅度，进而克服现有技术中游戏运行流畅度低的问题。

作为一种可选的方案，获取ui系统所需的一个第一资源文件包括：

s1，通过一次io读取来获取一个第一资源文件。

可选地，在本实施例中，由于ui系统所需的资源均被打包在一个第一资源文件中，那么，在获取这个第一资源文件时可以通过一次io读取来得到该第一资源文件。当玩家在操作ui界面的时候，玩家会要求界面的流畅度，不会有卡顿的感觉，包括界面的滑进滑出等动画效果也需要流畅。通过上述步骤，可以大大减少在加载ui系统时的io读取次数，从而减少加载资源时的io消耗，提高了游戏运行的流畅度。

作为一种可选的方案，获取场景系统所需的多个第二资源文件，并根据多个第二资源文件之间的依赖关系对多个第二资源文件进行加载包括：

s1，在进入游戏应用中的场景系统之前，获取场景系统所需的多个第二资源文件，并根据多个第二资源文件之间的依赖关系对多个第二资源文件进行加载。

可选地，在本实施例中，可以在进入游戏应用中的场景系统之前，对场景系统所需的多个第二资源文件进行获取和加载，在这个加载的过程中，游戏界面上可以显示对玩家的提示信息，游戏壁纸画等内容。

例如：如图5所示，在进入游戏应用中的场景系统之前，先跳转到加载多个第二资源文件的界面，在该界面中，展示了装备的合成途径，并在右下角以“loading…”的形式提示用户正在加载资源。

当玩家在游戏内进行战斗的时候，就是游戏最核心的玩法，必须得保证游戏流畅，因为可能稍微的卡顿也会影响游戏结果，玩家对于战斗中的卡顿也会非常地介意。玩家在游戏前会进行一小段时间的资源预加载，这个时间对于玩家来说是有预期的，只要不是时间非常长，对于玩家来说，都不会是影响体验的问题。

通过上述步骤，在进入游戏应用中的场景系统之前，对场景系统所需的多个第二资源文件进行获取和加载，可以避免在场景系统运行时获取和加载资源，从而减少了场景系统运行时加载资源对内存的占用，提高了游戏运行的流畅度。

作为一种可选的方案，在游戏应用运行的过程中，还包括：

s1，检测是否需要加载通用资源，其中，通用资源被设置为用于ui系统和场景系统；

s2，在检测到需要加载通用资源时，获取根据通用资源和通用资源所依赖的资源生成的多个第三资源文件；

s3，加载多个第三资源文件中的资源。

可选地，在本实施例中，上述通用资源被设置为用于ui系统和场景系统。例如：音效资源、装备资源等等。

可选地，在本实施例中，可以但不限于通过以下方式加载多个第三资源文件中的资源：对多个第三资源文件中的第一部分资源文件中的资源进行加载，其中，每个第一部分资源文件包括一个通用资源所依赖的资源，再按照通用资源与通用资源所依赖的资源之间的依赖关系，对多个第三资源文件中的第二部分资源文件中的资源进行加载，其中，每个第二部分资源文件包括一个通用资源，通用资源之间没有依赖关系，第二部分资源文件中包括的通用资源依赖于第一部分资源文件中的资源。

例如：在检测到需要加载通用资源a时，获取根据该通用资源a和通用资源a所依赖的资源b、c、d生成的两个第三资源文件e和第三资源文件f，其中，第三资源文件e中打包了资源a、c、d，第三资源文件f中打包了资源b，由于通用资源a依赖于资源b，那么在加载时，先加载第三资源文件f，再加载第三资源文件e来实现对通用资源a的加载。

可见，通过上述步骤，在游戏应用运行的过程中，检测是否需要加载被设置为用于ui系统和场景系统的通用资源，在需要加载通用资源时再对通用资源进行加载，可以避免在游戏应用运行的过程中加载过多的冗余的资源，在需要用到通用资源时，再根据依赖关系对通用资源进行加载，从而减少了资源加载时的冗余度和下载量，提高了游戏运行的流畅度。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

在本发明实施例中，提供了一种上述资源文件的生成方法的实施例。作为一种可选的实施方式，该资源文件的生成方法可以但不限于应用于如图6所示的应用环境中，服务器602用于检测是否需要为游戏应用中的ui系统生成资源文件，或者，是否需要为游戏应用中的场景系统生成资源文件；在检测出需要为游戏应用中的ui系统生成资源文件的情况下，生成ui系统所需的一个第一资源文件，其中，第一资源文件中包括ui系统所需的资源以及所需的资源所依赖的资源；在检测出需要为游戏应用中的场景系统生成资源文件的情况下，生成场景系统所需的多个第二资源文件，其中，多个第二资源文件之间在加载时存在依赖关系，每个第二资源文件包括一个或多个资源。

在本实施例中，服务器602根据游戏应用运行中的系统类型生成资源文件，对于ui系统，将ui系统所需的资源以及所需的资源所依赖的资源打包到一个第一资源文件中，从而生成一个第一资源文件，在加载ui系统时，只需加载这一个第一资源文件即可，减少了加载资源时的io读取次数，减少了io消耗，从而提高了游戏应用运行的流畅度，对于场景系统，根据资源之间的依赖关系生成多个第二资源文件，从而减少了资源的冗余度以及资源的下载量，减少了游戏应用运行时资源加载对内存的消耗，从而提高了现有技术中游戏应用运行的流畅度，进而克服现有技术中游戏应用运行的流畅度低的问题。

可选地，在本实施例中，上述服务器可以包括但不限于以下至少之一：手机、平板电脑、笔记本电脑、台式pc机、数字电视及其他进行资源文件生成的硬件设备。上述只是一种示例，本实施例对此不做任何限定。

可选地，在本实施例中，服务器602用于：获取ui系统所需的资源以及该所需的资源所依赖的资源；将ui系统所需的资源以及所需的资源所依赖的资源构建在一个第一资源文件中，得到一个第一资源文件。

可选地，在本实施例中，服务器602用于：获取场景系统资源以及该场景系统资源所依赖的资源；根据场景系统资源以及该场景系统资源所依赖的资源之间的依赖关系为场景系统构建多个第二资源文件。

可选地，在本实施例中，服务器602用于：分别将场景系统资源以及场景系统资源所依赖的资源构建在资源文件中，得到多个第二资源文件，其中，每个场景系统资源构建在一个第二资源文件中，场景系统资源所依赖的每个资源构建在一个第二资源文件中；根据场景系统资源以及场景系统资源所依赖的资源之间的依赖关系记录多个第二资源文件之间的依赖关系。

可选地，在本实施例中，服务器602用于：检测是否需要根据通用资源生成资源文件，其中，通用资源被设置为用于ui系统和场景系统；在检测到需要根据通用资源生成资源文件时，根据通用资源和通用资源所依赖的资源生成多个第三资源文件。

可选地，在本实施例中，服务器602用于：生成多个第三资源文件中的第一部分资源文件，其中，每个第一部分资源文件包括一个通用资源所依赖的资源；生成多个第三资源文件中的第二部分资源文件，其中，每个第二部分资源文件包括一个通用资源，通用资源之间没有依赖关系，第二部分资源文件中包括的通用资源依赖于第一部分资源文件中的资源。

可选地，在本实施例中，服务器602用于：获取通用资源所依赖的资源以及通用资源所依赖的资源中每个资源的特征值，其中，资源的特征值根据资源的资源大小与资源被依赖的次数得到；将通用资源所依赖的资源中特征值大于预定阈值的资源分别构建在一个资源文件中，得到第一部分资源文件。

可选地，在本实施例中，服务器602用于：将每个所述通用资源与所述每个所述通用资源所依赖的资源中所述特征值小于或等于所述预定阈值的资源构建在一个资源文件，得到所述第二部分资源文件。

根据本发明实施例，提供了一种资源文件的生成方法，如图7所示，该方法包括：

s702，检测是否需要为游戏应用中的ui系统生成资源文件，或者，是否需要为游戏应用中的场景系统生成资源文件；

s704，在检测出需要为游戏应用中的ui系统生成资源文件的情况下，生成ui系统所需的一个第一资源文件，其中，第一资源文件中包括ui系统所需的资源以及ui系统所需的资源所依赖的资源；

s706，在检测出需要为游戏应用中的场景系统生成资源文件的情况下，生成场景系统所需的多个第二资源文件，其中，多个第二资源文件之间在加载时存在依赖关系，每个第二资源文件包括一个或多个资源。

可选地，在本实施例中，上述资源文件的生成方法可以但不限于应用于生成游戏资源文件的场景中。

可选地，在本实施例中，上述ui系统可以但不限于包括游戏中的菜单界面、状态界面、技能界面、商城界面、游戏模式选择界面、关卡选择界面等等。

例如：以关卡选择界面为例，如图3所示，该对战模式的选择界面的ui系统所需的资源包括各个关卡的选项卡，游戏模式选项“自动”和“战斗”等等，该对战模式的选择界面的ui系统所需的资源所依赖的资源包括各个关卡的选项卡中的贴图、文字描述、关卡难易程度的标签(例如：关卡2对应标签“困难”)等等，这些资源都被打包在第一资源文件中，也就是说，加载了第一资源文件就相当于加载了跳转到该ui系统所需的全部资源。

可选地，在本实施例中，上述场景系统可以但不限于包括射击游戏中的战斗场景、对战游戏中的对战场景、竞速类游戏中的竞技场景、体育类游戏中的比赛场景等等。

例如：以射击游戏中的战斗场景为例，如图4所示，场景系统中包括了各种资源，例如：场景、树木、麻袋、箱子等等，这些资源被打包在多个第二资源文件，这多个第二资源文件之间具有依赖关系，比如，该场景系统下的多个场景中均有树木、麻袋和箱子，那么获取的多个第二资源文件中可以包括多个打包有不同场景资源的第二资源文件以及打包有树木资源的第二资源文件、打包有麻袋资源的第二资源文件和打包有箱子资源的第二资源文件各一个，那么在加载的过程中，可以先加载树木、箱子、麻袋的第二资源文件，再在需要进入各个场景时分别加载对应场景的第二资源文件。

可见，通过上述步骤，根据游戏应用运行中的系统类型生成资源文件，对于ui系统，将ui系统所需的资源以及所需的资源所依赖的资源打包到一个第一资源文件中，从而生成一个第一资源文件，在加载ui系统时，只需加载这一个第一资源文件即可，减少了加载资源时的io读取次数，减少了io消耗，从而提高了游戏应用运行的流畅度，对于场景系统，根据资源之间的依赖关系生成多个第二资源文件，从而减少了资源的冗余度以及资源的下载量，减少了游戏应用运行时资源加载对内存的消耗，从而提高了现有技术中游戏应用运行的流畅度，进而克服现有技术中游戏应用运行的流畅度低的问题。

作为一种可选的方案，生成ui系统所需的一个第一资源文件包括：

s1，获取ui系统所需的资源以及ui系统所需的资源所依赖的资源；

s2，将ui系统所需的资源以及所需的资源所依赖的资源构建在一个第一资源文件中，得到一个第一资源文件。

可选地，在本实施例中，对于游戏应用的ui系统，区分每个系统自己用到的资源。例如贴图，除了一张公用的贴图集，每个系统需管理自身的图集。这样能杜绝某张图集被多个系统同时依赖，整体构建导致冗余，分开构建又会增加文件个数导致加载时io增加。所以针对游戏应用的ui系统，每个系统独享自己的资源，将ui系统和其所依赖的资源整合打包在一个产出文件(即第一资源文件)里。

例如：如图8所示，在生成ui系统a的资源文件时，获取到ui系统所需的资源objecta以及该所需的资源objecta所依赖的资源objectb和贴图资源，将获取到的objecta、objectb和贴图资源构建在一个产出文件中，生成第一资源文件a.unity3d。

通过上述步骤，游戏运行时，跳转到某个ui系统时只需要加载这个整体的第一资源文件，只进行一次io读取即可。既大大降低io次数，也大大减少因为每个文件太小导致的每次io读取浪费太多，从而提高了游戏运行的流畅度。

作为一种可选的方案，生成场景系统所需的多个第二资源文件包括：

s1，获取场景系统资源以及场景系统资源所依赖的资源；

s2，根据场景系统资源以及场景系统资源所依赖的资源之间的依赖关系为场景系统构建多个第二资源文件

可选地，在本实施例中，可以通过以下方式构建多个第二资源文件：分别将场景系统资源以及场景系统资源所依赖的资源构建在资源文件中，得到多个第二资源文件，其中，每个场景系统资源构建在一个第二资源文件中，场景系统资源所依赖的每个资源构建在一个第二资源文件中，并根据场景系统资源以及该场景系统资源所依赖的资源之间的依赖关系记录多个第二资源文件之间的依赖关系。

可选地，在本实施例中，对于游戏应用内的场景系统的资源(例如：战斗资源)可以采取的方式是尽可能独立构建资源文件。在进入游戏战斗场景之前，都会进行一段时间的加载和预加载。会有如图5所示的一个专门的界面显示加载中，在这个时间点，多一些少一些时间，只要不太过分甚至卡死不动，对于玩家来说都是可以接受的。当采用尽可能独立构建资源的时候，会产生很多的零散资源文件，加载的时候，确实会需要更多的cpu和内存占用，但玩家几乎察觉不出来。

例如：如图9所示，在生成战斗系统a的资源文件时，获取到战斗系统a所需的资源objecta以及该所需的资源objecta所依赖的资源objectb和贴图资源，分别将获取到的objecta、objectb和贴图资源构建在三个产出文件中，生成多个第二资源文件a.unity3d、b.unity3d和atlas.unity3d。

可见，通过上述步骤，大大减少了场景系统资源的冗余度，也就是大大减少资源的磁盘占用。这同时也会降低玩家的资源下载量，而且量级上十分显著，对于游戏整体评价和数据也会有积极的提升。

作为一种可选的方案，在检测是否需要为游戏应用中的ui系统生成资源文件，或者，是否需要为所述游戏应用中的场景系统生成资源文件时，还包括：

s1，检测是否需要根据通用资源生成资源文件，其中，所述通用资源被设置为用于所述ui系统和所述场景系统；

s2，在检测到需要根据通用资源生成资源文件时，根据通用资源和通用资源所依赖的资源生成多个第三资源文件。

可选地，在本实施例中，可以通过以下方式生成多个第三资源文件：生成多个第三资源文件中的第一部分资源文件，其中，每个第一部分资源文件包括一个通用资源所依赖的资源；生成多个第三资源文件中的第二部分资源文件，其中，每个第二部分资源文件包括一个通用资源，通用资源之间没有依赖关系，第二部分资源文件中包括的通用资源依赖于第一部分资源文件中的资源。

可选地，在本实施例中，可以通过以下方式生成多个第三资源文件中的第一部分资源文件：获取通用资源所依赖的资源以及通用资源所依赖的资源中每个资源的特征值，其中，资源的特征值根据资源的资源大小与资源被依赖的次数得到；将通用资源所依赖的资源中特征值大于预定阈值的资源分别构建在一个资源文件中，得到第一部分资源文件。

可选地，在本实施例中，可以通过以下方式生成多个第三资源文件中的第二部分资源文件：将每个通用资源与每个通用资源所依赖的资源中特征值小于或等于预定阈值的资源构建在一个资源文件，得到第二部分资源文件。

可选地，在本实施例中，可以记录第一部分资源文件和第二部分资源文件之间的依赖关系，将生成的具有依赖关系的第一部分资源文件和第二部分资源文件作为多个第三资源文件。

例如：需要构建的通用资源为通用资源a、通用资源b和通用资源c，通用资源a依赖的资源有资源d、资源e、资源f，通用资源b依赖的资源有资源e、资源f和资源g，通用资源c依赖的资源有资源e和资源f，那么，通过计算得到资源d、资源e、资源f、资源g的特征值分别为1、3、3、1，为通用资源所依赖的资源中特征值大于2的资源分别构建资源文件，得到第一部分资源文件e.unity3d、f.unity3d。为通用资源与通用资源所依赖的资源中特征值不大于2的资源构建资源文件，得到第二部分资源文件a.unity3d、b.unity3d和c.unity3d，其中，a.unity3d中包括通用资源a和资源d，b.unity3d中包括通用资源b和资源g，c.unity3d中包括通用资源c。记录生成的资源文件中的依赖关系：a.unity3d、b.unity3d和c.unity3d均依赖于e.unity3d、f.unity3d，从而得到多个第三资源文件。

在一个示例中，对于通用资源，因为不存在像上述ui系统资源和场景系统资源的特殊性，所以可以使用下面的方式来进行构建。最终的目标，就是使得资源细分的颗粒度和冗余度，达到一个合理的平衡点。可以通过以下步骤为通用资源生成资源文件：

步骤1，获取每个需要构建的通用资源所依赖的所有资源。

步骤2，将有被多个资源所依赖的资源提出到被依赖资源列表中，并统计其被依赖的次数。

步骤3，对被依赖资源列表中的资源进行降序排序，计算资源的特征值＝资源大小*(资源被依赖次数-1)。

步骤4，取定阀值(相当于上述预设条件)，将前n个资源进行依赖堆栈的压栈，并进行独立构建，得到上述第一部分资源文件。

步骤5，构建完所依赖资源后，压入所需的上层资源，并进行资源文件的构建，得到上述第二部分资源文件。

其中步骤3里面的特征值表示一旦将被依赖的本资源独立构建出去，能获得的冗余收益，该值越大，独立构建带来的资源冗余越少。

对于这些通用资源，为了避免频繁加载卸载，程序中还会有资源加载系统对其进行管理。加载资源后，先缓存在内存，不急着卸载，避免引起gc的过度消耗。同时制定缓存个数和空间的阀值，使用lru算法，淘汰最长时间未使用的缓存资源。这样做以达到避免频繁io和频繁gc的过度消耗。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例3

根据本发明实施例，还提供了一种用于实施上述资源加载方法的资源加载装置，如图10所示，该装置包括：

1)第一检测模块1002，用于在游戏应用运行的过程中，检测是否跳转到游戏应用中的ui系统，或，是否进入游戏应用中的场景系统；

2)第一处理模块1004，耦合至第一检测模块1002，用于在游戏应用运行的过程中，检测是否跳转到游戏应用中的ui系统，或，是否进入游戏应用中的场景系统；

3)第二处理模块1006，耦合至第一检测模块1002，用于在检测到进入游戏应用中的场景系统的情况下，获取场景系统所需的多个第二资源文件，并根据多个第二资源文件之间的依赖关系对多个第二资源文件中的资源进行加载，其中，每个第二资源文件包括一个或多个资源。

可选地，在本实施例中，上述资源加载装置可以但不限于应用于游戏应用客户端运行过程中加载资源的场景。其中，上述游戏应用客户端可以但不限于为各种类型的游戏，例如，对战类游戏、消除类游戏、角色扮演类游戏、射击类游戏等等。上述仅是一种示例，本实施例中对此不做任何限定。

可选地，在本实施例中，上述ui系统可以但不限于包括游戏中的菜单界面、状态界面、技能界面、商城界面、游戏模式选择界面、关卡选择界面等等。

例如：以关卡选择界面为例，如图3所示，该对战模式的选择界面的ui系统所需的资源包括各个关卡的选项卡，游戏模式选项“自动”和“战斗”等等，该对战模式的选择界面的ui系统所需的资源所依赖的资源包括各个关卡的选项卡中的贴图、文字描述、关卡难易程度的标签(例如：关卡2对应标签“困难”)等等，这些资源都被打包在第一资源文件中，也就是说，加载了第一资源文件就相当于加载了跳转到该ui系统所需的全部资源。

可选地，在本实施例中，上述场景系统可以但不限于包括射击游戏中的战斗场景、对战游戏中的对战场景、竞速类游戏中的竞技场景、体育类游戏中的比赛场景等等。

例如：以射击游戏中的战斗场景为例，如图4所示，场景系统中包括了各种资源，例如：场景、树木、麻袋、箱子等等，这些资源被打包在多个第二资源文件，这多个第二资源文件之间具有依赖关系，比如，该场景系统下的多个场景中均有树木、麻袋和箱子，那么获取的多个第二资源文件中可以包括多个打包有不同场景资源的第二资源文件以及打包有树木资源的第二资源文件、打包有麻袋资源的第二资源文件和打包有箱子资源的第二资源文件各一个，那么在加载的过程中，可以先加载树木、箱子、麻袋的第二资源文件，再在需要进入各个场景时分别加载对应场景的第二资源文件。

可见，通过上述装置，在游戏应用的运行过程中，对游戏中系统的切换进行检测，比如检测是否跳转到游戏应用中的ui系统，或，是否进入游戏应用中的场景系统，对于跳转到游戏应用中的ui系统的情况，由于该ui系统所需的资源以及所需的资源所依赖的资源均构建在了一个第一资源文件中，只需获取这一个第一资源文件并加载其中的资源即可跳转到该ui系统，对于进入游戏应用中的场景系统的情况，可以获取该场景系统所需的具有依赖关系的多个第二资源文件，并根据依赖关系加载多个第二资源文件中的资源，可见，对于ui系统将需要的资源通过一个第一资源文件加载，可以减少读取资源的次数，从而提高了游戏运行的流畅度，而对于场景系统则根据多个第二资源文件之间的依赖关系加载资源，减少了场景系统下资源的冗余度，从而也减少了场景系统下资源对磁盘的占用，提高了游戏运行的流畅度，进而克服现有技术中游戏运行流畅度低的问题。

作为一种可选的方案，第一处理模块用于：

1)通过一次io读取来获取一个第一资源文件。

可选地，在本实施例中，由于ui系统所需的资源均被打包在一个第一资源文件中，那么，在获取这个第一资源文件时可以通过一次io读取来得到该第一资源文件。当玩家在操作ui界面的时候，玩家会要求界面的流畅度，不会有卡顿的感觉，包括界面的滑进滑出等动画效果也需要流畅。通过上述步骤，可以大大减少在加载ui系统时的io读取次数，从而减少加载资源时的io消耗，提高了游戏运行的流畅度。

作为一种可选的方案，第二处理模块用于：

1)在进入游戏应用中的场景系统之前，获取场景系统所需的多个第二资源文件，并根据多个第二资源文件之间的依赖关系对多个第二资源文件进行加载。

可选地，在本实施例中，由于ui系统所需的资源均被打包在一个第一资源文件中，那么，在获取这个第一资源文件时可以通过一次io读取来得到该第一资源文件。当玩家在操作ui界面的时候，玩家会要求界面的流畅度，不会有卡顿的感觉，包括界面的滑进滑出等动画效果也需要流畅。通过上述步骤，可以大大减少在加载ui系统时的io读取次数，从而减少加载资源时的io消耗，提高了游戏运行的流畅度。

作为一种可选的方案，上述装置还包括：

1)第二检测模块，用于在游戏应用运行的过程中，检测是否需要加载通用资源，其中，通用资源被设置为用于ui系统和场景系统；

2)获取模块，用于在检测到需要加载通用资源时，获取根据通用资源和通用资源所依赖的资源生成的多个第三资源文件；

3)加载模块，用于加载多个第三资源文件中的资源。

可选地，在本实施例中，上述通用资源被设置为用于ui系统和场景系统。例如：音效资源、装备资源等等。

作为一种可选的方案，加载模块包括：

1)第一加载单元，用于对多个第三资源文件中的第一部分资源文件中的资源进行加载，其中，每个第一部分资源文件包括一个通用资源所依赖的资源；

2)第二加载单元，用于按照通用资源与通用资源所依赖的资源之间的依赖关系，对多个第三资源文件中的第二部分资源文件中的资源进行加载，其中，每个第二部分资源文件包括一个通用资源，通用资源之间没有依赖关系，第二部分资源文件中包括的通用资源依赖于第一部分资源文件中的资源。

例如：在检测到需要加载通用资源a时，获取根据该通用资源a和通用资源a所依赖的资源b、c、d生成的两个第三资源文件e和第三资源文件f，其中，第三资源文件e中打包了资源a、c、d，第三资源文件f中打包了资源b，由于通用资源a依赖于资源b，那么在加载时，先加载第三资源文件f，再加载第三资源文件e来实现对通用资源a的加载。

可见，通过上述步骤，在游戏应用运行的过程中，检测是否需要加载被设置为用于ui系统和场景系统的通用资源，在需要加载通用资源时再对通用资源进行加载，可以避免在游戏应用运行的过程中加载过多的冗余的资源，在需要用到通用资源时，再根据依赖关系对通用资源进行加载，从而减少了资源加载时的冗余度和下载量，提高了游戏运行的流畅度。

实施例4

根据本发明实施例，还提供了一种用于实施上述资源文件的生成方法的资源文件的生成装置，如图11所示，该装置包括：

1)第三检测模块1102，用于检测是否需要为游戏应用中的ui系统生成资源文件，或者，是否需要为游戏应用中的场景系统生成资源文件；

2)第一生成模块1104，耦合至第三检测模块1102，用于在检测出需要为游戏应用中的ui系统生成资源文件的情况下，生成ui系统所需的一个第一资源文件，其中，第一资源文件中包括ui系统所需的资源以及ui系统所需的资源所依赖的资源；

3)第二生成模块1106，耦合至第三检测模块1102，用于在检测出需要为游戏应用中的场景系统生成资源文件的情况下，生成场景系统所需的多个第二资源文件，其中，多个第二资源文件之间在加载时存在依赖关系，每个第二资源文件包括一个或多个资源。

可选地，在本实施例中，上述资源文件的生成装置可以但不限于应用于生成游戏资源文件的场景中。

可选地，在本实施例中，上述ui系统可以但不限于包括游戏中的菜单界面、状态界面、技能界面、商城界面、游戏模式选择界面、关卡选择界面等等。

例如：以关卡选择界面为例，如图3所示，该对战模式的选择界面的ui系统所需的资源包括各个关卡的选项卡，游戏模式选项“自动”和“战斗”等等，该对战模式的选择界面的ui系统所需的资源所依赖的资源包括各个关卡的选项卡中的贴图、文字描述、关卡难易程度的标签(例如：关卡2对应标签“困难”)等等，这些资源都被打包在第一资源文件中，也就是说，加载了第一资源文件就相当于加载了跳转到该ui系统所需的全部资源。

可选地，在本实施例中，上述场景系统可以但不限于包括射击游戏中的战斗场景、对战游戏中的对战场景、竞速类游戏中的竞技场景、体育类游戏中的比赛场景等等。

例如：以射击游戏中的战斗场景为例，如图4所示，场景系统中包括了各种资源，例如：场景、树木、麻袋、箱子等等，这些资源被打包在多个第二资源文件，这多个第二资源文件之间具有依赖关系，比如，该场景系统下的多个场景中均有树木、麻袋和箱子，那么获取的多个第二资源文件中可以包括多个打包有不同场景资源的第二资源文件以及打包有树木资源的第二资源文件、打包有麻袋资源的第二资源文件和打包有箱子资源的第二资源文件各一个，那么在加载的过程中，可以先加载树木、箱子、麻袋的第二资源文件，再在需要进入各个场景时分别加载对应场景的第二资源文件。

可见，通过上述装置，根据游戏应用运行中的系统类型生成资源文件，对于ui系统，将ui系统所需的资源以及所需的资源所依赖的资源打包到一个第一资源文件中，从而生成一个第一资源文件，在加载ui系统时，只需加载这一个第一资源文件即可，减少了加载资源时的io读取次数，减少了io消耗，从而提高了游戏应用运行的流畅度，对于场景系统，根据资源之间的依赖关系生成多个第二资源文件，从而减少了资源的冗余度以及资源的下载量，减少了游戏应用运行时资源加载对内存的消耗，从而提高了现有技术中游戏应用运行的流畅度，进而克服现有技术中游戏应用运行的流畅度低的问题。

作为一种可选的方案，第一生成模块包括：

1)第一获取单元，用于获取ui系统所需的资源以及所需的资源所依赖的资源；

2)第一构建单元，用于将所述ui系统所需的资源以及所述所需的资源所依赖的资源构建在一个第一资源文件中，得到所述一个第一资源文件。

可选地，在本实施例中，对于游戏应用的ui系统，区分每个系统自己用到的资源。例如贴图，除了一张公用的贴图集，每个系统需管理自身的图集。这样能杜绝某张图集被多个系统同时依赖，整体构建导致冗余，分开构建又会增加文件个数导致加载时io增加。所以针对游戏应用的ui系统，每个系统独享自己的资源，将ui系统和其所依赖的资源整合打包在一个产出文件(即第一资源文件)里。

例如：如图8所示，在生成ui系统a的资源文件时，获取到ui系统所需的资源objecta以及该所需的资源objecta所依赖的资源objectb和贴图资源，将获取到的objecta、objectb和贴图资源构建在一个产出文件中，生成第一资源文件a.unity3d。

通过上述装置，游戏运行时，跳转到某个ui系统时只需要加载这个整体的第一资源文件，只进行一次io读取即可。既大大降低io次数，也大大减少因为每个文件太小导致的每次io读取浪费太多，从而提高了游戏运行的流畅度。

作为一种可选的方案，第二生成模块包括：

1)第二获取单元，用于获取场景系统资源以及场景系统资源所依赖的资源；

2)第二构建单元，用于根据场景系统资源以及场景系统资源所依赖的资源之间的依赖关系为场景系统构建多个第二资源文件。

可选地，在本实施例中，第二构建单元用于：分别将场景系统资源以及场景系统资源所依赖的资源构建在资源文件中，得到多个第二资源文件，其中，每个场景系统资源构建在一个第二资源文件中，场景系统资源所依赖的每个资源构建在一个第二资源文件中；根据场景系统资源以及场景系统资源所依赖的资源之间的依赖关系记录多个第二资源文件之间的依赖关系。

可选地，在本实施例中，对于游戏应用内的场景系统的资源(例如：战斗资源)可以采取的方式是尽可能独立构建资源文件。在进入游戏战斗场景之前，都会进行一段时间的加载和预加载。会有如图5所示的一个专门的界面显示加载中，在这个时间点，多一些少一些时间，只要不太过分甚至卡死不动，对于玩家来说都是可以接受的。当采用尽可能独立构建资源的时候，会产生很多的零散资源文件，加载的时候，确实会需要更多的cpu和内存占用，但玩家几乎察觉不出来。

例如：如图9所示，在生成战斗系统a的资源文件时，获取到战斗系统a所需的资源objecta以及该所需的资源objecta所依赖的资源objectb和贴图资源，分别将获取到的objecta、objectb和贴图资源构建在三个产出文件中，生成多个第二资源文件a.unity3d、b.unity3d和atlas.unity3d。

可见，通过上述装置，大大减少了场景系统资源的冗余度，也就是大大减少资源的磁盘占用。这同时也会降低玩家的资源下载量，而且量级上十分显著，对于游戏整体评价和数据也会有积极的提升。

作为一种可选的方案，上述装置还包括：

1)第四检测模块，在检测是否需要为游戏应用中的ui系统生成资源文件，或者，是否需要为游戏应用中的场景系统生成资源文件时，检测是否需要根据通用资源生成资源文件，其中，通用资源被设置为用于ui系统和场景系统；

2)第三生成模块，用于在检测到需要根据通用资源生成资源文件时，根据通用资源和通用资源所依赖的资源生成多个第三资源文件。

可选地，在本实施例中，第三生成模块包括：

1)第一生成单元，用于生成多个第三资源文件中的第一部分资源文件，其中，每个第一部分资源文件包括一个通用资源所依赖的资源；

2)第二生成单元，用于生成多个第三资源文件中的第二部分资源文件，其中，每个第二部分资源文件包括一个通用资源，通用资源之间没有依赖关系，第二部分资源文件中包括的通用资源依赖于第一部分资源文件中的资源。

可选地，在本实施例中，第一生成单元用于：获取通用资源所依赖的资源以及通用资源所依赖的资源中每个资源的特征值，其中，资源的特征值根据资源的资源大小与资源被依赖的次数得到；将通用资源所依赖的资源中特征值大于预定阈值的资源分别构建在一个资源文件中，得到第一部分资源文件。

可选地，在本实施例中，第二生成单元用于：将每个通用资源与每个通用资源所依赖的资源中特征值小于或等于预定阈值的资源构建在一个资源文件，得到第二部分资源文件。

可选地，在本实施例中，可以记录第一部分资源文件和第二部分资源文件之间的依赖关系，将生成的具有依赖关系的第一部分资源文件和第二部分资源文件作为多个第三资源文件。

例如：需要构建的通用资源为通用资源a、通用资源b和通用资源c，通用资源a依赖的资源有资源d、资源e、资源f，通用资源b依赖的资源有资源e、资源f和资源g，通用资源c依赖的资源有资源e和资源f，那么，通过计算得到资源d、资源e、资源f、资源g的特征值分别为1、3、3、1，为通用资源所依赖的资源中特征值大于2的资源分别构建资源文件，得到第一部分资源文件e.unity3d、f.unity3d。为通用资源与通用资源所依赖的资源中特征值不大于2的资源构建资源文件，得到第二部分资源文件a.unity3d、b.unity3d和c.unity3d，其中，a.unity3d中包括通用资源a和资源d，b.unity3d中包括通用资源b和资源g，c.unity3d中包括通用资源c。记录生成的资源文件中的依赖关系：a.unity3d、b.unity3d和c.unity3d均依赖于e.unity3d、f.unity3d，从而得到多个第三资源文件。

实施例5

本发明实施例的应用环境可以但不限于参照实施例1中的应用环境，本实施例中对此不再赘述。本发明实施例提供了用于实施上述资源加载方法的一种可选的具体应用示例。

作为一种可选的实施例，上述资源加载方法可以但不限于应用于对游戏应用客户端的资源进行加载的场景中。在游戏应用客户端(client)运行过程中，游戏的资源存放分两种：一种是包内资源，存放于游戏安装包内(如apk、ipa内)；另外一种是包外资源，存放在程序空间外的磁盘上。包外资源一般适用于游戏资源的增量更新，以及因为某种需求(例如：不希望游戏安装包太大)，需要将资源提出包外。包外资源的获取方式一般是在进入游戏之前，进行下载，或者是根据游戏进程，在需要使用的时候实时进行下载。

下载资源后，客户端需要对下载的资源进行加载，加载资源时将会占用内存空间或者消耗io资源。玩家玩游戏的时候，最注重的肯定是游戏的可玩性和流畅性。像fps类游戏，玩家对于手感的要求非常高，一丝的卡顿，很容易就会影响到高端玩家的体验和精准。根据游戏的模式，流畅性也分为两大类：ui系统与游戏战斗操作系统(相当于上述场景系统)。

当玩家在操作ui系统的时候，玩家会要求界面的流畅度，不会有卡顿的感觉，包括界面的滑进滑出等动画效果也需要流畅。在跳转到游戏应用中的ui系统时，可以获取ui系统所需的一个第一资源文件，并加载第一资源文件中的资源。对于ui系统将需要的资源通过一个第一资源文件加载，可以减少读取资源的次数，从而提高了游戏运行的流畅度，在资源大小、加载、卸载等方面对游戏ui系统操作进行优化。

对于游戏战斗操作系统中的资源加载，玩家在进入游戏战斗操作系统前可以进行一小段时间的资源预加载，这个时间对于玩家来说是有预期的，只要不是时间非常长，对于玩家来说，都不会是影响体验的问题。可以获取游戏战斗操作系统所需的多个第二资源文件，并根据多个第二资源文件之间的依赖关系对多个第二资源文件中的资源进行加载，减少了场景系统下资源的冗余度，从而也减少了场景系统下资源对磁盘的占用，提高了游戏运行的流畅度。

而当玩家在游戏内进行战斗的时候，是游戏最核心的玩法，必须得保证游戏流畅，因为可能稍微的卡顿也会影响游戏结果，玩家对于战斗中的卡顿也会非常地介意。对于战斗中需要的通用资源的加载，可以在检测到需要加载通用资源时，获取根据通用资源和通用资源所依赖的资源生成的多个第三资源文件，并对多个第三资源文件中的第一部分资源文件中的资源进行加载，其中，每个第一部分资源文件包括一个通用资源所依赖的资源，再按照通用资源与通用资源所依赖的资源之间的依赖关系，对多个第三资源文件中的第二部分资源文件中的资源进行加载，可以保证在这个环节中，从资源大小、预加载、加载、复用、卸载等方面对游戏内战斗操作进行优化。

实施例6

本发明实施例的应用环境可以但不限于参照实施例2中的应用环境，本实施例中对此不再赘述。本发明实施例提供了用于实施上述资源文件的生成方法的一种可选的具体应用示例。

作为一种可选的实施例，上述资源文件的生成方法可以但不限于应用于对游戏应用客户端的资源文件进行生成的场景中。在生成资源文件时，可以根据游戏应用中各个系统的特点，分别生成资源文件，将在需要为游戏应用中的ui系统生成资源文件的情况下，生成ui系统所需的一个第一资源文件，其中，第一资源文件中包括ui系统所需的资源以及ui系统所需的资源所依赖的资源，并在需要为游戏应用中的场景系统生成资源文件的情况下，生成场景系统所需的多个第二资源文件，其中，多个第二资源文件之间在加载时存在依赖关系，每个第二资源文件包括一个或多个资源。对于通用资源，可以根据通用资源和通用资源所依赖的资源生成多个第三资源文件。

通过上述方式生成资源文件，在资源下载时，可以尽可能地减少资源大小，就能减少玩家下载资源时等待的时间，这对于下载成功率和玩家留存都是有非常重大的意义。

实施例7

根据本发明实施例，还提供了一种用于实施上述资源加载方法的资源加载设备，如图12所示，该设备包括：

1)通讯接口1202，设置为获取ui系统所需的一个第一资源文件以及获取场景系统所需的多个第二资源文件，其中，第一资源文件中包括ui系统所需的资源以及所需的资源所依赖的资源，每个第二资源文件包括一个或多个资源；

2)处理器1204，与通讯接口1202连接，设置为在游戏应用运行的过程中，检测是否跳转到游戏应用中的ui系统，或，是否进入游戏应用中的场景系统；在检测到跳转到游戏应用中的ui系统的情况下，加载第一资源文件中的资源；在检测到进入游戏应用中的场景系统的情况下，根据多个第二资源文件之间的依赖关系对多个第二资源文件中的资源进行加载。

3)存储器1206，与通讯接口1202及处理器1204连接，设置为存储第一资源文件和第二资源文件。

可选地，本实施例中的具体示例可以参考上述实施例1和实施例3中所描述的示例，本实施例在此不再赘述。

实施例8

根据本发明实施例，还提供了一种用于实施上述资源加载方法的资源加载设备，如图13所示，该设备包括：

1)处理器1302，设置为检测是否需要为游戏应用中的ui系统生成资源文件，或者，是否需要为游戏应用中的场景系统生成资源文件；在检测出需要为游戏应用中的ui系统生成资源文件的情况下，生成ui系统所需的一个第一资源文件，其中，第一资源文件中包括ui系统所需的资源以及ui系统所需的资源所依赖的资源；在检测出需要为游戏应用中的场景系统生成资源文件的情况下，生成场景系统所需的多个第二资源文件，其中，多个第二资源文件之间在加载时存在依赖关系，每个第二资源文件包括一个或多个资源。

3)存储器1304，与处理器1302连接，设置为存储第一资源文件和第二资源文件。

可选地，本实施例中的具体示例可以参考上述实施例2和实施例4中所描述的示例，本实施例在此不再赘述。

实施例9

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以位于网络中的多个网络设备中的至少一个网络设备。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

s1，在游戏应用运行的过程中，检测是否跳转到游戏应用中的ui系统，或，是否进入游戏应用中的场景系统；

s2，在检测到跳转到游戏应用中的ui系统的情况下，获取ui系统所需的一个第一资源文件，并加载第一资源文件中的资源，其中，第一资源文件中包括ui系统所需的资源以及ui系统所需的资源所依赖的资源；

s3，在检测到进入游戏应用中的场景系统的情况下，获取场景系统所需的多个第二资源文件，并根据多个第二资源文件之间的依赖关系对多个第二资源文件中的资源进行加载，其中，每个第二资源文件包括一个或多个资源。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：通过一次io读取来获取一个第一资源文件。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：在进入游戏应用中的场景系统之前，获取场景系统所需的多个第二资源文件，并根据多个第二资源文件之间的依赖关系对多个第二资源文件进行加载。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：检测是否需要加载通用资源，其中，通用资源被设置为用于ui系统和场景系统；在检测到需要加载通用资源时，获取根据通用资源和通用资源所依赖的资源生成的多个第三资源文件；加载多个第三资源文件中的资源。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：对多个第三资源文件中的第一部分资源文件中的资源进行加载，其中，每个第一部分资源文件包括一个通用资源所依赖的资源；按照通用资源与通用资源所依赖的资源之间的依赖关系，对多个第三资源文件中的第二部分资源文件中的资源进行加载，其中，每个第二部分资源文件包括一个通用资源，通用资源之间没有依赖关系，第二部分资源文件中包括的通用资源依赖于第一部分资源文件中的资源。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：

s4，检测是否需要为游戏应用中的ui系统生成资源文件，或者，是否需要为游戏应用中的场景系统生成资源文件；

s5，在检测出需要为游戏应用中的ui系统生成资源文件的情况下，生成ui系统所需的一个第一资源文件，其中，第一资源文件中包括ui系统所需的资源以及ui系统所需的资源所依赖的资源；

s6，在检测出需要为游戏应用中的场景系统生成资源文件的情况下，生成场景系统所需的多个第二资源文件，其中，多个第二资源文件之间在加载时存在依赖关系，每个第二资源文件包括一个或多个资源。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：获取ui系统所需的资源以及ui系统所需的资源所依赖的资源；将ui系统所需的资源以及所需的资源所依赖的资源构建在一个第一资源文件中，得到一个第一资源文件。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：获取场景系统资源以及场景系统资源所依赖的资源；根据场景系统资源以及场景系统资源所依赖的资源之间的依赖关系为场景系统构建多个第二资源文件。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：分别将场景系统资源以及场景系统资源所依赖的资源构建在资源文件中，得到多个第二资源文件，其中，每个场景系统资源构建在一个第二资源文件中，场景系统资源所依赖的每个资源构建在一个第二资源文件中；根据场景系统资源以及场景系统资源所依赖的资源之间的依赖关系记录多个第二资源文件之间的依赖关系。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：检测是否需要根据通用资源生成资源文件，其中，通用资源被设置为用于ui系统和场景系统；在检测到需要根据通用资源生成资源文件时，根据通用资源和通用资源所依赖的资源生成多个第三资源文件。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：生成多个第三资源文件中的第一部分资源文件，其中，每个第一部分资源文件包括一个通用资源所依赖的资源；生成多个第三资源文件中的第二部分资源文件，其中，每个第二部分资源文件包括一个通用资源，通用资源之间没有依赖关系，第二部分资源文件中包括的通用资源依赖于第一部分资源文件中的资源。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：获取通用资源所依赖的资源以及通用资源所依赖的资源中每个资源的特征值，其中，资源的特征值根据资源的资源大小与资源被依赖的次数得到；将通用资源所依赖的资源中特征值大于预定阈值的资源分别构建在一个资源文件中，得到第一部分资源文件。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：将每个通用资源与每个通用资源所依赖的资源中特征值小于或等于预定阈值的资源构建在一个资源文件，得到第二部分资源文件。

可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

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

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

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

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。