CN106873960A - 一种应用软件的更新方法和设备 - Google Patents

Abstract

本申请公开了一种应用软件的更新方法和设备，包括：提供应用软件的增量安装包，所述增量安装包中包括第一基准版本信息；接收用户设备发送的应用软件更新请求，所述应用软件更新请求中包含所述应用软件的当前版本信息，所述当前版本信息中包括第二基准版本信息；在确定所述第一基准版本信息与所述第二基准版本信息一致时，将所述应用软件的增量安装包发送给所述用户设备，以用于增量更新。通过判断应用软件的实际版本信息与该应用软件的增量安装包对应的基准版本信息是否一致，有选择地向用户设备推送增量安装包或者全量安装包，以保证用户设备能够快速实现软件更新，提升了应用软件更新的效率，进而改善用户对应用软件的用户体验。

Description

一种应用软件的更新方法和设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种应用软件的更新方法和设备。

背景技术

随着科学技术的发展，为了满足用户需求，应用软件开发商开发出现了各种各样的应用软件，例如：即时通信软件、各种应用客户端等等，极大方便了用户的实际生活需要。

应用软件开发者开发在开发应用软件后，将不断地基于应用软件本身的使用情况或者应用软件产品本身性能完善的需要对应用软件进行功能更新。这种更新意味着对应用软件功能的新开发。

目前，应用软件的开发方式包含应用软件的全量构建方式和应用软件的增量构建方式。

具体地，所谓应用软件的全量构建方式是指对应用软件的所有功能进行构建，并针对构建得到的所有功能模块进行编译，以得到应用软件的安装包。这种全量构建方式适用于应用软件开发的初期。

所谓应用软件的增量构建方式是指针对应用软件的部分功能进行构建，并针对构建得到的部分功能进行编译，以生成针对该部分功能的补丁包。这种增量构建方式适用于应用软件开发的后期以及应用软件的维护阶段。

不管是在应用软件的开发阶段还是应用软件的维护阶段，为了提高应用软件功能的构建效率，可以采用增量构建方式对应用软件的功能进行修改构建，最后将修改构建的功能进行整合以得到应用软件的安装包。

但是，在实际应用中，需要开发者自行记录哪些功能采用增量构建方式，这样在需要整合得到应用软件的全量安装包时，一旦忘记哪些功能采用增量构建方式，将使得整合得到的全量安装包中未包含增量构建的功能，导致安装包出现“不完整”，进而使得应用软件在运行阶段出现错误，降低用户对应用软件的使用体验。

发明内容

有鉴于此，本申请实施例提供的一种应用软件的更新方法和设备，用于解决现有技术中应用软件由于安装包“不完整”出现运行错误的问题。

本申请实施例提供了一种应用软件的更新方法，包括：

提供应用软件的增量安装包，所述增量安装包中包括第一基准版本信息；

接收用户设备发送的应用软件更新请求，所述应用软件更新请求中包含所述应用软件的当前版本信息，所述当前版本信息中包括第二基准版本信息；

在确定所述第一基准版本信息与所述第二基准版本信息一致时，将所述应用软件的增量安装包发送给所述用户设备，以用于增量更新。

本申请实施例还提供了一种应用软件的更新设备，包括：

存储单元，提供应用软件的增量安装包，所述增量安装包中包括第一基准版本信息；

接收单元，接收用户设备发送的应用软件更新请求，所述应用软件更新请求中包含所述应用软件的当前版本信息，所述当前版本信息中包括第二基准版本信息；

发送单元，在确定所述第一基准版本信息与所述第二基准版本信息一致时，将所述应用软件的增量安装包发送给所述用户设备，以用于增量更新。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

通过提供应用软件的增量安装包，所述增量安装包中包括第一基准版本信息；接收用户设备发送的应用软件更新请求，所述应用软件更新请求中包含所述应用软件的当前版本信息，所述当前版本信息中包括第二基准版本信息；在确定所述第一基准版本信息与所述第二基准版本信息一致时，将所述应用软件的增量安装包发送给所述用户设备，以用于增量更新。通过判断应用软件的实际版本信息与该应用软件的增量安装包对应的基准版本信息是否一致，有选择地向用户设备推送增量安装包或者全量安装包，以保证用户设备能够快速实现软件更新，提升了应用软件更新的效率，进而改善用户对应用软件的用户体验。

附图说明

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

图1为本申请实施例提供的一种应用软件的更新方法的流程示意图；

图2为本申请实施例中提供的指针指向基线包的结构示意图；

图3为本申请实施例提供的一种应用软件的更新设备的结构示意图。

具体实施方式

为了实现本申请的目的，本申请实施例提供了一种应用软件的更新方法和设备，提供应用软件的增量安装包，所述增量安装包中包括第一基准版本信息；接收用户设备发送的应用软件更新请求，所述应用软件更新请求中包含所述应用软件的当前版本信息，所述当前版本信息中包括第二基准版本信息；在确定所述第一基准版本信息与所述第二基准版本信息一致时，将所述应用软件的增量安装包发送给所述用户设备，以用于增量更新。通过判断应用软件的实际版本信息与该应用软件的增量安装包对应的基准版本信息是否一致，有选择地向用户设备推送增量安装包或者全量安装包，以保证用户设备能够快速实现软件更新，提升了应用软件更新的效率，进而改善用户对应用软件的用户体验。

本申请实施例所提供的技术方案除了可以应用在Android操作系统中，还可以应用在其他各种半开源操作系统中，这里不做具体限定。

需要说明的是，本申请实施例中所记载的基线包是指应用软件的基准安装包，可以通过全量方式构建得到，又可以称之为基准安装包；增量包又可以称之为增量安装包，是指在基线包的基础之上针对应用软件的某一个或者某几个功能进行增量构建形成的安装包；全量包又可以称之为全量安装包，是针对应用软件的全部功能构建形成的安装包，可以包含基线包和增量包。

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

图1为本申请实施例提供的一种应用软件的更新方法的流程示意图。所述方法可以如下所示。

步骤101：提供应用软件的增量安装包和全量安装包。

其中，所述增量安装包中包括第一基准版本信息。

在本申请实施例中，在应用软件的开发过程中，可以根据开发需要，构建应用软件的增量安装包或者构建应用软件的全量安装包。

具体地，针对应用软件的部分功能，以基准安装包为基础，通过增量构建的方式得到针对所述部分功能的增量安装包。

可选地，在构建得到所述部分功能的增量安装包时，所述方法还包括：

确定所述基准安装包的版本信息，并将所述基准安装包的版本信息作为所述增量安装包的第一基准版本信息；

建立所述增量安装包与所述增量安装包对应的第一基准版本信息之间的映射关系。

例如：在应用软件开发初始化阶段，应用软件的运行代码通过全量打包方式形成安装包，即初始基线包(又可以称之为基准安装包)。

那么在该基准安装包的基础之上，对应用软件的某一功能的代码进行优化或者维护，那么针对优化后的代码可以采用增量构建的方式得到针对这一功能的增量安装包。同样的道理，还可以在该基准安装包的基础之上，对应用软件的其他功能的代码进行优化，得到其他功能的增量安装包。

那么在针对同一个基准安装包构建得到不同的增量安装包后，可以针对应用软件的全部或者部分功能，以基准安装包和/或增量安装包为基础，通过全量构建的方式得到针对所述应用软件的全量安装包。

可选地，在构建得到所述应用软件的全量安装包时，所述方法还包括：

确定所述全量安装包的版本信息，并将所述版本信息作为所述全量安装包的第二基准版本信息，所述第二基准版本信息中包含的版本号高于所述基准安装包对应的基准版本信息中包含的版本号；

建立所述全量安装包与所述第二基准版本信息之间的映射关系。

需要说明的是，在构建得到全量安装包时，需要为该全量安装包确定一个版本信息，这一个版本信息可以称之为一个新的基准版本信息。

也就是说，本申请实施例中所记载的基准安装包对应的基准版本信息可以是指通过全量构建得到的全量安装包对应的版本信息。

例如：如表1所示，为对应用软件进行增量或者全量构建后的得到的基准版本信息与不同安装包之间的映射关系表：

表1

从表1中可以看出，增量安装包1、增量安装包2和增量安装包3是以基准版本信息为1.0的基准安装包为基础通过增量构建得到的；增量安装包4和增量安装包5是以基准版本信息为3.0的基准安装包为基础通过增量构建得到的。

优选地，在本申请实施例中，确定所述应用软件的增量安装包对应的基准版本信息，包括：

首先，查找在对所述应用软件进行增量安装包构建之前所述应用软件的基准版本信息。

具体地，扫描所述应用软件的脚本，并确定指针指向的所述应用软件的基准版本信息。

其次，将查找到所述应用软件的基准版本信息作为所述应用软件的增量安装包对应的基准版本信息。

最后，在对所述应用软件的增量安装包进行全量构建后，调整所述指针的位置，使所述指针指向包含所述增量安装包的全量安装包对应的基准版本信息。

在本申请实施例中，在扫描应用软件的脚本时，可以通过查找指针的方式确定应用软件的基准版本信息。

在应用软件开发以及编译阶段，为了保证全量构建和增量构建的状态同步，本申请实施例中采用指针标定应用软件的基准版本信息的方式，以确定增量构建的增量包对应的基准版本信息以及以确定全量构建的全量包对应的基准版本信息，为后续应用软件维护提供便利，同时也能够防止在构建全量包时因为无法确定增量构建的具体情形导致全量包“不完整”问题。

例如：在应用软件开发阶段，对于应用软件1，构建初始全量安装包，该初始全量安装包对应的基准版本信息可以称为版本1.0，此时指针指向版本1.0；之后，开发者在版本1.0的基础之上对该应用软件的功能1进行修改，生成增量安装包a，那么该增量安装包对应的基准版本信息为版本1.0；开发者在版本1.0的基础之上对该应用软件的功能2进行修改，生成增量安装包b，那么该增量安装包对应的基准版本信息为版本1.0；开发者在版本1.0的基础之上对该应用软件的功能3进行修改，生成增量安装包c，那么该增量安装包对应的基准版本信息为版本1.0。

假设在得到三个增量安装包之后，基于增量安装包a、增量安装包b和增量安装包c可以构建针对该应用软件的全量安装包，那么该全量安装包对应的基准版本信息为版本2.0，此时指针指向版本2.0。

或者，开发者在版本1.0的基础之上对该应用软件的功能1进行修改，生成增量安装包a，那么该增量安装包对应的基准版本信息为版本1.0；假设在得到增量安装包a之后，基于该增量安装包a构建包含该增量安装包的全量安装包，那么该全量安装包对应的基准版本信息为版本1.0.1，此时指针指向版本1.0.1；开发者在版本1.0.1的基础之上对该应用软件的功能2进行修改，生成增量安装包b，那么该增量安装包对应的基准版本信息为版本1.0.1。

这样，应用软件在后续的开发中，通过不断构建新的全量基线包和/或新的增量包实现应用软件的更新。当在初始基线包中构建出新的全量基线包后，指针自动向新的全量基线包位置移动；当以新的全量基线包为基准构建出新的增量包时，增量包所对应的基线包即为新的全量基线包，指针的位置不发生移动；当以新的增量包为基准构建新的全量基线包时，此时新的全量基线包中包含新的增量包，此时基线包发生变化，即指针的位置自动移动至包含新的增量包的全量基线包所在位置。

图2为本申请实施例中提供的指针指向基线包的结构示意图。

在应用软件开发阶段，可以根据实际需要构建应用软件的全量安装包，也可以在一个已经构建的全量安装包的基础之上构建多个增量安装包，即可以在全量安装包的基础之上，对应用软件的多个不同功能分别构建增量安装包，那么这些增量安装包的基线包对应该全量安装包。

假设一个应用软件，目前已经存在基线包base，存在三个功能：A、B和C，从图2中可以看出，base为基线包(假设该基线包对应应用软件的版本信息为1.0)，在该基线包的基础之上，分别进行增量构建得到增量安装包A(对功能A进行增量构建)、增量安装包B(对功能B进行增量构建)和增量安装包C(对功能C进行增量构建)，那么对于该应用软件来说，包含基线包base，三个增量安装包：增量安装包A、增量安装包B和增量安装包C，那么该应用软件的基准版本信息为base对应的版本信息，此时指针指向基线包base。

假设在应用软件开发阶段，开发者在开发得到应用软件的基线包base(对应版本信息为1.0)时，通过全量构建的方式构建得到全量安装包M，这个全量安装包M是在基线包base基础之上对应用软件的一个功能(例如：功能A)进行改进后全量构建得到(即包含base+增量安装包A)，此时应用软件对应的基线包变更为全量安装包M(对应的版本信息为1.0.1)；

在全量安装包M的基础之上，通过全量构建的方式建得到全量安装包N，这个全量安装包N是在全量安装包M基础之上对应用软件的另一个功能(例如：功能B)进行改进后全量构建得到(即包含base+增量安装包A+增量安装包B)，此时应用软件对应的基线包变更为全量安装包N(对应的版本信息为1.0.2)；

在全量安装包N的基础之上，通过全量构建的方式建得到全量安装包P，这个全量安装包P是在全量安装包N基础之上对应用软件的第三个功能(例如：功能C)进行改进后全量构建得到(即包含base+增量安装包A+增量安装包B+增量安装包C)，此时应用软件对应的基线包变更为全量安装包P(对应的版本信息为2.0)。

那么此时指针指向全量安装包P，即得到新的基准版本信息。

需要说明的是，应用软件在后续的开发中，应用软件中的程序代码需要不断地进行变更，而变更后的应用软件的程序代码会经过不同构建流程形成新的基线包和/或增量包，进而实现应用软件中不同的功能模块的完善、功能模块的添加、以及应用软件的程序代码中漏洞的修复。

在应用软件开发阶段，当应用软件的功能更新只需要在基线包之上构建新的增量包时，指针指向所述基线包的位置，那么此时应用软件的功能更新不触发基线对齐，能够直接构建新的增量包，应用软件在功能更新前与功能更新后的基线包状态是一致的，当新的增量包构建完毕后，指针位置保持不变。当应用软件的功能更新需要重新构建基线包时，需要确定在该基线包之后是否构建过增量包，若在基线包之后没有构建过增量包，那么，应用软件直接通过全量构建的方式来构建新的基线包，不触发基线对齐，在新的基线包构建完毕后，指针自动移向最新的基线包状态；如果在基线包之后构建过增量包，那么，结合基线包和构建得到的增量包，通过全量构建的方式得到新的基线包，同步调整指针指向新的基线包位置。

需要说明的是，在对当前的应用软件中的增量包的各个子程序进行全量构建时，也存在各个子程序位于同层级的情况，此时采用并发构建的方式对增量包中的各个子程序进行全量构建，在全量构建完毕后，新的基线包中包含增量包中各个子程序的修改，而更新前的应用软件安装包中的增量包也在应用软件更新后的第一次启动中被清除，此时，指针自动指向新的基线包，实现基线的对齐。

步骤102：接收用户设备发送的应用软件更新请求，所述应用软件更新请求中包含所述应用软件的当前版本信息。

所述当前版本信息中包括第二基准版本信息。

在步骤102中，用户设备在检测到本地安装的应用软件发布的新版本时，向该应用软件对应的服务器发送应用软件更新请求，在该应用软件更新请求中包含该应用软件当前所使用的版本信息。

优选地，应用软件服务器在检测到用户设备所使用的应用软件的版本不是最新版本时，向用户设备发送应用软件更新通知消息，若用户设备确定更新应用软件，则向应用软件服务器发送应用软件更新请求，即应用软件服务器能够接收到用户设备发送的应用软件更新请求。

优选地，通过应用软件中的自动检测功能检测用户设备所使用的应用软件的版本是否为应用软件服务器所发布的最新版本。

其中，应用软件的自动检测功能可以通过运行应用软件中相应的检测程序代码实现。

具体地，当启动用户设备中安装的应用软件时，安装在用户设备中的应用软件的客户端主动与应用软件服务器建立数据连接。当应用软件的客户端与应用软件服务器建立数据连接后，应用软件的客户端通过对比当前所使用的应用软件的版本信息与应用软件服务器中已发布的最新的应用软件的版本信息，确定所使用的应用软件版本是否与应用软件服务器中已发布最新的应用软件版本一致。

如果客户端所使用的应用软件版本是否与应用软件服务器中已发布最新的应用软件版本一致，说明客户端无需更新应用软件版本；如果客户端所使用的应用软件版本是否与应用软件服务器中已发布最新的应用软件版本不一致，说明客户端需要更新应用软件版本，那么此时可以通过用户设备向应用软件服务器发送应用软件更新请求。

需要说明的是，客户端可以通过使用传输控制协议(Transmission ControlProtocol，TCP)的三次握手协议实现与应用软件服务器之间的数据连接。具体地，客户端创建一个基于TCP的套接字(Socket)，并向应用软件服务器发出连接请求(也可称作握手信号，Synchronous，SYN)，在接收到应用软件服务器返回的握手信号确认(Synchronous+Acknowledgement，SYN+ACK)时，对应用软件服务器的SYN进行ACK确认，并建立客户端与应用软件服务器之间的数据连接。

步骤103：判断所述应用软件的第二基准版本信息与步骤101中提供的增量安装包的第一基准版本信息是否一致；若一致，则执行步骤104；若不一致，则执行步骤105。

在步骤103中，比较所述应用软件的第二基准版本信息与所述应用软件的增量安装包对应的第一基准版本信息是否一致。

例如：该应用软件的当前版本信息为2.0.1.2，那么其第二基准版本信息为2.0或者2.0.1或者2.0.1.2，这个根据实际需要确定；若此时步骤101中提供的增量安装包对应的第一基准版本信息为3.0，则说明不一致；若此时步骤101中提供的增量安装包对应的第一基准版本信息为2.0.1.2，则说明一致。

步骤104：将所述应用软件的增量安装包发送给所述用户设备，以用于增量更新。

步骤105：将所述应用软件的全量安装包发送给所述用户设备，以用于全量更新。

通过本申请实施例提供的技术方案，提供应用软件的增量安装包，所述增量安装包中包括第一基准版本信息；接收用户设备发送的应用软件更新请求，所述应用软件更新请求中包含所述应用软件的当前版本信息，所述当前版本信息中包括第二基准版本信息；在确定所述第一基准版本信息与所述第二基准版本信息一致时，将所述应用软件的增量安装包发送给所述用户设备，以用于增量更新。通过判断应用软件的实际版本信息与该应用软件的增量安装包对应的基准版本信息是否一致，有选择地向用户设备推送增量安装包或者全量安装包，以保证用户设备能够快速实现软件更新，提升了应用软件更新的效率，进而改善用户对应用软件的用户体验。

需要说明的是，与现有的版本控制系统SVN(Subversion)相比：现有SVN需要将代码提交到中央库，在中央库中共用一份代码，SVN管理的是服务器与客户端之间的代码版本；而本申请实施例针对操作系统(如Android)开发编译过程中基线包与终端(手机端)中的安装包同步的问题，不需要提交到中央库，代码的开发环境可以不一致，具体管理的是代码与安装包之间的关系。

实施例2

图3为本申请实施例提供的一种应用软件的更新设备的结构示意图。所述更新设备包括：存储单元31、接收单元32和发送单元33，其中：

存储单元31，提供应用软件的增量安装包，所述增量安装包中包括第一基准版本信息；

接收单元32，接收用户设备发送的应用软件更新请求，所述应用软件更新请求中包含所述应用软件的当前版本信息，所述当前版本信息中包括第二基准版本信息；

发送单元33，在确定所述第一基准版本信息与所述第二基准版本信息一致时，将所述应用软件的增量安装包发送给所述用户设备，以用于增量更新。

在本申请的另一个实施例中，所述存储单元31，还提供所述应用软件的全量安装包；

所述发送单元33，在确定所述第一基准版本信息与所述第二基准版本信息不一致时，将所述应用软件的全量安装包发送给所述用户设备，以用于全量更新。

在本申请的另一个实施例中，所述存储单元31提供应用软件的增量安装包，包括：

在应用软件的开发阶段，针对应用软件的部分功能，以基准安装包为基础，通过增量构建的方式得到针对所述部分功能的增量安装包。

在本申请的另一个实施例中，所述存储单元31，在构建得到所述部分功能的增量安装包时，确定所述基准安装包的版本信息，并将所述基准安装包的版本信息作为所述增量安装包的第一基准版本信息；

建立所述增量安装包与所述增量安装包对应的第一基准版本信息之间的映射关系。

在本申请的另一个实施例中，所述存储单元31提供应用软件的全量安装包，包括：

在应用软件的开发阶段，针对应用软件的全部或者部分功能，以基准安装包和/或增量安装包为基础，通过全量构建的方式得到针对所述应用软件的全量安装包。

在本申请的另一个实施例中，所述存储单元31，在构建得到所述应用软件的全量安装包时，确定所述全量安装包的版本信息，并将所述版本信息作为所述全量安装包的第二基准版本信息，所述第二基准版本信息中包含的版本号高于所述基准安装包对应的基准版本信息中包含的版本号；

建立所述全量安装包与所述第二基准版本信息之间的映射关系。

需要说明的是，本申请实施例提供的更新设备可以通过软件方式实现，也可以通过硬件方式实现，这里不做具体限定。所述更新设备在接收到用户设备发送的应用软件更新请求时，通过判断应用软件的实际版本信息与该应用软件的增量安装包对应的基准版本信息是否一致，有选择地向用户设备推送增量安装包或者全量安装包，以保证用户设备能够快速实现软件更新，提升了应用软件更新的效率，进而改善用户对应用软件的用户体验。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (12)

1.一种应用软件的更新方法，其特征在于，包括：

提供应用软件的增量安装包，所述增量安装包中包括第一基准版本信息；

接收用户设备发送的应用软件更新请求，所述应用软件更新请求中包含所述应用软件的当前版本信息，所述当前版本信息中包括第二基准版本信息；

在确定所述第一基准版本信息与所述第二基准版本信息一致时，将所述应用软件的增量安装包发送给所述用户设备，以用于增量更新。

2.如权利要求1所述的更新方法，其特征在于，所述方法还包括：

提供所述应用软件的全量安装包；

在确定所述第一基准版本信息与所述第二基准版本信息不一致时，将所述应用软件的全量安装包发送给所述用户设备，以用于全量更新。

3.如权利要求1所述的更新方法，其特征在于，提供应用软件的增量安装包，包括：

在应用软件的开发阶段，针对应用软件的部分功能，以基准安装包为基础，通过增量构建的方式得到针对所述部分功能的增量安装包。

4.如权利要求3所述的更新方法，其特征在于，在构建得到所述部分功能的增量安装包时，所述方法还包括：

确定所述基准安装包的版本信息，并将所述基准安装包的版本信息作为所述增量安装包的第一基准版本信息；

建立所述增量安装包与所述增量安装包对应的第一基准版本信息之间的映射关系。

5.如权利要求2所述的更新方法，其特征在于，提供应用软件的全量安装包，包括：

在应用软件的开发阶段，针对应用软件的全部或者部分功能，以基准安装包和/或增量安装包为基础，通过全量构建的方式得到针对所述应用软件的全量安装包。

6.如权利要求5所述的更新方法，其特征在于，在构建得到所述应用软件的全量安装包时，所述方法还包括：

确定所述全量安装包的版本信息，并将所述版本信息作为所述全量安装包的第二基准版本信息，所述第二基准版本信息中包含的版本号高于所述基准安装包对应的基准版本信息中包含的版本号；

建立所述全量安装包与所述第二基准版本信息之间的映射关系。

7.一种应用软件的更新设备，其特征在于，包括：

存储单元，提供应用软件的增量安装包，所述增量安装包中包括第一基准版本信息；

接收单元，接收用户设备发送的应用软件更新请求，所述应用软件更新请求中包含所述应用软件的当前版本信息，所述当前版本信息中包括第二基准版本信息；

发送单元，在确定所述第一基准版本信息与所述第二基准版本信息一致时，将所述应用软件的增量安装包发送给所述用户设备，以用于增量更新。

8.如权利要求7所述的更新设备，其特征在于，

所述存储单元，还提供所述应用软件的全量安装包；

所述发送单元，在确定所述第一基准版本信息与所述第二基准版本信息不一致时，将所述应用软件的全量安装包发送给所述用户设备，以用于全量更新。

9.如权利要求7所述的更新设备，其特征在于，所述存储单元提供应用软件的增量安装包，包括：

在应用软件的开发阶段，针对应用软件的部分功能，以基准安装包为基础，通过增量构建的方式得到针对所述部分功能的增量安装包。

10.如权利要求9所述的更新设备，其特征在于，

所述存储单元，在构建得到所述部分功能的增量安装包时，确定所述基准安装包的版本信息，并将所述基准安装包的版本信息作为所述增量安装包的第一基准版本信息；

建立所述增量安装包与所述增量安装包对应的第一基准版本信息之间的映射关系。

11.如权利要求8所述的更新设备，其特征在于，所述存储单元提供应用软件的全量安装包，包括：

在应用软件的开发阶段，针对应用软件的全部或者部分功能，以基准安装包和/或增量安装包为基础，通过全量构建的方式得到针对所述应用软件的全量安装包。

12.如权利要求11所述的更新设备，其特征在于，

所述存储单元，在构建得到所述应用软件的全量安装包时，确定所述全量安装包的版本信息，并将所述版本信息作为所述全量安装包的第二基准版本信息，所述第二基准版本信息中包含的版本号高于所述基准安装包对应的基准版本信息中包含的版本号；

建立所述全量安装包与所述第二基准版本信息之间的映射关系。