CN107168730A - 应用程序加载方法、服务器及终端 - Google Patents

Abstract

本申请实施例提供一种应用程序加载方法、服务器及终端，服务器将对应同一个业务的N个Bundle文件中的每个Bundle文件拆分为公共部分和业务部分，得到1个公共部分和N个业务部分，根据该1个公共部分、N个业务部分和属性配置文件得到从外到内依次为1个公共部分、属性配置文件以及N个业务部分的压缩文件并发送给终端，使得终端根据属性配置文件，确定待加载业务对应的业务部分，进而合并待加载业务对应的业务部分和1个公共部分，以加载待加载业务。该过程中，终端根据待加载业务对应的Bundle文件的标识读取属性配置文件，快速获得待加载业务对应的Bundle文件，实现快速加载Bundle文件的目的。

Description

应用程序加载方法、服务器及终端

技术领域

本申请实施例涉及计算机技术，尤其涉及一种应用程序加载方法、服务器及终端。

背景技术

随着互联网的发展，应用程序(Application，APP)等的种类和数量越来越多。开发人员通过开发各种APP来满足用户需求。

目前，开发人员通过React Native(RN)热更新平台开发APP，一个APP包括多个捆绑(Bundle)文件。终端的APP需要更新一些内容(如运营的弹窗或者功能模块)时，可以直接从热更新平台的服务器下载该APP的多个Bundle文件，然后该APP解析并加载下载的多个Bundle文件，在无需下载安装新版本的APP的同时，实现更新该APP的内容的功能。

然而，一个APP包含多个业务，每个业务都有对应的Bundle文件，如何从多个Bundle文件中找到当前业务对应的Bundle文件并加载，实为业界亟待解决的问题。

发明内容

本申请实施例提供一种应用程序加载方法、服务器及终端，通过根据待加载业务对应的Bundle文件的标识读取配置文件，快速获得待加载业务对应的Bundle文件，实现快速加载Bundle文件的目的。

第一方面，本申请实施例提供一种应用程序加载方法，包括：

服务器将N个捆绑文件中的每个捆绑文件拆分为公共部分和业务部分，以得到1个公共部分和N个业务部分，N≥1，且为整数；

所述服务器根据所述1个公共部分、N个业务部分和属性配置文件得到压缩文件，所述压缩文件从外到内依次为所述1个公共部分、所述属性配置文件以及所述N个业务部分，所述属性配置文件用于描述1个公共部分的属性和N个业务部分中每个业务部分的属性；

所述服务器向终端发送所述压缩包。

在一种可行的设计中，所述N个捆绑文件包含第一捆绑文件，所述第一捆绑文件包含所述公共部分和第一业务部分，所述N个业务部分包含所述第一业务部分，所述服务器向终端发送所述压缩包之后，还包括：

所述服务器更新所述第一业务部分，得到第一更新业务部分；

所述服务器向所述终端发送所述第一更新业务部分。

在一种可行的设计中，所述服务器向终端发送所述压缩包之后，还包括：

所述服务器更新所述公共部分，得到更新公共部分；

所述服务器向所述终端发送所述更新公共部分。

在一种可行的设计中，所述服务器根据所述1个公共部分、N个业务部分和属性配置文件得到压缩文件，包括：

所述服务器将所述N个业务部分打包成N个补丁文件；

所述服务器根据所述1个公共部分、所述N个补丁文件和所述属性配置文件得到所述压缩文件。

第二方面，本申请实施例提供一种应用程序加载方法，包括：

终端接收服务器发送的压缩文件，所述压缩文件从外到内依次为1个公共部分、属性配置文件以及N个业务部分，所述属性配置文件用于描述所述1个公共部分的属性和所述N个业务部分中每个业务部分的属性，所述1个公共部分和N个业务部分为所述服务器对N个捆绑文件中的每个捆绑文件进行拆分得到的；

所述终端根据所述属性配置文件，确定待加载业务对应的业务部分；

所述终端合并所述待加载业务对应的业务部分和所述1个公共部分，以加载所述待加载业务。

在一种可行的设计中，所述终端根据所述属性配置文件，确定待加载业务对应的业务部分，包括：

所述终端解压缩所述压缩文件，依次释放所述1个公共部分、所述属性配置文件以及所述N个业务部分；

所述终端根据所述配置文件构建Bundle目录，根据所述Bundle目录存储所述1个公共部分、所述属性配置文件以及所述N个业务部分；

所述终端根据所述Bundle目录，确定所述待加载业务对应的业务部分。

在一种可行的设计中，所述N个捆绑文件包含第一捆绑文件，所述第一捆绑文件包含所述公共部分和第一业务部分，所述N个业务部分包含所述第一业务部分，所述终端合并所述待加载业务对应的业务部分和所述1个公共部分之后，还包括：

所述终端接收所述服务器发送的第一更新业务部分，所述第一更新业务部分为所述服务器对所述第一业务部分进行更新得到；

所述终端根据所述第一更新业务部分，更新所述第一业务部分。

在一种可行的设计中，所述终端根据所述第一更新业务部分，更新所述第一业务部分，包括：

所述终端判断是否需要更新所述公共部分，若需要，则先更新所述公共部分，再根据所述第一更新业务部分，更新所述第一业务部分；若不需要，则根据所述第一更新业务部分，更新所述第一业务部分。

在一种可行的设计中，所述终端合并所述待加载业务对应的业务部分和所述1个公共部分之后，还包括：

所述终端接收所述服务器发送的更新公共部分，所述更新公共部分为所述服务器对所述公共部分进行更新得到；

所述终端根据所述更新公共部分更新所述公共部分。

第三方面，本申请实施例提供一种服务器，包括:

处理模块，用于将N个捆绑文件中的每个捆绑文件拆分为公共部分和业务部分，以得到1个公共部分和N个业务部分，N≥1，且为整数；根据所述1个公共部分、N个业务部分和属性配置文件得到压缩文件，所述压缩文件从外到内依次为所述1个公共部分、所述属性配置文件以及所述N个业务部分，所述属性配置文件用于描述1个公共部分的属性和N个业务部分中每个业务部分的属性；

收发模块，用于向终端发送所述压缩包。

在一种可行的设计中，所述N个捆绑文件包含第一捆绑文件，所述N个业务部分包含所述第一业务部分，所述第一捆绑文件包含所述公共部分和第一业务部分，所述处理模块，在所述收发模块向终端发送所述压缩包之后，还用于更新所述第一业务部分，得到第一更新业务部分；

所述收发模块，还用于向所述终端发送所述第一更新业务部分。

在一种可行的设计中，所述处理模块，在所述收发模块向终端发送所述压缩包之后，还用于更新所述公共部分，得到更新公共部分；

所述收发模块，还用于向所述终端发送所述更新公共部分。

在一种可行的设计中，所述处理模块，在根据所述1个公共部分、N个业务部分和属性配置文件得到压缩文件时，具体用于将所述N个业务部分打包成N个补丁文件；根据所述1个公共部分、所述N个补丁文件和所述属性配置文件得到所述压缩文件。

第四方面，本申请实施例提供一种终端，包括：

收发模块，用于接收服务器发送的压缩文件，所述压缩文件从外到内依次为1个公共部分、属性配置文件以及N个业务部分，所述属性配置文件用于描述所述1个公共部分的属性和所述N个业务部分中每个业务部分的属性，所述1个公共部分和N个业务部分为所述服务器对N个捆绑文件中的每个捆绑文件进行拆分得到的；

处理模块，用于根据所述属性配置文件，确定待加载业务对应的业务部分；合并所述待加载业务对应的业务部分和所述1个公共部分，以加载所述待加载业务。

在一种可行的设计中，所述处理模块，在根据所述属性配置文件，确定待加载业务对应的业务部分时，具体用于解压缩所述压缩文件，依次释放所述1个公共部分、所述属性配置文件以及所述N个业务部分；根据所述配置文件构建Bundle目录，根据所述Bundle目录存储所述1个公共部分、所述属性配置文件以及所述N个业务部分；根据所述Bundle目录，确定所述待加载业务对应的业务部分。

在一种可行的设计中，所述N个捆绑文件包含第一捆绑文件，所述第一捆绑文件包含所述公共部分和第一业务部分，所述N个业务部分包含所述第一业务部分，所述收发模块，在所述处理模块合并所述待加载业务对应的业务部分和所述1个公共部分之后，还用于接收所述服务器发送的第一更新业务部分，所述第一更新业务部分为所述服务器对所述第一业务部分进行更新得到；

所述处理模块，还用于根据所述第一更新业务部分，更新所述第一业务部分。

在一种可行的设计中，所述处理模块，在根据所述第一更新业务部分，更新所述第一业务部分时，具体用于判断是否需要更新所述公共部分，若需要，则先更新所述公共部分，再根据所述第一更新业务部分，更新所述第一业务部分；若不需要，则根据所述第一更新业务部分，更新所述第一业务部分。

在一种可行的设计中，所述收发模块，在所述处理模块合并所述待加载业务对应的业务部分和所述1个公共部分之后，还用于接收所述服务器发送的更新公共部分，所述更新公共部分为所述服务器对所述公共部分进行更新得到；

所述处理模块，还用于根据所述更新公共部分更新所述公共部分。

本申请实施例提供的应用程序加载方法、服务器及终端，服务器将对应同一个业务的N个Bundle文件中的每个Bundle文件拆分为公共部分和业务部分，得到1个公共部分和N个业务部分，根据该1个公共部分、N个业务部分和属性配置文件得到从外到内依次为1个公共部分、属性配置文件以及N个业务部分的压缩文件并发送给终端，使得终端根据属性配置文件，确定待加载业务对应的业务部分，进而合并待加载业务对应的业务部分和1个公共部分，以加载待加载业务。该过程中，终端根据待加载业务对应的Bundle文件的标识读取属性配置文件，快速获得待加载业务对应的Bundle文件，实现快速加载Bundle文件的目的。

附图说明

图1为本申请应用程序加载方法实施例一的信令图；

图2为本申请应用程序加载方法中压缩文件的结构示意图；

图3为本申请应用程序加载方法中的Bundle目录的示意图；

图4为本申请应用程序加载方法的一个举例示意图；

图5为本申请应用程序加载方法所适用的更新过程示意图；

图6为本申请服务器的结构示意图；

图7为本申请终端的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。以下内容为结合附图及较佳实施例，对依据本申请申请的具体实施方式、结构、特征及其功效的详细说明。

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

React Native是脸书(Facebook)开源的，可同时用来开发iOS和Android应用的技术。开发人员通过React Native(RN)热更新平台开发APP，一个APP包括多个捆绑(Bundle)文件。终端的APP需要更新一些内容(如运营的弹窗或者功能模块)时，可以直接从热更新平台的服务器下载该APP的多个Bundle文件，然后该APP解析并加载下载的多个Bundle文件，在无需下载安装新版本的APP的同时，实现更新该APP的内容的功能。

通常来说，移动互联网行业应用可分为两种，一种是基于本地操作系统，如iOS或Android操作系统运行的APP，称之为Native APP；一种是基于智能终端的浏览器运行的WebAPP。开发人员通过React Native(RN)热更新平台开发APP，一个APP包括多个捆绑(Bundle)文件。下载APP时，终端从热更新平台的服务器下载该APP的多个Bundle文件，然后安装APP并使用。

然而，一个APP包含多个业务，每个业务都有对应的Bundle文件，如何从多个Bundle文件中找到当前业务对应的Bundle文件并加载，实为业界亟待解决的问题。

因此，如何快速加载APP，实为业界亟待解决的问题。

有鉴于此，本申请实施例提供一种应用程序加载方法、服务器及终端，通过对多个Bundle文件进行配置，实现快速加载Bundle文件的目的。具体的，可参加图1。

图1为本申请应用程序加载方法实施例一的信令图，本实施例从服务器与终端交互的角度对本申请应用程序下载方法进行详细说明。具体的，本实施例包括：

101、服务器将N个捆绑文件中的每个捆绑文件拆分为公共部分和业务部分。

本申请实施例中，一个APP可支持多种业务，如58同城APP中包括的租房、招聘、二手、黄页等多个业务，每个业务具有不同的特征，并且每个业务对应N个捆绑(Bundle)文件，对应同一个业务的N个Bundle文件中，每个Bundle文件可拆分为公共部分和业务部分，N个Bundle文件的公共部分相同，业务部分不同。其中，公共部分指Bundle文件中和热更新平台自身逻辑有关的部分，业务部分时指Bundle文件中和业务逻辑相关的部分。对应同一个业务的N个Bundle文件的公共部分与RN热更新平台自身逻辑相关的部分相同，而对应同一个业务的N个Bundle文件的业务部分不同。因此，本步骤中，热更新平台的服务器将对应同一个业务的N个Bundle文件中的每个Bundle文件拆分为公共部分和业务部分，由于N个Bundle文件的公共部分相同，因此可视为1个公共部分，从而得到1个公共部分和N个业务部分。

102、所述服务器根据所述1个公共部分、N个业务部分和属性配置文件得到压缩文件。

本步骤中，服务器对1个公共部分、N个业务部分和属性配置文件进行压缩，得到压缩文件。该压缩文件从外到内依次为所述1个公共部分、所述属性配置文件以及所述N个业务部分，所述属性配置文件用于描述1个公共部分的属性和N个业务部分中每个业务部分的属性。

103、服务器向终端发送所述压缩包。

压缩完毕后，服务器将该压缩文件发送给终端。相应的，终端接收该压缩文件。

104、终端根据所述属性配置文件，确定待加载业务对应的业务部分。

接收到压缩文件后，终端释放压缩文件，根据待加载业务对应的Bundle的标识，读取属性配置文件，确定待加载业务对应的业务部分。

105、所述终端合并所述待加载业务对应的业务部分和所述1个公共部分，以加载所述待加载业务。

在确定出待加载业务对应的业务部分后，终端合并待加载业务对应的业务部分和1个公共部分，以加载待加载业务。

本申请实施例提供的应用程序加载方法，服务器将对应同一个业务的N个Bundle文件中的每个Bundle文件拆分为公共部分和业务部分，得到1个公共部分和N个业务部分，根据该1个公共部分、N个业务部分和属性配置文件得到从外到内依次为1个公共部分、属性配置文件以及N个业务部分的压缩文件并发送给终端，使得终端根据属性配置文件，确定待加载业务对应的业务部分，进而合并待加载业务对应的业务部分和1个公共部分，以加载待加载业务。该过程中，终端根据待加载业务对应的Bundle文件的标识读取属性配置文件，快速获得待加载业务对应的Bundle文件，实现快速加载Bundle文件的目的。

图2为本申请应用程序加载方法中压缩文件的结构示意图。请参照图2，本申请实施例中，压缩文件例如为zip压缩包，属性配置文件包含的属性数据用于描述1个公共部分的属性和N个业务部分中每个业务部分的属性，如公共部分的标识、公共部分的版本号、业务部分的标识、业务部分的版本号、业务部分对应的公共部分等。下面，假设一个Bundle文件的标识为Bundle ID，该Bundle文件的公共部分表示为“common.bundle”、公共部分相同的多个Bundle文件中，每个Bundle文件的业务部分经过打包得到补丁文件(patch)，属性配置文件表示为“config.json”，则config.json的一个示例为：

根据该属性配置文件可知：一个Bundle文件的标识，即Bundle ID为456，改Bundle文件的版本号为789。

终端在接收到服务器发送的zip压缩包后，解压缩该zip压缩包，并释放该zip压缩包。释放过程中，建立不同的文件夹，并在不同的文件夹中放置不同的文件，从而将zip压缩包的各个文件释放到磁盘并存储。具体的，终端根据Bundle文件的ID命名并建立文件夹，在每个文件夹中再命名并建立patch文件夹，用于放置对应的patch，commcon.bundle和属性配置文件放置在最外层。例如，终端根据该压缩包中的公共部分的标识建立一级文件夹，不同的公共部分对应不同的一级文件夹。对于一个具体的公共部分，在该公共部分对应的一级文件夹中放置属性配置文件，并建立至少一个二级文件夹，二级文件夹的名称根据Bundle ID命名，也就是说，公共部分相同、业务部分不同的各个Bundle文件分别对应不同的二级文件夹，而公共部分相同。业务部分不同的Bundle文件具有不同的Bundle ID，因此，一级文件夹中，每个Bundle ID对应一个二级文件夹。对于一个具体的Bundle ID，在该Bundle ID对应的二级文件夹中建立三级文件夹，每个三级文件夹用于放置patch，该三级文件夹的名称根据放置的patch命名。根据一级文件夹、二级文件夹以及三级文件夹的放置顺序，可知：zip压缩包从外到内依次为1个公共部分、属性配置文件以及N个业务部分。

终端第一次加载应用程序时，所述终端解压缩所述压缩文件，依次释放所述1个公共部分、所述属性配置文件以及所述N个业务部分；所述终端根据所述配置文件构建Bundle目录，根据所述Bundle目录存储所述1个公共部分、所述属性配置文件以及所述N个业务部分；所述终端根据所述Bundle目录，确定所述待加载业务对应的业务部分。

具体的，终端先解压缩zip包，读取属性配置文件，根据属性配置文件中记录的属性数据，将common.bundle和各个patch是否到磁盘存储。Commcon.bundle以“base_version.bundle”命名；patch则以“version.patch”命名。Patch和commcon.bundle合并得到的Bundle文件则以“bundle_version.bundle”命名。假设Bundle ID分别为106和112，则构建出的Bundle目录可参见图3。

图3为本申请应用程序加载方法中的Bundle目录的示意图。请参照图3，Commcon.bundle为“base_7.bundle”，补丁文件(patch)有两个，分别为“31.patch”、“2.patch”，Bundle ID有两个，分别为106和107，该两个Bundle ID的公共部分相同，均为“base_7.bundle”，Bundle ID为106的Bundle文件是对“base_7.bundle”和“31.patch”进行合并得到的，如图中的“106_31Bundle”，Bundle ID为112的Bundle文件是对“base_7.bundle”和“2.patch”进行合并得到的，如图中的“112_2Bundle”。

另外，根据图3可知，根据该Bundle目录，只要知道待加载Bundle文件的BundleID，查询该Bundle目录，就能过快速查找到Bundle文件的路径，并获取到待加载的Bundle文件。而且，根据patch名称以及common.bundle的文件名称，就能够快速确定出Bundle文件以及common.bundle的版本号。

图4为本申请应用程序加载方法的一个举例示意图。请参照图4，包括：

201、终端判断资源是否已经释放，若是，则执行208；若否，则执行202；

202、终端判断是否存在压缩文件，若是，则执行204；若否，则执行208。

203、解压缩压缩文件。

204、释放公共部分。

205、读取属性配置文件。

206、释放patch。

207、根据待加载Bundle文件的标识，读取属性配置文件，确定待加载业务对应的业务部分，并合并待加载Bundle文件的业务部分和公共部分。

208、标记资源释放完毕。

APP被开发出来后，不可避免的需要更新。现有的采用用插件技术更新APP时，不需要发布新版本APP就能够实现对APP的页面和功能的更新，但是更新后必须重启APP使得插件代码生效。为避免重启APP，本申请实施例中，开发人员通过React Native(RN)热更新平台对APP进行更新。下面，对本申请实施例中如何更新应用程序进行详细说明。

具体的，APP的一个业务对应多个Bundle文件，对该APP进行更新，实质上是对该APP包含的Bundle文件进行更新。而一个Bundle文件可以被拆分为公共部分和业务部分，因此，对一个Bundle文件的更新，是指对该Bundle文件的公共部分进行更新、对该Bundle文件的业务部分进行更新，或者对该Bundle文件的公共部分和业务部分都进行更新。下面，对该些情况分别进行详细说明。

首先，对公共部分进行更新。

具体的，对于同一个业务对应的N个Bundle文件，该N个Bundle文件的公共部分相同。当需要对该公共部分进行更新时，服务器更新所述公共部分，得到更新公共部分；接着，所述服务器向所述终端发送所述更新公共部分。相应的，终端接收该公共部分，根据所述更新公共部分更新所述公共部分，即用更新公共部分替换公共部分。然后，终端将N个业务部分中的每个业务部分和更新公共部分合并，得到对应一个业务的N个Bundle文件，从而实现对N个Bundle文件的更新。

其次，对业务部分进行更新。

具体的，对于同一个业务对应的N个Bundle文件，该N个Bundle文件的业务部分不相同。该N个捆绑文件包含第一捆绑文件，所述第一捆绑文件包含所述公共部分和第一业务部分，所述N个业务部分包含所述第一业务部分。当需要对第一捆绑文件的第一业务部分进行更新时，所述终端将所述N个业务部分中的每个业务部分与所述1个公共部分合并之后，当需要对第一捆绑文件的第一业务部分进行更新时，服务器更新所述第一业务部分，得到第一更新业务部分；接着，所述服务器向所述终端发送所述第一更新业务部分。相应的，终端接收该第一更新业务部分，根据所述第一更新业务部分更新所述第一业务部分，即用第一更新业务部分替换第一业务部分。然后，终端将第一业务部分和公共部分合并，得到更新后的第一Bundle文件，从而实现对第一Bundle文件的更新。

最后，对公共部分和业务部分都进行更新。

本申请实施例中，对于APP的同一个业务，终端第一次该业务的Bundle文件时，将该业务的Bundle文件的1个公共部分和N个业务部分都进行下载。后续，当需要对公共部分和N个业务部分中的至少一个业务部分进行更新时，由于更新后的每个业务部分需要和更新后的公共部分进行合并。因此，本申请实施例中，当需要对公共部分和业务部分都进行更新时，先对公共部分进行更新，再对业务部分进行更新，避免先对业务部分进行更新、再对公共部分进行更新后，需要继续对更新后的业务部分和更新后的公共部分进行合并的弊端。

下面，结合图3，对本申请实施例中如何更新应用程序进行详细说明。具体的，可参见图5，图5为本申请应用程序加载方法所适用的更新过程示意图，包括：

301、终端接收大服务器发送的Bundle更新信息。

302、终端判断是否需要更新公共部分，若是，则执行303；否则，执行307。

303、下载公共部分。

304、对公共部分进行完整性验证。

305、解压缩公共部分。

306、用最新下载的公共部分替换旧版本的公共部分。

307、判断patch是否更新，若是，执行308；否则，执行301

308、终端判断是否需要强制更新patch，若是，则执行309；否则，执行310；

309、提示用户，之后执行310。

例如，弹出指示用户需要强制更新patch的窗口，强制用户更新。

310、下载patch。

311、对patch进行完整性验证。

312、解压缩patch。

313、合并最新下载的patch和公共部分。

上述步骤310～313中，假设Bundle ID为106的Bundle文件包含的patch由31版本更新为32版本。则服务器向终端指示Bundle ID为106的Bundle文件包含的Patch文件的最新版本号为32，终端将最新的版本号为32的patch下载并保存到/106/patch/目录下，以32.patch命名。然后将32.patch和base_7.bundle进行合并生成106_32.bundle，用106_32.bundle替换106_31.bundle，使得终端加载Bundle D为106的Bundle文件时，加载106_32.bundle。另外，patch文件夹下面会保存所有下载的patch版本，以增加容错机制。例如，当106_32.bundle合并成功后，由于研发人员的粗心，使得32版本的patch文件有问题(bug)，导致终端加载106_32.bundle对应的Bundle文件失败，此时，抛出异常，将将31.patch和base_7.bundle进行合并生成106_31.bundle，使得终端重新加载Bundle D为106的Bundle文件时，加载106_31.bundle。

另外，上述实施例中，当公共部分和业务部分都有更新时，为保证公共部分的下载优先级高于业务部分，本申请实施例中，通过RxJava，将公共部分交由行为科目(BehaviorSubject)执行，将业务部的下载合并任务交由科目(subject)通过concatMap连接，若公共部分有更新，则先执行BehaviorSubject，否则，BehaviorSubject将公共部分的路径发送给后面执行的观察模式(observable)。

另外，上述实施例中，所述服务器将所述N个业务部分打包成N个补丁文件；所述服务器根据所述1个公共部分、所述N个补丁文件和所述属性配置文件得到所述压缩文件。

图6为本申请服务器的结构示意图，包括：

处理模块11，用于将N个捆绑文件中的每个捆绑文件拆分为公共部分和业务部分，以得到1个公共部分和N个业务部分，N≥1，且为整数；根据所述1个公共部分、N个业务部分和属性配置文件得到压缩文件，所述压缩文件从外到内依次为所述1个公共部分、所述属性配置文件以及所述N个业务部分，所述属性配置文件用于描述1个公共部分的属性和N个业务部分中每个业务部分的属性；

收发模块12，用于向终端发送所述压缩包。

本申请实施例提供的服务器，将对应同一个业务的N个Bundle文件中的每个Bundle文件拆分为公共部分和业务部分，得到1个公共部分和N个业务部分，根据该1个公共部分、N个业务部分和属性配置文件得到从外到内依次为1个公共部分、属性配置文件以及N个业务部分的压缩文件并发送给终端，使得终端根据属性配置文件，确定待加载业务对应的业务部分，进而合并待加载业务对应的业务部分和1个公共部分，以加载待加载业务。该过程中，终端根据待加载业务对应的Bundle文件的标识读取属性配置文件，快速获得待加载业务对应的Bundle文件，实现快速加载Bundle文件的目的。

可选的，在本申请一实施例中，所述N个捆绑文件包含第一捆绑文件，所述N个业务部分包含所述第一业务部分，所述第一捆绑文件包含所述公共部分和第一业务部分，所述处理模块11，在所述收发模块12向终端发送所述压缩包之后，还用于更新所述第一业务部分，得到第一更新业务部分；

所述收发模块12，还用于向所述终端发送所述第一更新业务部分。

可选的，在本申请一实施例中，所述处理模块11，在所述收发模块12向终端发送所述压缩包之后，还用于更新所述公共部分，得到更新公共部分；

所述收发模块12，还用于向所述终端发送所述更新公共部分。

可选的，在本申请一实施例中，所述处理模块11，在根据所述1个公共部分、N个业务部分和属性配置文件得到压缩文件时，具体用于将所述N个业务部分打包成N个补丁文件；根据所述1个公共部分、所述N个补丁文件和所述属性配置文件得到所述压缩文件。

图7为本申请终端的结构示意图，包括：

收发模块21，用于接收服务器发送的压缩文件，所述压缩文件从外到内依次为1个公共部分、属性配置文件以及N个业务部分，所述属性配置文件用于描述所述1个公共部分的属性和所述N个业务部分中每个业务部分的属性，所述1个公共部分和N个业务部分为所述服务器对N个捆绑文件中的每个捆绑文件进行拆分得到的；

处理模块22，用于根据所述属性配置文件，确定待加载业务对应的业务部分；合并所述待加载业务对应的业务部分和所述1个公共部分，以加载所述待加载业务。

本申请实施例提供的终端，接收服务器发送的压缩文件，该压缩文件为服务器将对应同一个业务的N个Bundle文件中的每个Bundle文件拆分为公共部分和业务部分，得到1个公共部分和N个业务部分，根据该1个公共部分、N个业务部分和属性配置文件得到从外到内依次为1个公共部分、属性配置文件以及N个业务部分的压缩文件，终端根据属性配置文件，确定待加载业务对应的业务部分，进而合并待加载业务对应的业务部分和1个公共部分，以加载待加载业务。该过程中，终端根据待加载业务对应的Bundle文件的标识读取属性配置文件，快速获得待加载业务对应的Bundle文件，实现快速加载Bundle文件的目的。

可选的，在本申请一实施例中，所述处理模块22，在根据所述属性配置文件，确定待加载业务对应的业务部分时，具体用于解压缩所述压缩文件，依次释放所述1个公共部分、所述属性配置文件以及所述N个业务部分；根据所述配置文件构建Bundle目录，根据所述Bundle目录存储所述1个公共部分、所述属性配置文件以及所述N个业务部分；根据所述Bundle目录，确定所述待加载业务对应的业务部分。

可选的，在本申请一实施例中，所述N个捆绑文件包含第一捆绑文件，所述第一捆绑文件包含所述公共部分和第一业务部分，所述N个业务部分包含所述第一业务部分，所述收发模块21，在所述处理模块22合并所述待加载业务对应的业务部分和所述1个公共部分之后，还用于接收所述服务器发送的第一更新业务部分，所述第一更新业务部分为所述服务器对所述第一业务部分进行更新得到；

所述处理模块22，还用于根据所述第一更新业务部分，更新所述第一业务部分。

可选的，在本申请一实施例中，所述处理模块22，在根据所述第一更新业务部分，更新所述第一业务部分时，具体用于判断是否需要更新所述公共部分，若需要，则先更新所述公共部分，再根据所述第一更新业务部分，更新所述第一业务部分；若不需要，则根据所述第一更新业务部分，更新所述第一业务部分。

可选的，在本申请一实施例中，所述收发模块21，在所述处理模块22合并所述待加载业务对应的业务部分和所述1个公共部分之后，还用于接收所述服务器发送的更新公共部分，所述更新公共部分为所述服务器对所述公共部分进行更新得到；

所述处理模块22，还用于根据所述更新公共部分更新所述公共部分。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (11)

1.一种应用程序加载方法，其特征在于，包括：

服务器将N个捆绑文件中的每个捆绑文件拆分为公共部分和业务部分，以得到1个公共部分和N个业务部分，N≥1，且为整数；

所述服务器根据所述1个公共部分、N个业务部分和属性配置文件得到压缩文件，所述压缩文件从外到内依次为所述1个公共部分、所述属性配置文件以及所述N个业务部分，所述属性配置文件用于描述1个公共部分的属性和N个业务部分中每个业务部分的属性；

所述服务器向终端发送所述压缩包。

2.根据权利要求1所述的方法，其特征在于，所述N个捆绑文件包含第一捆绑文件，所述第一捆绑文件包含所述公共部分和第一业务部分，所述N个业务部分包含所述第一业务部分，所述服务器向终端发送所述压缩包之后，还包括：

所述服务器更新所述第一业务部分，得到第一更新业务部分；

所述服务器向所述终端发送所述第一更新业务部分。

3.根据权利要求1或2所述的方法，其特征在于，所述服务器向终端发送所述压缩包之后，还包括：

所述服务器更新所述公共部分，得到更新公共部分；

所述服务器向所述终端发送所述更新公共部分。

4.根据权利要求1或2所述的方法，其特征在于，所述服务器根据所述1个公共部分、N个业务部分和属性配置文件得到压缩文件，包括：

所述服务器将所述N个业务部分打包成N个补丁文件；

所述服务器根据所述1个公共部分、所述N个补丁文件和所述属性配置文件得到所述压缩文件。

5.一种应用程序加载方法，其特征在于，包括：

终端接收服务器发送的压缩文件，所述压缩文件从外到内依次为1个公共部分、属性配置文件以及N个业务部分，所述属性配置文件用于描述所述1个公共部分的属性和所述N个业务部分中每个业务部分的属性，所述1个公共部分和N个业务部分为所述服务器对N个捆绑文件中的每个捆绑文件进行拆分得到的；

所述终端根据所述属性配置文件，确定待加载业务对应的业务部分；

所述终端合并所述待加载业务对应的业务部分和所述1个公共部分，以加载所述待加载业务。

6.根据权利要求5所述的方法，其特征在于，所述终端根据所述属性配置文件，确定待加载业务对应的业务部分，包括：

所述终端解压缩所述压缩文件，依次释放所述1个公共部分、所述属性配置文件以及所述N个业务部分；

所述终端根据所述配置文件构建Bundle目录，根据所述Bundle目录存储所述1个公共部分、所述属性配置文件以及所述N个业务部分；

所述终端根据所述Bundle目录，确定所述待加载业务对应的业务部分。

7.根据权利要求5或6所述的方法，其特征在于，所述N个捆绑文件包含第一捆绑文件，所述第一捆绑文件包含所述公共部分和第一业务部分，所述N个业务部分包含所述第一业务部分，所述终端合并所述待加载业务对应的业务部分和所述1个公共部分之后，还包括：

所述终端接收所述服务器发送的第一更新业务部分，所述第一更新业务部分为所述服务器对所述第一业务部分进行更新得到；

所述终端根据所述第一更新业务部分，更新所述第一业务部分。

8.根据权利要求7所述的方法，其特征在于，所述终端根据所述第一更新业务部分，更新所述第一业务部分，包括：

所述终端判断是否需要更新所述公共部分，若需要，则先更新所述公共部分，再根据所述第一更新业务部分，更新所述第一业务部分；若不需要，则根据所述第一更新业务部分，更新所述第一业务部分。

9.根据权利要求5或6所述的方法，其特征在于，所述终端合并所述待加载业务对应的业务部分和所述1个公共部分之后，还包括：

所述终端接收所述服务器发送的更新公共部分，所述更新公共部分为所述服务器对所述公共部分进行更新得到；

所述终端根据所述更新公共部分更新所述公共部分。

10.一种服务器，其特征在于，包括:

处理模块，用于将N个捆绑文件中的每个捆绑文件拆分为公共部分和业务部分，以得到1个公共部分和N个业务部分，N≥1，且为整数；根据所述1个公共部分、N个业务部分和属性配置文件得到压缩文件，所述压缩文件从外到内依次为所述1个公共部分、所述属性配置文件以及所述N个业务部分，所述属性配置文件用于描述1个公共部分的属性和N个业务部分中每个业务部分的属性；

收发模块，用于向终端发送所述压缩包。

11.一种终端，其特征在于，包括：

收发模块，用于接收服务器发送的压缩文件，所述压缩文件从外到内依次为1个公共部分、属性配置文件以及N个业务部分，所述属性配置文件用于描述所述1个公共部分的属性和所述N个业务部分中每个业务部分的属性，所述1个公共部分和N个业务部分为所述服务器对N个捆绑文件中的每个捆绑文件进行拆分得到的；

处理模块，用于根据所述属性配置文件，确定待加载业务对应的业务部分；合并所述待加载业务对应的业务部分和所述1个公共部分，以加载所述待加载业务。