生成及加载文件包的方法、装置、介质和计算设备与流程

1.本公开的实施方式涉及计算机软件技术领域，更具体地，本公开的实施方式涉及一种生成及加载文件包的方法、装置、介质和计算设备。


背景技术：

2.本部分旨在为本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
3.在应用程序在发布之前，通常需要将记录有程序代码的模块(module)文件打包为文件包(bundle)，以便客户端下载和执行。随着应用程序的代码量逐渐增长，若仍然将应用程序的全部模块文件打包为一个体积较大的文件包，将会导致文件的加载和执行时间显著增加，从而导致客户端性能恶化。为此，可以通过拆分打包的方式将应用程序的全部模块文件打包成多个文件包，以便客户端分别下载。
4.为实现拆分打包，现阶段通常由应用程序的开发人员在编写程序代码时设置多个入口文件，并指定各个入口文件分别对应的模块文件，实现对模块文件的拆分；进而，对各个入口文件及其分别对应的模块文件进行打包，从而得到分别对应于各个入口文件的文件包。


技术实现要素：

5.但是，相关技术中的上述拆包方案需要开发人员手动设置多个入口文件，在应用程序的代码发生变更的情况下，还需要注意手动更新相应的入口文件，因此难以实现应用程序的快速更新。而且在生成文件包的过程中，任一入口文件及其对应的模块文件需要统一经过解析(resolution)、转换(transformation)和序列化(serialization)的完整打包过程，才能够生成相应的文件包，而对于多个入口文件及其分别对应的模块文件，就需要分别经过上述完整打包过程才能够生成应用程序的多个文件包，因此拆分和打包的整体效率较低。
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.图1示意性地示出了根据本公开实施方式的一种应用程序部署及运行系统的示意图；
31.图2示意性地示出了根据本公开实施方式的一种生成文件包的方法的流程图；
32.图3示意性地示出了根据本公开实施方式的一种依赖树的示意图；
33.图4示意性地示出了根据本公开实施方式的一种生成及加载文件包的过程示意图；
34.图5示意性地示出了根据本公开实施方式的一种加载文件包的方法的流程图；
35.图6示意性地示出了根据本公开实施方式的一种页面关系的示意图；
36.图7示意性地示出了根据本公开实施方式的一种介质的示意图；
37.图8示意性地示出了根据本公开实施方式的一种生成文件包的装置的框图；
38.图9示意性地示出了根据本公开实施方式的一种加载文件包的装置的框图；
39.图10示意性地示出了根据本公开实施方式的一种计算设备的示意图。
40.在附图中，相同或对应的标号表示相同或对应的部分。
具体实施方式
41.下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。
42.本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法
或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。
43.根据本公开的实施方式，提出了一种生成及加载文件包的方法、装置、介质和计算设备。
44.在本文中，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。
45.下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。
46.发明概述
47.发明人发现，相关技术中的拆包方案需要开发人员手动设置多个入口文件，在应用程序的代码发生变更的情况下，还需要注意手动更新相应的入口文件，因此难以实现应用程序的快速更新。而且在生成文件包的过程中，任一入口文件及其对应的模块文件需要统一经过解析、转换和序列化的完整过程，才能够生成相应的文件包，而对于多个入口文件及其分别对应的模块文件，就需要分别经过上述完整过程才能够生成应用程序的多个文件包，因此拆分和打包的整体效率较低。另外，通过上述方式得到的多个文件包分别对应于不同的入口文件，客户端需要下载并加载全部文件包才能够向用户展示相应的页面内容，加载效率较低导致内容展示耗时较长，影响用户体验。
48.为了解决上述问题，本公开提供一种生成及加载文件包的方法、装置、介质和计算设备。
49.根据本公开实施方式的生成文件包的方法，对于包括至少一个中间文件和依赖于所述中间文件的一个入口文件在内的多个模块文件，文件包的生成设备可以确定多个模块文件之间的依赖关系，然后响应于中间文件包括按照动态方式导入入口文件的动态中间文件，根据上述依赖关系生成入口文件对应的第一文件包和动态中间文件对应的第二文件包，其中，所述第二文件包可以被所述应用程序的客户端用于在所述第一文件包之后加载。根据本公开实施方式的加载文件包的方法，应用程序的客户端可以加载第一文件包产生第一页面，进而响应于在所述第一页面中检测到的文件包获取指令，获取并加载第二文件包。
50.采用这样的方式，应用程序的全部模块文件中仅包含一个入口文件，该文件被用于生成相应的第一文件包，而被导入该入口文件的动态中间文件则被用于生成第二文件包。可见，因为其他模块文件均被导入同一个入口文件，所以开发人员无需逐一手动变更入口文件，只需更新相应模块文件中的代码即可实现文件包的自动化拆分和打包，从而有助于实现应用程序的快速更新。而且，因为仅生成对应于入口文件的一个第一文件包和对应于动态中间文件的第二文件包，所以上述各个文件包的仅需要经过解析、转换和序列化的一个完整过程即可实现，显著提升了文件包的生成速度。
51.另外，对于通过该方式得到的多个文件包，客户端可以首先加载入口文件展示第一页面，进一步地，在该页面中检测到文件包获取指令的情况下再获取并加载相应的第二文件包，而无需一次性加载全部文件包，实现了对第二文件包的按需加载，有助于避免对第二文件包的非必要加载，从而提升了客户端加载文件包的效率；而且由于需要获取和加载的第二文件包数量较少，因此能够大幅缩短用户的等待时长，从而提升用户体验。
52.在介绍了本公开的基本原理之后，下面具体介绍本公开的各种非限制性实施方式。
53.应用场景总览
54.需要注意的是，上述应用场景仅是为了便于理解本公开的精神和原理而示出，本公开的实施方式在此方面不受任何限制。相反，本公开的实施方式可以应用于适用的任何场景。
55.图1是一示例性实施例提供的一种应用开发及运行系统的示意图。如图1所示，该系统可以包括网络10、服务器11、数据库12、若干电子设备，如手机13、手机14和手机15等。
56.手机13-15只是用户可以使用的一种类型的电子设备举例。实际上，用户显然还可以使用诸如下述类型的电子设备：平板设备、笔记本电脑、掌上电脑(pdas，personal digital assistants)、可穿戴设备(如智能眼镜、智能手表等)等；上述任一电子设备中运行的客户端(如下述开发客户端或者应用程序的客户端)可以被预先安装在电子设备上，使得该客户端可以在该电子设备上被启动并运行。
57.服务器11可以为包含一独立主机的物理服务器，或者该服务器11可以为主机集群承载的虚拟服务器、云服务器等；数据库12可以为集中式或者分布式的数据库等，本说明书一个或多个实施例并不对此进行限制。而对于网络10，可以包括多种类型的有线或无线网络。
58.首先需要说明的是，上述应用开发及运行系统可以由应用开发平台和应用运行平台所构成。其中，应用开发平台可以包括应用程序的开发客户端(如手机13)和存储设备(如数据库12)，应用程序的开发人员可以通过所述开发客户端编写、编译该应用程序的代码，根据包含上述代码的模块文件生成文件包并发布至所述存储设备，当然，上述开发代码、生成和发布文件包的过程也可以由所述开发客户端、存储设备和服务器11相互配合实现。应用运行平台可以包括该应用程序的服务端(如服务器11)、存储设备(如数据库12)和客户端(如手机14-15)，在所述应用程序的新版本客户端对应的文件包被发布至所述存储设备之后，该应用程序的旧版本客户端可以从存储设备中获取并加载上述文件包，从而在本地实现新版本客户端，该客户端可以通过与服务端相互配合实现相应的业务功能(如展示页面、在页面中展示控件等)。当然，上述新、旧版本客户端仅是为了区分加载文件包前后的客户端，上述两客户端在实际应用中可以使用同一版本号，不再赘述。
59.简而言之，图1所示的手机13或者服务器11可以通过本公开实施例所述的生成文件包的方法对记录有上述程序代码的模块文件进行拆分和打包，从而生成相应的第一文件包和第二文件包，并将上述文件包发布至数据库12中。手机13和手机14可以通过本公开实施例所述的加载文件包的方法从上述数据库12处获取并加载第二文件包，进而通过与服务器11交互实现该应用程序的预设功能。
60.在本实施例中，应用开发及运行系统不仅可以实现生成和加载文件包的功能，还可以作为诸多其他功能的集成化功能平台，比如对代码进行依赖分析并生成依赖树、检测中间文件中的预设标记、确定文件包的存储地址、发布或下载已生成的文件包、跳转相应页面等，本说明书一个或多个实施例并不对此进行限制。
61.根据本公开实施方式的生成文件包的方法，对于包括至少一个中间文件和依赖于所述中间文件的一个入口文件在内的多个模块文件，文件包的生成设备可以确定多个模块文件之间的依赖关系，然后响应于中间文件包括按照动态方式导入入口文件的动态中间文件，根据上述依赖关系生成入口文件对应的第一文件包和动态中间文件对应的第二文件
包，其中，所述第二文件包可以被所述应用程序的客户端用于在所述第一文件包之后加载。根据本公开实施方式的加载文件包的方法，应用程序的客户端可以加载第一文件包产生第一页面，进而响应于在所述第一页面中检测到的文件包获取指令，获取并加载第二文件包。
62.其中，本公开实施例所述的应用程序，可以基于react native技术框架所开发，即该应用程序可以为rn应用。所述rn应用可以运行于终端设备的android(安卓)或者ios操作系统中，具体可以为上述操作系统中独立运行的app(application)。上述rn应用在运行过程中可以获取并加载已经发布的相关数据，即获取并加载通过本方案所述方案生成的所述文件包。另外，可以使用javascript编程语言编写本公开所述应用程序的代码。
63.示例性方法
64.需要注意的是，上述应用场景仅是为了便于理解本公开的精神和原理而示出，本公开的实施方式在此方面不受任何限制。相反，本公开的实施方式可以应用于适用的任何场景。
65.参考图2，图2示意性地示出了根据本公开实施方式的一种生成文件包的方法的流程图。该方法可以包括以下步骤s201-s202。
66.步骤s201，确定多个模块文件之间的依赖关系，所述多个模块文件包括至少一个中间文件和依赖于所述中间文件的一个入口文件，各个模块文件用于记录应用程序的代码。
67.该方法可以应用于开发应用程序的第一设备，如前述的手机13或者服务器11，具体可以由运行于第一设备中的应用程序开发软件所实现。其中，在第一设备为开发人员使用的终端设备(如所述手机13)的情况下，开发人员可以通过该终端设备中运行的开发软件编写、编译应用程序的代码，进而根据该软件提供的文件包生成功能触发该终端设备根据本公开所述生成文件包的方法生成相应的文件包并进行发布；在第一设备为服务器(如所述服务器11)的情况下，开发人员可以将上述代码或者记录有上述代码的各个模块文件提交至服务器，并触发服务器本公开所述生成文件包的方法生成相应的文件包并进行发布。
68.在开发人员对待发布的应用程序的代码完成编写、编译等开发步骤之后，可以得到多个模块文件，此时第一设备可以通过本方案所述的生成文件包的方法根据上述各个模块文件生成文件包，以用于发布。本公开实施例所述的模块文件即为module、所述的文件包即为bundle，本公开实施例所述的生成文件包的方案即用于通过多个module生成相应地bundle。
69.其中，上述多个模块文件包括至少一个中间文件和依赖于所述中间文件的一个入口文件，任一模块文件的文件类型(即该文件为入口文件还是中间文件)可以由开发人员指定，并被记录在该文件的头部信息或者该文件的代码中。例如，对于拆分前的文件代码，可以在其下述注册代码中写入下述语句，用于标识入口文件：
70.appregistry.registercomponent(appname,()＝》app)；
71.以模板文件module a为例，可以在module a对应的文件代码的尾部写入语句：
72.appregistry.registercomponent(appname
‘
a’,()＝》{return《app/》})；
73.从而将拆分后的模块文件module a指定为入口文件。
74.各个模块文件均用于记录所述应用程序的代码，不同模块文件中可以记录相同或者不同的代码。本公开实施例所述任一模块文件中记录的“代码”可以包括狭义的程序代
码，这类代码可以是所述应用程序运行阶段所需的基础代码，如用于绘制页面、设置页面背景或其他参数的代码等；或者，任一模块文件中包含的“代码”也可以包括广义的程序代码，这类代码可以是程序运行阶段所需的程序资源，如文字、图片等。其中，上述代码可以关联至音乐、视频等多种形式的多媒体资源，如上述文字可以为某视频访问地址的超链接，或者上述图片可以被设置有某音乐的访问跳转功能等，不再赘述。换言之，本公开实施例对于任一模块文件中记录的内容并不对此进行限制。
75.为了保证加载后的各个文件包能够实现预设功能，所生成的各个文件包与其对应的模块文件之间需要满足预设逻辑关系，而该逻辑关系可以通过各个模块文件之间的依赖关系所体现。因此，在生成文件包之间，第一设备可以先确定多个模块文件之间的依赖关系。
76.在一实施例中，第一设备可以通过依赖树确定多个模块文件之间的依赖关系。例如，可以对所述多个模块文件记录的代码进行依赖分析，并根据分析结果生成多个模块文件对应的依赖树，进而可以根据该依赖树确定多个模块文件之间的依赖关系。
77.以图3为例进行说明，图3所示即为对module a～i共九个模块文件进行依赖分析后生成的依赖树。由图可见，上述九个模块文件中包括一个入口文件module a和八个中间文件module b～i。由该依赖树可以确定上述各个模块文件之间的依赖关系如下：module a依赖于module b、module f和module g这三个模块文件，进一步地，module b依赖于module c，module c依赖于module d和module e；module f不依赖于其他模块文件；module g依赖于module h，module h进一步依赖于module i。
78.步骤s202，响应于所述中间文件包括按照动态方式导入所述入口文件的动态中间文件，根据所述依赖关系生成所述入口文件对应的第一文件包和所述动态中间文件对应的第二文件包，其中，所述第二文件包被所述应用程序的客户端用于在所述第一文件包之后加载。
79.对于上述多个模块文件中的至少一个中间文件，第一设备可以确定各个中间文件的导入方式，以便根据中间文件的导入方式生成相应类型的文件包。任一中间文件的导入方式，即为该中间文件被导入入口文件的方式，进一步地，应用程序的客户端在运行阶段可以根据该导入方式对应的加载方式加载该中间文件对应的文件包。任一中间文件的导入方式可以为动态导入或者静态导入，在任一中间文件的导入方式为动态导入的情况下，该中间文件即为动态中间文件；在任一中间文件的导入方式为静态导入的情况下，该中间文件即为静态中间文件。
80.第一设备可以通过多种方式确定任一中间文件为动态中间文件。例如，开发人员可以在编写任一中间文件中的代码时，在其中写入预设动态标记或者预设静态标记，以便指定将该中间文件导入入口文件的方式。相应地，第一设备可以在任一中间文件中记录有预设动态标记的情况下，确定该中间文件为动态中间文件。其中，上述预设动态标记和预设静态标记可以记录在导入类型语句中，如预设动态标记和预设静态标记可以分别为“async”和“sync”，相应的导入类型语句可以分别为：
81.const asyncmodule＝import(
‘
./asyncmodule’)；和，
82.import syncmodule from
‘
./syncmodule’；
83.从而，根据任一中间文件的导入类型语句，即可判断该中间文件为何种倒入类型。
通过该方式，开发人员可以在编写代码时指定将各个中间文件导入相应入口文件的方式，在该导入方式发生变化的情况下，只需修改上述代码即可，无需对多个入口文件分别进行处理，从而有助于简化应用程序的更新操作。
84.再例如，开发人员可以按照特定导入方式编写任一中间文件中的代码，以指定将该中间文件导入入口文件的方式。相应地，第一设备可以在任一中间文件中记录的代码被按照动态导入对应的语法规则编写的情况下，将该中间文件确定为动态中间文件。其中，上述语法规则可以为编程语言对应的原生规则；或者，为满足开发人员的个性化需求，上述语法规则也可以采用由开发人员在应用程序的配置文件中指定的自定义规则，本公开实施例并不对此进行限制。
85.如图3所示依赖树对应的多个模块文件，不妨假设module b被到动态导入module a、module h被动态导入module g、其他各个中间文件均被静态导入相应的上一级中间文件，不再赘述。在确定各个中间文件中的动态中间文件后，第一设备可以根据所述依赖关系生成入口文件对应的第一文件包和动态中间文件对应的第二文件包。
86.在一实施例中，第一设备可以根据上述依赖关系逐级生成相应的文件包，例如，可以先生成各个动态中间文件分别对应的第二文件包，然后基于生成的各个第二文件包生成所述入口文件对应的第一文件包。承接于前述实施例，对于图3所示的各个模块文件，根据前述依赖关系以及各个中间文件的代入方式，第一设备可以根据module b～e生成bundle1、并根据module h和module i生成bundle2，进而根据所述bundle1和bundle2，并结合module a、module f和module g生成bundle0。显然，上述bundle0为入口文件module a对应的第一文件包、bundle1为中间文件module b～e对应的第二文件包、bundle2为中间文件module h和module i对应的第二文件包。其中，根据多个模块文件生成一个文件包的过程，可以为将所述多个模块文件打包成一个文件包的过程。
87.实际上，多个第二文件之间也可以存在层级关系。例如，若上述module i也为动态中间文件，即module i通过动态方式导入module h(图3并未示出)，在其他各个模块文件之间的依赖关系和导入方式不变的情况下，第一设备可以先根据module i生成第二文件包bundle2”，再根据module h生成第二bundle2’，最后根据所述bundle1、bundle2”和bundle2’，并结合module a、module f和module g生成第一文件包bundle0’。
88.其中，为保证客户端在加载第一文件包之后能够顺利获取并加载第二文件包，在生成第一文件包时可以在其中记录第二文件包的存储地址。例如，第一设备可以确定各个第二文件包的第二存储地址，该第二存储地址用于存储发布后的相应的所述第二文件包(即任一第二文件包在发布后将被保存在该第二文件包的第二存储地址处)，然后可以将确定出的各个第二存储地址记录在第一文件包中。实际上，对于所述第一文件包，也可以确定用于存储该文件包的第一存储地址。其中，任一文件包的存储地址可以根据{约定域名} {应用程序名称} {bundle名称}的规则生成，所述“约定域名”可以为所述应用程序的服务端的访问地址或域名等，所述“应用程序名称”可以为所述应用程序的全称或者预设编号等标识，所述“bundle名称”可以为该文件包的文件包名称，如全称或者预设编号等，不再赘述。
89.承接于图3对应的前述实施例，第一设备可以分别确定所述bundle1和bundle2的第二存储地址，然后可以将确定出的第二存储地址记录在bundle0中，如可以在生成
bundle0时将上述第二存储地址记录在bundle0的文件包头部或者文件包信息中，不再赘述。通过该方式，客户端在加载第一文件包时可以从中确定该第二文件包对应的各个第二文件包的第二存储地址，进而在需要加载任一第二文件包时可以从相应的第二存储地址处下载该第二文件包，不仅实现了第一文件包和第二文件包的分离，而且实现了各个文件包的存储地址的分离，有助于提升文件包的发布及下载效率。
90.在另一实施例中，第一设备中运行的开发软件可以为metro工具，该工具为react native官方提供的打包工具，可以用于根据各个模块文件生成相应的文件包。在使用metro工具进行拆分打包时，一个完整的打包过程包括解析、转换和序列化三个阶段，其中，在解析阶段可以对各个模块文件记录的代码进行代码分析，并生成各个模块文件之间的依赖树；在转换阶段可以将使用当前语言版本编写的上述代码转换为待发布的应用程序对应的目标版本语言的代码，以提升发布后的各个文件包在加载过程中的兼容性，保证应用程序的顺利运行和预设功能的顺利实现；在序列化阶段可以根据记录有上述转换后代码的各个模块文件生成相应的文件包。
91.实际上，在获取到相关各方充分授权的情况下，本公开实施例所述的生成文件包的方法可以实现为上述metro工具的功能插件，如以外挂或内嵌的方式与该工具配合运行。上述功能插件可以作为对metro工具所提供原生功能的补充和改进，开发人员在使用metro工具对待发布的应用程序的代码进行开发之后，可以通过该功能插件对记录有上述代码的各个模块文件进行拆分打包，并生成相应的第一文件包和第二文件包用于发布。
92.在相关技术中，待发布的应用程序对应的模块文件中通常包含多个入口文件，因此各个入口文件及其对应的中间文件都需要分别、依次经过上述三个阶段才能够生成相应的文件包，换言之，对于具有n个入口文件的应用程序来说，需要经过n次完整的打包过程才能够生成n个文件包，文件包的生成过程步骤繁琐、效率太低。
93.而在本公开所述的一实施例中，可以由metro工具在同一序列化阶段，根据所述依赖关系生成入口文件对应的第一文件包和动态中间文件对应的第二文件包。在本公开所述实施例中，因为所述多个模块文件中仅包含一个入口文件，所以metro工具最终仅需要生成该入口文件对应的一个第一文件包以及(所述至少一个中间文件中包含的)至少一个动态中间文件分别对应的第二文件包即可，而且仅需要在一个完整的打包过程中即可生成上述一个第一文件包和至少一个第二文件包——metro工具只需要执行(包含上述三个阶段的)一次完整的打包过程即可，大大简化了文件包的生成步骤，显著提升了文件包的生成效率。
94.在另一实施例中，上述中间文件除了包括通过动态方式导入入口文件的动态中间文件之外，还可以包括通过静态方式导入入口文件的静态中间文件。在这种情况下，第一设备可以将上述静态中间文件打包至所述第一文件包，以生成该第一文件包。显然，上述入口文件依赖于被打包至第一文件包的所述静态中间文件。当然，在任一动态中间文件依赖于至少一个静态中间文件的情况下，第一设备也可以将所述至少一个静态中间文件打包至该动态中间文件对应的第二件包，以生成该第二文件包。仍以图3所示依赖树为例，入口文件module a所依赖的module f和module g被通过静态方式导入module a，即module f和module g均为静态中间文件，则在生成第一文件包bundle0时可以将module f和module g打包至该文件包中。动态中间文件module h所依赖的module i被通过静态方式导入module h，即module i均为静态中间文件，则在生成第二文件包bundle2时可以将module i打包至
该文件包中；动态中间文件module b所依赖的module c与此类似，不再赘述。
95.通过前述实施例所述方式生成第一文件包和第二文件包之后，第一设备可以将上述文件包发布至相应的存储设备中。例如，第一设备可以分别确定所述第一文件包的第一存储地址和所述第二文件包的第二存储地址，然后将第一文件包发布至所述第一存储地址，并将第二文件包发布至所述第二存储地址。当然，在前述步骤生成了多个第二文件包的情况下，可以分别确定各个第二文件包的第二存储地址，并将各个第二文件包分别发布至各自对应的第二存储地址，以便实现各个文件包之间的隔离。
96.另外，上述第一文件包和第二文件包可以在生成后关联发布至所述存储设备；或者，在先生成第二文件包再生成第一文件包的情况下，也可以按照上述生成顺序依次发布上述第二文件包和第一文件包，本公开实施例并不对此进行限制。
97.其中，任一文件包的存储地址即为发布后的该文件包在存储设备中的存储地址。上述存储设备可以具有多种形式，如为了便于实现对文件包的管理，该存储设备可以为中心化的数据库；而在所述应用程序的客户端分布范围较广的情况下，上述存储设备也可以采用分布式的数据库，如可以为cdn(content delivery network，内容分发网络)。在这种情况下，客户端可以就近下载被发布的文件包，有助于减少客户端地理位置分散造成的下载延迟，从而提升客户端的响应速度，进而提升用户体验。
98.采用这样的方式，应用程序的全部模块文件中仅包含一个入口文件，该文件被用于生成相应的第一文件包，而被导入该入口文件的动态中间文件则被用于生成第二文件包。可见，因为其他模块文件均被导入同一个入口文件，所以开发人员无需逐一手动变更入口文件，只需更新相应模块文件中的代码即可实现文件包的自动化拆分和打包，从而有助于实现应用程序的快速更新。而且，因为仅生成对应于入口文件的一个第一文件包和对应于动态中间文件的第二文件包，所以各个文件包的仅需要经过解析、转换和序列化的一个完整过程即可实现，显著提升了文件包的生成速度。
99.请参见图4所示的生成及加载文件包的过程示意图。如图4所示，第一设备所在的应用开发平台可以通过前述各个实施例所述的方案将应用程序的多个module拆分打包并生成多个bundle，即将多个模块文件自动拆分以生成一个第一文件包和至少一个第二文件包。此后，该平台可以将上述多个bundle推送至cdn中，以由cdn将其分别保存在相应的存储地址，从而完成对各个文件包的发布。其中，被发布的任一文件包可以对应于应用程序的一个页面或者页面中需要显示的组件等至少一个页面内容。在上述文件包发布之后，应用程序的客户端(如图4所示的rn应用客户端)可以在展示上述页面或页面内容之前，从cdn处下载相应的文件包，通过加载该文件包并进行页面渲染，即可展示出上述页面或页面内容。
100.下面结合图5所示的一种加载文件包的方法的流程图，对文件包的加载过程进行详细说明。该方法可以应用于运行有所述应用程序的客户端的第一设备，如图1所述的手机14或手机15，其中，该方法可以由所述应用程序的客户端所实现，下述实施例均以该客户端作为执行主体进行说明。该方法可以包括以下步骤s501-s502。
101.步骤s501，响应于在第一页面中检测到的文件包获取指令获取第二文件包，所述第一页面由应用程序的客户端加载第一文件包所产生。
102.首先需要说明的是，本公开实施例所述的第一文件包和第二文件包可以通过前述实施例所述的生成文件包的方法所生成，或者也可以通过其他方法所生成，本公开实施例
并不对此进行限制。
103.应用程序的客户端可以先加载第一文件包以展示第一页面，该第一页面可以为应用程序的首页，当然也可以为其他任意页面。考虑到上述第一文件包通常为客户端的功能入口，通过第一文件包对应的第一页面可以跳转至其他功能页面，所以第一文件包的第一存储地址可以为固定地址并由该客户端所维护，从而客户端可以在启动后根据自身维护的固定地址获取被发布的第一文件包，进而通过加载该第一文件包显示出第一页面。在客户端维护第一文件包的固定存储地址的情况下，客户端可以对上述第一文件包的发布过程无感知，而只需要正常按照上述固定存储地址获取相应的第一文件包，即可加载得到更新后的、最新的第一页面，因此有助于简化客户端的文件包加载逻辑和应用程序维护逻辑。
104.展示第一页面的客户端可能会产生或者接收到用于触发获取第二文件包的文件包获取指令。例如，客户端可能接收到服务端发送的文件包获取指令。再例如，客户端也可能接收到附近的其他设备通过近场方式发送至第一设备的文件包获取指令，如手机扫描可租借物品或者被收银设备扫描后，可租借物品或者收银设备可以通过近场信号的方式向手机14发送相应的文件包获取指令。又例如，在查看第一页面的过程中，第二设备的用户可能会对该页面中的某些页面内容感兴趣，从而针对第一页面实施第一触发操作。其中，被触发的上述页面内容可以为图片、视频或音乐等多媒体资源的入口，也可以为按钮等可触发控件；上述第一触发操作可以为点击或滑动等动作，也可以为唤醒或操控语音等，本公开实施例并不对此进行限制。响应于上述第一触发操作，客户端或者第一设备可以生成相应的文件包获取指令，进而，客户端可以响应于该指令获取相应的第二文件包。
105.在一实施例中，客户端可以先确定所述文件包获取指令对应的第二文件包的存储地址(即前述的第二存储地址)，如在该文件包获取指令中记录有上述存储地址的情况下，可以从该指令中解析该存储地址。或者，客户端本地或者服务端处也可以维护应用程序的各个第二文件包的文件包标识与存储地址之间的映射关系，从而在文件包获取指令包含需要获取的第二文件包的文件包标识的情况下，客户端可以根据从上述文件包获取指令中解析到的该文件包标识，从本地维护的上述映射关系中查询相应的存储地址，或者向服务端请求(由服务端查询)并获取相应的存储地址。其中，若上述映射关系保存在客户端本地，则客户端可以在第一文件包和第二文件包发布后首次下载第一文件包时关联下载该映射关系；或者该映射关系也可以记录在第一文件包中。另外，在下次发布所述第一文件包和第二文件包时，可以相应的更新上述映射关系。
106.进一步的，客户端可以从获取到的存储地址处下载所述第二文件包，例如，可以通过发送http(hyper text transfer protocol，超文本传输协议)请求的方式向从上述存储设备中获取第二文件包。其中，客户端可以根据获取到的所述存储地址生成http请求的报文头，然后通过发送该http请求获取上述第二文件包。因为http请求自身具有缓存机制，所以在发送所述请求之前，客户端可以根据该机制检查本地是否已经保存有需要获取的第二文件包，从而避免短时间内重复获取同一第二文件包，以便节省流量并减少网络拥堵。如在用户触发第一页面(获取第二文件包)导致客户端跳转至第二页面并退回第一页面之后，若短时间内(第二文件包尚未从本地删除)再次实施相同的触发操作，则客户端可以直接加载本地的第二文件包，而无需从存储设备处重复下载。
107.步骤s502，加载所述第二文件包，所述第一文件包和所述第二文件包被响应于预
设条件并根据多个模块文件之间的依赖关系而生成，其中，所述多个模块文件包括至少一个中间文件和依赖于所述中间文件的一个入口文件，所述预设条件包括：所述中间文件包括动态中间文件，所述动态中间文件按照动态方式导入所述入口文件，各个模块文件用于记录所述应用程序的代码。
108.在获取所述第二文件包之后，客户端可以加载该文件包。因为当前时刻展示的第一页面对应于第一文件包，该第一文件包与获取到的第二文件包分别对应于入口文件与动态中间文件，且入口文件与动态中间文件之间满足相应的依赖关系，所以客户端可以在第一文件包的运行环境中加载获取到的第二文件包，以保证同一应用程序所对应各个文件包的运行环境一致，避免在加载第二文件包过程中出现兼容性问题。
109.以加载第一文件包产生第一页面、加载第二文件包产生第二页面为例：通过上述方式，运行在同一运行环境中的第一页面和第二页面之间可以实现双向通信。换言之，在这种情况下，虽然本方案的执行主体是客户端，但是实际进行数据交互的是第一页面和第二页面，如第一页面所在的线程与第二页面所在的线程之间可以进行数据传递。显然，该方式无需客户端在两页面之间进行数据中转，有助于提升页面交互效率以及客户端对所述文件包获取指令的响应速度。
110.在一实施例中，第二设备在同一时刻往往并非仅运行一个应用程序，因此第二设备在运行所述应用程序的客户端的过程中，通常会为该客户端分配客户端容器，用于管理该客户端可以调用的软硬件资源。其中，所述客户端容器可以由该应用程序的客户端独占，或者也可以与其他应用程序共享。在这种情况下，客户端可以在加载第一文件包的客户端容器中加载所述第二文件包。客户端在该客户端容器中加载所述第二文件包，能够充分保证第二文件包与第一文件包处于同一运行环境中。并且，将第一文件包和第二文件包加载在同一客户端容器中，无需分配新的客户端容器，而且无需客户端对自身容器进行适配，因此可以取得较佳的文件包加载速度以及客户端运行效率。
111.在另一实施例中，上述应用程序的代码可以由javascript语言编写，此时，所述第一文件包中记录的第一代码和所述第二文件包中记录的第二代码即由该语音编写，在这种情况下，客户端可以通过创建独立函数的方式加载第二文件包。例如，客户端可以生成包含所述第二代码的function()函数，并在所述第一代码的上下文(context)中执行该函数。通过上述方式，可以在相同的上下文中分别执行第一文件包和第二文件包，大大降低了向第一文件包中导入第二文件包的导入成本，且客户端无需对第一文件包和第二文件包进行适配。
112.从展示页面的角度来说，客户端响应于所述文件包获取指令获取并加载第二文件包，能够在第一页面的基础上进一步展示新的页面内容或者跳转至新的页面。例如，客户端可以根据第二文件包的加载结果刷新所述第一页面，从而对第一页面的页面内容进行更新。再例如，客户端也可以根据第二文件包的加载结果跳转至第二页面，其中，第二页面可以完全替换(遮盖)第一页面，也可以在第一页面上方以部分遮盖或者弹窗等方式展示第二页面；进一步的，客户端可以响应于针对第二页面的第二触发操作，根据相应的操作结果刷新所述第一页面或者跳转至第三页面。如在所述第一页面为会员购买页面的情况下，所述第二页面可以为付款页面，第二设备的用户可以在该付款页面中进行付款操作，进而，客户端可以根据付款结果进行后续展示：若付款成功，客户端可以将所述会员购买页面刷新为
购买后的会员主页，或者从会员购买页面跳转至当前余额页面等；否则，若因余额不足而付款失败，则客户端可以将所述会员购买页面刷新为购买失败页面，或者从会员购买页面跳转至更低等级会员费的对应的付款页面，以提升会员购买形成的成功率，不再赘述。具体的，上述页面更新可以具有多种形式，如可以在第一页面中新增页面内容、删除或隐藏已有页面内容、调整已有页面内容的大小、位置、颜色、速度、轨迹等展示参数，不再赘述。
113.如图4所示，客户端通过加载第一文件包展示出页面1，响应于用户在页面1中实时第一触发操作产生的文件包获取指令，客户端可以从cdn处下载相应的第二文件包，进而加载该文件包展示出页面2。当然，在任一页面的基础上也可以进一步下载页面内容(如页面组件)对应的文件包，从而在该页面中展示相应的页面内容。可见，通过上述方式，客户端可以响应于文件包获取指令按需下载各个第二文件包，而无需一次性下载应用程序对应的全部文件包。而且由图4以及前述实施例可见，在生成应用程序对应的各个文件包之后，发布、下载及加载的对象均为文件包，而非单一的模块文件或者代码，从而有助于提升处理效率。
114.根据本公开实施方式的生成文件包的方法，对于包括至少一个中间文件和依赖于所述中间文件的一个入口文件在内的多个模块文件，文件包的生成设备可以确定多个模块文件之间的依赖关系，然后响应于中间文件包括按照动态方式导入入口文件的动态中间文件，根据上述依赖关系生成入口文件对应的第一文件包和动态中间文件对应的第二文件包，其中，所述第二文件包可以被所述应用程序的客户端用于在所述第一文件包之后加载。根据本公开实施方式的加载文件包的方法，应用程序的客户端可以加载第一文件包产生第一页面，进而响应于在所述第一页面中检测到的文件包获取指令，获取并加载第二文件包。
115.采用这样的方式，应用程序的全部模块文件中仅包含一个入口文件，该文件被用于生成相应的第一文件包，而被导入该入口文件的动态中间文件则被用于生成第二文件包。可见，因为其他模块文件均被导入同一个入口文件，所以开发人员无需逐一手动变更入口文件，只需更新相应模块文件中的代码即可实现文件包的自动化拆分和打包，从而有助于实现应用程序的快速更新。而且，因为仅生成对应于入口文件的一个第一文件包和对应于动态中间文件的第二文件包，所以上述各个文件包的仅需要经过解析、转换和序列化的一个完整过程即可实现，显著提升了文件包的生成速度。
116.另外，对于通过该方式得到的多个文件包，客户端可以首先加载入口文件展示第一页面，进一步地，在该页面中检测到文件包获取指令的情况下再获取并加载相应的第二文件包，而无需一次性加载全部文件包，实现了对第二文件包的按需加载，有助于避免对第二文件包的非必要加载，从而提升了客户端加载文件包的效率；而且由于需要获取和加载的第二文件包数量较少，因此能够大幅缩短用户的等待时长，从而提升用户体验。
117.示例性介质
118.在介绍了本公开示例性实施方式的方法之后，接下来，参考图7对本公开示例性实施方式的介质进行说明。
119.本示例性实施方式中，可以通过程序产品实现上述方法，如可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，该存储器可以在设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读介质70可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
120.该程序产品可以采用一个或多个可读介质的任意组合。可读介质70可以是可读信
号介质或者可读介质。可读介质70例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
121.计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
122.可读介质70上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、re等等，或者上述的任意合适的组合。
123.可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，程序设计语言包括面向对象的程序设计语言，诸如java、c 等，还包括常规的过程式程序设计语言，诸如c语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
124.示例性装置
125.在介绍了本公开示例性实施方式的介质之后，接下来，参考图8和图9对本公开示例性实施方式的装置进行说明。关于下述装置，其中各个功能模块执行操作的具体方式以及执行操作后所实现的具体功能，均已在生成文件包的方法和加载文件包的方法的前述各实施例中进行了详细描述，此处不再详细阐述说明。
126.图8示意性地示出了根据本公开实施方式的一种生成文件包的装置的框图。该生成文件包的装置可以包括：
127.依赖确定模块801，用于确定多个模块文件之间的依赖关系，所述多个模块文件包括至少一个中间文件和依赖于所述中间文件的一个入口文件，各个模块文件用于记录应用程序的代码；
128.文件包生成模块802，用于响应于所述中间文件包括按照动态方式导入所述入口文件的动态中间文件，根据所述依赖关系生成所述入口文件对应的第一文件包和所述动态中间文件对应的第二文件包，其中，所述第二文件包被所述应用程序的客户端用于在所述第一文件包之后加载。
129.可选地，所述依赖确定模块801还用于：
130.对所述多个模块文件记录的所述代码进行依赖分析，以生成所述多个模块文件对应的依赖树；
131.根据所述依赖树确定所述多个模块文件之间的依赖关系。
132.可选地，任一中间文件为动态中间文件，包括：
133.所述任一中间文件中记录有预设动态标记；或者，
134.所述任一中间文件中记录的代码被按照动态导入对应的语法规则编写。
135.可选地，所述文件包生成模块802还用于：
136.生成各个所述动态中间文件分别对应的第二文件包；
137.基于各个第二文件包生成所述入口文件对应的第一文件包。
138.可选地，所述文件包生成模块802还用于：
139.确定各个第二文件包的第二存储地址，所述第二存储地址用于存储发布后的相应的所述第二文件包；
140.将确定出的各个所述第二存储地址记录在所述第一文件包中。
141.可选地，所述文件包生成模块802还用于：
142.由metro工具在同一序列化阶段，根据所述依赖关系生成所述入口文件对应的第一文件包和所述动态中间文件对应的第二文件包。
143.可选地，所述中间文件还包括按照静态方式导入所述入口文件的静态中间文件，所述文件包生成模块802还用于：
144.将所述静态中间文件打包至所述第一文件包。
145.可选地，还包括：
146.地址确定模块803，用于分别确定所述第一文件包的第一存储地址和所述第二文件包的第二存储地址；
147.文件包发布模块804，用于将所述第一文件包发布至所述第一存储地址，并将所述第二文件包发布至所述第二存储地址。
148.可选地，所述存储地址为所述第二文件包在内容分发网络中的存储地址。
149.图9示意性地示出了根据本公开实施方式的一种加载文件包的装置的框图。该加载文件包的装置可以包括：
150.文件包获取模块901，用于响应于在第一页面中检测到的文件包获取指令获取第二文件包，所述第一页面由应用程序的客户端加载第一文件包所产生；
151.文件包加载模块902，用于加载所述第二文件包，所述第一文件包和所述第二文件包被响应于预设条件并根据多个模块文件之间的依赖关系而生成，其中，所述多个模块文件包括至少一个中间文件和依赖于所述中间文件的一个入口文件，所述预设条件包括：所述中间文件包括动态中间文件，所述动态中间文件按照动态方式导入所述入口文件，各个模块文件用于记录所述应用程序的代码。
152.可选地，所述文件包获取指令由面向所述客户端的所述第一页面的第一触发操作产生。
153.可选地，所述文件包获取模块901还用于：
154.确定所述文件包获取指令对应的第二文件包的存储地址，并从所述存储地址处下载所述第二文件包。
155.可选地，所述文件包获取模块901还用于：
156.根据所述存储地址生成超文本传输协议http请求的报文头；
157.通过发送所述http请求获取所述第二文件包。
158.可选地，所述文件包加载模块902还用于：
159.在所述第一文件包的运行环境中加载所述第二文件包。
160.可选地，所述文件包加载模块902还用于：
161.在加载所述第一文件包的客户端容器中加载所述第二文件包。
162.可选地，所述第一文件包记录的第一代码和所述第二文件包记录的第二代码由javascript语言编写，所述文件包加载模块902还用于：
163.生成包含所述第二代码的function()函数，并在所述第一代码的上下文中执行所述function()函数。
164.可选地，还包括：
165.页面刷新模块903，用于根据所述第二文件包的加载结果刷新所述第一页面；或者，
166.页面跳转模块904，用于根据所述第二文件包的加载结果跳转至第二页面，并响应于针对所述第二页面的第二触发操作，根据相应的操作结果刷新所述第一页面或者跳转至第三页面。
167.示例性计算设备
168.在介绍了本公开示例性实施方式的方法、介质和装置之后，接下来，参考图10对本公开示例性实施方式的计算设备进行说明。
169.图10显示的计算设备100仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
170.如图10所示，计算设备100以通用计算设备的形式表现。计算设备100的组件可以包括但不限于：上述至少一个处理单元1001、上述至少一个存储单元1002，连接不同系统组件(包括处理单元1001和存储单元1002)的总线1003。
171.总线1003包括数据总线、控制总线和地址总线。
172.存储单元1002可以包括易失性存储器形式的可读介质，例如随机存取存储器(ram)10021和/或高速缓存存储器10022，可以进一步包括非易失性存储器形式的可读介质，例如只读存储器(rom)10023。
173.存储单元1002还可以包括具有一组(至少一个)程序模块10024的程序/实用工具10025，这样的程序模块10024包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
174.计算设备100也可以与一个或多个外部设备1004(例如键盘、指向设备等)通信。
175.这种通信可以通过输入/输出(i/o)接口1005进行。并且，计算设备100还可以通过网络适配器1006与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图10所示，网络适配器1006通过总线1003与计算设备100的其它模块通信。应当理解，尽管图中未示出，可以结合计算设备100使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
176.应当注意，尽管在上文详细描述中提及了生成文件包的装置或者加载文件包的装置的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。
177.此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
178.虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。