CN105871600A - 应用程序的升级包检测方法和服务器、升级方法和*** - Google Patents

Abstract

本发明公开了一种应用程序的升级包检测方法和服务器、升级方法和***，该方法包括服务器接收来自客户端发送的应用程序参数信息，应用程序参数包括应用程序的包名，根据接收到的包名获取对应的应用程序ID，以及根据应用程序ID从第三方应用供应商中获取与应用程序对应的升级包，将获取到的升级包反馈回给客户端；通过本发明的实施，服务器通过接收客户端发送的应用程序的包名获取应用程序ID，根据应用程序ID直接从第三方应用供应商中获取升级包，实现了通过应用程序的包名与第三方应用供应商建立连接关系进行快速连接查询，从而缩短了客户端在更新应用程序时的时间周期，也提高了查询的效率和性能。

Description

应用程序的升级包检测方法和服务器、升级方法和***

技术领域

本发明涉及应用程序领域，尤其涉及一种应用程序的升级包检测方法和服务器、升级方法和***。

背景技术

应用商店中的一个重要功能是对应用程序的升级检测，由于每个用户在客户端上一般都安装三位数以上的应用程序，这时，如果需要对这些应用程序进行升级时，通过现有的服务器对客户端上的应用程序进行升级包检测会需要很长的时间周期。

现有的升级应用程序的方法是通过搜索引擎来进行搜索检测，该搜索引擎检索是需要根据用户从客户端上输入对应的应用程序的信息或信息列表，搜索引擎在根据对应的信息从为搜索引擎配置的数据库中查询到对应的应用程序的最新升级包，并下载反馈回去给客户端。

但是通过该种方式进行查询更新时，对于搜索引擎的数据库中不存在最新的升级包时，服务器需要等待数据库从第三方应用供应商中获取应用程序的升级包对数据库的应用程序升级包进行更新后才能获取，而该数据库的更新和采集的时间周期比较长，一般都几十分钟，甚至半个小时分钟以上。

随着用户对客户端的体验度越来越高，而现有的通过搜索引擎的更新方式已经不能满足用户的要求了。例如，当用户需要更新升级一个应用程序时，搜索引擎需要在其数据库更新完毕后，才能获取到升级包并发送给客户端，由于数据库的更新周期过长，导致了部分应用程序的升级包不能及时的被服务器获取到，从使得用户无法及时的获取到应用程序的升级信息。

发明内容

本发明的主要目的在于提出一种应用程序的升级包检测方法和服务器、升级方法和***，旨在解决通过现有的更新方式对客户端的应用程序进行升级检测的时间过长，用户不能及时获取客户端上应用程序的升级信息的技术问题。

为实现上述目的，本发明提供的一种服务器，包括：

接收模块，用于接收客户端发送的应用程序参数信息，所述应用程序参数包括应用程序的包名；

获取模块，用于根据应用程序的包名获取对应的应用程序ID，以及根据所述应用程序ID从第三方应用供应商中获取与应用程序对应的升级包；

发送模块，用于将升级包发送至客户端进行升级处理。

在本发明的另一实施例中，应用程序参数信息包括应用程序的校验码，获取模块包括：

查询子模块，用于根据应用程序的包名到内存哈希表中查询是否存在与应用程序的包名相对应的应用程序ID；若不存在，根据应用程序的包名到数据库中查询是否存在与应用程序的包名相对应的应用程序ID；以及用于根据应用程序ID到数据库哈希表中查询应用程序的新版本号；

获取子模块用于根据新版本号以及校验码从第三方应用供应商中获取应用程序的升级包。

在本发明的另一实施例中，服务器还包括：设置模块，用于设置时间戳；时间戳用于从数据库中获取应用程序ID更新内存哈希表中应用程序的包名与应用程序ID之间的对应关系。

在本发明的另一实施例中，升级包包括差分升级包和完整升级包，差分升级包为应用程序的当前版本与新版本的差分升级包，服务器还包括：比较模块，用于在查询子模块根据应用程序ID到数据库哈希表中查询应用程序的新版本号之后，将应用程序的当前版本号与新版本号进行比较；

若所述新版本号比当前版本号高时，获取子模块根据应用程序的当前版本号以及其校验码从第三方应用供应商中获取差分升级包，通过发送模块将差分升级包发送至客户端进行升级处理；

或者，获取子模块根据所述应用程序的新版本号以及其校验码从第三方应用供应商中获取应用程序最新的完整升级包，通过发送模块将完整升级包发送至客户端进行升级处理。

在本发明的另一实施例中，获取模块根据应用程序ID从第三方应用商店中获取升级包之前，还用于判断数据库中对应的应用程序的版本号是否大于客户端上对应的应用程序的当前版本号，若是，则直接从数据库调用升级包对应用程序进行升级处理，若否，则从第三方应用供应商中获取升级包对应用程序进行升级处理。

为实现上述目的，本发明还提出一种应用程序的升级***，包括至少一个客户端和如上所述的服务器，服务器用于检测查询升级包；

服务器用于接收所述至少一个客户端发送的至少一个应用程序参数信息，所述应用程序参数信息包括应用程序的包名；根据接收到的至少一个应用程序的包名作为一个集合获取对应的应用程序ID，以及根据所述应用功能程序ID从第三方应用供应商中获取对应的应用程序的升级包；所述服务器将所述升级包发送至对应的客户端；

所述客户端用于接收所述升级包，并将对应的应用程序进行升级处理。

此外，为实现上述目的，本发明还提出一种应用程序的升级包检测方法，包括以下步骤：

服务器接收客户端发送的应用程序参数信息，应用程序参数包括应用程序的包名；

根据应用程序的包名获取对应的应用程序ID，以及根据应用程序ID从第三方应用供应商中获取与应用程序对应的升级包；

将升级包发送至客户端进行升级处理。

在本发明的另一实施例中，应用程序参数信息包括应用程序的包名及其校验码；

根据应用程序的包名到内存哈希表中查询是否存在与应用程序的包名相对应的应用程序ID；

若内存哈希表中不存在，根据应用程序的包名到数据库中查询是否存在与应用程序的包名相对应的应用程序ID；

根据应用程序ID到数据库哈希表中查询应用程序的新版本号；

根据新版本号以及校验码从第三方应用供应商中获取应用程序的升级包。

在本发明的另一实施例中，所述方法还包括设置时间戳；时间戳用于从数据库中获取应用程序ID更新内存哈希表中应用程序的包名与应用程序ID之间的对应关系。

在本发明的另一实施例中，升级包包括差分升级包和完整升级包，差分升级包为应用程序的当前版本与新版本的差分升级包；

在根据应用程序ID到数据库哈希表中查询应用程序的新版本号之后，还包括将应用程序的当前版本号与新版本号进行比较；

若新版本号比当前版本号高时，根据应用程序的当前版本号以及其校验码从第三方应用供应商中获取差分升级包，将差分升级包发送至客户端进行升级处理；

或者，根据应用程序的新版本号以及其校验码从第三方应用供应商获取应用程序最新的完整升级包，将完整升级包发送至客户端进行升级处理。

在本发明的另一实施例中，在根据所述应用程序ID从所述第三方应用商店中获取升级包之前，还用于判断数据库中对应的应用程序的版本号是否大于客户端上对应的应用程序的当前版本号，若是，则直接从数据库调用升级包对应用程序进行升级处理，若否，则从所述第三方应用供应商中获取对应用程序进行升级处理。

为实现上述目的，本发明还提出应用程序的升级方法，包括：

服务器接收至少一个客户端发送的至少一个应用程序参数信息，应用程序参数信息包括应用程序的包名；根据接收到的至少一个应用程序的包名作为一个集合获取对应的应用程序ID，以及根据应用功能程序ID从第三方应用供应商中获取对应的应用程序的升级包；将所述升级包发送至对应的客户端；

客户端接收所述升级包，并将对应的应用程序进行升级处理。

本发明所提出的一种应用程序的升级包检测方法和服务器、升级方法和***，该服务器包括接收模块接收客户端发送过来的应用程序参数信息，获取模块根据接收模块接收到的应用程序参数信息获取对应的应用程序ID，以及根据所述应用程序ID从第三方应用供应商中获取与应用程序相对应的升级包，发送模块将获取模块获取到的升级包发送至客户端；通过本发明提供的检测方法检测升级包，服务器通过应用程序参数信息中的包名与第三方应用供应商建立快速查询路径，使得在检测需要升级的应用程序的最新升级包时，能快速准确地获取到应用程序的升级包，实现了客户端能及时获取到应用程序的升级信息，通过客户端上的应用程序自身的信息获取升级包，缩短了客户端对应用程序升级时的时间周期，也提高了对应用程序升级信息的查询效率和查询的正确性。

进一步的，通过应用程序的包名从服务器的内存哈希表中查询应用程序ID，根据应用程序ID从数据库哈希表中查询与应用程序对应的新版本号，根据新版本号和校验码从第三方应用供应商中获取升级包，使得客户端通过应用程序ID实现了与服务器中的内存哈希表以及第三方应用供应商之间的快速连接查询，从而缩短了客户端在更新应用程序时的时间周期，也提高了查询的效率和性能；另外，本发明还设置了时间戳对哈希表中应用程序的包名与应用程序ID之间的对应关系进行更新，进一步提高了查询性能和正确性。

附图说明

图1为实现本发明各个实施例的客户端一个可选的硬件结构示意图；

图2为如图1所示的客户端的无线通信***示意图；

图3为本发明第一实施例提供的服务器的模块示意图；

图4为本发明第二实施例提供的服务器的模块示意图；

图5为本发明第三实施例提供的应用程序的升级包检测方法流程图；

图6为本发明第四实施例提供的应用程序的升级包检测方法流程图；

图7为本发明提供的更新内存哈希表中应用程序的包名与应用程序ID的对应关系的流程图；

图8为本发明提供的对于多个应用程序同时进行升级包检测的处理流程图；

图9为本发明第五实施例提供的应用程序的升级***的模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

现在将参考附图描述实现本发明各个实施例的客户端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，“模块”与“部件”可以混合地使用。

客户端可以以各种形式来实施。例如，本发明中描述的客户端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置等等的客户端以及诸如数字TV、台式计算机等等的固定终端。下面，假设客户端是移动终端。然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的客户端。

图1为实现本发明各个实施例的客户端一个可选的硬件结构示意图。

客户端100可以包括无线通信单元110、用户输入单元120、输出单元130、存储器140、接口单元150、控制器160和电源单元170等等。图1示出了具有各种组件的客户端，但是应理解的是，并不要求实施所有示出的组件。可以替代地实施更多或更少的组件。将在下面详细描述客户端的元件。

无线通信单元110通常包括一个或多个组件，其允许客户端100与无线通信***或网络之间的无线电通信，将客户端100中需要升级的应用程序参数信息发送出去。例如，无线通信单元110可以包括移动通信模块111、无线互联网模块112、短程通信模块113中的至少一个，客户端通过无线通信单元110将客户端100上需要进行升级处理的应用程序的相关信息以无线信号的形式发送至服务器上，再有服务器根据客户端发送的内容进行查询处理，获取升级包。

所述客户端100具体通过无线通信单元110中的移动通信模块111将客户端上的应用程序参数信息转换成无线电信号发送到服务器基站、外部网络接入终端以及服务器中的至少一个无线电信号的接收终端，所述服务器基站可以为移动通信互联网***中的某个接入点、节点B等等。这样的无线电信号可以包括应用程序参数转换成的语音信号、文本消息等等各种类型的数据信号。

无线互联网模块112支持客户端的无线互联网接入。该模块可以内部或外部地耦接到终端。该模块所涉及的无线互联网接入技术可以包括WLAN(无线LAN)(Wi-Fi)、Wibro(无线宽带)、Wimax(全球微波互联接入)、HSDPA(高速下行链路分组接入)等等。客户端100在将应用程序参数信息发送给服务器时，可以直接通过无线互联网模块112与服务器实现网络传输连接，然后在将应用程序参数信息通过互联网传输至服务器。

短程通信模块113是用于支持短程通信的模块。短程通信技术的一些示例包括蓝牙^TM、射频识别(RFID)、红外数据协会(IrDA)、超宽带(UWB)、紫蜂^TM等等。当客户端与服务器之间是通过蓝牙、射频等通信方式进行通信时，客户端将通过短程通信模块113将应用程序参数转换成无线射频信号，然后在由短程通信模块113将其无线射频信号发送至服务器上。

在客户端将应用程序参数信息发送出去之前，所述客户端需要通过用户输入单元120根据用户输入的命令生成对应格式的输入数据以控制客户端的各种操作。用户输入单元120允许用户输入各种类型的信息，并且可以包括键盘、锅仔片、触摸板(例如，检测由于被接触而导致的电阻、压力、电容等等的变化的触敏组件)、滚轮、摇杆等等。特别地，当触摸板以层的形式叠加在显示单元131上时，可以形成触摸屏。可选的，在本发明中，用户通过用户输入单元120将需要升级的应用程序信息输入到客户端中，客户端根据输入的应用程序信息检测客户端上对应的版本号和校验码等等的参数信息。

接口单元150用作至少一个外部装置与客户端100连接可以通过的接口。例如，外部装置可以包括有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口等等。识别模块可以是存储用于验证用户使用客户端100的各种信息并且可以包括用户识别模块(UIM)、客户识别模块(SIM)、通用客户识别模块(USIM)等等。另外，具有识别模块的装置(下面称为“识别装置”)可以采取智能卡的形式，因此，识别装置可以经由端口或其它连接装置与客户端100连接。接口单元150可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到客户端100内的一个或多个元件或者可以用于在客户端和外部装置之间传输数据，例如，本发明中的当服务器查询获取到对应的应用程序的升级包后，需要通过与客户端连接的外部装置或接口将所述升级包发送回给客户端，客户端再根据升级包升级对应的应用程序。

另外，当客户端100与外部底座连接时，接口单元150可以用作允许通过其将电力从底座提供到客户端100的路径或者可以用作允许从底座输入的各种命令信号通过其传输到客户端的路径。从底座输入的各种命令信号或电力可以用作用于识别客户端是否准确地安装在底座上的信号。输出单元150被构造为以视觉、音频和/或触觉方式提供输出信号(例如，音频信号、视频信号、警报信号、振动信号等等)。输出单元130可以包括显示单元131等等。

显示单元131可以显示在客户端100中处理的信息。例如，当客户端100处于升级应用程序时，显示单元131可以显示进行应用程序升级的相关的用户界面(UI)或图形用户界面(GUI)。

同时，当显示单元131和触摸板以层的形式彼此叠加以形成触摸屏时，显示单元131可以用作输入装置和输出装置，通过输入装置将客户端100中需要进行升级的应用程序信息输入客户端中，客户端再检测查询更详细的参数信息通过输出装置输出给服务器。显示单元131可以包括液晶显示器(LCD)、柔性显示器、三维(3D)显示器等等中的至少一种。这些显示器中的一些可以被构造为透明状以允许用户从外部观看，这可以称为透明显示器，典型的透明显示器可以例如为TOLED(透明有机发光二极管)显示器等等。根据特定想要的实施方式，客户端100可以包括两个或更多显示单元(或其它显示装置)，例如，客户端可以包括外部显示单元(未示出)和内部显示单元(未示出)。触摸屏可用于检测触摸输入压力以及触摸输入位置和触摸输入面积来将相关的信息输入到客户端中。

存储器140可以存储由控制器160执行的处理和控制操作的软件程序等等，或者可以暂时地存储己经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频等等)。

存储器140可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等等。而且，客户端100可以与通过网络连接执行存储器140的存储功能的网络存储装置协作，在本发明中，客户端可以通过存储器140将客户端上安装的应用程序的参数信息存储在存储器140中，若客户端需要对应用程序进行升级时，客户端可以直接从存储器140中查询获取到对应的应用程序的参数信息，将其发送至服务器中检测升级包。

控制器160通常控制客户端的总体操作。例如，控制器160执行数据通信、视频通话等等相关的控制和处理。控制器160可以执行模式识别处理，以将在触摸屏上执行的手写输入或者图片绘制输入识别为字符或图像，同时根据输入的信息将客户端上需要升级的应用程序的参数信息查询出来。

电源单元170在控制器160的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。

这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施，这里描述的实施方式可以通过使用特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑装置(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在控制器160中实施。对于软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储器140中并且由控制器160执行，也可以通过客户端将应用程序的相关信息存储在存储器140中，再由控制器160控制客户端读取对应的应用程序的参数信息。

至此，己经按照其功能描述了客户端。下面，为了简要起见，将描述诸如折叠型、直板型、摆动型、滑动型客户端等等的各种类型的客户端，其中以滑动型客户端作为示例。但是本发明能够应用于任何类型的客户端，并且不限于滑动型客户端。

如图1中所示的客户端100可以被构造为利用经由帧或分组发送数据的诸如有线和无线通信***以及基于卫星的通信***来操作。

请参考图2，图2描述的是根据本发明的客户端能够操作的通信***。

这样的通信***可以使用不同的空中接口和/或物理层。例如，由通信***使用的空中接口包括例如频分多址(FDMA)、时分多址(TDMA)、码分多址(CDMA)和通用移动通信***(UMTS)(特别地，长期演进(LTE))、全球移动通信***(GSM)等等。作为非限制性示例，下面的描述涉及CDMA通信***，但是这样的教导同样适用于其它类型的***。

如图2所示，CDMA无线通信***可以包括多个客户端100、多个基站(BS)270、基站控制器(BSC)275和移动交换中心(MSC)280。MSC280被构造为与公共电话交换网络(PSTN)290形成接口。MSC280还被构造为与可以经由回程线路耦接到基站270的BSC275形成接口。回程线路可以根据若干己知的接口中的任一种来构造，所述接口包括例如E1/T1、ATM，IP、PPP、帧中继、HDSL、ADSL或xDSL。将理解的是，如图2中所示的***可以包括多个BSC275。

每个BS270可以服务一个或多个分区(或区域)，由多向天线或指向特定方向的天线覆盖的每个分区放射状地远离BS270。或者，每个分区可以由用于分集接收的两个或更多天线覆盖。每个BS270可以被构造为支持多个频率分配，并且每个频率分配具有特定频谱(例如，1.25MHz,5MHz等等)。

分区与频率分配的交叉可以被称为CDMA信道。BS270也可以被称为基站收发器子***(BTS)或者其它等效术语。在这样的情况下，术语"基站"可以用于笼统地表示单个BSC275和至少一个BS270。基站也可以被称为"蜂窝站"。或者，特定BS270的各分区可以被称为多个蜂窝站。

如图2中所示，射频发射器(RF)295将射频无线信号发送给在***内操作的客户端100。如图1中所示的移动通信模块111被设置在客户端100处以接收由RF295发送的射频无线信号。在图2中，示出了几个全球定位***(GPS)卫星300。卫星300帮助定位多个客户端100中的至少一个。

在图2中，描绘了多个卫星300，但是理解的是，可以利用任何数目的卫星获得有用的定位信息。假如图1中所示的客户端设置有GPS模块时，可以与卫星300配合以获得用户想要或者目前所处的位置信息。也可以使用该卫星300跟踪客户端的位置。另外，至少一个GPS卫星300可以选择性地或者额外地处理卫星DMB传输。

作为无线通信***的一个典型操作，BS270接收来自各种客户端100的反向链路信号。客户端100通常参与消息收发和其它类型的通信。特定基站270接收的每个反向链路信号被在特定BS270内进行处理。获得的数据被转发给相关的BSC275。BSC提供通话资源分配和包括BS270之间的软切换过程的协调的移动管理功能。BSC275还将接收到的数据路由到MSC280，其提供用于与PSTN290形成接口的额外的路由服务。类似地，PSTN290与MSC280形成接口，MSC与BSC275形成接口，并且BSC275相应地控制BS270以将正向链路信号发送到客户端100。

基于上述移动终端的硬件结构，提出本发明的服务器，该服务器包括接收模块接收客户端发送的应用程序的参数信息，获取模块根据该参数信息获取对应的升级包，最后通过发送模块将升级包发送给客户端进行升级处理，实现了应用程序的升级检测，使得所述服务器在检测需要升级的应用程序的最新升级包时，能快速准确地获取到所述应用程序的升级包，实现了客户端能及时获取到应用程序的升级信息，通过客户端上的应用程序自身的信息获取升级包，既提高了对应用程序升级信息的查询效率，又保证了查询的正确性。

基于上述客户端硬件结构以及通信***，提出本发明方法和装置的各个实施例。

第一实施例：

如图3所示，本发明第一实施例提出一种服务器的模块示意图，所述服务器用于为客户端提供应用程序升级服务的服务器，所述服务器30包括依次连接的接收模块301、获取模块302和发送模块303，其中：

接收模块301，用于接收客户端发送的应用程序参数信息。

在本实施例中，当所述客户端触发发送应用程序的参数信息后，所述服务器中的接收模块301开始接收来自与所述客户端发送过来的应用程序参数信息，所述参数信息包括有所述应用程序的包名、所述客户端当前的应用程序的版本号或者所述客户端所有安装的应用程序的版本号和所述应用程序对应的校验码。可以理解的是，本发明各个实施例中的数据库可以为Redis缓存数据库，数据表可以为对应的Redis哈希表，第三方应用供应商也可是Redis缓存数据库。

可选的，客户端100从自身的存储器140中获取到需要升级的应用程序的参数信息，并通过自身的无线通信单元110将需要升级的应用程序参数信息发送给服务器30的接收模块301，所述接收模块301接收到客户端100发送过来的参数信息后，触发服务器30进行查询等操作。

获取模块302，用于根据所述应用程序的包名获取对应的应用程序ID，以及根据所述应用程序ID从第三方应用供应商中获取与所述应用程序对应的升级包。

在本实施例中，所述获取模块302在接收模块301获取到应用程序的参数信息后，所述获取模块302具体的根据所述应用程序的包名到内存哈希表中查询与所述应用程序对应的应用程序ID，然后根据所述应用程序ID在数据库哈希表中查询对应的应用程序的版本号，最后，根据所述查询到的版本号以及校验码从第三方应用供应商中获取最新版本的应用程序的升级包；在数据库哈希表中查询的过程中，若查询到对应的版本号比所述应用程序当前版本号高的，则说明查询到的该应用程序的版本号是最新的版本号，反之则说明该应用程序在当前时间段并不需要更新或者查询不到新的版本。可理解的是，上述的获取模块302具体是通过应用程序ID从Redis哈希表中查询版本号，根据所述版本号以及校验码到Redis缓存数据库中获取升级包。

在本实施例中，除了可以直接从第三方应用供应商中获取升级包之外，还可以直接从数据库中获取升级包，该数据库实现有的memcached数据库，但是由于从数据库中获取不存在的升级包时，需要进行等待数据库的自动刷新，为了解决该问题，本实施例通过所述获取模块302判断数据库中对应的应用程序的版本号是否大于客户端上对应的应用程序的当前版本号，若是，则直接从数据库调用升级包对应用程序进行升级处理，若否，则从第三方应用供应商中获取升级包对应用程序进行升级处理；当数据库中存在新版本的升级包时，可以直接从数据库中获取，这时可以理解的是，第三方应用供应商就是Redis缓存数据库，使得服务器可以选择的先从数据库中获取还是直接从第三方应用供应商中获取，从而提高了对应用程序升级查询时的查询性能以及效率。

发送模块303，用于将所述升级包发送至所述开户端进行升级处理。可选的，所述发送模块303与客户端100的无线通信单元110建立无线通信或者互联网通信，所述发送模块303将所述升级包通过无线通信信道或者互联网发送至库护短100的无线通信单元110上。

第二实施例：

如图4所示，为本发明实施例提供的服务器的模块示意图，在本实施例中，所述获取模块302包括查询子模块3021和获取子模块3022；

查询子模块3021用于根据所述应用程序的包名查询所述应用程序ID，其中，在本实施例中，在查询应用程序ID时，具体的是所述查询子模块3021是从内存哈表中查询，所述内存哈希表是用于存储有应用程序的包名与应用程序ID之间的对应关系的关系表，在实际的开发过程中，通过哈希表记录查询应用程序ID是完全可以的，因为其占用的内存是服务器或者客户端存储器完全可以接受的，并且在内存哈希表中的存储的对应关系可以认为是固定的在该哈希表中其应用程序的包名与应用程序ID的关系唯一的；进一步的，在查询到应用程序ID后，再根据应用程序ID在数据库哈希表(即是Redis哈希表)中查询是否存在与所述应用程序对应的新版本号，若存在，所述获取子模块3022根据所述新版本号和校验码到第三方应用供应商中获取升级包，可选的，具体的是从Redis缓存数据库中获取所述应用程序的升级包。

在本实施例中，所述查询子模块3021具体用于根据所述应用程序的包名查询存于所述服务器30上的内存哈希表中是否存在与所述包名对应的应用程序ID；若不存在，则所述查询子模块3021继续从数据库中查询，若存在，则获取所述应用程序ID。

为了实现内存哈希表中应用程序的包名与应用程序ID之间对应关系能实时更新，因为内存哈希表中存储的内容是有限的，对于不常用的或者不用的应用程序的信息会进行适当的清除，空出空间存储一些常用的应用程序的信息，因此，本实施例提供的服务器30还设置了设置模块305，所述设置模块305用于设置时间戳；所述时间戳用于从所述数据库中获取应用程序ID更新内存哈希表中应用程序的包名与应用程序ID之间的对应关系。值得说明的是设置时间戳就是为了能定时自动更新内存哈希表中应用程序的包名与应用程序ID的对应关系。

在本实施例中，在所述查询子模块3021查询内存哈希表中存在与所述包名对应的应用程序ID之后，还可以对所述应用程序ID进行判断，判断所述应用程序ID是否大于0；若否，通过判断所述时间戳的到来进行自动更新所述应用程序的包名对应的应用程序ID的值。

若所述查询子模块3021查询数据库中不存在与所述包名对应的应用程序ID，所述设置模块305将所述应用程序ID置为0，所述设置模块305设置所述时间戳用于更新所述应用程序ID。另外设置所述时间戳也方便了在下次进行应用程序ID查询时，通过判断该时间戳是否超时，若超时，则直接到数据库中查询即可，避免了通过等待第一时间戳自动更新会造成时间过长的情况

在本实施例中，所述升级包包括所述应用程序的当前版本与新版本的差分升级包和完整升级包；所述比较模块304将所述应用程序的当前版本号与所述新版本号进行比较时，若所述新版本号比所述当前版本号高时，所述获取子模块根据所述应用程序的当前版本号以及校验码从第三方应用供应商(即是Redis数据库)中获取所述应用程序的所述差分升级包的信息，通过所述发送模块将所述差分升级包发送至所述客户端进行升级处理；或者，所述获取子模块根据所述应用程序的新版本号以及校验码获取所述应用程序最新的完整升级包的信息，通过所述发送模块将所述最新的完整升级包发送至所述客户端进行升级处理。

在本实施例中，当所述客户端存在多个应用程序需要同时进行升级处理时，所述客户端将多个应用程序的参数信息发送至所述服务器30，所述接收模块301接收多个应用程序参数信息，所述查询子模块3021根据接收的多个应用程序ID和版本号依次在内存哈希表和Redis缓存数据库中查询，然后根据查询的结果以及多个应用程序的校验码获取各应用程序对应的所述升级包，若所述比较校验码一致，则获取所述升级包发送至所述客户端进行升级处理。这样，既能保证查询的性能，又能保证查询的正确性。

在本实施例中，所述查询子模块3021还可以将多个应用程序ID和版本号作为一个集合进行查询，具体的在获取差分升级包时，将多个应用程序ID与版本号作为一个集合进行查询，在获取差分升级包时也一起同时获取多个，这样可以通过减少网络的请求次数来提高查询的性能，也即是实现Redis哈希表的多键查询功能。

第三实施例：

参照图5，图5为本实施例提供的应用程序升级包检测方法流程图，该方法包括以下步骤：

S501，服务器接收客户端发送的应用程序参数信息；

在本实施例中，服务器检测应用程序的升级信息时，客户端传给服务器的参数信息包括应用程序的包名、当前安装应用程序的版本号与其校验码。

值得说明的是，这里的参数信息可以是通过一个存储器进行统一的存储，也可以分开存储，在本实施例中，参数信息均可存储在客户端上的存储器中，然后客户端在从存储器中查询出对应的应用程序的参数信息发送至服务器。

S502，根据应用程序的包名获取对应的应用程序ID，以及根据应用程序ID从第三方应用供应商中获取与应用程序对应的升级包；

在本实施例中，服务器首先要根据应用程序的包名获取应用程序ID，然后再去获取该应用程序下最新版本的版本号，如果版本号比客户端传入的版本号高，则表示有更新版本。这时候，再用当前安装版本的版本号及检验码等信息去查询差分升级包的信息；如果差分升级包不存在，则去获取应用最新完整包的信息。

具体的，根据应用程序的包名到内存哈希表中查询是否存在与应用程序的包名相对应的应用程序ID；若内存哈希表中不存在，根据应用程序的包名到数据库中查询是否存在与应用程序的包名相对应的应用程序ID；根据应用程序ID到数据库哈希表中查询应用程序的新版本号；根据新版本号以及校验码从第三方应用供应商中获取应用程序的升级包。

进一步的，在本实施例中，应用程序ID通过内存哈希表来查询获取，在内存哈希表中存储有应用程序的包名与应用程序ID之间的对应关系，通过查询该对应关系即可获取到应用程序对应的应用程序ID。

在本实施例中，方法还包括：设置时间戳；时间戳用于从数据库中获取应用程序ID更新内存哈希表中应用程序的包名与应用程序ID之间的对应关系。内存哈希表是用于存储有应用程序的包名与应用程序ID之间的对应关系的关系表，在实际的开发过程中，通过哈希表记录查询应用程序ID是完全可以的，因为其占用的内存是服务器或者客户端存储器完全可以接受的，并且在内存哈希表中的存储的对应关系可以认为是固定的在该哈希表中其应用程序的包名与应用程序ID的关系唯一的；因此，通过设置时间戳来实时更新获取客户端应用程序的包名与应用程序ID的对应关系，使得在进行升级查询时，能快速地准确查询到对应的应用程序升级包信息。

S503，将升级包发送至客户端进行升级处理。

在本实施例提供的升级包检测方法中，获取的升级包具体包括两种类型的升级包，一种是差分升级包，该差分升级包指的是由应用程序的当前版本与获取到的最新版本之间的差异部分所组成的升级包；另一种是完整的升级包；服务器在获取升级包之前还包括：将应用程序的当前版本号与所述新版本号进行比较。

若新版本号比当前版本号高时，根据应用程序的当前版本号以及其校验码从第三方应用供应商中获取所述差分升级包，将差分升级包发送至客户端进行升级处理。

此外，服务器还可以根据应用程序的新版本号以及其校验码从第三方应用供应商中获取应用程序最新的完整升级包，将完整升级包发送至客户端进行升级处理。

在本实施例中，方法还包括：在从第三方应用商店中获取升级包之前，判断数据库中对应的应用程序的版本号是否大于客户端上对应的应用程序的当前版本号，若是，则直接从数据库调用升级包对应用程序进行升级处理，若否，则从第三方应用供应商中获取对应用程序进行升级处理。

第四实施例：

如图6所示，为本实施例提供的应用程序升级包检测方法流程图，其包括如下步骤：

S601，检测客户端发送的应用程序参数信息；参数信息包括应用程序的包名、当前安装应用程序的版本号与其校验码等。

S602，对应用程序参数信息进行解析，得到应用程序的包名、版本号和校验码；

S603，根据应用程序的包名获取对应的应用程序ID；

S604，根据应用程序ID获取应用程序的最新版本号；

S605，判断最新版本号是否大于客户端输入的应用程序的当前版本号；若是，则执行步骤S606，否则，查询结束；

S606，根据应用程序的最新版本号、ID和校验码获取对应的差分升级包；

S607，判断差分升级包是否存在，若不存在，执行步骤S608；反之，执行步骤S609；

在本实施例中，升级包具体包括应用程序的当前版本与新版本的差分升级包和完整升级包；差分升级包为应用程序的当前版本与新版本之间的差异的功能部分所组成的升级安装包。

若查询Redis哈希表中存在应用程序的新版本号时，将应用程序的当前版本号与新版本号进行比较；

若新版本号比当前版本号高时，根据应用程序的当前版本号以及校验码从Redis数据库中获取应用程序的差分升级包的信息，将差分升级包发送至客户端进行升级处理；否则，执行步骤S608。

S608，返回获取完整的最新升级包信息；

在本步骤中，在判断Redis数据库中不存在差分升级包时，则执行获取完整升级包，具体根据应用程序的新版本号以及校验码获取应用程序最新完整升级包的信息，将最新完整升级包发送至客户端进行升级处理。

S609，返回获取差分升级包信息；差分升级包具体为应用程序当前版本的功能与最新版本之间的差异的功能部分所组成的升级安装包。

S610，更新检测结束。

在本实施例中，应用程序参数信息包括应用程序的包名、应用程序的当前版本号和校验码；服务器根据应用程序的包名在内存哈希表中查询是否存在应用程序ID，若存在，在判断应用ID是否大于0，若大于，则获取应用程序ID；若小于，则等待判断时间戳的到来进行自动更新内存哈希表中的应用程序的包名与应用程序ID的对应关系。

若服务器根据包名查询内存哈希表中不存在对应的应用程序ID时，则执行从数据库中查询，若数据库中存在，则直接获取应用程序ID，并将应用程序ID写入内存哈希表与包名对应的应用程序ID中；若数据库中也不存在，则将该应用程序ID置为0，并设置时间戳来进行更新应用程序ID，同时也为下次查询时，可以通过判断该时间戳是否超时，若超时，则直接到数据库中再次查询。

如图7所示，为本实施例提供的更新内存哈希表中应用程序的包名与应用程序ID的对应关系的流程图，其具体步骤包括：

S701，获取应用程序的包名对应的应用程序ID；

S702，根据应用程序的包名去内存哈希表中获取应用程序ID；

在一些实施例中，内存哈希表存储的是客户端中应用程序的包名与应用程序ID的对应关系，该对应关系是唯一的，因为每个应用程序在客户端中的应用程序ID是相同的，不管是版本有多高，例如：内存哈希表中存储有5个应用程序的相关信息，其中，“QQ”对应的应用程序ID是1、“微信”对应的应用程序ID是2、“微博”对应的应用程序ID是3、“腾讯视频”对应的应用程序ID是4、“搜狐新闻”对应的应用程序ID是0，因此，根据接收到客户端发送的包名查询对应的ID，如，接收的应用程序的包名是“QQ”，则到内存哈希表中查询到“QQ”后，根据其对应关系直接获取到“QQ”的应用程序ID是1；如果在内存哈希表中查询不到，则到数据库中查询，在数据库中查询对应的应用程序ID的方式与在内存哈希表中查询的方式是一样的，这里就不在列举赘述了。

S703，判断内存哈希表中是否存在应用程序ID，若是则执行S704，反之，执行S707；例如：客户端发送的应用程序的包名是“土豆视频”，而通过查询内存哈希表，其中，并没有“土豆视频”的信息，则表明内存哈希表中不存在应用程序的包名为“土豆视频”的应用程序ID。

S704，判断应用程序ID是否大于0，若是，则执行S705，否则，执行S706；

可选的，在内存哈希表中存储有应用程序包名与应用程序ID的对应关系，但是其可能并没有对应的应用功能程序ID，例如：在内存哈希表中存有“搜狐新闻”的对应关系，但是其对应的应用程序ID是0，其表示的是虽然有对应的关系但是其应用程序ID小于等于0的，这时，则需要等待通过时间戳来进行更新，或者直接到数据库中查询获取，即是执行步骤S707。

S705，返回应用程序ID并获取；

S706，判断时间戳是否超时需要刷新应用程序ID，若是，则执行S707，反之，执行S705；进一步的，在步骤S704中查询的“搜狐新闻”对应的应用程序ID是0，这时可以有两种方式获取到对应的应用程序ID，一是等待时间戳的到来，服务器自动更新应用程序ID，但是若时间戳超过了仍然没有更新，则执行S707，到数据库中查询获取。

S707，从数据库中根据应用程序的包名获取应用程序ID；

S708，判断是否存在应用程序ID，若是，则执行S709，反之，执行S710；

S709，将包名作为键，应用程序ID作为值写入内存哈希表中；在内存哈希表中查询不到“土豆视频”的应用程序ID，则跳转到数据库中查询，而数据库中查询到其对应的应用程序ID为5，这时为了方便下次再次查询更新升级，将其查询到的信息写入到内存哈希表中。

S710，将包名作为键，应用程序ID标记为0，并设置时间戳；若在数据库中也查询不到“土豆视频”的应用程序ID，则说明“土豆视频”这应用程序部需要更新升级，这时将“土豆视频”的对应关系写入到内存哈希表中，但是其应用程序ID为0，同时设置一个时间戳，通过时间戳来进行自动更新或者在下次继续查询升级包时，可以通过该时间戳来实现快速查询。

S711，应用程序ID获取、更新结束。

在本实施例中，当客户端存在多个应用程序需要同时进行升级处理时，客户端将多个应用程序的参数信息发送至服务器30，服务器接收多个应用程序参数信息，根据接收的多个应用程序ID和版本号依次在内存哈希表和Redis数据库中查询，然后根据查询的结果以及多个应用程序的校验码获取各应用程序对应的升级包，若比较校验码一致，则获取升级包发送至客户端进行升级处理。这样，既能保证查询的性能，又能保证查询的正确性。

在本实施例中，服务器还可以将多个应用程序ID和版本号作为一个集合进行查询，具体的在获取差分升级包时，将多个应用程序ID与版本号作为一个集合进行查询，在获取差分升级包时也一起同时获取多个，这样可以通过减少网络的请求次数来提高查询的性能，也即是实现Redis哈希表的多键查询功能。具体处理步骤如图8所示。

S801，查询应用程序的差分升级包信息；差分升级包具体为应用程序当前版本的功能与最新版本之间的差异的功能部分所组成的升级安装包。

S802，根据应用程序最新版本号和应用程序ID作为一个集合；可选的，当客户端存在多个应用程序同时需要进行升级处理时，客户端将多个应用程序的参数信息同时发送至服务器，服务器在将接收到的多个应用程序的参数信息处理为一个集合，需要说明的是，该集合可以是以数据包的形式存在，例如：客户端有三个应用程序需要升级，分别为“QQ”、“微信”和“微博”，客户端将该三个应用程序的参数信息发送服务器，然后服务器将接收到的参数信息到打包成一个数据包，通过该数据包进行查询。

S803，根据集合从Redis哈希表中查询差分升级包信息；

S804，判断是否存在差分升级包信息；

S805，若是，将差分升级包的校验码与客户端发送的应用程序的校验码进行比较；

S806，判断校验码是否相同；

S807，若是，则返回获取差分升级包信息；

S808，查询结束。

具体的，当客户端需要对三个应用程序同时查询升级时，客户端将这三个应用程序的参数信息发送给服务器，服务器接收到后，根据这三个应用程序的包名分别查询出对应的应用程序ID，然后将三个应用程序ID进行集合处理，一次发送到内存哈希表上进行查询，获取到版本号后再统一下载通过校验码一起进行验证，这样的查询方式避免了一次一次的反复查询，减少了查询时的网络请求次数，也提高了查询的效率，缩短了升级查询的时间周期。

第五实施例：

请参考图9，为本实施例提供的应用程序的升级***的模块示意图，该***包括至少一个客户端40和服务器30，服务器30具体可以为第一实施例中提供的服务器，服务器30通过接收至少一个客户端40发送的至少一个应用程序参数信息，服务器30根据接收到的至少一个应用程序参数信息作为一个集合获取对应的应用程序ID，以及根据应用功能程序ID从第三方应用供应商中获取对应的应用程序的升级包；服务器30将升级包发送至对应的客户端。

客户端接收服务器发送的升级包，根据接收到的升级包对客户端上对应的应用程序进行升级处理。

在本实施例中，应用程序参数信息包括应用程序的包名、应用程序的当前版本号及其校验码，服务器30根据应用程序的包名到内存哈希表中获取对应的应用功能程序ID，根据应用功能程序ID到Redis哈希表中获取应用程序的新版本号，最后再根据新版本号以及校验码从Redis缓存数据库中获取对应的应用程序的升级包，并将升级包发送至对应的客户端进行升级处理。

在一些实施例中，服务器30还可以同时对多个客户端40或者一个客户端40的多个应用程序进行升级处理，其具体的升级包检测过程与升级一个应用程序的方法是一样的，这里就不再重复赘述了。

应用程序的升级***通过采用本发明提供的服务器实现了应用程序的升级检测，使得***在检测需要升级的应用程序的最新升级包时，能快速准确地获取到应用程序的升级包，实现了客户端能及时获取到应用程序的升级信息，通过客户端上的应用程序自身的信息获取升级包，既提高了对应用程序升级信息的查询效率，又保证了查询的正确性。

第六实施例：

在本发明中还提供了一种与应用程序的升级***对应的应用程序升级方法，包括：服务器根据本发明提供的应用程序的升级包检测方法获取至少一个应用程序的升级包；具体的，服务器接收至少一个客户端发送过来的至少一个应用程序参数信息，该应用程序参数信息包括应用程序的包名；根据接收到的至少一个应用程序的包名作为一个集合获取对应的应用程序ID，以及根据应用功能程序ID从第三方应用供应商中获取对应的应用程序的升级包；将所述升级包发送至对应的客户端；

客户端接收所述升级包，并将对应的应用程序进行升级处理。

在本实施例中，通过应用程序的升级包检测方法获取的升级包，因此，也可以实现缩短了客户端在更新应用程序时的时间周期，也提高了查询的效率和性能。

在本实施例中，客户端将所需要进行升级处理的应用程序参数信息发送至服务器上，应用程序参数包括应用程序的包名、当前版本号以及校验码，服务器根据应用程序的包名到内存哈希表中获取对应的应用程序ID，根据应用程序ID从数据库哈希表中获取对应的版本号，判断该新版本号是否大于应用程序的当前版本号，若是，则直接从该数据库中获取与新版本号对应的升级包；若不是，则从第三方应用供应商中获取对应的升级包。

在本实施例中，升级方法还包括同时接收多个客户端发送的应用程序参数信息或者一个客户端发送的多个应用程序参数信息，将该参数信息进行整合处理，例如，整合成一个数据包，再发送至数据库中查询对应的程序的升级包，或者直接到第三方应用供应商中获取升级包。可理解的是，可以到Redis缓存数据库中获取。

综上，本发明提供的服务器和应用程序的升级包检测方法和服务器、升级方法和***，通过接收客户端发送过来的应用程序参数信息中的应用程序的包名，根据接收模块接收到的应用程序的包名获取对应的应用程序ID，并且从第三方应用供应商中获取与应用程序相对应的升级包，将获取模块获取到的升级包发送至客户端；通过客户端上的应用程序参数信息实现与第三方应用供应商之间的快速查询连接，使得客户端能及时获取应用程序的升级信息，能快速准确地获取到应用程序的升级包，从而缩短了客户端在更新应用程序时的时间周期，也提高了查询的效率和性能。

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

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种服务器，其特征在于，包括：

接收模块，用于接收客户端发送的应用程序参数信息，所述应用程序参数包括应用程序的包名；

获取模块，用于根据所述应用程序的包名获取对应的应用程序ID，以及根据所述应用程序ID从第三方应用供应商中获取与应用程序对应的升级包；

发送模块，用于将所述升级包发送至客户端进行升级处理。

2.根据权利要求1所述的服务器，其特征在于，应用程序参数信息还包括应用程序的校验码，所述获取模块包括：

查询子模块，用于根据所述应用程序的包名到内存哈希表中查询是否存在与所述应用程序的包名相对应的应用程序ID；若不存在，根据所述应用程序的包名到数据库中查询是否存在与所述应用程序的包名相对应的应用程序ID；以及用于根据所述应用程序ID到数据库表中查询所述应用程序的新版本号；

获取子模块用于根据所述新版本号以及所述校验码从第三方应用供应商中获取所述应用程序的升级包。

3.根据权利要求2所述的服务器，其特征在于，所述服务器还包括：设置模块，用于设置时间戳；所述时间戳用于从所述数据库中获取应用程序ID更新内存哈希表中应用程序的包名与应用程序ID之间的对应关系。

4.根据权利要求1所述的服务器，其特征在于，所述升级包包括差分升级包和完整升级包，所述差分升级包为应用程序的当前版本与新版本的差分升级包，所述服务器还包括：比较模块，用于在所述查询子模块根据所述应用程序ID到数据库表中查询所述应用程序的新版本号之后，将应用程序的当前版本号与所述新版本号进行比较；

若所述新版本号比当前版本号高时，所述获取子模块根据所述应用程序的当前版本号以及其校验码从第三方应用供应商中获取所述差分升级包，通过所述发送模块将所述差分升级包发送至所述客户端进行升级处理；

或者，所述获取子模块根据所述应用程序的新版本号以及其校验码从第三方应用供应商中获取应用程序最新的完整升级包，通过所述发送模块将所述完整升级包发送至所述客户端进行升级处理。

5.根据权利要求1-4任一项所述的服务器，其特征在于，所述获取模块根据所述应用程序ID从所述第三方应用商店中获取升级包之前，还用于判断数据库中对应的应用程序的版本号是否大于客户端上对应的应用程序的当前版本号，若是，则直接从数据库调用升级包对应用程序进行升级处理，若否，则从所述第三方应用供应商中获取对应用程序进行升级处理。

6.一种应用程序的升级***，其特征在于，包括至少一个客户端和如权利要求1-5任一项所述的服务器，所述服务器用于检测查询升级包；

所述服务器用于接收所述至少一个客户端发送的至少一个应用程序参数信息，所述应用程序参数信息包括应用程序的包名；根据接收到的至少一个应用程序的包名作为一个集合获取对应的应用程序ID，以及根据所述应用功能程序ID从第三方应用供应商中获取对应的应用程序的升级包；所述服务器将所述升级包发送至对应的客户端；

所述客户端用于接收所述升级包，并将对应的应用程序进行升级处理。

7.一种应用程序的升级包检测方法，其特征在于，包括以下步骤：

服务器接收客户端发送的应用程序参数信息，所述应用程序参数包括应用程序的包名；

根据所述应用程序参数的包名获取对应的应用程序ID，以及根据所述应用程序ID从第三方应用供应商中获取与应用程序对应的升级包；

将所述升级包发送至客户端进行升级处理。

8.根据权利要求7所述的应用程序的升级包检测方法，其特征在于，所述升级包包括差分升级包和完整升级包，所述差分升级包为应用程序的当前版本与新版本的差分升级包；

在根据所述应用程序ID到数据库表中查询所述应用程序的新版本号之后，还包括将应用程序的当前版本号与所述新版本号进行比较；

若所述新版本号比当前版本号高时，根据所述应用程序的当前版本号以及其校验码从第三方应用供应商中获取所述差分升级包，将所述差分升级包发送至所述客户端进行升级处理；

或者，根据所述应用程序的新版本号以及其校验码从第三方应用供应商中获取应用程序最新的完整升级包，将所述完整升级包发送至所述客户端进行升级处理。

9.根据权利要求7或8所述的应用程序的升级包检测方法，其特征在于，在根据所述应用程序ID从所述第三方应用商店中获取升级包之前，还用于判断数据库中对应的应用程序的版本号是否大于客户端上对应的应用程序的当前版本号，若是，则直接从数据库调用升级包对应用程序进行升级处理，若否，则从所述第三方应用供应商中获取对应用程序进行升级处理。

10.一种应用程序的升级方法，其特征在于，包括：

服务器接收至少一个客户端发送的至少一个应用程序参数信息，所述应用程序参数信息包括应用程序的包名；根据接收到的至少一个应用程序的包名作为一个集合获取对应的应用程序ID，以及根据所述应用功能程序ID从第三方应用供应商中获取对应的应用程序的升级包；将所述升级包发送至对应的客户端；

所述客户端接收所述升级包，并将对应的应用程序进行升级处理。