分包资源下载方法及装置、存储介质、电子设备与流程

1.本公开涉及计算机技术领域，尤其涉及一种游戏应用的分包资源下载方法与游戏应用的分包资源下载装置、计算机可读存储介质及电子设备。


背景技术：

2.随着计算机和移动终端的普及，游戏已经成为一种越来越普遍的娱乐形式。随着游戏市场规模的不断扩大，游戏业的竞争日益激烈，优秀的游戏内容成为各游戏产商的核心竞争力。随之而来的，游戏包体的大小迅速增大，导致玩家下载patch(补丁)时间过长，使得玩家留存率下降。目前存在的一种分包下载的方法是首包(分包) 小patch 二段patch的形式。即首包包含游戏内所有代码，但是分包本身只包含了创建账号和角色展示的功能，玩家在分包界面只能在选择的服务器上进行角色创建。而其他游戏内容则需要进行新一轮的大patch下载后才能体验到。
3.这种分包下载方式的patch逻辑复杂，测试难度大，并且由于采取分段式patch，无法在游戏内自由选择下载单个资源文件。除此之外，首包无法体验游戏内容，玩家的游戏体验感下降，还存在安卓和ios的游戏文件不同，需要针对不同平台进行差异分包处理，提高了维护复杂度，并且ios系统还存在不过审的风险。
4.鉴于此，本领域亟需开发一种新的游戏应用的分包资源下载方法及装置。
5.需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。


技术实现要素：

6.本公开的目的在于提供一种游戏应用的分包资源下载方法、游戏应用的分包资源下载装置、计算机可读存储介质及电子设备，进而至少在一定程度上克服由于相关技术的限制而导致的资源下载自由度低和维护复杂度高的技术问题。
7.本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。
8.根据本发明实施例的第一个方面，提供一种游戏应用的分包资源下载方法，所述方法包括：
9.获取分包资源数据，并根据所述分包资源数据中的资源标识查找存储所述分包资源数据的虚拟路径；
10.根据所述虚拟路径确定所述分包资源数据的依赖关系，并根据所述依赖关系生成所述分包资源数据的目标标识列表；
11.对所述分包资源数据和所述目标标识列表进行转换更新处理得到包括所述目标标识列表的补丁列表，以进行下载。
12.在本发明的一种示例性实施例中，所述获取分包资源数据，包括：
13.获取资源分包表格；
14.对所述资源分包表格进行表格转换处理得到分包资源数据。
15.在本发明的一种示例性实施例中，所述根据所述虚拟路径确定所述分包资源数据的依赖关系，包括：
16.当所述分包资源数据非场景资源数据时，在资源仓库文件中根据所述虚拟路径确定所述分包资源数据的依赖关系；
17.当所述分包资源数据为场景资源数据时，在目标文件中根据所述虚拟路径确定所述分包资源数据的依赖关系。
18.在本发明的一种示例性实施例中，所述依赖关系包括可依赖关系和被依赖关系，
19.所述根据所述依赖关系生成所述分包资源数据的目标标识列表，包括：
20.对所述可依赖关系和所述被依赖关系进行唯一依赖判定得到依赖关系结果；
21.根据所述依赖关系结果对所述分包资源数据进行剔除更新处理得到更新后的分包资源数据，并根据所述更新后的分包资源数据生成目标标识列表。
22.在本发明的一种示例性实施例中，所述根据所述依赖关系生成所述分包资源数据的目标标识列表，包括：
23.根据所述依赖关系生成所述分包资源数据的初始标识列表，并获取与所述分包资源数据对应的系统标识；
24.利用所述系统标识对所述初始标识列表进行标识列表更新得到目标标识列表。
25.在本发明的一种示例性实施例中，所述根据所述依赖关系生成所述分包资源数据的目标标识列表，包括：
26.获取所述分包资源数据中的目标字段，并获取所述补丁列表的目标参数；
27.利用所述目标字段更新所述目标参数，并利用更新后的所述目标字段和所述依赖关系生成所述分包资源数据的目标标识列表。
28.在本发明的一种示例性实施例中，所述进行下载，包括：
29.获取所述补丁列表中的原始文件，并对所述信息摘要值进行预订更新处理得到目标文件；
30.对所述目标文件进行文件压缩处理更新后的补丁列表，以对所述更新后的补丁列表进行下载。
31.根据本发明实施例的第二个方面，提供一种游戏应用的分包资源下载装置，包括：
32.路径确定模块，被配置为获取分包资源数据，并根据所述分包资源数据中的资源标识查找存储所述分包资源数据的虚拟路径；
33.列表生成模块，被配置为根据所述虚拟路径确定所述分包资源数据的依赖关系，并根据所述依赖关系生成所述分包资源数据的目标标识列表；
34.分包下载模块，被配置为对所述分包资源数据和所述目标标识列表进行转换更新处理得到包括所述目标标识列表的补丁列表，以进行下载。
35.根据本发明实施例的第三个方面，提供一种电子设备，包括：处理器和存储器；其中，存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现上述任意示例性实施例中的游戏应用的分包资源下载方法。
36.根据本发明实施例的第四个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意示例性实施例中的游戏应用的分
包资源下载方法。
37.由上述技术方案可知，本公开示例性实施例中的游戏应用的分包资源下载方法、游戏应用的分包资源下载装置、计算机存储介质及电子设备至少具备以下优点和积极效果：
38.在本公开的示例性实施例提供的方法及装置中，获取到的分包资源数据可以细致划分到单个文件级别，自由对时装、场景、枪械和皮肤等资源进行分离，不影响其他游戏内容的体验，从而降低下载的补丁列表的大小。并且，根据依赖关系生成的目标标识列表能够避免游戏中因缺失资源而导致闪退的情况发生，将该包括目标标识列表的补丁列表扩展到各个平台，也解决了不同平台差异化分包下载带来的维护复杂度高和存在不过审风险的问题，同时也降低了测试复杂度，优化了玩家在分包资源下载方面的游戏体验。
39.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
40.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
41.图1示意性示出本公开示例性实施例中一种游戏应用的分包资源下载方法的流程示意图；
42.图2示意性示出本公开示例性实施例中获取分包资源数据的方法的流程示意图；
43.图3示意性示出本公开示例性实施例中根据资源标识查找存储分包资源数据的虚拟路径的方法的界面示意图；
44.图4示意性示出本公开示例性实施例中确定分包资源数据的依赖关系的方法的流程示意图；
45.图5示意性示出本公开示例性实施例中根据依赖关系生成目标标识列表的方法的流程示意图；
46.图6示意性示出本公开示例性实施例中生成目标标识列表的界面示意图；
47.图7示意性示出本公开示例性实施例中更新得到目标标识列表的方法的流程示意图；
48.图8示意性示出本公开示例性实施例中安卓系统的目标标识列表的界面示意图；
49.图9示意性示出本公开示例性实施例中根据目标字段生成目标标识列表的方法的流程示意图；
50.图10示意性示出本公开示例性实施例中修改后的patch_md5的结果示意图；
51.图11示意性示出本公开示例性实施例中下载补丁列表的方法的流程示意图；
52.图12示意性示出本公开示例性实施例中对各种资源集合进行关联判断的逻辑示意图；
53.图13示意性示出本公开示例性实施例中分包资源ui的界面示意图；
54.图14示意性示出本公开示例性实施例中应用场景下游戏应用的分包资源下载方
法的流程示意图；
55.图15示意性示出本公开示例性实施例中一种游戏应用的分包资源下载装置的结构示意图；
56.图16示意性示出本公开示例性实施例中一种用于实现游戏应用的分包资源下载方法的电子设备；
57.图17示意性示出本公开示例性实施例中一种用于实现游戏应用的分包资源下载方法的计算机可读存储介质。
具体实施方式
58.现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。
59.本说明书中使用用语“一个”、“一”、“该”和“所述”用以表示存在一个或多个要素/组成部分/等；用语“包括”和“具有”用以表示开放式的包括在内的意思并且是指除了列出的要素/组成部分/等之外还可存在另外的要素/组成部分/等；用语“第一”和“第二”等仅作为标记使用，不是对其对象的数量限制。
60.此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。
61.随着计算机和移动终端的普及，游戏已经成为一种越来越普遍的娱乐形式。随着游戏市场规模的不断扩大，游戏业的竞争日益激烈，优秀的游戏内容成为各游戏产商的核心竞争力。随之而来的，游戏包体的大小迅速增大，导致玩家下载patch时间过长，使得玩家留存率下降。目前存在的一种分包下载的方法是首包(分包) 小patch 二段patch的形式。即首包包含游戏内所有代码，但是分包本身只包含了创建账号和角色展示的功能，玩家在分包界面只能在选择的服务器上进行角色创建。而其他游戏内容则需要进行新一轮的大patch下载后才能体验到。
62.这种分包下载方式的patch逻辑复杂，测试难度大，并且由于采取分段式patch，无法在游戏内自由选择下载单个资源文件。除此之外，首包无法体验游戏内容，玩家的游戏体验感下降，还存在安卓和ios的游戏文件不同，需要针对不同平台进行差异分包处理，提高了维护复杂度，并且ios系统还存在不过审的风险。
63.针对相关技术中存在的问题，本公开提出了一种游戏应用的分包资源下载方法。图1示出了游戏应用的分包资源下载方法的流程图，如图1所示，游戏应用的分包资源下载方法至少包括以下步骤：
64.步骤s110.获取分包资源数据，并根据分包资源数据中的资源标识查找存储分包
资源数据的虚拟路径。
65.步骤s120.根据虚拟路径确定分包资源数据的依赖关系，并根据依赖关系生成分包资源数据的目标标识列表。
66.步骤s130.对分包资源数据和目标标识列表进行转换更新处理得到包括目标标识列表的补丁列表，以进行下载。
67.在本公开的示例性实施例中，获取到的分包资源数据可以细致划分到单个文件级别，自由对时装、场景、枪械和皮肤等资源进行分离，不影响其他游戏内容的体验，从而降低下载的补丁列表的大小。并且，根据依赖关系生成的目标标识列表能够避免游戏中因缺失资源而导致闪退的情况发生，将该包括目标标识列表的补丁列表扩展到各个平台，也解决了不同平台差异化分包下载带来的维护复杂度高和存在不过审风险的问题，同时也降低了测试复杂度，优化了玩家在分包资源下载方面的游戏体验。
68.下面对游戏应用的分包资源下载方法的各个步骤进行详细说明。
69.在步骤s110中，获取分包资源数据，并根据分包资源数据中的资源标识查找存储分包资源数据的虚拟路径。
70.在本公开的示例性实施例中，分包资源数据可以是对游戏里的所有资源进行分类得到的。举例而言，将游戏资源进行简单分类可以得到游戏场景、角色、特效、ui(user interface，用户界面)资源、数据表格和脚本文件等类型。并且，分包资源数据可以是messiah(弥赛亚)文件系统的资源数据，也可以是其他文件系统的分包资源数据，本示例性实施例对此不做特殊限定。
71.在可选的实施例中，图2示出了获取分包资源数据的方法的流程示意图，如图2所示，该方法至少包括以下步骤：在步骤s210中，获取资源分包表格。
72.通过对游戏流程的把控和项目需求的分析，可以知道部分资源是在用户刚进入游戏阶段就必须有的，有些资源是在刚开始的阶段用不到的，或者是一些资源是所有玩家进行游戏必须使用到的，有些资源是当玩家具有自身需求时才会用到的等。因此，可以根据对资源大小的评估结果，选择合适的分包资源名称填入到表格中得到资源分包表格。
73.在步骤s220中，对资源分包表格进行表格转换处理得到分包资源数据。
74.当得到资源分包表格之后，还可以对资源分包表格进行表格转换处理。具体的，该表格转换处理可以是将表格形式的资源分包表格转换成data数据，亦即分包资源数据。
75.在本示例性实施例中，根据获取到的资源分包表格可以得到对应的分包资源数据，使得分包资源数据的获取经过严格缜密的需求分析和流程把控，与游戏内容贴合度更加紧密和统一，进一步保障了玩家在不同阶段或者需求下的游戏娱乐体验。
76.在获取到分包资源数据之后，还可以进一步查找到存储分包资源数据的虚拟路径。
77.由于分包资源数据中包括分包资源的mod(modification，游戏模组)和目标字段，该mod即为资源标识。因此可以根据分包资源数据中的mod，例如时装或者枪皮资源的分包查找存储分包资源的虚拟路径。
78.具体的，可以通过查找与分包资源数据中的mod相关的data数据得到存储分包资源数据的虚拟路径。
79.图3示出了根据资源标识查找存储分包资源数据的虚拟路径的方法的界面示意
图，如图3所示，当时装资源的名称为圣诞骑手的上衣时，可以根据查询相关data数据的方式获取到该套时装相关的虚拟路径。
80.在步骤s120中，根据虚拟路径确定分包资源数据的依赖关系，并根据依赖关系生成分包资源数据的目标标识列表。
81.在本公开的示例性实施例中，查找到存储分包资源数据的虚拟路径之后，可以根据虚拟路径确定分包资源的依赖关系。
82.在可选的实施例中，图4示出了确定分包资源数据的依赖关系的方法的流程示意图，如图4所示，该方法至少包括以下步骤：在步骤s410中，当分包资源数据非场景资源数据时，在资源仓库文件中根据虚拟路径确定分包资源数据的依赖关系。
83.基于messiah文件系统独特的guid(globally unique identifier，全局唯一标识符)文件特点(即每个资源文件都用一个独有的guid表示)，根据虚拟路径去查找对应资源仓库文件的所有资源文件，messiah文件系统中的resource.repository文件记录了每个guid文件对应的属性。其中，deps属性代表该guid文件还依赖其他哪些guid文件，同样可以确定这些依赖的guid文件是被哪个guid文件所依赖，亦即依赖关系。因此，求算资源仓库文件中的所有resource.repository文件便可以得到所有guid文件的可依赖关系和被依赖关系。
84.在步骤s420中，当分包资源数据为场景资源数据时，在目标文件中根据虚拟路径确定分包资源数据的依赖关系。
85.对于场景资源数据的分包下载，可以是根据虚拟路径扫描整个场景里的物体对应资源，即对应场景的ilevel文件中定义引用了哪些物体以得到对应的依赖关系。
86.在本示例性实施例中，对于不同的分包资源数据，可以通过不同的文件确定对应的依赖关系，该依赖关系的确定准确度高，对分包资源下载提供了数据基础。
87.在确定分包资源数据的依赖关系之后，可以根据该依赖关系生成分包资源数据的目标标识列表。
88.在可选的实施例中，依赖关系包括可依赖关系和被依赖关系，图5示出了根据依赖关系生成目标标识列表的方法的流程示意图，如图5所示，该方法至少包括以下步骤：在步骤s510中，对可依赖关系和被依赖关系进行唯一依赖判定得到依赖关系结果。
89.具体的，通过比对某时装相关的虚拟路径和全部资源文件的关系，在所有资源文件中递归寻找该虚拟路径对应的全部依赖的guid列表。进一步的，使用递归方法来判断这些所有依赖的资源文件中的每个资源及其依赖是否只会被当前所有依赖的guid列表引用到。亦即，保证依赖的资源文件不会被包体里的其他资源文件引用到，以免出现游戏中文件缺失导致闪退的问题。
90.其中，对于场景资源的分包下载，可以使用相同的递归方法去得到每个资源文件对应的所有依赖资源的guid列表，接着判断其中每个资源及其依赖的引用关系。并且，还要保证这些资源不会在分包资源外的其他场景或脚本中被引用到。亦即，需要进行递归判断不同场景里的引用和依赖之间的关系。而根据脚本引用的虚拟路径求得对应的所有依赖的guid列表，再判断需要分包的资源是否存在于脚本对应的guid列表中，最后得到每个资源mod对应的，并且不影响分包资源外的游戏内容的guid列表。
91.在步骤s520中，根据依赖关系结果对分包资源数据进行剔除更新处理得到更新后
的分包资源数据，并根据更新后的分包资源数据生成目标标识列表。
92.当对可依赖关系和被依赖关系进行唯一依赖判定得到对应的依赖关系结果之后，可以在依赖关系结果为可依赖关系或被依赖关系还包括其他资源文件的引用时，从对应的guid列表中剔除掉被其他地方引用到的资源文件对应的分包资源数据，以得到更新后的分包资源数据，并且，该更新后的分包资源数据组成的guid列表即为目标标识列表。
93.图6示出了生成目标标识列表的界面示意图，如图6所示，a可以是将要分包的时装a对应的所有分包资源数据组成的guid列表，亦即标识列表，b为时装a的guid列表中资源文件的依赖情况。其中，a资源有a1、a2、a3的资源文件的依赖，而c资源有a、c1、c2的资源文件的依赖。亦即，a文件还被c资源引用到，但是这是属于自身guid列表中的内部引用，是被允许的。
94.而c可以是未分包的时装b的所有资源的guid列表，d为时装b的guid列表中资源文件的依赖情况。其中，d资源和e资源的依赖还包括a1资源，也就是a1资源被b时装里的一部分资源引用到了，那么a时装中的a资源的依赖已经被其他时装引用到了，如果依然将a资源的依赖a1作为分包资源数据，那么这部分资源下载patch的时候便不会进行下载，玩家如果使用到了b时装则会因缺少相关资源从而崩溃闪退。因此，可以将a1资源从时装a的guid列表中剔除来保证不会影响其他游戏内容。
95.在本示例性实施例中，通过对依赖关系进行唯一依赖判定，以生成目标标识列表，该目标标识列表可以尽可能大地分出相关联的资源，又保证不会造成由于正常游戏内容的关联文件缺失而导致的游戏崩溃闪退的情况发生。并且，对目标标识列表进行增、删和修改也不会影响整体游戏体验，还为开发人员提供了灵活调整需求的解决入口。
96.一般情况下，对于不分平台的资源，只需要生成一次，可以存储在common标识的文件夹中。但是，texture(贴图)和physics(物理)类型的资源都需要进行不同平台的区分。例如，安卓的贴图格式有etc2和etc1等，而ios的贴图格式有pvr、astc和dxtc等，所以贴图要根据不同平台的需要进行不同方法的压缩。但是，最开始对应的guid是一样的，只不过会根据压缩格式加入特定的后缀表明压缩格式，亦即进行了不同平台的区分。
97.因此，由于messiah文件系统的机制，不同平台的资源文件的guid名称会在原来的guid中加上不同的后缀，因此可以对生成的标识列表进行更新。
98.在可选的实施例中，图7示出了更新得到目标标识列表的方法的流程示意图，如图7所示，该方法至少包括以下步骤：在步骤s710中，根据依赖关系生成分包资源数据的初始标识列表，并获取与分包资源数据对应的系统标识。
99.对可依赖关系和被依赖关系进行唯一依赖判定得到依赖关系结果。
100.具体的，通过比对某时装相关的虚拟路径和全部资源文件的关系，在所有资源文件中递归寻找该虚拟路径对应的全部依赖的guid列表。进一步的，使用递归方法来判断这些所有依赖的资源文件中的每个资源及其依赖是否只会被当前所有依赖的guid列表引用到。亦即，保证依赖的资源文件不会被包体里的其他资源文件引用到，以免出现游戏中文件缺失导致闪退的问题。
101.其中，对于场景资源的分包下载，可以使用相同的递归方法去得到每个资源文件对应的所有依赖资源的guid列表，接着判断其中每个资源及其依赖的引用关系。并且，还要保证这些资源不会在分包资源外的其他场景或脚本中被引用到。亦即，需要进行递归判断
不同场景里的引用和依赖之间的关系。而根据脚本引用的虚拟路径求得对应的所有依赖的guid列表，再判断需要分包的资源是否存在于脚本对应的guid列表中，最后得到每个资源mod对应的，并且不影响分包资源外的游戏内容的guid列表。
102.根据依赖关系结果对分包资源数据进行剔除更新处理得到更新后的分包资源数据，并根据更新后的分包资源数据生成初始标识列表。
103.当对可依赖关系和被依赖关系进行唯一依赖判定得到对应的依赖关系结果之后，可以在依赖关系结果为可依赖关系或被依赖关系还包括其他资源文件的引用时，从对应的guid列表中剔除掉被其他地方引用到的资源文件对应的分包资源数据，以得到更新后的分包资源数据，并且，该更新后的分包资源数据组成的guid列表即为初始标识列表。
104.进一步的，获取与分包资源数据对应的系统标识。该系统标识可以是表征不同平台的标识。举例而言，.2可以是安卓系统的系统标识，.4可以是ios系统的系统标识。除此之外，也可以有其他形式的系统标识，本示例性实施例对此不做特殊限定。
105.具体的，后缀为.2代表的是贴图的etc1或者etc2的压缩格式，也就是代表安卓的贴图。而后缀为.4代表的是astc的压缩格式，即为ios的贴图。在步骤s720中，利用系统标识对初始标识列表进行标识列表更新得到目标标识列表。
106.在生成初始标识列表和获取到系统标识之后，可以根据该初始标识列表中的guid适用的系统进行标识列表更新。
107.具体的，在得到初始标识列表之后，只需判断当前patch_list里的资源去除后缀，亦即系统标识后是否在得到的guid列表中。如果是的话，将这个有后缀的guid替换掉原来的初始标识列表中的guid得到目标标识列表，最后将这个新的标识列表作为一个新mods放入patch_list中。因此，在patch下载的步骤中，只需判断需要下载的资源文件的guid名称是否在新mods中的guid列表中，存在的话便不进行下载，即可达到分包的目的。
108.图8示出了安卓系统的目标标识列表的界面示意图，如图8所示，common标识即表明安卓系统和ios系统均适用的guid，带有android标识的guid即只适用与安卓系统。因此，利用系统标识对初始标识列表标识列表更新得到的目标标识列表在不影响修改整个打patch流程的情况下，可以达到针对得到的目标标识列表扩展到修改所有平台的资源列表的目的。
109.值得说明的是，后缀为.2代表的安卓系统的贴图和后缀为.4代表的ios系统的贴图可以是对同一张原始的贴图进行压缩的，因此，除去后缀的话，guid也是一样的。基于此，根据一份原始得到的guid列表就可以得到扩展到不同平台的patch_list，并且，只需要判断生成的不同的patch_list文件中的guid列表如果去掉后缀后是否存在在原始的guid列表中，如果存在的话，替换掉原来的guid即可改变为该平台对应的资源文件。
110.其中，打patch即为将用到的资源文件转换成以guid为key(键)，且以资源文件对应的md5值和大小为value(值)的数据。
111.在本示例性实施例中，利用系统标识得到满足不同平台的目标标识列表，无需单独维护各个平台的分包内容，也不需要玩家更换游戏包体，整个分包过程对玩家来说是无感知的，游戏效果更佳。
112.除此之外，为了达到满足共研服等服务器的资源分包下载需求，还可以在不影响修改整个打patch流程的基础上，修改patch_md5，从而不影响其他服务器的分包需求。
113.在步骤s130中，对分包资源数据和目标标识列表进行转换更新处理得到包括目标标识列表的补丁列表，以进行下载。
114.在本公开的示例性实施例中，在得到目标标识列表之后，可以对分包资源数据和目标标识列表进行转换更新处理。亦即，基于目标标识列表修改patch_list这一补丁列表。
115.因此，需要在正常的打patch_list的流程中，嵌套修改patch_list。
116.值得说明的是，不能在打patch结束后，再去修改patch_list。具体的。这样会破坏patch_list文件的md5值，导致下载patch的时候检测失败。其次，还需要同时修改该版本相关的所有文件夹里的不同平台的patch_list来保持不会冲突。最后，若改变了正常的打patch流程，也会在一定程度上增加风险。
117.因此，可以使用patch_hook方法，在不改变任何打patch的代码的情况下，利用hook机制(在打patch的任何步骤之前或之后都可以调用一段新的代码)对分包资源数据和目标标识列表进行转换更新处理。
118.因此，在正常打patch流程最后生成patch_md5之前，可以调用修改patch_list的代码来对目前存在的patch_list进行修改，亦即在patch_list中增加目标标识列表，以得到包括目标标识列表的补丁列表。
119.除此之外，还可以根据补丁列表的设定对生成目标标识列表的参数进行修改，以满足共研服的资源分包下载需求。
120.在可选的实施例中，图9示出了根据目标字段生成目标标识列表的方法的流程示意图，如图9所示，该方法至少包括以下步骤：在步骤s910中，获取分包资源数据中的目标字段，并获取补丁列表的目标参数。
121.根据messiah文件系统的打patch机制，一些设定的参数是在patch_config里修改的，以使最后的参数修改反映到patch_md5里的元数据中。因此，可以获取补丁列表的目标参数patch_config。
122.并且，由于分包资源数据中还包括共研服服务器的特殊字段，因此可以获取该特殊字段作为目标字段。
123.在步骤s920中，利用目标字段更新目标参数，并利用更新后的目标字段和依赖关系生成分包资源数据的目标标识列表。
124.在获取到目标字段和目标参数之后，可以将该目标字段写入到patch_config这一目标参数中，表明共研服服务器需要将哪些资源mod进行分包，以在根据依赖关系生成分包资源数据的目标标识列表的同时，实现利用目标字段对对应patch_md5的修改，得到对应的目标标识列表。
125.图10示出了修改后的patch_md5的结果示意图，如图10所示，bdvpfo为共研服服务的标志字段，读取到该字段即表明需要进行共研服服务器的分包下载。而后面的3001即为分包下载资源对应的id(identity document，标识)，因此，在patch_list中读取该id即可得到对应的guid列表。
126.在本示例性实施例中，通过目标字段对目标参数的更新，可以得到满足共研服服务器的资源分包下载需求的目标标识列表，达到根据共研服服务器的对应字段实现新内容的分包下载，而不影响其他服务器的分包流程的效果。
127.更进一步的，生成包括目标标识列表的补丁列表之后，玩家可以对该补丁列表进
行下载。
128.在可选的实施例中，图11示出了下载补丁列表的方法的流程示意图，如图11所示，该方法至少包括以下步骤：在步骤s1110中，获取补丁列表中的原始文件，并对信息摘要值进行预订更新处理得到目标文件。
129.当发布patch以供玩家下载的时候，messiah文件系统的发布代码会修改发布平台的patch_md5文件来达到更新patch的目的。其中，next_patch_md5文件里的内容即为该新patch的文件夹名称，表明哪个patch进行预下载。
130.因此，在发布代码修改patch_md5文件的时候，可以对该原始文件增加一行修改next_patch_md5文件的代码得到目标文件。
131.在步骤s1120中，对目标文件进行文件压缩处理更新后的补丁列表，以对更新后的补丁列表进行下载。
132.在得到目标文件之后，可以在将该目标文件打包上传patch的压缩文件之前，将patch_md5文件复制到压缩文件中一起打包上传，这样就可以让游戏客户端访问到新的patch内容，亦即补丁列表，从而进行下载。
133.在本示例性实施例中，通过对原始文件进行预订更新处理和文件压缩处理，可以得到以供玩家下载的补丁列表，无需手动修改文件内容，避免误操作带来的风险，还可以使游戏客户端提前感知下载内容，对玩家更加友好。
134.基于步骤s110
‑
s130的游戏应用的分包资源下载方法的准备，游戏客户端的代码可以实现动态的分包下载功能。
135.首先，在修改patch下载代码的基础上，通过读取服务器上的patch_list文件可以得到所有的资源列表和分包下载的guid列表。为了满足分包下载的guid列表对应资源的增、删、修改操作对整个游戏内容没有影响的效果，也就是即使后面因为游戏版本内容导致的移除、修改或者增加某个分包资源mod里的某个资源也不会造成游戏内容的异常，例如缺少资源文件导致崩溃闪退或者修改某个资源的内容，但分包里的该资源没有进行改变等问题，需要对分包内容中已经下载的资源集合和未下载的资源集合、以及全部资源文件集合进行关联判断。
136.图12示出了对各种资源集合进行关联判断的逻辑示意图，如图12所示，a表示已经下载的资源集合，b表示未下载的资源集合，c表示全部资源文件集合。
137.其中，集合a和集合b可能存在共有资源，但是这部分资源如果发生变化，同样需要进行更新下载。而游戏中未进行下载的分包资源在每次进行patch下载时，并不需要进行额外判断和下载，所以可以将集合b减少集合a得到集合b独有的资源，再用集合c减少集合b独有的资源，该资源即是每次下载patch时和游戏客户端本地的文件进行比对判断md5和大小是否发生变化，来进行文件更新的部分。这样可以保证无论集合a和集合b中的资源如何变化，都不会影响整个游戏内容的完整性和游戏体验的效果。
138.除此之外，还可以在游戏中提供一个分包资源的ui。图13示出了分包资源ui的界面示意图，如图13所示，玩家可以主动进行下载某些资源mod来丰富游戏体验，而不影响其他游戏内容的体验。在大厅空闲时，可以去访问服务器上的next_patch_md5文件的内容和本地patch时间戳来判断是否有新的patch。如果存在新的patch时，可以根据patch_md5文件去下载节点上的patch文件到指定文件夹中。当正式外放patch_md5文件时，只需要比对
需要下载的文件是否存在在指定文件夹中。当存在于指定文件夹时，直接复制到patch文件夹中便可省略下载步骤直接进入游戏。而对于共研服服务器的包体，只需要根据patch_md5中的元数据里的数据进行专属的分包资源下载，即可实现动态的分包下载功能，优化玩家的用户体验。
139.下面结合一应用场景对本公开实施例中游戏应用的分包资源下载方法做出详细说明。
140.图14示出了应用场景下游戏应用的分包资源下载方法的流程示意图，如图14所示，在步骤s1410中，策划表格。
141.通过对游戏流程的把控和项目需求的分析，策划人员可以知道部分资源是在用户刚进入游戏阶段就必须有的，有些资源是在刚开始的阶段用不到的，或者是一些资源是所有玩家进行游戏必须使用到的，有些资源是当玩家具有自身需求时才会用到的等。因此，策划人员可以根据对资源大小的评估结果，选择合适的分包资源名称填入到表格中得到资源分包表格。
142.当得到资源分包表格之后，还可以对资源分包表格进行表格转换处理。具体的，该表格转换处理可以是将表格形式的资源分包表格转换成data数据，亦即分包资源数据。
143.在获取到分包资源数据之后，还可以进一步查找到存储分包资源数据的虚拟路径。
144.由于分包资源数据中包括分包资源的mod和目标字段，该mod即为资源标识。因此可以根据分包资源数据中的mod，例如时装或者枪皮资源的分包查找存储分包资源的虚拟路径。
145.具体的，可以通过查找与分包资源数据中的mod相关的data数据得到存储分包资源数据的虚拟路径。
146.查找到存储分包资源数据的虚拟路径之后，可以根据虚拟路径确定分包资源的依赖关系。
147.当分包资源数据非场景资源数据时，在资源仓库文件中根据虚拟路径确定分包资源数据的依赖关系。
148.基于messiah文件系统独特的guid(globally unique identifier，全局唯一标识符)文件特点(即每个资源文件都用一个独有的guid表示)，根据虚拟路径去查找对应资源仓库文件的所有资源文件，messiah文件系统中的resource.repository文件记录了每个guid文件对应的属性。其中，deps属性代表该guid文件还依赖其他哪些guid文件，同样可以确定这些依赖的guid文件是被哪个guid文件所依赖，亦即依赖关系。因此，求算资源仓库文件中的所有resource.repository文件便可以得到所有guid文件的可依赖关系和被依赖关系。
149.当分包资源数据为场景资源数据时，在目标文件中根据虚拟路径确定分包资源数据的依赖关系。
150.对于场景资源数据的分包下载，可以是根据虚拟路径扫描整个场景里的物体对应资源，即对应场景的ilevel文件中定义引用了哪些物体以得到对应的依赖关系。
151.在步骤s1420中，获得每个mod对应的guid列表。
152.在确定分包资源数据的依赖关系之后，可以根据该依赖关系生成分包资源数据的
目标标识列表。
153.对可依赖关系和被依赖关系进行唯一依赖判定得到依赖关系结果。
154.具体的，通过比对某时装相关的虚拟路径和全部资源文件的关系，在所有资源文件中递归寻找该虚拟路径对应的全部依赖的guid列表。进一步的，使用递归方法来判断这些所有依赖的资源文件中的每个资源及其依赖是否只会被当前所有依赖的guid列表引用到。亦即，保证依赖的资源文件不会被包体里的其他资源文件引用到，以免出现游戏中文件缺失导致闪退的问题。
155.其中，对于场景资源的分包下载，可以使用相同的递归方法去得到每个资源文件对应的所有依赖资源的guid列表，接着判断其中每个资源及其依赖的引用关系。并且，还要保证这些资源不会在分包资源外的其他场景或脚本中被引用到。亦即，需要进行递归判断不同场景里的引用和依赖之间的关系。而根据脚本引用的虚拟路径求得对应的所有依赖的guid列表，再判断需要分包的资源是否存在于脚本对应的guid列表中，最后得到每个资源mod对应的，并且不影响分包资源外的游戏内容的guid列表。
156.根据依赖关系结果对分包资源数据进行剔除更新处理得到更新后的分包资源数据，并根据更新后的分包资源数据生成目标标识列表。
157.当对可依赖关系和被依赖关系进行唯一依赖判定得到对应的依赖关系结果之后，可以在依赖关系结果为可依赖关系或被依赖关系还包括其他资源文件的引用时，从对应的guid列表中剔除掉被其他地方引用到的资源文件对应的分包资源数据，以得到更新后的分包资源数据，并且，该更新后的分包资源数据组成的guid列表即为目标标识列表。
158.举例而言，a可以是将要分包的时装a对应的所有分包资源数据组成的guid列表，亦即标识列表，b为时装a的guid列表中资源文件的依赖情况。其中，a资源有a1、a2、a3的资源文件的依赖，而c资源有a、c1、c2的资源文件的依赖。亦即，a文件还被c资源引用到，但是这是属于自身guid列表中的内部引用，是被允许的。
159.而c可以是未分包的时装b的所有资源的guid列表，d为时装b的guid列表中资源文件的依赖情况。其中，d资源和e资源的依赖还包括a1资源，也就是a1资源被b时装里的一部分资源引用到了，那么a时装中的a资源的依赖已经被其他时装引用到了，如果依然将a资源的依赖a1作为分包资源数据，那么这部分资源下载patch的时候便不会进行下载，玩家如果使用到了b时装则会因缺少相关资源从而崩溃闪退。因此，可以将a1资源从时装a的guid列表中剔除来保证不会影响其他游戏内容。
160.在步骤s1430中，修改patch_list。
161.在得到目标标识列表之后，可以对分包资源数据和目标标识列表进行转换更新处理。亦即，基于目标标识列表修改patch_list这一补丁列表。
162.因此，需要在正常的打patch_list的流程中，嵌套修改patch_list。
163.值得说明的是，不能在打patch结束后，再去修改patch_list。具体的。这样会破坏patch_list文件的md5值，导致下载patch的时候检测失败。其次，还需要同时修改该版本相关的所有文件夹里的不同平台的patch_list来保持不会冲突。最后，若改变了正常的打patch流程，也会在一定程度上增加风险。
164.因此，可以使用patch_hook方法，在不改变任何打patch的代码的情况下，利用hook机制(在打patch的任何步骤之前或之后都可以调用一段新的代码)对分包资源数据和
目标标识列表进行转换更新处理。
165.因此，在正常打patch流程最后生成patch_md5之前，可以调用修改patch_list的代码来对目前存在的patch_list进行修改，亦即在patch_list中增加目标标识列表，以得到包括目标标识列表的补丁列表。
166.由于messiah文件系统的机制，不同平台的资源文件的guid名称会在原来的guid中加上不同的后缀，因此可以对生成的标识列表进行更新。
167.根据依赖关系生成分包资源数据的初始标识列表，并获取与分包资源数据对应的系统标识。
168.对可依赖关系和被依赖关系进行唯一依赖判定得到依赖关系结果。
169.具体的，通过比对某时装相关的虚拟路径和全部资源文件的关系，在所有资源文件中递归寻找该虚拟路径对应的全部依赖的guid列表。进一步的，使用递归方法来判断这些所有依赖的资源文件中的每个资源及其依赖是否只会被当前所有依赖的guid列表引用到。亦即，保证依赖的资源文件不会被包体里的其他资源文件引用到，以免出现游戏中文件缺失导致闪退的问题。
170.其中，对于场景资源的分包下载，可以使用相同的递归方法去得到每个资源文件对应的所有依赖资源的guid列表，接着判断其中每个资源及其依赖的引用关系。并且，还要保证这些资源不会在分包资源外的其他场景或脚本中被引用到。亦即，需要进行递归判断不同场景里的引用和依赖之间的关系。而根据脚本引用的虚拟路径求得对应的所有依赖的guid列表，再判断需要分包的资源是否存在于脚本对应的guid列表中，最后得到每个资源mod对应的，并且不影响分包资源外的游戏内容的guid列表。
171.根据依赖关系结果对分包资源数据进行剔除更新处理得到更新后的分包资源数据，并根据更新后的分包资源数据生成初始标识列表。
172.当对可依赖关系和被依赖关系进行唯一依赖判定得到对应的依赖关系结果之后，可以在依赖关系结果为可依赖关系或被依赖关系还包括其他资源文件的引用时，从对应的guid列表中剔除掉被其他地方引用到的资源文件对应的分包资源数据，以得到更新后的分包资源数据，并且，该更新后的分包资源数据组成的guid列表即为初始标识列表。
173.进一步的，获取与分包资源数据对应的系统标识。该系统标识可以是表征不同平台的标识。举例而言，/1可以是安卓系统的系统标识，/2可以是ios系统的系统标识。除此之外，也可以有其他形式的系统标识，本示例性实施例对此不做特殊限定。
174.利用系统标识对初始标识列表进行标识列表更新得到目标标识列表。
175.在生成初始标识列表和获取到系统标识之后，可以根据该初始标识列表中的guid适用的系统进行标识列表更新。
176.具体的，在得到初始标识列表之后，只需判断当前patch_list里的资源去除后缀，亦即系统标识后是否在得到的guid列表中。如果是的话，将这个有后缀的guid替换掉原来的初始标识列表中的guid得到目标标识列表，最后将这个新的标识列表作为一个新mods放入patch_list中。因此，在patch下载的步骤中，只需判断需要下载的资源文件的guid名称是否在新mods中的guid列表中，存在的话便不进行下载，即可达到分包的目的，从而达到在不影响修改整个打patch流程的情况下，针对得到的目标标识列表扩展到修改所有平台的资源列表的目的。
177.在步骤s1440中，修改patch_md5。
178.在不影响修改整个打patch流程下，修改patch_md5，达到满足共研服服务器的资源分包下载，从而不影响其他服务器的分包需求。
179.根据messiah文件系统的打patch机制，一些设定的参数是在patch_config里修改的，以使最后的参数修改反映到patch_md5里的元数据中。因此，可以获取补丁列表的目标参数patch_config。
180.并且，由于分包资源数据中还包括共研服服务器的特殊字段，因此可以获取该特殊字段作为目标字段。
181.利用目标字段更新目标参数，并利用更新后的目标字段和依赖关系生成分包资源数据的目标标识列表。
182.在获取到目标字段和目标参数之后，可以将该目标字段写入到patch_config这一目标参数中，表明共研服服务器需要将哪些资源mod进行分包，以在根据依赖关系生成分包资源数据的目标标识列表的同时，实现利用目标字段对对应patch_md5的修改，得到对应的目标标识列表。
183.在步骤s1450中，修改next_patch_md5。
184.当发布patch以供玩家下载的时候，messiah文件系统的发布代码会修改发布平台的patch_md5文件来达到更新patch的目的。其中，next_patch_md5文件里的内容即为该新patch的文件夹名称，表明哪个patch进行预下载。
185.因此，在发布代码修改patch_md5文件的时候，可以对该原始文件增加一行修改next_patch_md5文件的代码得到目标文件。
186.对目标文件进行文件压缩处理更新后的补丁列表，以对更新后的补丁列表进行下载。
187.在得到目标文件之后，可以在将该目标文件打包上传patch的压缩文件之前，将patch_md5文件复制到压缩文件中一起打包上传，这样就可以让游戏客户端访问到新的patch内容，亦即补丁列表，从而进行下载。
188.具体的，游戏进行patch下载是通过将不同平台的资源文件打包成一个zip文件上传到一个服务器上，该服务器再对应分发到各个下载节点，以解压存放在下载节点上。而每次publish(发布)就是将资源文件以及对应的patch_list文件一起打包上传到服务器上，再修改该服务器上的patch_md5文件。
189.其中，该patch_md5文件是存放在服务器上的。并且，当patch_md5文件中包含新的patch的相关信息时，表明存在新的patch，且可以准备下载了。而这些资源文件会立即分发到对应的下载节点上。
190.在之前的处理流程中，除了patch_md5文件和patch_list文件外，玩家可以访问到资源文件里的其他内容，但是玩家无法立即下载到。只有在维护当天手动更新发布patch_md5文件和patch_list文件，亦即将patch_md5文件和patch_list文件设置为外网可以访问的状态，玩家的客户端才可以知道patch_md5文件已经更新，因此根据patch_list文件下载新的资源文件。
191.对于步骤s1450而言，为了让玩家可以在维护前就下载到资源文件，可以提供一种next_patch_md5文件的方法。具体的，在打包上传前，将patch_md5文件也放入到压缩包中
上传，而修改服务器上的patch_md5文件时，可以增加一行修改next_patch_md5文件的代码，并且该文件是服务器原本没有的。
192.并且，该next_patch_md5文件可以指向新的patch的文件夹的名称(时间戳)，再提前将该文件进行外放，设置成外网可以访问的状态，然后修改patch的下载机制，使得客户端每次空闲的时候都可以去判断服务器上的next_patch_md5文件是否更新。当next_patch_md5文件更新时，寻找服务器上的next_patch_md5文件，并且由于patch_md5文件已经上传了，因此可以根据文件夹中的patch_md5文件和patch_list文件进行patch的提前下载。值得说明的是，此时的patch文件的下载是下载到本地的一个特别目录中，只有当正式维护更新时，才会进行比对更新从而避免重复下载。
193.在步骤s1460中，实现动态的分包下载需求。
194.首先，在修改patch下载代码的基础上，通过读取服务器上的patch_list文件可以得到所有的资源列表和分包下载的guid列表。为了满足分包下载的guid列表对应资源的增、删、修改操作对整个游戏内容没有影响的效果，也就是即使后面因为游戏版本内容导致的移除、修改或者增加某个分包资源mod里的某个资源也不会造成游戏内容的异常，例如缺少资源文件导致崩溃闪退或者修改某个资源的内容，但分包里的该资源没有进行改变等问题，需要对分包内容中已经下载的资源集合和未下载的资源集合、以及全部资源文件集合进行关联判断。
195.例如，集合a和集合b可能存在共有资源，但是这部分资源如果发生变化，同样需要进行更新下载。而游戏中未进行下载的分包资源在每次进行patch下载时，并不需要进行额外判断和下载，所以可以将集合b减少集合a得到集合b独有的资源，再用集合c减少集合b独有的资源，该资源即是每次下载patch时和游戏客户端本地的文件进行比对判断md5和大小是否发生变化，来进行文件更新的部分。这样可以保证无论集合a和集合b中的资源如何变化，都不会影响整个游戏内容的完整性和游戏体验的效果。
196.除此之外，还可以在游戏中提供一个分包资源的ui。
197.玩家可以主动进行下载某些资源mod来丰富游戏体验，而不影响其他游戏内容的体验。在大厅空闲时，可以去访问服务器上的next_patch_md5文件的内容和本地patch时间戳来判断是否有新的patch。如果存在新的patch时，可以根据patch_md5文件去下载节点上的patch文件到指定文件夹中。当正式外放patch_md5文件时，只需要比对需要下载的文件是否存在在指定文件夹中。当存在于指定文件夹时，直接复制到patch文件夹中便可省略下载步骤直接进入游戏。而对于共研服服务器的包体，只需要根据patch_md5中的元数据里的数据进行专属的分包资源下载，即可实现动态的分包下载功能，优化玩家的用户体验。
198.在本公开的示例性实施例中的游戏应用的分包资源下载方法，获取到的分包资源数据可以细致划分到单个文件级别，自由对时装、场景、枪械和皮肤等资源进行分离，不影响其他游戏内容的体验，从而降低下载的补丁列表的大小。并且，根据依赖关系生成的目标标识列表能够避免游戏中因缺失资源而导致闪退的情况发生，将该包括目标标识列表的补丁列表扩展到各个平台，也解决了不同平台差异化分包下载带来的维护复杂度高和存在不过审风险的问题，同时也降低了测试复杂度，优化了玩家在分包资源下载方面的游戏体验。
199.此外，在本公开的示例性实施例中，还提供一种游戏应用的分包资源下载装置。图15示出了游戏应用的分包资源下载装置的结构示意图，如图15所示，游戏应用的分包资源
下载装置1500可以包括：路径确定模块1510、列表生成模块1520和分包下载模块1530。其中：
200.路径确定模块1510，被配置为获取分包资源数据，并根据分包资源数据中的资源标识查找存储分包资源数据的虚拟路径；列表生成模块1520，被配置为根据虚拟路径确定分包资源数据的依赖关系，并根据依赖关系生成分包资源数据的目标标识列表；分包下载模块1530，被配置为对分包资源数据和目标标识列表进行转换更新处理得到包括目标标识列表的补丁列表，以进行下载。
201.在本发明的一种示例性实施例中，所述获取分包资源数据，包括：
202.获取资源分包表格；
203.对所述资源分包表格进行表格转换处理得到分包资源数据。
204.在本发明的一种示例性实施例中，所述根据所述虚拟路径确定所述分包资源数据的依赖关系，包括：
205.当所述分包资源数据非场景资源数据时，在资源仓库文件中根据所述虚拟路径确定所述分包资源数据的依赖关系；
206.当所述分包资源数据为场景资源数据时，在目标文件中根据所述虚拟路径确定所述分包资源数据的依赖关系。
207.在本发明的一种示例性实施例中，所述依赖关系包括可依赖关系和被依赖关系，
208.所述根据所述依赖关系生成所述分包资源数据的目标标识列表，包括：
209.对所述可依赖关系和所述被依赖关系进行唯一依赖判定得到依赖关系结果；
210.根据所述依赖关系结果对所述分包资源数据进行剔除更新处理得到更新后的分包资源数据，并根据所述更新后的分包资源数据生成目标标识列表。
211.在本发明的一种示例性实施例中，所述根据所述依赖关系生成所述分包资源数据的目标标识列表，包括：
212.根据所述依赖关系生成所述分包资源数据的初始标识列表，并获取与所述分包资源数据对应的系统标识；
213.利用所述系统标识对所述初始标识列表进行标识列表更新得到目标标识列表。
214.在本发明的一种示例性实施例中，所述根据所述依赖关系生成所述分包资源数据的目标标识列表，包括：
215.获取所述分包资源数据中的目标字段，并获取所述补丁列表的目标参数；
216.利用所述目标字段更新所述目标参数，并利用更新后的所述目标字段和所述依赖关系生成所述分包资源数据的目标标识列表。
217.在本发明的一种示例性实施例中，所述进行下载，包括：
218.获取所述补丁列表中的原始文件，并对所述信息摘要值进行预订更新处理得到目标文件；
219.对所述目标文件进行文件压缩处理更新后的补丁列表，以对所述更新后的补丁列表进行下载。
220.上述游戏应用的分包资源下载装置1500的具体细节已经在对应的游戏应用的分包资源下载方法中进行了详细的描述，因此此处不再赘述。
221.应当注意，尽管在上文详细描述中提及了游戏应用的分包资源下载装置1500的若
干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
222.此外，在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。
223.下面参照图16来描述根据本发明的这种实施例的电子设备1600。图16显示的电子设备1600仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
224.如图16所示，电子设备1600以通用计算设备的形式表现。电子设备1600的组件可以包括但不限于：上述至少一个处理单元1610、上述至少一个存储单元1620、连接不同系统组件(包括存储单元1620和处理单元1610)的总线1630、显示单元1640。
225.其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元1610执行，使得所述处理单元1610执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施例的步骤。
226.存储单元1620可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(ram)1621和/或高速缓存存储单元1622，还可以进一步包括只读存储单元(rom)1623。
227.存储单元1620还可以包括具有一组(至少一个)程序模块1625的程序/实用工具1624，这样的程序模块1625包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
228.总线1630可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。
229.电子设备1600也可以与一个或多个外部设备1800(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备1600交互的设备通信，和/或与使得该电子设备1600能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口1650进行。并且，电子设备1600还可以通过网络适配器1660与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器1660通过总线1630与电子设备1600的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1600使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
230.通过以上的实施例的描述，本领域的技术人员易于理解，这里描述的示例实施例可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd
‑
rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施例的方法。
231.在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施例中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施例的步骤。
232.参考图17所示，描述了根据本发明的实施例的用于实现上述方法的程序产品1700，其可以采用便携式紧凑盘只读存储器(cd
‑
rom)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
233.所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
234.计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
235.可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、rf等等，或者上述的任意合适的组合。
236.可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c 等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
237.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施例。本技术旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。