CN109413186A - 应用程序更新方法、终端、服务器及系统 - Google Patents

Abstract

本申请实施例公开了一种应用程序更新方法、终端、服务器及系统，属于应用程序领域。所述方法用于第一后台服务器，第一后台服务器是终端中安装的预下载应用程序的后台服务器，所述方法包括：接收中间服务器发送的目标应用程序的应用更新信息，应用更新信息是所述中间服务器从第二后台服务器处查询得到，第二后台服务器是目标应用程序的后台服务器；根据应用更新信息，从第二后台服务器处下载并存储应用更新数据包；当接收到终端通过预下载应用程序发送的更新请求时，向终端发送目标应用更新数据包，终端用于在目标应用程序启动过程中，读取并安装目标应用更新数据包。本申请实施例可以缩短了更新场景下应用程序的启动时长。

Description

应用程序更新方法、终端、服务器及系统

技术领域

本申请实施例涉及应用程序领域，特别涉及一种应用程序更新方法、终端、服务器及系统。

背景技术

为了丰富应用程序的功能，并优化使用体验，应用程序开发商会定期对应用程序进行版本更新或资源更新。

相关技术中，应用程序启动过程中，会进行更新检测，当检测到需要进行更新时，即从应用程序服务器处下载更新数据包。更新数据包下载并安装完成后，用户即可使用应用程序。

发明内容

本申请实施例提供了一种应用程序更新方法、终端、服务器及系统，可以解决相关技术中，应用程序在启动过程中下载更新数据包并进行安装，导致应用程序启动时长过长的问题。所述技术方案如下：

一方面，提供了一种应用程序更新方法，所述方法用于第一后台服务器，所述第一后台服务器是终端中安装的预下载应用程序的后台服务器，所述方法包括：

接收中间服务器发送的目标应用程序的应用更新信息，所述应用更新信息是所述中间服务器从第二后台服务器处查询得到，所述第二后台服务器是所述目标应用程序的后台服务器；

根据所述应用更新信息，从所述第二后台服务器处下载并存储应用更新数据包；

当接收到所述终端通过所述预下载应用程序发送的更新请求时，向所述终端发送目标应用更新数据包，所述终端用于在所述目标应用程序启动过程中，读取并安装所述目标应用更新数据包。

另一方面，提供了一种应用程序更新方法，所述方法用于终端，所述终端中安装有目标应用程序和预下载应用程序，所述方法包括：

通过所述预下载应用程序向第一后台服务器发送更新请求，所述第一后台服务器是所述预下载应用程序对应的后台服务器；

接收并存储所述第一后台服务器发送的目标应用更新数据包，所述目标应用更新数据包是所述第一后台服务器根据中间服务器发送的应用更新信息从第二后台服务器处下载得到，所述应用更新信息由所述中间服务器从所述第二后台服务器处查询得到所述第二后台服务器是所述目标应用程序的后台服务器；

在所述目标应用程序启动过程中，读取并安装所述目标应用更新数据包。

另一方面，提供了一种应用程序更新装置，所述装置用于第一后台服务器，所述第一后台服务器是终端中安装的预下载应用程序的后台服务器，所述装置包括：

第一接收模块，用于接收中间服务器发送的目标应用程序的应用更新信息，所述应用更新信息是所述中间服务器从第二后台服务器处查询得到所述第二后台服务器是所述目标应用程序的后台服务器；

第一下载模块，用于根据所述应用更新信息，从所述第二后台服务器处下载并存储应用更新数据包；

第一发送模块，用于当接收到所述终端通过所述预下载应用程序发送的更新请求时，向所述终端发送目标应用更新数据包，所述终端用于在所述目标应用程序启动过程中，读取并安装所述目标应用更新数据包。

另一方面，提供了一种应用程序更新装置，所述装置用于终端，所述终端中安装有目标应用程序和预下载应用程序，所述装置包括：

第二发送模块，用于通过所述预下载应用程序向第一后台服务器发送更新请求，所述第一后台服务器是所述预下载应用程序对应的后台服务器；

第二接收模块，用于接收并存储所述第一后台服务器发送的目标应用更新数据包，所述目标应用更新数据包是所述第一后台服务器根据中间服务器发送的应用更新信息从第二后台服务器处下载得到，所述应用更新信息由所述中间服务器从所述第二后台服务器处查询得到所述第二后台服务器是所述目标应用程序的后台服务器；

更新模块，用于在所述目标应用程序启动过程中，读取并安装所述目标应用更新数据包。

另一方面，提供了一种服务器，所述服务器包括处理器和存储器；所述存储器存储有至少一条指令，所述至少一条指令用于被所述处理器执行以实现如上述方面所述的应用程序更新方法。

另一方面，提供了一种终端，所述终端包括处理器和存储器；所述存储器存储有至少一条指令，所述至少一条指令用于被所述处理器执行以实现如上述方面所述的应用程序更新方法。

另一方面，提供了一种计算机可读存储介质，所述存储介质存储有至少一条指令，所述至少一条指令用于被处理器执行以实现如权上述方面所述的服务器侧或终端侧的应用程序更新方法。

另一方面，提供了一种应用程序更新系统，所述系统中包含安装有目标应用程序和预下载应用程序的终端、第一后台服务器、第二后台服务器和中间服务器，所述第一后台服务器是所述预下载应用程序的后台服务器，所述第二后台服务器是所述目标应用程序的后台服务器；

所述中间服务器，用于从所述第二后台服务器处查询所述目标应用程序的应用更新信息；向所述第一后台服务器发送所述应用更新信息；

所述第一后台服务器，用于接收所述中间服务器发送的所述应用更新信息；根据所述应用更新信息，从所述第二后台服务器处下载并存储应用更新数据包；

所述终端，用于向所述第一后台服务器发送更新请求；接收并存储所述第一后台服务器发送的目标应用更新数据包；在所述目标应用程序启动过程中，读取并安装所述目标应用更新数据包。

本申请实施例中，中间服务器从第二后台服务器处查询到目标应用程序的应用更新信息后，将该应用更新信息发送至预下载应用程序对应的第一后台服务器，由第一后台服务器根据应用更新信息从第二后台服务器处下载应用更新数据包；终端中的预下载应用程序向第一后台服务器发送更新请求后，第一后台服务器即将目标应用更新数据包发送给终端，由终端完成应用更新数据包预下载；后续目标应用程序在启动过程中，终端读取预下载的应用更新数据包并进行安装，最终完成目标应用程序启动。相较于相关技术中，由应用程序在启动过程中下载并安装更新数据包，本申请实施例中，终端通过预下载应用程序预先下载应用更新数据包，以便应用程序在启动过程中直接读取安装，从而缩短了应用程序更新时长，进而缩短了更新场景下应用程序的启动时长。

附图说明

图1示出了本申请一个实施例提供的应用程序更新系统的系统架构图；

图2示出了本申请一个示例性实施例示出的应用程序更新方法的流程图；

图3示出了本申请另一个示例性实施例示出的应用程序更新方法的流程图；

图4示出了本申请另一个示例性实施例示出的应用程序更新方法的流程图；

图5示出了本申请另一个示例性实施例示出的应用程序更新方法的流程图；

图6示出了本申请另一个示例性实施例示出的应用程序更新方法的流程图；

图7示出了本申请另一个示例性实施例示出的应用程序更新方法的流程图；

图8示出了本申请另一个示例性实施例示出的应用程序更新方法的流程图；

图9示出了本申请一个实施例提供的应用程序更新装置的结构框图；

图10示出了本申请一个实施例提供的应用程序更新装置的结构框图；

图11示出了本申请一个示例性实施例所提供的服务器的结构示意图；

图12示出了本申请一个示例性实施例所提供的终端的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

请参考图1，其示出了本申请一个实施例提供的应用程序更新系统的系统架构图，该系统中包含终端120、第一后台服务器140、第二后台服务器160和中间服务器180。

终端120是安装有应用程序的电子设备，该电子设备可以是智能手机、平板电脑、可穿戴式设备或便携式个人计算机等等。图1中以终端120是智能手机为例进行说明。

本申请实施例中，终端120中安装有目标应用程序以及预下载应用程序。

其中，该目标应用程序是具有更新需求的应用程序，比如游戏类应用程序、视频类应用程序、即时通信应用程序、社交类应用程序、购物类应用程序等等，本申请实施例对目标应用程序的类型不做限定。

预下载应用程序是具有预下载功能的应用程序，可选的，该预下载应用程序由终端厂商开发并安装到终端120中。其中，预下载应用程序支持为指定应用程序提供更新预下载服务，用于预先将指定应用程序的应用更新数据包下载到本地。

第一后台服务器140是终端120中预下载应用程序的后台服务器，第二后台服务器160是终端120中目标应用程序的后台服务器，第一后台服务器140和第二后台服务器160可以是单台服务器，若干台服务器构成的服务器集群或云计算中心。

中间服务器180是架设在第一后台服务器140和第二后台服务器160之间的服务器，用于实现第一后台服务器140和第二后台服务器160之间的数据交互，其可以是单台服务器，若干台服务器构成的服务器集群或云计算中心。在一种可能的实施方式中，中间服务器180和第二后台服务器160均由同一厂商架设。

本申请实施例中，目标应用程序厂商向终端厂商提供软件开发工具包(SoftwareDevelopment Kit，SDK)，由终端厂商将该SDK嵌入预下载应用程序中。预下载应用程序安装到终端120后，即可通过该SDK获取目标应用程序的应用信息。除了获取应用信息外，该SDK还可以与中间服务器180进行数据通信。

在一种可能的应用场景下，如图1所示，中间服务器180向第二后台服务器160发送查询请求，以查询目标应用程序的更新情况。当查询到目标应用程序需要进行更新时，即将查询到的应用更新信息上报至第一后台服务器140，以便第一后台服务器140根据应用更新信息从第二后台服务器160处下载相应的应用更新数据包。在未启动目标应用程序的情况下，终端120通过预下载应用程序向第一后台服务器140发送更新请求，进而从第一后台服务器140处预下载目标应用更新数据包。目标应用程序启动过程中，即读取本地预下载的目标应用更新数据包，并在完成安装后启动目标应用程序，实现目标应用程序更新。

下述各个实施例中，以服务器侧的应用程序更新方法用于图1中的第一后台服务器140，终端侧的应用程序更新方法用于图1中的终端120为例进行说明。

相关技术中，当终端中安装的应用程序需要更新时，应用程序在启动过程中，从应用程序的后台服务器下载更新数据包，并在下载完成后进行安装，即更新场景下，应用程序的启动时长与更新数据包下载时长以及安装时长相关。

然而，当需要下载的更新数据包较大(比如进行版本更新)，且终端未连接无线网络时，通过蜂窝网络下载更新数据包将消耗大量流量；并且，下载更新数据包需要花费较长时间，导致应用程序的整个启动时长过长。

而本申请实施例提供的应用程序更新方法中，预下载应用程序对应的后台服务器预先根据中间服务器上报的应用更新信息，从目标应用程序的后台服务器处下载应用更新数据包，以便安装有预下载应用程序的终端预先将目标应用更新数据包下载到本地，供目标应用程序启动时读取安装。由于应用更新数据包已预先下载到本地，因此无需在目标应用程序启动阶段实时下载，从而节省了流量，并进一步缩短了应用程序的启动时长。下面采用示意性的实施例进行说明。

请参考图2，其示出了本申请一个示例性实施例示出的应用程序更新方法的流程图。本实施例以该方法应用于图1所示的第一后台服务器140来举例说明。该方法包括：

步骤201，接收中间服务器发送的目标应用程序的应用更新信息，应用更新信息是中间服务器从第二后台服务器处查询得到，第二后台服务器是目标应用程序的后台服务器。

在一种可能的实施方式中，目标应用程序厂商在架设第二后台服务器时，额外架设中间服务器，并将中间服务器与第二后台服务器相连。通过与第二后台服务器之间的连接，中间服务器能够查询到目标应用程序的应用更新信息。同时，预下载应用程序厂商在架设第一后台服务器(实现预下载功能)时，将中间服务器与第一后台服务器相连，以此获取中间服务器查询到的应用更新信息。其中，当预下载功能由终端提供时，预下载应用程序厂商可以为终端厂商。

可选的，该应用更新信息包括应用程序标识、更新内容类型、更新内容版本号和更新内容下载地址中的至少一种。

其中，应用程序标识用于唯一标识应用程序，更新内容类型包括程序和资源中的至少一种，更新内容版本号包括程序版本号和资源版本号中的至少一种，更新内容下载地址为IP地址。

可选的，中间服务器每隔预定时间间隔(比如24h)，从第二后台服务器处查询目标应用程序的应用更新信息，并将应用更新信息上报至第一后台服务器。相应的，第一后台服务器接收中间服务器上报的应用更新信息。

当然，第二后台服务器也可以主动向中间服务器推送应用更新信息，本申请实施例对此不做限定。

步骤202，根据应用更新信息，从第二后台服务器处下载并存储应用更新数据包。

可选的，应用更新信息中包含更新内容下载地址时，第一后台服务器即根据该更新内容下载地址从第二后台服务器处下载应用更新数据包。

可选的，为了保证下载的应用更新数据包的准确性，第一后台服务器对下载的应用更新数据包进行校验，并在校验通过后存储应用更新数据包。

步骤203，当接收到终端通过预下载应用程序发送的更新请求时，向终端发送目标应用更新数据包，终端用于在目标应用程序启动过程中，读取并安装目标应用更新数据包。

对于同时安装有目标应用程序和预下载应用程序的终端，在一种可能的实施方式中，在目标应用程序未启动，且终端符合预下载条件的情况下，终端向第一后台服务器发送更新请求，请求获取应用更新数据包，实现更新数据包预下载。

可选的，由于不同终端中安装的目标应用程序的程序版本或资源版本可能不同，相应的，不同终端中的目标应用程序更新至最新版本时所需要安装的应用更新数据包也不同，因此，终端发送的更新请求中包含本地应用信息，相应的，第一后台服务器根据本地应用信息和最新应用信息，确定目标应用程序更新至最新版本是所需安装的目标应用更新数据包。

通过上述步骤，终端在目标应用程序未启动的情况下，完成应用更新数据包的预下载，后续目标应用程序启动时，首先检测本地是否存储有应用更新数据包，并在本地存储有应用更新数据包时，直接读取并安装，而无需从第二后台服务器处下载。

相较于相关技术中的应用程序更新方式，本申请实施例中，终端在更新目标应用程序时，免去了实时下载应用更新数据包的流程，从而缩短了应用更新场景下的应用程序启动时长，并避免通过移动数据网络下载应用更新数据包造成的流量消耗。

综上所述，本申请实施例中，中间服务器从第二后台服务器处查询到目标应用程序的应用更新信息后，将该应用更新信息发送至预下载应用程序对应的第一后台服务器，由第一后台服务器根据应用更新信息从第二后台服务器处下载应用更新数据包；终端中的预下载应用程序向第一后台服务器发送更新请求后，第一后台服务器即将目标应用更新数据包发送给终端，由终端完成应用更新数据包预下载；后续目标应用程序在启动过程中，终端读取预下载的应用更新数据包并进行安装，最终完成目标应用程序启动。相较于相关技术中，由应用程序在启动过程中下载并安装更新数据包，本申请实施例中，终端通过预下载应用程序预先下载应用更新数据包，以便应用程序在启动过程中直接读取安装，从而缩短了应用程序更新时长，进而缩短了更新场景下应用程序的启动时长。

请参考图3，其示出了本申请另一个示例性实施例示出的应用程序更新方法的流程图。本实施例以该方法应用于图1所示的终端120来举例说明。该方法包括：

步骤301，通过预下载应用程序向第一后台服务器发送更新请求，第一后台服务器是预下载应用程序对应的后台服务器。

在一种可能的实施方式中，在目标应用程序未启动，且终端符合预下载条件的情况下，终端向第一后台服务器发送更新请求，请求获取应用更新数据包，实现更新数据包预下载。

可选的，该预下载条件包括如下至少一种：接入无线网络(避免通过移动数据网络下载造成流量消耗)、剩余电量大于电量阈值(避免预下载过程中关机导致数据包下载不全)、剩余存储空间大于空间阈值(避免预下载的应用更新数据包无法存储)。

可选的，由于预下载应用程序可以同时为多个应用程序提供预下载服务，因此，该更新请求中还包含目标应用程序的应用标识；由于不同版本的目标应用程序更新至最新版本所需安装的应用更新数据包不同，因此，该更新请求中还包含目标应用程序的程序信息。

可选的，用户可以通过预下载应用程序手动设置是否开启目标应用程序的预下载功能。

步骤302，接收并存储第一后台服务器发送的目标应用更新数据包，目标应用更新数据包是第一后台服务器根据中间服务器发送的应用更新信息从第二后台服务器处下载得到，应用更新信息由中间服务器从第二后台服务器处查询得到第二后台服务器是目标应用程序的后台服务器。

可选的，第一后台服务器接收到更新请求后，根据更新请求中的内容，检测终端中安装的目标应用程序是否需要进行更新，若需要，则向终端发送目标应用更新数据包，若不需要，则向终端发送指示信息，指示目标应用程序当前为最新版本。

其中，第一后台服务器可以采用数据包推送的方式向终端发送目标应用更新数据包，也可以向终端提供目标应用更新数据包的下载地址，由终端根据下载地址从第一后台服务器处下载，本申请并不对此进行限定。

可选的，为了保证下载的目标应用更新数据包的准确性，终端对下载的目标应用更新数据包进行校验，并在校验通过后存储目标应用更新数据包，且为了使目标应用程序在启动过程中能够读取到目标应用更新数据包，终端将目标应用更新数据包存储在指定路径下。

需要说明的是，目标应用更新数据包的下载过程在后台静默执行，用户无法从前台感知。同时，终端在空闲状态下下载目标应用更新数据包，或在非空闲状态下限制下载目标应用更新数据包的速度，从而避免对用户正常使用造成影响。

步骤303，在目标应用程序启动过程中，读取并安装目标应用更新数据包。

由于终端已完成更新数据包预下载，因此，在目标应用程序启动过程中，目标应用程序无需再从第二后台服务器处下载应用更新数据包，而是直接读取预下载的应用更新数据包。

可选的，终端安装完目标应用更新数据包后，删除该目标应用更新数据包，以便从而节省终端存储空间。

综上所述，本申请实施例中，中间服务器从第二后台服务器处查询到目标应用程序的应用更新信息后，将该应用更新信息发送至预下载应用程序对应的第一后台服务器，由第一后台服务器根据应用更新信息从第二后台服务器处下载应用更新数据包；终端中的预下载应用程序向第一后台服务器发送更新请求后，第一后台服务器即将目标应用更新数据包发送给终端，由终端完成应用更新数据包预下载；后续目标应用程序在启动过程中，终端读取预下载的应用更新数据包并进行安装，最终完成目标应用程序启动。相较于相关技术中，由应用程序在启动过程中下载并安装更新数据包，本申请实施例中，终端通过预下载应用程序预先下载应用更新数据包，以便应用程序在启动过程中直接读取安装，从而缩短了应用程序更新时长，进而缩短了更新场景下应用程序的启动时长。

请参考图4，其示出了本申请另一个示例性实施例示出的应用程序更新方法的流程图。本实施例以该方法应用于图1所示的应用程序更新系统举例说明。该方法包括：

步骤401，中间服务器从第二后台服务器处查询目标应用程序的应用更新信息。

在一个示意性的例子中，目标应用程序是游戏应用程序，第二后台服务器是游戏服务器，中间服务器由游戏厂商架设，用于通过与游戏服务器之间的接口查询游戏更新信息。其中，游戏更新信息包括程序更新信息和资源更新信息。

步骤402，中间服务器向第一后台服务器发送应用更新信息。

在一个示意性的例子中，终端内置应用更新预下载功能(可实现成为预下载应用程序)，且支持游戏应用程序预下载。终端厂商架设的第一后台服务器即为预下载服务器，该预下载服务器通过与中间服务器之间的接口进行数据通信。

步骤403，第一后台服务器根据应用更新信息，从第二后台服务器处下载并存储应用更新数据包。

本步骤的实施方式可以参考步骤202，本实施例在此不再赘述。

为了保证预下载的应用更新数据包的准确性，在一种可能的实施方式中，本步骤可以包括如下步骤：

一、根据应用更新信息中包含的数据包下载地址，从第二后台服务器处下载应用更新数据包。

可选的，当中间服务器发送的应用更新信息中包含数据包下载地址时，第一后台服务器即根据数据包下载地址，通过第二后台服务器的预留端口下载应用更新数据包。

二、当完成应用更新数据包下载时，根据应用更新信息中包含的校验码，对应用更新数据包进行校验。

当应用更新信息中还包含校验码时，第一后台服务器利用该校验码对下载的应用更新数据包进行校验，若应用更新数据包通过校验，则确定下载的应用更新数据包正确，若应用更新数据包未通过校验，则确定下载的应用更新数据包发生正确，从而删除已下载的应用更新数据包，并重新下载。

可选的，该校验码可以是第二后台服务器根据应用更新数据包计算得到的消息摘要算法码(Message-Digest Algorithm 5，MD5)，在进行校验时，第一后台服务器计算下载的应用更新数据包的MD5码，并检测该MD5码与应用更新信息中包含的MD5码是否一致，若一致，则确定应用更新数据包通过校验。

当然，该校验码也可以由第二后台服务器提供，本实施例对此不做限定。

三、若应用更新数据包通过校验，则存储应用更新数据包。

进一步的，第一后台服务器对通过校验的应用更新数据包进行存储。

步骤404，终端通过预下载应用程序向第一后台服务器发送更新请求。

本步骤的实施方式可以参考步骤301，本实施例在此不再赘述。

示意性的，游戏应用程序未启动时，预下载应用程序即向预下载服务器发送更新请求，请求预下载游戏应用程序的游戏更新数据包。

步骤405，当接收到终端通过预下载应用程序发送的更新请求时，第一后台服务器向终端发送目标应用更新数据包。

本步骤的实施方式可以参考步骤203，本实施例在此不再赘述。

示意性的，预下载服务器根据更新请求确定终端中的游戏应用程序需要进行更新时，即将相应的游戏更新数据包(即目标应用更新数据包)发送至终端。

步骤406，终端接收并存储第一后台服务器发送的目标应用更新数据包。

本步骤的实施方式可以参考步骤302，本实施例在此不再赘述。

步骤407，在目标应用程序启动过程中，终端读取并安装目标应用更新数据包。

本步骤的实施方式可以参考步骤303，本实施例在此不再赘述。

示意性的，游戏应用程序启动过程中，检测是否需要进行更新，若需要更新，首先从指定目录下读取游戏更新数据包，若读取到游戏更新数据包，则进行安装；若未读取到游戏更新数据包，则从游戏服务器处下载游戏更新数据包并安装。

在一种可能的场景下，当第二后台服务器通过中间服务器向第一后台服务器发送停止更新指令时，第一后台服务器删除停止更新指令指示的应用更新数据包。

在一种可能的实施方式中，停止更新指令中包含停止更新数据包的数据包标识，第一后台服务器即根据该数据包标识，删除对应的应用更新数据包，从而避免终端后续下载。

为了使预下载应用程序知悉目标应用程序的应用信息，在一种可能的实施方式中，预下载应用程序中内嵌有目标应用程序厂商提供的SDK，借助该SDK，预下载应用程序能够获取到目标应用程序的相关应用信息。在图4的基础上，如图5所示，上述步骤404包括步骤404A和404B，步骤405包括步骤405A和405B。

步骤404A，终端通过预下载应用程序中的SDK，获取目标应用程序的本地应用信息，本地应用信息包括本地程序版本和本地资源版本中的至少一种。

终端中的预下载应用程序中内嵌有目标应用程序厂商提供的SDK，通过调用该SDK中的应用程序接口(Application Programming Interface，API)，预下载应用程序可以获取到目标应用程序的本地应用信息。该本地应用信息是预下载应用程序无法直接从目标应用程序处获取的信息。

其中，本地程序版本为本地应用程序的代码版本，本地资源版本为本地应用程序中资源的版本，该资源可以是图标资源、音频资源、视频资源、贴图资源等等。

需要说明的是，当预下载应用程序支持多种应用程序(对应不同应用程序厂商)预下载时，预下载应用程序中可以内嵌不同应用程序厂商提供的SDK，且通过调用SDK只能从指定应用程序处获取本地应用信息。

比如，终端中安装有游戏应用程序A，视频应用程序B，且预下载应用程序中内嵌有游戏应用程序A对应的SDK A，视频应用程序B对应的SDK B，通过调用SDK A，预下载应用程序获取到游戏应用程序A的本地应用信息：本地程序版本v1.0.1，本地资源版本v1.1.1。

步骤404B，终端通过预下载应用程序向第一后台服务器发送包含本地应用信息的更新请求。

通过SDK获取到本地应用信息后，终端将本地应用信息添加到更新请求中，并通过预下载应用程序发送至第一后台服务器。

可选的，由于第一后台服务器中存储有不同应用程序对应的应用更新数据包，因此，该更新请求中还包含目标应用程序的应用标识，该应用标识可以为应用包名。

步骤405A，当接收到更新请求时，第一后台服务器获取更新请求中包含的本地应用信息。

相应的，为了确定终端中安装的目标应用程序是否需要进行更新，第一后台服务器获取更新请求中包含的本地应用信息，并检测本地应用信息与服务器端维护的最新应用信息是否一致。若两者一致，表明终端侧的目标应用程序为最新版本，无需更新；若两者不一致，表明终端侧的目标应用程序需要更新，并执行步骤405B。

可选的，当更新请求中包含应用标识时，第一后台服务器根据应用标识确定目标应用程序对应的最新版本信息。示意性的，第一后台服务器中存储的应用程序与最新应用信息的对应关系如表一所示。

表一

应用标识	最新应用信息
		App A	程序版本：v1.1.1资源版本：v1.2.1
App B	程序版本：v2.0.1资源版本：v2.0.1
		App C	程序版本：v4.1.1资源版本：v4.3.2

结合表一和步骤404B中的示例，第一后台服务器根据应用标识“App A”，获取到最新应用信息为“程序版本：v1.1.1，资源版本：v1.2.1”，并检测到本地应用信息与最新应用信息不一致。

步骤405B，若本地应用信息与最新应用信息不一致，第一后台服务器则向终端发送目标应用更新数据包。

其中，该目标应用更新数据包用于将目标应用程序由本地版本更新至最新版本。由于不同终端中目标应用程序的版本不同，相应的，更新至最新版本所需安装的应用更新数据包也不同，因此，在一种可能的实施方式中，本步骤可以包括如下步骤：

一、获取本地应用信息对应的目标应用更新数据包，其中，不同的本地应用信息对应不同的目标应用更新数据包。

可选的，第一后台服务器从第二后台服务器处下载应用更新数据包后，即将应用更新信息与应用更新数据包进行关联存储，应用更新数据包与应用更新信息的对应关系如表二所示。

表二

应用更新信息	应用更新数据包
		程序版本：v1.0.1资源版本：v1.1.1	数据包A
程序版本：v1.0.2资源版本：v1.1.1	数据包B
		程序版本：v1.0.2资源版本：v1.2.1	数据包C
程序版本：v1.1.1资源版本：v1.2.1	数据包D

其中，数据包B为程序版本由v1.0.1升至v1.0.2所需安装的应用更新数据包，数据包C为资源版本由v1.1.1升至v1.2.1所需安装的应用更新数据包，数据包D为程序版本由v1.0.2升至v1.1.1所需安装的应用更新数据包。

基于应用更新信息与更新数据包之间的对应关系，第一后台服务器获取本地应用信息对应的目标应用更新数据包。其中，该目标应用更新数据包中包含本地应用信息所指示版本之后各个版本对应的应用更新数据包。

比如，当本地应用信息为：本地程序版本v1.0.1，本地资源版本v1.1.1时，第一后台服务器确定目标应用程序更新至最新版本所需安装的目标更新数据包包括数据包B、C和D。

二、向终端发送目标应用更新数据包。

进一步的，第一后台服务器将确定出的目标应用更新数据包发送至终端，供终端进行存储。

本实施例中，通过在预下载应用程序中内嵌SDK，从而利用该SDK获取终端中目标应用程序的本地应用信息，以便预下载应用程序根据本地应用信息从第一后台服务器处下载相应的应用更新数据包，保证了预下载的应用更新数据包的准确性。

在其他可能的实施方式中，预下载应用程序中还可以内嵌静默安装SDK，完成目标应用更新数据包下载后，终端即可以通过调用静默安装SDK读取并安装目标应用更新数据包，从而省去目标应用程序在启动阶段读取安装应用更新数据包的过程，进一步缩短应用更新场景下应用程序的启动时长。

应用程序厂商对应用程序进行更新时，采用的更新方式包括全量更新和灰度更新。其中，进行全量更新时，所有安装非最新版本应用程序的终端均需要更新，而进行灰度更新时，仅部分安装非最新版本的应用程序需要进行更新。为了在灰度更新场景下实现预下载，在图4的基础上，如图6所示，步骤403之后还包括步骤408，步骤404包括步骤404C和404D步骤405包括步骤405C和405D。

步骤408，第一后台服务器获取应用更新数据包对应的灰度更新策略，灰度更新策略用于指示向目标终端发送应用更新数据包。

在一种可能的实施方式中，第一后台服务器获取应用更新数据包时，获取该应用更新数据包对应的灰度更新策略，并对灰度更新策略和应用更新数据包进行关联存储。示意性的，应用更新信息、应用更新数据包以及更新策略之间的对应关系如表三所示。

表三

其中，数据包A、B、C均采用全量更新，而数据包D采用灰度更新，且灰度更新的目标终端为型号为R15和R17的终端。

步骤404C，终端通过预下载应用程序中的SDK，获取目标应用程序的本地应用信息，本地应用信息包括本地程序版本和本地资源版本中的至少一种。

本步骤的实施方式可以参考上述步骤404A，本实施例在此不再赘述。

步骤404D，通过预下载应用程序向第一后台服务器发送包含本地应用信息和终端信息的更新请求，终端信息包括终端型号、终端厂商和终端位置中的至少一种。

除了将获取到的本地应用信息添加到更新请求之外，预下载应用程序还将终端信息添加到更新请求中，以便第一后台服务器确定该终端是否为目标终端。

可选的，该终端信息至少包括终端型号、终端厂商和终端位置中的一种。比如，终端发送的更新请求中包含终端型号“R15”，终端厂商“X牌”以及终端位置“P城”。

步骤405C，当接收到更新请求时，第一后台服务器获取更新请求中包含的本地应用信息以及终端信息。

在一种可能的实施方式中，第一后台服务器检测本地应用信息与最新应用信息是否一致，且终端信息是否符合灰度更新策略。若本地应用信息与最新应用信息一致，且终端信息符合灰度更新策略，则确定终端为需要进行应用更新的目标终端；若本地应用信息与最新应用信息不一致，或终端信息不符合灰度更新策略，则确定终端不属于需要进行应用更新的目标终端。

结合上述步骤中的示例，第一后台服务器获取到本地应用信息为“程序版本：v1.0.2，资源版本：v1.2.1”，终端型号为“R15”，从而确定本地应用信息与最新应用信息不一致，且终端信息指示终端符合灰度更新策略。

本实施例仅以对指定型号终端进行应用更新为例进行说明，在其他可能的实施方式中，还可以对指定厂商、指定地区的终端进行应用更新，本实施例对此不做限定。

步骤405D，若本地应用信息与最新应用信息不一致，且终端信息指示终端符合灰度更新策略，第一后台服务器则向终端发送目标应用更新数据包。

进一步的，第一后台服务器向需要进行灰度更新的目标终端发送目标应用更新数据包。其中，确定目标应用更新数据包的过程可以参考步骤405B，本实施例在此不再赘述。

本实施例中，第一后台服务器基于获取到的灰度更新策略以及终端上报的终端信息，确定当前终端是否为需要进行灰度更新的目标终端，并在当前终端为目标终端时，发送相应的应用更新数据包，实现了灰度更新场景下的应用更新预下载，保证灰度更新策略的实施准确性。

图6所示实施例中，灰度更新策略存储在第一后台服务器侧，并由第一后台服务器检测请求更新的终端是否为灰度更新策略指示的目标终端。为了进一步降低第一后台服务器的请求处理压力，在图4的基础上，如图7所示，步骤404可以包括如下步骤。

步骤404E，终端通过预下载应用程序中的SDK，接收中间服务器发送的灰度更新策略，灰度更新策略用于指示向目标终端发送应用更新数据包。

可选的，预下载应用程序通过内嵌的SDK与中间服务器之间建立有数据传输通道。中间服务器从第二后台服务器处查询到应用更新信息的同时，获取到相应的灰度更新策略，并将该灰度更新策略下发给终端。预下载应用程序通过SDK获取中间服务器下发的灰度更新策略。

当然，第一后台服务器也可以将获取到的灰度更新策略发送给预下载服务器，本实施例对此不做限定。

步骤404F，终端获取终端信息，终端信息包括终端型号、终端厂商和终端位置中的至少一种。

终端获取到灰度更新策略后，进一步获取自身的终端信息，以便后续根据自身的终端信息确定是否需要预下载应用更新数据包。

在一种可能的实施方式中，终端检测终端信息是否符合灰度更新策略，若本终端信息符合灰度更新策略，则确定终端为需要进行应用更新的目标终端；若终端信息不符合灰度更新策略，则确定终端不属于需要进行应用更新的目标终端。

步骤404G，当终端信息指示终端符合灰度更新策略时，终端向第一后台服务器发送更新请求。

终端向第一后台服务器发送更新请求的过程可以参考上述步骤404B，本实施例在此不再赘述。

终端从第一后台服务器处下载目标应用更新数据包的过程中，可能会因为多种因素导致下载失败。可选的，若在接收目标应用更新数据包的过程中接收到停止下载信号，终端则停止下载目标应用更新数据包，并删除已下载数据，停止下载信号的触发方式包括如下至少一种：电量不足、存储空间不足、网络切换和下载异常。

在一种可能的实施方式中，终端在下载目标应用更新数据包的过程中，实时获取当前剩余电量，并根据当前剩余电量和当前下载进度，确定当前剩余电量耗尽前是否能够完成下载，若不能完成下载，则确定电量不足，并触发停止下载信号。

在另一种可能的实施方式中，终端在下载目标应用更新数据包的过程中，实时获取当前剩余存储空间，并根据目标应用更新数据包的剩余下载量，确定是否能够存储目标应用更新数据包，若不能，则确定存储空间不足，并触发停止下载信号。

在另一种可能的实施方式中，终端在下载目标应用更新数据包的过程中，若检测到有无线网络切换为移动数据网络，则确定发生网络切换，并触发停止下载信号。

除了受到上述因素的影响外，若目标应用程序在接收目标应用更新数据包的过程中启动，终端则停止下载目标应用更新数据包，并删除已下载数据，进而通过目标应用程序从第二后台服务器处下载目标应用更新数据包。

为了方便应用程序厂商对应用程序的更新情况进行统计，在图5的基础上，如图8所示，步骤407之后还包括如下步骤。

步骤409，终端通过预下载应用程序中的SDK，向中间服务器发送反馈信息，反馈信息包括下载成功反馈和下载失败反馈中的至少一种。

在一种可能的实施方式中，完成目标应用更新数据包下载后，终端通过预下载应用程序中的SDK，向中间服务器发送下载成功反馈，其中包含下载开始时间、下载结束时间、更新版本、当前版本、应用包名和终端标识中的至少一种。

在另一种可能的实施方式中，若下载目标应用更新数据包失败，终端则通过预下载应用程序中的SDK，向中间服务器发送下载失败反馈，其中包含下载失败原因标识、更新版本、当前版本、应用包名和终端标识中的至少一种。

中间服务器接收到反馈信息后，进一步将反馈信息发送至第二后台服务器，以便第二后台服务器统计目标应用程序在预下载场景下的更新情况。

需要说明的是，上述各个实施例中，以第一后台服务器为执行主体的步骤可以组合实现成为第一后台服务器侧的应用程序更新方法，以终端为执行主体的步骤可以组合实现成为终端侧的应用程序更新方法，本实施例在此不再赘述。

请参考图9，其示出了本申请一个实施例提供的应用程序更新装置的结构框图。该装置可以通过软件、硬件或者两者的结合实现成为图1中第一后台服务器140的全部或一部分。该装置包括：

第一接收模块901，用于接收中间服务器发送的目标应用程序的应用更新信息，所述应用更新信息是所述中间服务器从第二后台服务器处查询得到，所述第二后台服务器是所述目标应用程序的后台服务器；

第一下载模块902，用于根据所述应用更新信息，从所述第二后台服务器处下载并存储应用更新数据包；

第一发送模块903，用于当接收到所述终端通过所述预下载应用程序发送的更新请求时，向所述终端发送目标应用更新数据包，所述终端用于在所述目标应用程序启动过程中，读取并安装所述目标应用更新数据包。

可选的，所述第一发送模块903，包括：

第一接收单元，用于当接收到所述更新请求时，获取所述更新请求中包含的本地应用信息，所述本地应用信息通过所述预下载应用程序中的软件开发工具包SDK从所述目标应用程序处获取，所述本地应用信息包括本地程序版本和本地资源版本中的至少一种；

第一发送单元，用于若所述本地应用信息与最新应用信息不一致，则向所述终端发送所述目标应用更新数据包。

可选的，所述装置还包括：

第一获取模块，用于获取所述应用更新数据包对应的灰度更新策略，所述灰度更新策略用于指示向目标终端发送所述应用更新数据包；

所述第一发送模块903，包括：

第一获取单元，用于当接收到所述更新请求时，获取所述更新请求中包含的本地应用信息以及终端信息，所述本地应用信息通过所述预下载应用程序中的SDK从所述目标应用程序处获取，所述本地应用信息包括本地程序版本和本地资源版本中的至少一种，所述终端信息包括终端型号、终端厂商和终端位置中的至少一种；

第一发送单元，用于若所述本地应用信息与最新应用信息不一致，且所述终端信息指示所述终端符合所述灰度更新策略，则向所述终端发送所述目标应用更新数据包。

可选的，所述第一发送单元，用于：

获取所述本地应用信息对应的所述目标应用更新数据包，其中，不同的所述本地应用信息对应不同的所述目标应用更新数据包；

向所述终端发送所述目标应用更新数据包。

可选的，所述第一下载模块902，包括：

下载单元，用于根据所述应用更新信息中包含的数据包下载地址，从所述第二后台服务器处下载所述应用更新数据包；

校验单元，用于当完成所述应用更新数据包下载时，根据所述应用更新信息中包含的校验码，对所述应用更新数据包进行校验；

存储单元，用于若所述应用更新数据包通过校验，则存储所述应用更新数据包。

可选的，所述装置还包括：

删除模块，用当接收到所述中间服务器发送的停止更新指令时，删除所述停止更新指令指示的应用更新数据包，所述停止更新指令由所述第二后台服务器发送给所述中间服务器。

请参考图10，其示出了本申请另一个实施例提供的应用程序更新装置的结构框图。该装置可以通过软件、硬件或者两者的结合实现成为图1中终端120的全部或一部分。该装置包括：

第二发送模块1001，用于通过所述预下载应用程序向第一后台服务器发送更新请求，所述第一后台服务器是所述预下载应用程序对应的后台服务器；

第二接收模块1002，用于接收并存储所述第一后台服务器发送的目标应用更新数据包，所述目标应用更新数据包是所述第一后台服务器根据中间服务器发送的应用更新信息从第二后台服务器处下载得到，所述应用更新信息由所述中间服务器从所述第二后台服务器处查询得到所述第二后台服务器是所述目标应用程序的后台服务器；

更新模块1003，用于在所述目标应用程序启动过程中，读取并安装所述目标应用更新数据包。

可选的，所述第二发送模块1001，包括：

第二获取单元，用于通过所述预下载应用程序中的软件开发工具包SDK，获取所述目标应用程序的本地应用信息，所述本地应用信息包括本地程序版本和本地资源版本中的至少一种；

第二发送单元，用于向所述第一后台服务器发送包含所述本地应用信息的所述更新请求，所述第一后台服务器用于在所述本地应用信息与最新应用信息不一致时，向所述终端发送所述目标应用更新数据包。

可选的，所述第二发送模块1001，还包括：

第一接收单元，用于通过所述预下载应用程序中的软件开发工具包SDK，接收所述中间服务器发送的灰度更新策略，所述灰度更新策略用于指示向目标终端发送所述应用更新数据包；

第三获取单元，用于获取终端信息，所述终端信息包括终端型号、终端厂商和终端位置中的至少一种；

第三发送单元，用于当所述终端信息指示所述终端符合所述灰度更新策略时，向所述第一后台服务器发送所述更新请求。

可选的，所述通装置还包括：

第一停止模块，用于若在接收所述目标应用更新数据包的过程中接收到停止下载信号，则停止下载所述目标应用更新数据包，并删除已下载数据，所述停止下载信号的触发方式包括如下至少一种：电量不足、存储空间不足、网络切换和下载异常。

可选的，所述装置还包括：

第二停止模块，用于若所述目标应用程序在接收所述目标应用更新数据包的过程中启动，则停止下载所述目标应用更新数据包，并删除已下载数据；

第二下载模块，用于通过所述目标应用程序从所述第二后台服务器处下载所述目标应用更新数据包。

可选的，所述装置还包括：

第三发送模块，用于通过所述预下载应用程序中的SDK，向所述中间服务器发送反馈信息，所述反馈信息包括下载成功反馈和下载失败反馈中的至少一种，所述中间服务器用于将所述反馈信息发送至所述第二后台服务器。

图11示出了本申请一个示例性实施例所提供的服务器的结构示意图。该服务器可以实现成为图1中的第一后台服务器140。。

可选的，该服务器1100中包括：处理器1120和存储器1140。

处理器1120可以包括一个或者多个处理核心。处理器1120利用各种接口和线路连接整个服务器1100内的各个部分，通过运行或执行存储在存储器1140内的指令、程序、代码集或指令集，以及调用存储在存储器1140内的数据，执行服务器1100的各种功能和处理数据。可选的，处理器1120可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(ProgrammableLogic Array，PLA)中的至少一种硬件形式来实现。处理器1120可集成中央处理器(CentralProcessing Unit，CPU)、图像处理器(Graphics Processing Unit，GPU)中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示屏所需要显示的内容的渲染和绘制。

存储器1140可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory)。可选的，该存储器1140包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器1140可用于存储指令、程序、代码、代码集或指令集。存储器1140可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现上述各个方法实施例的指令等；存储数据区可存储上面各个方法实施例中涉及到的数据等。

图12示出了本申请一个示例性实施例所提供的终端的结构示意图。该终端可以实现成为图1中的终端120。

可选的，该终端1200中包括：处理器1220和存储器1240。

处理器1220可以包括一个或者多个处理核心。处理器1220利用各种接口和线路连接整个终端1200内的各个部分，通过运行或执行存储在存储器1240内的指令、程序、代码集或指令集，以及调用存储在存储器1240内的数据，执行终端1200的各种功能和处理数据。可选的，处理器1220可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable LogicArray，PLA)中的至少一种硬件形式来实现。处理器1220可集成中央处理器(CentralProcessing Unit，CPU)、图像处理器(Graphics Processing Unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示屏所需要显示的内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器1220中，单独通过一块芯片进行实现。

存储器1240可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory)。可选的，该存储器1240包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器1240可用于存储指令、程序、代码、代码集或指令集。存储器1240可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现上述各个方法实施例的指令等；存储数据区可存储上面各个方法实施例中涉及到的数据等。

当然，除了包含处理器和存储器外，终端1200还包括显示组件、定位组件、蓝牙组件、传感器、射频(Radio Frequency，RF)组件、WiFi组件、显示屏等其他必要组件，本申请实施例并不对终端1200包含的具体组件进行限定。

本申请实施例还提供了一种计算机可读介质，该计算机可读介质存储有至少一条指令，所述至少一条指令由所述处理器加载并执行以实现如上各个实施例中服务器侧或终端侧的应用程序更新方法。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (18)

1.一种应用程序更新方法，其特征在于，所述方法用于第一后台服务器，所述第一后台服务器是终端中安装的预下载应用程序的后台服务器，所述方法包括：

接收中间服务器发送的目标应用程序的应用更新信息，所述应用更新信息是所述中间服务器从第二后台服务器处查询得到，所述第二后台服务器是所述目标应用程序的后台服务器；

根据所述应用更新信息，从所述第二后台服务器处下载并存储应用更新数据包；

当接收到所述终端通过所述预下载应用程序发送的更新请求时，向所述终端发送目标应用更新数据包，所述终端用于在所述目标应用程序启动过程中，读取并安装所述目标应用更新数据包。

2.根据权利要求1所述的方法，其特征在于，所述当接收到所述终端通过所述预下载应用程序发送的更新请求时，向所述终端发送目标应用更新数据包，包括：

当接收到所述更新请求时，获取所述更新请求中包含的本地应用信息，所述本地应用信息通过所述预下载应用程序中的软件开发工具包SDK从所述目标应用程序处获取，所述本地应用信息包括本地程序版本和本地资源版本中的至少一种；

若所述本地应用信息与最新应用信息不一致，则向所述终端发送所述目标应用更新数据包。

3.根据权利要求1所述的方法，其特征在于，所述根据所述应用更新信息，从所述第二后台服务器处下载并存储应用更新数据包之后，所述方法还包括：

获取所述应用更新数据包对应的灰度更新策略，所述灰度更新策略用于指示向目标终端发送所述应用更新数据包；

所述当接收到所述终端通过所述预下载应用程序发送的更新请求时，向所述终端发送目标应用更新数据包，包括：

当接收到所述更新请求时，获取所述更新请求中包含的本地应用信息以及终端信息，所述本地应用信息通过所述预下载应用程序中的SDK从所述目标应用程序处获取，所述本地应用信息包括本地程序版本和本地资源版本中的至少一种，所述终端信息包括终端型号、终端厂商和终端位置中的至少一种；

若所述本地应用信息与最新应用信息不一致，且所述终端信息指示所述终端符合所述灰度更新策略，则向所述终端发送所述目标应用更新数据包。

4.根据权利要求2或3所述的方法，其特征在于，所述向所述终端发送所述目标应用更新数据包，包括：

获取所述本地应用信息对应的所述目标应用更新数据包，其中，不同的所述本地应用信息对应不同的所述目标应用更新数据包；

向所述终端发送所述目标应用更新数据包。

5.根据权利要求1至3任一所述的方法，其特征在于，所述根据所述应用更新信息，从所述第二后台服务器处下载并存储应用更新数据包，包括：

根据所述应用更新信息中包含的数据包下载地址，从所述第二后台服务器处下载所述应用更新数据包；

当完成所述应用更新数据包下载时，根据所述应用更新信息中包含的校验码，对所述应用更新数据包进行校验；

若所述应用更新数据包通过校验，则存储所述应用更新数据包。

6.根据权利要求1至3任一所述的方法，其特征在于，所述根据所述应用更新信息，从所述第二后台服务器处下载并存储应用更新数据包之后，所述方法还包括：

当接收到所述中间服务器发送的停止更新指令时，删除所述停止更新指令指示的应用更新数据包，所述停止更新指令由所述第二后台服务器发送给所述中间服务器。

7.一种应用程序更新方法，其特征在于，所述方法用于终端，所述终端中安装有目标应用程序和预下载应用程序，所述方法包括：

通过所述预下载应用程序向第一后台服务器发送更新请求，所述第一后台服务器是所述预下载应用程序对应的后台服务器；

接收并存储所述第一后台服务器发送的目标应用更新数据包，所述目标应用更新数据包是所述第一后台服务器根据中间服务器发送的应用更新信息从第二后台服务器处下载得到，所述应用更新信息由所述中间服务器从所述第二后台服务器处查询得到所述第二后台服务器是所述目标应用程序的后台服务器；

在所述目标应用程序启动过程中，读取并安装所述目标应用更新数据包。

8.根据权利要求7所述的方法，其特征在于，所述通过所述预下载应用程序向第一后台服务器发送更新请求，包括：

通过所述预下载应用程序中的软件开发工具包SDK，获取所述目标应用程序的本地应用信息，所述本地应用信息包括本地程序版本和本地资源版本中的至少一种；

向所述第一后台服务器发送包含所述本地应用信息的所述更新请求，所述第一后台服务器用于在所述本地应用信息与最新应用信息不一致时，向所述终端发送所述目标应用更新数据包。

9.根据权利要求7所述的方法，其特征在于，所述通过所述预下载应用程序向第一后台服务器发送更新请求，还包括：

通过所述预下载应用程序中的软件开发工具包SDK，接收所述中间服务器发送的灰度更新策略，所述灰度更新策略用于指示向目标终端发送所述应用更新数据包；

获取终端信息，所述终端信息包括终端型号、终端厂商和终端位置中的至少一种；

当所述终端信息指示所述终端符合所述灰度更新策略时，向所述第一后台服务器发送所述更新请求。

10.根据权利要求7至9任一所述的方法，其特征在于，所述通过所述预下载应用程序向第一后台服务器发送更新请求之后，所述方法还包括：

若在接收所述目标应用更新数据包的过程中接收到停止下载信号，则停止下载所述目标应用更新数据包，并删除已下载数据，所述停止下载信号的触发方式包括如下至少一种：电量不足、存储空间不足、网络切换和下载异常。

11.根据权利要求7至9任一所述的方法，其特征在于，所述通过所述预下载应用程序向第一后台服务器发送更新请求之后，所述方法还包括：

若所述目标应用程序在接收所述目标应用更新数据包的过程中启动，则停止下载所述目标应用更新数据包，并删除已下载数据；

通过所述目标应用程序从所述第二后台服务器处下载所述目标应用更新数据包。

12.根据权利要求7至9任一所述的方法，其特征在于，所述方法还包括：

通过所述预下载应用程序中的SDK，向所述中间服务器发送反馈信息，所述反馈信息包括下载成功反馈和下载失败反馈中的至少一种，所述中间服务器用于将所述反馈信息发送至所述第二后台服务器。

13.一种应用程序更新装置，其特征在于，所述装置用于第一后台服务器，所述第一后台服务器是终端中安装的预下载应用程序的后台服务器，所述装置包括：

第一接收模块，用于接收中间服务器发送的目标应用程序的应用更新信息，所述应用更新信息是所述中间服务器从第二后台服务器处查询得到，所述第二后台服务器是所述目标应用程序的后台服务器；

第一下载模块，用于根据所述应用更新信息，从所述第二后台服务器处下载并存储应用更新数据包；

第一发送模块，用于当接收到所述终端通过所述预下载应用程序发送的更新请求时，向所述终端发送目标应用更新数据包，所述终端用于在所述目标应用程序启动过程中，读取并安装所述目标应用更新数据包。

14.一种应用程序更新装置，其特征在于，所述装置用于终端，所述终端中安装有目标应用程序和预下载应用程序，所述装置包括：

第二发送模块，用于通过所述预下载应用程序向第一后台服务器发送更新请求，所述第一后台服务器是所述预下载应用程序对应的后台服务器；

第二接收模块，用于接收并存储所述第一后台服务器发送的目标应用更新数据包，所述目标应用更新数据包是所述第一后台服务器根据中间服务器发送的应用更新信息从第二后台服务器处下载得到，所述应用更新信息由所述中间服务器从所述第二后台服务器处查询得到所述第二后台服务器是所述目标应用程序的后台服务器；

更新模块，用于在所述目标应用程序启动过程中，读取并安装所述目标应用更新数据包。

15.一种服务器，其特征在于，所述服务器包括处理器和存储器；所述存储器存储有至少一条指令，所述至少一条指令用于被所述处理器执行以实现如权利要求1至6任一所述的应用程序更新方法。

16.一种终端，其特征在于，所述终端包括处理器和存储器；所述存储器存储有至少一条指令，所述至少一条指令用于被所述处理器执行以实现如权利要求7至12任一所述的应用程序更新方法。

17.一种计算机可读存储介质，其特征在于，所述存储介质存储有至少一条指令，所述至少一条指令用于被处理器执行以实现如权利要求1至6任一所述的应用程序更新方法，或者，实现如权利要求7至12任一所述的应用程序更新方法。

18.一种应用程序更新系统，其特征在于，所述系统中包含安装有目标应用程序和预下载应用程序的终端、第一后台服务器、第二后台服务器和中间服务器，所述第一后台服务器是所述预下载应用程序的后台服务器，所述第二后台服务器是所述目标应用程序的后台服务器；

所述中间服务器，用于从所述第二后台服务器处查询所述目标应用程序的应用更新信息；向所述第一后台服务器发送所述应用更新信息；

所述第一后台服务器，用于接收所述中间服务器发送的所述应用更新信息；根据所述应用更新信息，从所述第二后台服务器处下载并存储应用更新数据包；

所述终端，用于向所述第一后台服务器发送更新请求；接收并存储所述第一后台服务器发送的目标应用更新数据包；在所述目标应用程序启动过程中，读取并安装所述目标应用更新数据包。