应用程序的打包、加载方法、装置、电子设备及存储介质与流程

1.本发明涉及计算机技术领域，尤其涉及一种应用程序的打包、加载方法、装置、电子设备及存储介质。


背景技术：

2.react
‑
native框架，是目前使用越来越广泛的一种跨平台应用开发框架。相关技术中，在基于react
‑
native框架的应用开发中，随着业务需求不断迭代，业务代码越来越大，构建后的包体积越来越臃肿，导致下载包的耗时增加，白屏时间增加，导致影响用户体验。


技术实现要素：

3.本发明实施例提供一种应用程序的打包、加载方法、装置、电子设备及存储介质，以解决相关技术中的问题。
4.本发明的目的是通过以下技术方案实现的：
5.第一方面，本发明实施例提供一种应用程序的打包方法，包括：
6.将react
‑
native框架的应用程序的源代码的业务代码，进行拆分，以得到拆分结果，拆分结果包括从源代码的业务代码中拆分出来的主业务代码；
7.生成包含主业务代码的应用程序的安装包。
8.在一种可能的实施方式中，将react
‑
native框架的应用程序的源代码的业务代码进行拆分，包括：
9.响应于业务代码未被任何业务代码加载，将该业务代码拆分为主业务代码；
10.响应于业务代码仅被当前拆分出的主业务代码同步加载或者被当前拆分出的主业务代码既同步加载又异步加载，将该业务代码添加至主业务代码；
11.响应于业务代码仅被当前拆分出的主业务代码中的一段业务代码异步加载，将该业务代码添加至主业务代码。
12.在一种可能的实施方式中，拆分结果还包括从源代码的业务代码中拆分出来的至少一段次业务代码，次业务代码用于在应用程序运行过程中被动态加载，将react
‑
native框架的应用程序的源代码的业务代码进行拆分，还包括：
13.响应于业务代码仅被当前拆分出的主业务代码中的多段业务代码异步加载，将该业务代码拆分为次业务代码；
14.响应于业务代码仅被当前拆分出的次业务代码同步加载，将该业务代码添加至该次业务代码。
15.在一种可能的实施方式中，将react
‑
native框架的应用程序的源代码的业务代码进行拆分，以得到拆分结果，包括：
16.基于源代码的业务代码对应的依赖图，对源代码的业务代码进行拆分，以得到拆分结果；
17.其中，源代码的业务代码包括多段业务代码，依赖图表征各段业务代码之间的依赖关系。
18.在一种可能的实施方式中，基于源代码的业务代码对应的依赖图，对源代码的业务代码进行拆分，以得到拆分结果，包括：
19.遍历依赖图中每段业务代码，分析当前遍历的业务代码的依赖信息；
20.响应于当前遍历的业务代码没有被其它业务代码依赖，将当前遍历的业务代码的标识，添加至与主业务代码对应的第一标识组；
21.响应于当前遍历的业务代码被其它业务代码依赖，基于当前遍历的业务代码与其它业务代码的依赖信息，将当前遍历的业务代码的标识，添加至第一标识组或者一个与次业务代码对应的第二标识组；
22.将第二标识组对应的代码，确定为次业务代码；
23.将第一标识组对应的代码，确定为主业务代码。
24.在一种可能的实施方式中，将第二标识组对应的代码，确定为次业务代码，还包括：
25.响应于第二标识组对应的代码所占的存储空间的大小达到预设阈值，将第二标识组对应的代码，确定为次业务代码；
26.在一种可能的实施方式中，该方法还包括：
27.响应于第二标识组对应的代码所占的存储空间的大小未达到预设阈值，将第二标识组添加至第一标识组。
28.在一种可能的实施方式中，还包括：
29.生成次业务代码的标识与次业务代码的名称信息的映射关系；
30.生成包含主业务代码的应用程序的安装包，包括：
31.生成包含主业务代码和映射关系的安装包，映射关系用于通过需要动态加载的次业务代码的标识，查找次业务代码的标识对应的名称信息，以基于查找到的次业务代码的名称信息，确定次业务代码的加载地址，以及基于加载地址，从服务端加载次业务代码。
32.第二方面，本发明实施例提供一种应用程序的加载方法，包括：
33.基于从服务端加载的react
‑
native框架的应用程序的安装包，安装应用程序，应用程序的安装包中包含主业务代码，主业务代码是从应用程序的源代码的业务代码中拆分出来的；
34.运行应用程序。
35.在一种可能的实施方式中，所述主业务代码是从所述应用程序的源代码的业务代码中拆分出来的，包括：
36.响应于业务代码未被任何业务代码加载，将该业务代码拆分为主业务代码；
37.响应于业务代码仅被当前拆分出的主业务代码同步加载或者被当前拆分出的主业务代码既同步加载又异步加载，将该业务代码添加至主业务代码；
38.响应于业务代码仅被当前拆分出的主业务代码中的一段业务代码异步加载，将该业务代码添加至主业务代码。
39.在一种可能的实施方式中，还包括：
40.基于应用程序运行过程中的输入操作，确定响应输入操作需要动态加载的次业务
代码，次业务代码是从源代码的业务代码中拆分出来的；
41.从服务端加载次业务代码。
42.在一种可能的实施方式中，所述次业务代码是从所述源代码的业务代码中拆分出来的，包括：
43.响应于业务代码仅被当前拆分出的主业务代码中的多段业务代码异步加载，将该业务代码拆分为次业务代码；
44.响应于业务代码仅被当前拆分出的次业务代码同步加载，将该业务代码添加至该次业务代码。
45.在一种可能的实施方式中，安装包中包含映射关系，映射关系为次业务代码的标识与次业务代码的名称信息的映射关系；
46.从服务端次业务代码，包括：
47.从映射关系中，查找次业务代码的标识对应的名称信息；
48.基于查找到的次业务代码的名称信息，确定次业务代码的加载地址；
49.基于加载地址，从服务端加载次业务代码。
50.在一种可能的实施方式中，从服务端加载次业务代码，包括：
51.响应于记录的次业务代码的加载状态为未加载，从服务端加载次业务代码。
52.在一种可能的实施方式中，还包括：
53.响应于记录的次业务代码的加载状态为加载中，将加载中的promise实例对应的结果，作为次业务代码的加载结果。
54.在一种可能的实施方式中，还包括：
55.响应于次业务代码所依赖的业务代码被拆分至其它次业务代码中，从服务端加载其它次业务代码。
56.第三方面，本发明实施例提供一种应用程序的打包装置，包括：
57.拆分模块，用于将react
‑
native框架的应用程序的源代码的业务代码，进行拆分，以得到拆分结果，拆分结果包括从源代码的业务代码中拆分出来的主业务代码；
58.打包模块，用于生成包含主业务代码的应用程序的安装包。
59.在一种可能的实施方式中，拆分模块，具体用于：
60.响应于业务代码未被任何业务代码加载，将该业务代码拆分为主业务代码；
61.响应于业务代码仅被当前拆分出的主业务代码同步加载或者被当前拆分出的主业务代码既同步加载又异步加载，将该业务代码添加至主业务代码；
62.响应于业务代码仅被当前拆分出的主业务代码中的一段业务代码异步加载，将该业务代码添加至主业务代码。
63.在一种可能的实施方式中，拆分结果还包括从源代码的业务代码中拆分出来的至少一段次业务代码，次业务代码用于在应用程序运行过程中被动态加载，拆分模块，还用于：
64.响应于业务代码仅被当前拆分出的主业务代码中的多段业务代码异步加载，将该业务代码拆分为次业务代码；
65.响应于业务代码仅被当前拆分出的次业务代码同步加载，将该业务代码添加至该次业务代码。
66.在一种可能的实施方式中，拆分模块，具体用于：
67.基于源代码的业务代码对应的依赖图，对源代码的业务代码进行拆分，以得到拆分结果；
68.其中，源代码的业务代码包括多段业务代码，依赖图表征各段业务代码之间的依赖关系。
69.在一种可能的实施方式中，拆分模块，具体用于：
70.遍历依赖图中每段业务代码，分析当前遍历的业务代码的依赖信息；
71.响应于当前遍历的业务代码没有被其它业务代码依赖，将当前遍历的业务代码的标识，添加至与主业务代码对应的第一标识组；
72.响应于当前遍历的业务代码被其它业务代码依赖，基于当前遍历的业务代码与其它业务代码的依赖信息，将当前遍历的业务代码的标识，添加至第一标识组或者一个与次业务代码对应的第二标识组；
73.将第二标识组对应的业务代码，确定为次业务代码；
74.将第一标识组对应的业务代码，确定为主业务代码。
75.在一种可能的实施方式中，拆分模块，还用于：
76.响应于第二标识组对应的业务代码所占的存储空间的大小达到预设阈值，将第二标识组对应的业务代码，确定为次业务代码；
77.在一种可能的实施方式中，拆分模块，还用于：
78.响应于第二标识组对应的业务代码所占的存储空间的大小未达到预设阈值，将第二标识组添加至第一标识组。
79.在一种可能的实施方式中，还包括：
80.映射模块，用于生成次业务代码的标识与次业务代码的名称信息的映射关系；
81.打包模块，具体用于：
82.生成包含主业务代码和映射关系的安装包，映射关系用于通过需要动态加载的次业务代码的标识，查找次业务代码的标识对应的名称信息，以基于查找到的次业务代码的名称信息，从服务端加载次业务代码。
83.第四方面，本发明实施例提供一种应用程序的加载装置，包括：
84.加载安装模块，用于基于从服务端加载的react
‑
native框架的应用程序的安装包，安装应用程序，应用程序的安装包中包含主业务代码，主业务代码是从应用程序的源代码的业务代码中拆分出来的；
85.程序运行模块，用于运行应用程序。
86.在一种可能的实施方式中，所述主业务代码是从所述应用程序的源代码的业务代码中拆分出来的，包括：
87.响应于业务代码未被任何业务代码加载，将该业务代码拆分为主业务代码；
88.响应于业务代码仅被当前拆分出的主业务代码同步加载或者被当前拆分出的主业务代码既同步加载又异步加载，将该业务代码添加至主业务代码；
89.响应于业务代码仅被当前拆分出的主业务代码中的一段业务代码异步加载，将该业务代码添加至主业务代码。
90.在一种可能的实施方式中，还包括：
91.加载确定模块，用于基于应用程序运行过程中的输入操作，确定响应输入操作需要动态加载的次业务代码，次业务代码是从源代码的业务代码中拆分出来的；
92.动态加载模块，用于从服务端加载次业务代码。
93.在一种可能的实施方式中，所述次业务代码是从所述源代码的业务代码中拆分出来的，包括：
94.响应于业务代码仅被当前拆分出的主业务代码中的多段业务代码异步加载，将该业务代码拆分为次业务代码；
95.响应于业务代码仅被当前拆分出的次业务代码同步加载，将该业务代码添加至该次业务代码。
96.在一种可能的实施方式中，安装包中包含映射关系，映射关系为次业务代码的标识与次业务代码的名称信息的映射关系；
97.动态加载模块，具体用于：
98.从映射关系中，查找次业务代码的标识对应的名称信息；
99.基于查找到的次业务代码的名称信息，确定次业务代码的加载地址；
100.基于加载地址，从服务端加载次业务代码。
101.在一种可能的实施方式中，动态加载模块，具体用于：
102.响应于记录的次业务代码的加载状态为未加载，从服务端加载次业务代码。
103.在一种可能的实施方式中，动态加载模块，具体用于：
104.响应于记录的次业务代码的加载状态为加载中，将加载中的promise实例对应的结果，作为次业务代码的加载结果。
105.在一种可能的实施方式中，动态加载模块，还用于：
106.响应于次业务代码所依赖的业务代码被拆分至其它次业务代码中，从服务端加载其它次业务代码。
107.第五方面，本发明实施例提供一种电子设备，包括：处理器、存储器及存储在存储器上并可在处理器上运行的计算机程序，计算机程序被处理器执行时实现如第一方面和第二方面中任一的方法的步骤。
108.第六方面，本发明实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如第一方面和第二方面中任一的方法的步骤。
109.上述技术方案中的优点或有益效果至少包括：
110.由于react
‑
native框架的应用程序的安装包中，包含的是从源代码的业务代码中拆分出的主业务代码，而非全部的业务代码，减少了该应用程序的安装包的体积，可以快速下载应用程序的安装包，减少了白屏时间，提高了用户体验。
111.上述概述仅仅是为了说明书的目的，并不意图以任何方式进行限制。除上述描述的示意性的方面、实施方式和特征之外，通过参考附图和以下的详细描述，本发明进一步的方面、实施方式和特征将会是容易明白的。
附图说明
112.图1是本发明实施例中的一种示例性的应用程序的打包方法的流程图；
113.图2是本发明实施例中的一种示例性的应用程序的打包方法的流程图；
114.图3是本发明实施例中的一种示例性的应用程序的加载方法的流程图；
115.图4是本发明实施例中的一种示例性的应用程序的打包方法的流程图；
116.图5是本发明实施例中的一种示例性的应用程序的加载方法的流程图；
117.图6是本发明实施例中的一种示例性的应用程序的打包装置的示意图；
118.图7是本发明实施例中的一种示例性的应用程序的打包装置的示意图；
119.图8是本发明实施例中的一种示例性的应用程序的加载装置的示意图；
120.图9是本发明实施例中的一种示例性的应用程序的加载装置的示意图；
121.图10是本发明实施例中的一种示例性的电子设备的示意图。
具体实施方式
122.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
123.react
‑
native框架，是目前使用越来越广泛的一种跨平台应用开发框架。相关技术中，在基于react
‑
native框架的应用开发中，随着业务需求不断迭代，业务代码越来越大，构建后的包体积越来越臃肿，导致下载包的耗时增加，白屏时间增加，导致影响用户体验。
124.相关技术中，react
‑
native框架一般采用metro打包器进行打包。metro打包器是适用于react
‑
native框架的js打包器。metro打包器打包时，最终构建成一个包。随着业务需求不断迭代，构建后的包会越来越大，导致下载包的耗时增加，白屏时间增加，导致影响用户体验。
125.为解决上述技术问题，本发明实施例提供一种应用程序的打包、加载方法、装置、设备及存储介质，对react
‑
native框架的应用程序的源代码的业务代码合理拆分出主业务代码，生成包含主业务代码的应用程序的安装包，从而减小了安装包的体积，减小了安装包的下载耗时，从而提升了用户体验。下面对本发明实施例的方案进行介绍。
126.图1是本发明实施例提供的一种示例性的应用程序的打包方法的流程图。如图1所示，本实施例提供的一种应用程序的打包方法，至少包括如下步骤：
127.步骤101、将react
‑
native框架的应用程序的源代码的业务代码，进行拆分，以得到拆分结果，该拆分结果包括从源代码的业务代码中拆分出来的主业务代码。
128.这里，基于react
‑
native框架开发的应用程序的源代码包含通用代码和业务代码。源代码包含的通用代码可以包含react
‑
native、react的第三方公共代码。源代码包含的业务代码则是与具体业务相关的代码。实际应用中，可以预先将源代码拆分成通用代码和业务代码。本步骤中，将源代码的业务代码进行拆分，从业务代码中拆分出主要的业务代码，也即主业务代码。
129.步骤102、生成包含主业务代码的应用程序的安装包。
130.实际应用中，当需要安装应用程序时，需要下载应用程序的安装包，然后进行安装并启动。本实施例中，由于react
‑
native框架的应用程序的安装包中，包含的是从源代码的
业务代码中拆分出的主业务代码，而非全部的业务代码，减少了该应用程序的安装包的体积，可以快速下载应用程序的安装包，减少了白屏时间，提高了用户体验。
131.可以理解的是，上述应用程序的安装包中还包含源代码的通用代码。
132.在示例性实施例中，步骤101中，将react
‑
native框架的应用程序的源代码的业务代码进行拆分，其具体实现方式可以包括：响应于业务代码未被任何业务代码加载，将该业务代码拆分为主业务代码；响应于业务代码仅被当前拆分出的主业务代码同步加载或者被当前拆分出的主业务代码既同步加载又异步加载，将该业务代码添加至主业务代码；响应于业务代码仅被当前拆分出的主业务代码中的一段业务代码异步加载，将该业务代码添加至主业务代码。
133.实际应用中，如果源代码的业务代码中，一段业务代码没有被任何业务代码加载，有可能是主函数代码，应该作为主业务代码。
134.如果一段业务代码仅被当前拆分出的主业务代码中的业务代码同步加载，则需要添加至主业务代码拆分出来，以满足同步加载的需求。
135.如果一段业务代码被当前拆分出的主业务代码中的业务代码依赖，且既同步加载又异步加载，此时，就需要以同步加载为主，首先满足同步加载的需求，将该业务代码与依赖它的业务代码放在一起，更加合理。举例来说，a段业务代码依赖e段业务代码，a段业务代码位于主业务代码中，由于a段业务代码有两个地方加载了e段业务代码，一个地方是同步加载，另一个地方是异步加载，此时，则可以将e段业务代码添加至a段业务代码所在的主业务代码中。
136.如果一段业务代码仅被当前拆分出的一段主业务代码中的业务代码异步加载，也就是说，不是公共代码，此时，则可以将其添加至主业务代码中。
137.在示例性实施例中，上述拆分结果还可以包括从所述源代码的业务代码中拆分出来的至少一段次业务代码，该次业务代码用于在所述应用程序运行过程中被动态加载，上述将react
‑
native框架的应用程序的源代码的业务代码进行拆分步骤，还可以包括：响应于业务代码仅被当前拆分出的主业务代码中的多段业务代码异步加载，将该业务代码拆分为次业务代码；响应于业务代码仅被当前拆分出的次业务代码同步加载，将该业务代码添加至该次业务代码。
138.实际应用中，如果一段业务代码仅被主业务代码中的多段业务代码依赖，且均是异步加载，该段业务代码可以作为按照需要动态加载的次业务代码拆分出来。举例来说，a段业务代码依赖b段业务代码，c段业务代码依赖b段业务代码，a段业务代码和c段业务代码位于主业务代码中，由于b段业务代码均被主业务代码中的a段业务代码和c段业务代码异步加载，则可以将b段业务代码作为次业务代码拆分出来。
139.如果一段业务代码仅被一段次业务代码中的业务代码依赖，且是同步加载，而没有被主业务代码中的业务代码依赖，该业务代码可以作为按照需要动态加载的业务代码跟随依赖它的业务代码拆分出来，与依赖它的业务代码拆分在一段次业务代码中，一同加载，更加方便。举例来说，b段业务代码依赖d段业务代码，b段业务代码位于一段次业务代码中，由于d段业务代码仅被b段业务代码同步加载，则可以将d段业务代码与b段业务代码一同拆分出来，添加至b段业务代码所在的一段次业务代码中。
140.本实施例中，由于次业务代码被应用程序运行过程中动态加载，可以将次业务代
码发布到服务端，不包含在应用程序的安装包中，以减少安装包的体积。
141.可以理解的是，以上仅是列举了其中几种业务代码可以拆分为主业务代码和次业务代码的情况，还可以有许多其它的情况，实际应用中，可以根据实际情况设置更多的拆分方式，从而实现规范化、自由度高、可控性强、自动化程度高的打包方案。
142.在示例性实施例中，将react
‑
native框架的应用程序的源代码的业务代码进行拆分，以得到拆分结果，其具体实现方式可以包括：基于业务代码对应的依赖图，对业务代码进行拆分，以得到拆分结果；其中，源代码的业务代码包括多段业务代码，依赖图表征各段业务代码之间的依赖关系。
143.实际应用中，源代码的业务代码可以按照业务逻辑分成多段业务代码。依赖图能够表征各段业务代码之间的依赖关系。例如，a段业务代码依赖b段业务代码，c段业务代码依赖b段业务代码。实际应用中，可以先获取源代码的业务代码对应的依赖图。
144.具体的，可以通过序列化器获取源代码的业务代码对应的依赖图。例如，通过serializer.customserializer序列化器获取源代码的业务代码对应的依赖图。
145.serializer.customserializer是metro打包器提供的自定义序列化方法，可以获取依赖图等信息。如此，通过已有的序列化器可以快速得到依赖图。
146.本实施例中，通过源代码的业务代码对应的依赖图，可以对源代码的业务代码进行合理的拆分。
147.在示例性实施例中，基于源代码的业务代码对应的依赖图，对源代码的业务代码进行拆分，以得到拆分结果，如图2所示，其具体实现方式可以包括：
148.步骤201、遍历依赖图中每段业务代码，分析当前遍历的业务代码的依赖信息。
149.实际应用中，每段业务代码具有对应的业务代码的标识。该业务代码的标识是表征业务代码的唯一性的身份标识。
150.本步骤中，具体的，可以通过逆向依赖，即当前遍历的业务代码被哪段业务代码依赖，获取当前遍历的业务代码对应的引用标识，分析当前遍历的业务代码对应的引用标识，以得到当前遍历的业务代码的依赖信息。其中的引用标识是依赖当前遍历的业务代码的其它业务代码的标识。可以通过数组形式存储当前遍历的业务代码对应的引用标识。分析当前遍历的业务代码对应的引用标识，具体可以包括：如果存储的当前遍历的业务代码对应的引用标识为空，也即不包含任何其它业务代码的标识，确定该业务代码没有被任何业务代码依赖，例如主函数代码，不被任何业务代码依赖，所以其对应的引用标识为空。如果存储的当前遍历的业务代码对应的引用标识包含其它业务代码的标识，确定该业务代码被其它业务代码所依赖，其中，如果仅包含一段业务代码的标识，确定该业务代码仅被一段业务代码依赖，如果包含多段业务代码的标识，确定该业务代码被多段业务代码依赖。
151.步骤202、响应于当前遍历的业务代码没有被其它业务代码依赖，将当前遍历的业务代码的标识，添加至与主业务代码对应的第一标识组。
152.如果通过分析，当前遍历的业务代码没有被其它业务代码依赖，可能是作为入口的主函数等，应该在主业务代码中，因此，将当前遍历的业务代码的标识添加至第一标识组。
153.步骤203、响应于当前遍历的业务代码被其它业务代码依赖，基于当前遍历的业务代码与其它业务代码的依赖信息，将当前遍历的业务代码的标识，添加至第一标识组或者
一个与次业务代码对应的第二标识组。
154.这里，第二标识组可以为一个新建的组，也可以是已包含其它业务代码的标识的组。
155.如果通过分析，当前遍历的业务代码被其它业务代码依赖，则可以基于当前遍历的业务代码与其它业务代码的依赖信息，将当前遍历的业务代码的标识添加至合适的组。该当前遍历的业务代码可能适合在主业务代码中，此时可以将当前遍历的业务代码的标识添加至第一标识组；该当前遍历的业务代码可能适合与依赖本业务代码的其它业务代码在一段次业务代码中，此时，可以将当前遍历的业务代码的标识添加至已包含其它业务代码的标识的第二标识组；该当前遍历的业务代码也可能不适合在已有的任何次业务代码对应的组中，此时，可以将当前遍历的业务代码的标识添加至的新建的为空的第二标识组中。
156.步骤204、将第二标识组对应的业务代码，确定为次业务代码。
157.具体的，基于第二标识组所包含的业务代码的标识，从源代码的业务代码中查找到该业务代码的标识所对应的业务代码，将查找到的业务代码作为次业务代码。
158.遍历完所有的业务代码之后，可以得到一个第二标识组，也可以得到多个第二标识组，相应的，可以确定出一个或者多个次业务代码。
159.步骤205、将第一标识组对应的业务代码，确定为主业务代码。
160.具体的，基于第一标识组所包含的业务代码的标识，从源代码的业务代码中查找到该业务代码的标识所对应的业务代码，将查找到的业务代码作为主业务代码。
161.遍历完所有业务代码之后，得到一个第一标识组，形成一个主业务代码。
162.本实施例中，通过遍历每段业务代码，对其依赖信息进行分析，能够对业务代码进行更合理的拆分。
163.在示例性实施例中，在将第二标识组对应的业务代码，确定为次业务代码，将第一标识组对应的业务代码，确定为主业务代码之前，上述应用程序的打包方法还可以包括：对所有的业务代码进行编译。具体的，可以通过basejsbundle对所有的业务代码进行编译。basejsbundle是metro打包器提供的编译方法，可以直接使用，非常方便。
164.在示例性实施例中，将第二标识组对应的业务代码，确定为次业务代码，还可以包括：响应于第二标识组对应的业务代码所占的存储空间的大小达到预设阈值，将第二标识组对应的业务代码，确定为次业务代码。
165.其中，预设阈值的具体值可以根据实际情况进行设置，例如设置为20000b。该预设阈值表征了最小拆分大小。
166.实际应用中，基于各段业务代码之间的依赖关系，对源代码的业务代码进行拆分完毕之后，得到的各第二标识组对应的业务代码的体积可能大小不同，体积较大的业务代码对安装包的体积的影响较大，通过设置最小拆分大小，进一步将体积较大的业务代码作为次业务代码，拆分更加合理。
167.相应的，上述应用程序的打包方法还可以包括：响应于第二标识组对应的业务代码所占的存储空间的大小未达到预设阈值，将第二标识组添加至第一标识组。由于较小的业务代码对安装包的体积影响较小，本实施例中，通过设置最小拆分大小，对较小的业务代码不做拆分，而是放在主业务代码中，不做动态加载，加载更快，如此，进一步提高了拆分的合理性。
168.具体的，可以是响应于编译后的第二标识组对应的业务代码所占的存储空间的大小达到预设阈值，将第二标识组对应的业务代码，确定为次业务代码。相应的，响应于编译后的第二标识组对应的业务代码所占的存储空间的大小未达到预设阈值，将第二标识组添加至第一标识组。由于最终打包输出的是编译后的文件，所以基于编译后的业务代码的大小，与预设阈值对比，更加准确。该过程可以认为是预分配的过程，看分配是否合理，最终得到的分组，则可以作为正式分配的基础。
169.在示例性实施例中，上述应用程序的打包方法还可以包括：确定每段业务代码被异步加载或者同步加载。示例性的，根据metro打包器中的async异步模块标识，确定每段业务代码被异步加载或者同步加载。
170.在示例性实施例中，上述应用程序的打包方法还可以包括：生成次业务代码的标识与次业务代码的名称信息的映射关系；生成包含主业务代码的应用程序的安装包，其具体实现方式可以包括：生成包含主业务代码和映射关系的安装包，映射关系用于通过需要动态加载的次业务代码的标识，查找次业务代码的标识对应的名称信息，以基于查找到的次业务代码的名称信息，确定次业务代码的加载地址，以及基于加载地址，从服务端加载次业务代码。
171.其中，次业务代码的名称信息可以是次业务代码的名称所对应的哈希值。实际应用中，可以基于目标次业务代码的名称信息，获得目标次业务代码的加载地址，基于该加载地址从服务端加载次业务代码。如此，可以基于映射关系快速准确加载到次业务代码，方案实现简单。
172.在示例性实施例中，上述应用程序的打包方法可以封装成一个中间件，基于metro打包器，和该中间件，实现react
‑
native框架的应用程序的打包。可以设置中间件的开关标识，也即拆分业务代码(splitchunk)功能的开关标识，如果开启，则基于metro打包器，结合中间件打包，如果未开启，则完全基于metro打包器打包。
173.可以理解的是，通过本发明实施例提供的应用程序打包方法完成打包之后，可以将应用程序的安装包和次业务代码发布到服务端，例如，内容分发网络(cdn，content delivery network)服务端，以供用户终端进行下载。
174.图3是本发明实施例提供的一种示例性的应用程序的加载方法的流程图。如图3所示，本实施例提供的一种应用程序的加载方法，至少包括如下步骤：
175.步骤301、基于从服务端加载的react
‑
native框架的应用程序的安装包，安装应用程序，该应用程序的安装包中包含主业务代码，该主业务代码是从应用程序的源代码的业务代码中拆分出来的。
176.步骤302、运行应用程序。
177.由于react
‑
native框架的应用程序的安装包中，包含的是从源代码的业务代码中拆分出的主业务代码，而非全部的业务代码，减少了该应用程序的安装包的体积，可以快速下载应用程序的安装包，减少了白屏时间，提高了用户体验。
178.在示例性实施例中，所述主业务代码是从所述应用程序的源代码的业务代码中拆分出来的，包括：响应于业务代码未被任何业务代码加载，将该业务代码拆分为主业务代码；响应于业务代码仅被当前拆分出的主业务代码同步加载或者被当前拆分出的主业务代码既同步加载又异步加载，将该业务代码添加至主业务代码；响应于业务代码仅被当前拆
分出的主业务代码中的一段业务代码异步加载，将该业务代码添加至主业务代码。
179.需要说明的是，本发明实施例提供的应用程序的加载方法中的安装包是上述应用程序的打包方法中得到的安装包，得到该安装包和其中的主业务代码的方式可以上述应用程序的打包方法的相关实施例实施，此处不做赘述。
180.在示例性实施例中，上述应用程序的加载方法还可以包括：基于应用程序运行过程中的输入操作，确定响应输入操作需要动态加载的次业务代码，次业务代码是从源代码的业务代码中拆分出来的；从服务端加载次业务代码。
181.实际应用中，用户终端从服务端加载react
‑
native框架的应用程序的安装包，并进行安装。在应用程序运行时，用户操作了一个按需加载的页面功能，如点击操作，此时，可以确定响应输入操作需要动态加载的次业务代码，然后，从服务端加载该次业务代码，从而实现了按需要动态加载次业务代码。
182.可以理解的是，上述应用程序的加载方法还可以包括基于加载的次业务代码，响应输入操作。
183.在示例性实施例中，所述次业务代码是从所述源代码的业务代码中拆分出来的，包括：响应于业务代码仅被当前拆分出的主业务代码中的多段业务代码异步加载，将该业务代码拆分为次业务代码；响应于业务代码仅被当前拆分出的次业务代码同步加载，将该业务代码添加至该次业务代码。
184.需要说明的是，本发明实施例提供的应用程序的加载方法中的次业务代码是上述应用程序的打包方法中得到的次业务代码，得到该次业务代码的具体方式可以上述应用程序的打包方法的相关实施例实施，此处不做赘述。
185.实际应用中，可以将动态加载的次业务代码在js上下文注册代码，以使得次业务代码能够执行，从而响应输入操作。具体的，可以通过类eval在js上下文注册代码。
186.在示例性实施例中，上述安装包中还可以包含映射关系，该映射关系为次业务代码的标识与次业务代码的名称信息的映射关系，该次业务代码的标识中包括次业务代码所包含的次业务代码的标识。相应的，从服务端加载次业务代码，其具体实现方式包括：从映射关系中，查找次业务代码的标识对应的名称信息；基于查找到的次业务代码的名称信息，确定次业务代码的加载地址；基于加载地址，从服务端加载次业务代码。
187.其中，次业务代码的名称信息可以是次业务代码的名称所对应的哈希值。实际应用中，可以基于次业务代码的名称信息，获得次业务代码的加载地址，基于该加载地址从服务端加载次业务代码。如此，可以基于映射关系准确加载到次业务代码。
188.实际应用中，可以基于应用程序的原生(native)中的import()函数动态加载次业务代码。import()函数用于动态导入模块，返回一个promise。promise：该对象用于表示一个异步操作的最终完成(或失败)及其结果值，resolve标志加载成功，reject标志加载失败。可以在import()传入需要加载的业务代码的标识来加载次业务代码。
189.由于react.lazy使用import()来懒加载组件，所以也可以直接基于react.lazy懒加载次业务代码。
190.在示例性实施例中，上述应用程序的加载方法还可以包括：记录每个次业务代码的加载状态。实际应用中，该加载状态可以为未加载，加载中，以及加载完成。示例性的，若未加载，记录为undefined，若加载完成，记录为0，若加载中，则记录为数组[resolvefn,
rejectfn,promise实例]。
[0191]
在示例性实施例中，从服务端加载次业务代码，其具体实现方式可以包括：响应于记录的次业务代码的加载状态为未加载，从服务端加载次业务代码。
[0192]
实际应用中，在确定需要动态加载次业务代码时，可以首先从记录的每段次业务代码的加载状态中，查找次业务代码的加载状态，如果是加载完成，则不再从服务端加载，如果是未加载，再从服务端加载次业务代码，从而避免了重复从服务端加载。
[0193]
另外，如果记录的次业务代码的加载状态是加载中，可以复用promise实例，此时，响应于记录的次业务代码的加载状态为加载中，将加载中的promise实例对应的结果，作为次业务代码的加载结果。如此，也无需重复从服务端加载次业务代码。
[0194]
在示例性实施例中，从服务端加载次业务代码时，可以通过预设接口从服务端加载次业务代码。该预设接口可以是fetch接口，fetch接口提供了一个获取资源的接口，可以在多种环境中获取资源。或者，该预设接口也可以是自定义的native接口。该native接口还用于对文件进行解密。为保证数据安全，在内部进行业务开发时，可以对文件加密，此时，可以通过native接口对文件进行解密，更安全。
[0195]
在示例性实施例中，上述应用程序的加载方法还可以包括：响应于未查找到异步加载的业务代码的标识，确定该业务代码位于主业务代码中。
[0196]
实际应用中，如上述应用程序的打包方法的相关实施例中的描述，可能存在的一种情况是，一段业务代码被主业务代码中的业务代码依赖，且既同步加载又异步加载，此时，该段业务代码是位于主业务代码中的，此时，可以认为是已经完成了加载了。基于此，当异步加载的业务代码的标识，在映射关系中未查找到时，可以认为该业务代码位于主业务代码中，已完成了加载，不会抛出异常。
[0197]
在示例性实施例中，上述应用程序的加载方法还可以包括：响应于次业务代码所依赖的业务代码被拆分至其它次业务代码，从服务端加载其它次业务代码。以一种可能的情况举例来说，如果一段业务代码被拆分至次业务代码f，该段业务代码所依赖的其它业务代码被拆分至了次业务代码g，这时，除了加载次业务代码f，还可以一同加载次业务代码g。如此，可以实现次业务代码的快速加载。
[0198]
下面以一个具体应用场景为例，对本发明实施例提供的方案进行更加详细地说明。
[0199]
本实施例提出了一种基于原生import()语法对react
‑
native动态加载的实现方案，在构建环节合理拆分，减少安装包体积，进而减少安装包下载耗时，提升用户体验，是拥有规范化、自由度高、可控性强、自动化程度高、可扩展性强、升级方向明确等多种优点的react
‑
native动态加载解决方案。
[0200]
在本实施例中，结合metro打包器实现本实施例的应用程序的打包方案，用户(开发react
‑
native人员)需使用预先构建的下载工具下载最新的react
‑
native(简称rn)模板并开启splitchunk标识，当需要对应用程序打包时，在构建环节，如图4所示，执行如下步骤：
[0201]
步骤401、依赖收集。
[0202]
本步骤中，预先对源代码进行拆分，得到通用代码(例如react
‑
native、react的第三方公共代码)和业务代码。该业务代码包括按照业务逻辑划分的多段业务代码，这里，每
段业务代码称为一个业务模块。metro打包器的serializer.customserializer获取到源程序的业务代码对应的依赖图。该依赖图能够表征各业务模块之间的依赖关系。
[0203]
步骤402、计算代码块(compute chunks)。
[0204]
本步骤中的一个代码块，也即上述一段次业务代码。一个代码块中可以包括至少一个业务模块。根据metro打包器对import()的async异步模块标识，通过计算代码块，得到了moduleids对象，该moduleids对象中记录了上述第一标识组、第二标识组分别所包含的业务模块的标识，例如身份标识(id，identity document)，记为moduleid。基于此，可以知道哪些业务模块应该被拆分成代码块，哪些业务模块应该被拆分到一起。本步骤的具体实现可以参考以上图2中步骤201至步骤203相关实施例，此处不做赘述。
[0205]
步骤403、对所有的业务模块进行编译，也即全量编译。
[0206]
本步骤中，通过metro打包器中的basejsbundle对所有的业务模块直接进行编译。
[0207]
步骤404、按照计算出的代码块进行预分配、重组和正式分配。
[0208]
本步骤中，先按照计算出的第二标识组进行预分配，根据预分配后每个代码块的大小(即占用存储空间的大小)与拆分的最小大小(即预设阈值)进行对比，如果未达到拆分的最小大小，重组业务模块，即将第二标识组添加到第一标识组中，然后，进行正式分配。具体可以参考图2步骤204至步骤205的相关实施例，此处不做赘述。
[0209]
步骤405、记录映射关系，进行打包。
[0210]
生成映射关系，该映射关系包括代码块的标识与代码块的名称所对应的哈希值映射关系，记为chunknametohashmap。代码块的标识由该代码块所包含的业务模块的标识构成。
[0211]
通过调用bundle to string，进行打包，队列批量输出代码块，以及安装包。该安装包中包含dll文件，该dll文件中包含通用代码，该安装包还包含主文件，该主文件包含主业务代码，称为main主文件。
[0212]
步骤406、修改主文件中的映射关系。
[0213]
本步骤中，修改main主文件中的chunkmoduleid to hash这个模块，将该模块的初始值替换成chunknametohashmap。该映射关系中代码块的名称所对应的哈希值也作为加载时cdn中的文件名。
[0214]
具体的，可以通过抽象语法树(ast，abstract syntax code)修改主文件中的映射关系。
[0215]
至此，代码块的拆分逻辑结束。
[0216]
用户(浏览器页面的使用者)操作了一个按需动态加载模块，如点击操作，此时，按需动态导入目标业务模块，即import(moduleid)，执行本方案的加载逻辑，该逻辑封装为中间件，记为wrapasyrequire，如图5所示，应用程序的加载过程如下：
[0217]
通过installedchunks记录所有代码块的加载状态，该installedchunks是一个闭包变量，示例性的，若未加载，记录为undefined，若加载完成，记录为0，若加载中，则记录为数组[resolvefn,rejectfn,promise实例]。promise实例的状态置为resolve，标志这这个代码块已经加载并在js上下文中注册完成。promise实例的状态置为reject，标志这这个代码块加载失败或超时。
[0218]
步骤501、基于映射关系确定是否从服务端加载目标业务模块。
[0219]
具体的，判断chunknametohashmap中是否包含目标业务模块的moduleid，如果不存在，说明该目标业务模块被打入主文件中但有异步引用的地方，此时应该在下一个promise.resolve()微队列中执行，表示该目标业务模块已经加载成功，如果存在，执行步骤502。
[0220]
步骤502、查找installedchunks，确定目标业务模块所在的目标代码块的加载状态，基于加载状态进行对应的处理。
[0221]
本步骤中，如果目标代码块的加载状态为未加载，可以直接加载目标代码块，或者可以继续判断目标业务模块是否被拆分，即是否目标业务模块所依赖的其它业务模块也拆分到了其它代码块，如果拆分，通过promise.all并发加载每个代码块，如果未拆分，则加载包含目标业务模块的代码块即可。在js上下文中判断该目标业务模块的加载状态，如果加载完成，js上下文注册过promise.all([])，则进入下一个微队列中执行。promise.all([])的功能是等待需要加载的所有的代码块的promise实例均为resolve。
[0222]
其中，加载时，可以调用fetch接口或者native接口加载目标代码块，native接口响应，结果成功类eval在js上下文注册代码，记录该目标代码块的加载状态为加载完成，并将promise状态置为resolve，失败则清空该目标代码块的加载状态，promise状态置为reject。注册过程示例如下：function(`"use strict"；${data}`)(),data为代码块的代码字符串。
[0223]
如果目标代码块的加载状态为加载中，通过promises.push方法复用同一个promise实例，例如，通过promises.push(installedchunkdata[2])实现，无需重复加载。其中，installedchunkdata[2]的取值为上述installedchunks包含的promise实例的取值。
[0224]
步骤503、输出处理结果。
[0225]
本步骤中，通过asyncrequire()返回处理结果。asyncrequire()是metor预留的接口，本身未实现任何功能，本实施例通过该接口返回了处理结果。
[0226]
本实施例的方案具有如下有益效果：
[0227]
1、基于原生import()拆分业务代码，使用时动态加载所需模块，减少安装包下载时间及体积，提升用户体验。
[0228]
2、可控性强、规范化，基于原生import()，开发人员使用自由度高，什么模块需要按需加载，应该怎样引用模块都由开发人员掌控。
[0229]
3、拆分逻辑的自由度高、扩展性强，由于基于原生import()，可以直接基于react.lazy实现路由懒加载。
[0230]
图6是本发明实施例中的一种示例性的应用程序的打包的示意图。如图6所示，本发明实施例提供的一种应用程序的打包装置600，包括：
[0231]
拆分模块601，用于将react
‑
native框架的应用程序的源代码的业务代码进行拆分，以得到拆分结果，拆分结果包括从源代码的业务代码中拆分出来的主业务代码；
[0232]
打包模块602，用于生成包含主业务代码的应用程序的安装包。
[0233]
在一种可能的实施方式中，拆分模块601，具体用于：
[0234]
响应于业务代码未被任何业务代码加载，将该业务代码拆分为主业务代码；
[0235]
响应于业务代码仅被当前拆分出的主业务代码同步加载或者被当前拆分出的主业务代码既同步加载又异步加载，将该业务代码添加至主业务代码；
[0236]
响应于业务代码仅被当前拆分出的主业务代码中的一段业务代码异步加载，将该业务代码添加至主业务代码。
[0237]
在一种可能的实施方式中，拆分结果还包括从源代码的业务代码中拆分出来的至少一段次业务代码，次业务代码用于在应用程序运行过程中被动态加载，拆分模块601，还用于：
[0238]
响应于业务代码仅被当前拆分出的主业务代码中的多段业务代码异步加载，将该业务代码拆分为次业务代码；
[0239]
响应于业务代码仅被当前拆分出的次业务代码同步加载，将该业务代码添加至该次业务代码。
[0240]
在一种可能的实施方式中，拆分模块601，具体用于：
[0241]
基于源代码的业务代码对应的依赖图，对源代码的业务代码进行拆分，以得到拆分结果。
[0242]
在一种可能的实施方式中，拆分模块601，具体用于：
[0243]
遍历依赖图中每段业务代码，分析当前遍历的业务代码的依赖信息；
[0244]
响应于当前遍历的业务代码没有被其它业务代码依赖，将当前遍历的代码的标识，添加至与主业务代码对应的第一标识组；
[0245]
响应于当前遍历的业务代码被其它业务代码依赖，基于当前遍历的业务代码与其它业务代码的依赖信息，将当前遍历的业务代码的标识，添加至第一标识组或者一个与一段次业务代码对应的第二标识组；
[0246]
将第二标识组对应的业务代码，确定为次业务代码；
[0247]
将第一标识组对应的业务代码，确定为主业务代码。
[0248]
在一种可能的实施方式中，拆分模块601，具体用于：
[0249]
响应于第二标识组对应的业务代码所占的存储空间的大小达到预设阈值，将第二标识组对应的业务代码，确定为次业务代码。
[0250]
在一种可能的实施方式中，拆分模块601还用于：
[0251]
响应于第二标识组对应的业务代码所占的存储空间的大小未达到预设阈值，将第二标识组添加至第一标识组。
[0252]
在一种可能的实施方式中，如图7所示，还包括：
[0253]
映射模块603，用于生成次业务代码的标识与次业务代码的名称信息的映射关系；
[0254]
打包模块602，具体用于：
[0255]
生成包含主业务代码和映射关系的安装包，映射关系用于通过需要动态加载的次业务代码的标识，查找次业务代码的标识对应的名称信息，以基于查找到的次业务代码的名称信息，确定次业务代码的加载地址，以及基于加载地址，从服务端加载次业务代码。
[0256]
关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处不做赘述。
[0257]
图8是本发明实施例中的一种示例性的应用程序的打包的示意图。如图8所示，本发明实施例提供的一种应用程序的加载装置800，包括：
[0258]
加载安装模块801，用于基于从服务端加载的react
‑
native框架的应用程序的安装包，安装应用程序，应用程序的安装包中包含主业务代码，主业务代码是从应用程序的源
代码的业务代码中拆分出来的；
[0259]
程序运行模块802，用于运行应用程序。
[0260]
在一种可能的实施方式中，所述主业务代码是从所述应用程序的源代码的业务代码中拆分出来的，包括：
[0261]
响应于业务代码未被任何业务代码加载，将该业务代码拆分为主业务代码；
[0262]
响应于业务代码仅被当前拆分出的主业务代码同步加载或者被当前拆分出的主业务代码既同步加载又异步加载，将该业务代码添加至主业务代码；
[0263]
响应于业务代码仅被当前拆分出的主业务代码中的一段业务代码异步加载，将该业务代码添加至主业务代码。
[0264]
在一种可能的实施方式中，如图9所示，还包括：
[0265]
加载确定模块803，用于基于应用程序运行过程中的输入操作，确定响应输入操作需要动态加载的次业务代码，次业务代码是从源代码的业务代码中拆分出来的；
[0266]
动态加载模块804，用于从服务端加载次业务代码。
[0267]
在一种可能的实施方式中，安装包中包含映射关系，映射关系为次业务代码的标识与次业务代码的名称信息的映射关系；
[0268]
动态加载模块804，具体用于：
[0269]
从映射关系中，查找次业务代码的标识对应的名称信息；
[0270]
基于查找到的次业务代码的名称信息，确定次业务代码的加载地址；
[0271]
基于加载地址，从服务端加载次业务代码。
[0272]
在一种可能的实施方式中，所述次业务代码是从所述源代码的业务代码中拆分出来的，包括：
[0273]
响应于业务代码仅被当前拆分出的主业务代码中的多段业务代码异步加载，将该业务代码拆分为次业务代码；
[0274]
响应于业务代码仅被当前拆分出的次业务代码同步加载，将该业务代码添加至该次业务代码。
[0275]
在一种可能的实施方式中，动态加载模块804，具体用于：
[0276]
响应于记录的次业务代码的加载状态为未加载，从服务端加载次业务代码。
[0277]
在一种可能的实施方式中，动态加载模块804，还用于：
[0278]
响应于记录的次业务代码的加载状态为加载中，将加载中的promise实例对应的结果，作为次业务代码的加载结果。
[0279]
在一种可能的实施方式中，动态加载模块804，还用于：
[0280]
响应于次业务代码所依赖的业务代码被拆分至其它次业务代码中，从服务端加载其它次业务代码。
[0281]
关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处不做赘述。
[0282]
优选的，本发明实施例还提供了一种电子设备，包括：处理器，存储器，存储在存储器上并可在处理器上运行的计算机程序，该计算机程序被处理器执行时实现上述方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
[0283]
图10是本发明实施例提供的一种示例性的电子设备的结构示意图。如图10所示，
该电子设备可以包括：处理器1001、通信接口1002、存储器1003和通信总线1004，其中，处理器1001，通信接口1002，存储器1003通过通信总线1004完成相互间的通信。处理器1001可以调用存储器1003中的计算机程序，以执行以上任一实施例中的方法。
[0284]
本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(read
‑
only memory，简称rom)、随机存取存储器(random access memory，简称ram)、磁碟或者光盘等。
[0285]
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
[0286]
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。
[0287]
上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本发明的保护之内。
[0288]
本领域普通技术人员可以意识到，结合本发明实施例中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
[0289]
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0290]
在本技术所提供的实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0291]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目
的。
[0292]
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
[0293]
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
[0294]
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。