客户端软件的更新方法和装置与流程

本申请涉及终端技术领域，尤其涉及一种客户端软件的更新方法和装置。

背景技术：

随着互联网技术的快速发展，越来越多的智能设备走进了人们的生活。人们可以在智能设备中安装各种各样的客户端软件(Application，APP)，以用来满足不同的需求。

客户端软件中通常可以包括多种应用，各应用通常会包括有一些可以保存在本地的离线资源，比如：CSS(Cascading Style Sheets，层叠样式表)文件，JS(JavaScript)文件等。当客户端软件进行更新时，往往需要重新从服务端下载这些离线资源，导致流量消耗较多。

技术实现要素：

有鉴于此，本申请提供一种客户端软件的更新方法和装置。

具体地，本申请是通过如下技术方案实现的：

一种客户端软件的更新方法，应用在服务端，所述方法包括：

获取客户端当前软件的版本信息；

将服务端保存的所述版本信息对应的多个原始文件转换为一个第一当前版本文件；

将最新版本对应的多个新版本文件转换为一个第一目标版本文件；

根据所述第一目标版本文件生成所述第一当前版本文件的增量文件；

将所述增量文件发送给客户端，以供客户端进行更新。

可选的，所述方法还包括：

为所述第一当前版本文件生成第一校验因子；

为所述增量文件生成第二校验因子；

将所述第一校验因子和所述第二校验因子发送给客户端，以供客户端进行校验，并在校验通过时进行更新。

可选的，所述将服务端保存的所述版本信息对应的多个原始文件转换为一个第一当前版本文件，包括：

基于FLAT协议以及预设的排序规则，将服务端保存的所述版本信息对应的多个原始文件转换为一个第一当前版本文件；

所述将最新版本对应的多个新版本文件转换为一个第一目标版本文件，包括:

基于FLAT协议以及所述排序规则，将最新版本对应的多个新版本文件转换为一个第一目标版本文件。

一种客户端软件的更新方法，应用在客户端，所述方法包括：

将本地当前版本目录中的多个原始文件转换为一个第二当前版本文件；

接收服务端发送的增量文件；

将所述增量文件和所述第二当前版本文件合并为第二目标版本文件；

将所述第二目标版本文件分解为多个新版本文件；

用所述多个新版本文件替换所述多个原始文件，以形成目标版本目录。

可选的，所述将所述增量文件和所述第二当前版本文件合并为第二目标版本文件之前，还包括：

接收服务端发送的第一校验因子和第二校验因子；

为所述第二当前版本文件生成第三校验因子；

为所述增量文件生成第四校验因子；

当所述第三校验因子和所述第四校验因子分别与所述第一校验因子和所述第二校验因子相同时，将所述增量文件和所述第二当前版本文件合并为第二目标版本文件。

可选的，所述将本地当前版本目录中的多个原始文件转换为一个第二当前版本文件，包括：

基于FLAT协议以及预设的排序规则，将本地当前版本目录中的多个原始文件转换为一个第二当前版本文件。

可选的，在将所述多个原始文件转换为一个第二当前版本文件时，忽略所述原始文件的特定属性。

一种客户端软件的更新装置，应用在服务端，所述装置包括：

版本获取单元，获取客户端当前软件的版本信息；

第一转换单元，将服务端保存的所述版本信息对应的多个原始文件转换为一个第一当前版本文件；

第二转换单元，将最新版本对应的多个新版本文件转换为一个第一目标版本文件；

增量生成单元，根据所述第一目标版本文件生成所述第一当前版本文件的增量文件；

增量发送单元，将所述增量文件发送给客户端，以供客户端进行更新。

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

第一生成单元，为所述第一当前版本文件生成第一校验因子；

第二生成单元，为所述增量文件生成第二校验因子；

因子发送单元，将所述第一校验因子和所述第二校验因子发送给客户端，以供客户端进行校验，并在校验通过时进行更新。

可选的，所述第一转换单元，具体基于FLAT协议以及预设的排序规则，将服务端保存的所述版本信息对应的多个原始文件转换为一个第一当前版本文件；

所述第二转换单元，具体基于FLAT协议以及所述排序规则，将最新版本对应的多个新版本文件转换为一个第一目标版本文件。

一种客户端软件的更新装置，应用在服务端，所述装置包括：

第三转换单元，将本地当前版本目录中的多个原始文件转换为一个第二 当前版本文件；

增量接收单元，接收服务端发送的增量文件；

增量合并单元，将所述增量文件和所述第二当前版本文件合并为第二目标版本文件；

文件分解单元，将所述第二目标版本文件分解为多个新版本文件；

文件替换单元，用所述多个新版本文件替换所述多个原始文件，以形成目标版本目录。

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

因子接收单元，所述将所述增量文件和所述第二当前版本文件合并为第二目标版本文件之前，接收服务端发送的第一校验因子和第二校验因子；

第三生成单元，为所述第二当前版本文件生成第三校验因子；

第四生成单元，为所述增量文件生成第四校验因子；

所述增量合并单元，具体在所述第三校验因子和所述第四校验因子分别与所述第一校验因子和所述第二校验因子相同时，将所述增量文件和所述第二当前版本文件合并为第二目标版本文件。

可选的，所述第三转换单元，具体基于FLAT协议以及预设的排序规则，将本地当前版本目录中的多个原始文件转换为一个第二当前版本文件。

可选的，所述第三转换单元，具体在将所述多个原始文件转换为一个第二当前版本文件时，忽略所述原始文件的特定属性。

由以上描述可以看出，本申请服务端可以将客户端当前版本与目标版本的增量文件发送给客户端，客户端可以将本地当前版本目录中的多个原始文件转换为一个第二当前版本文件，然后将增量文件与第二当前版本文件进行合并后再分解为多个新版本文件，从而实现对离线文件的增量更新，大大节省了更新过程中的流量消耗。

附图说明

图1是本申请一示例性实施例示出的一种客户端软件的更新方法的流程 示意图。

图2是本申请一示例性实施例示出的另一种客户端软件的更新方法的流程示意图。

图3是本申请一示例性实施例示出的一种用于客户端软件的更新装置的一结构示意图。

图4是本申请一示例性实施例示出的一种客户端软件的更新装置的结构示意图。

图5是本申请一示例性实施例示出的另一种用于客户端软件的更新装置的一结构示意图。

图6是本申请一示例性实施例示出的另一种客户端软件的更新装置的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所 使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

相关技术中，客户端本地缓存的CSS文件、JS文件等离线文件的更新频率较低，当客户端软件升级时，通常会重新从服务端下载上述离线文件，从而消耗了用户大量非必要的流量。

针对上述问题，本申请提供一种客户端软件的更新方案，可以在客户端软件更新时，针对离线文件实现增量更新，从而节省用户流量。

图1是本申请一示例性实施例示出的一种客户端软件的更新方法的流程示意图。

请参考图1，所述客户端软件的更新方法可以应用在服务端，包括有以下步骤：

步骤101，获取客户端当前软件的版本信息。

在本实施例中，服务端可以在发布新版本时，获取客户端当前软件的版本信息，比如：服务端可以获取本地保存的所述版本信息，服务端也可以发送版本查询请求给客户端以获取所述版本信息。

在另一实施例中，客户端也可以主动发送更新请求给服务端，并在所述更新请求中携带客户端当前软件的版本信息，服务端可以从所述更新请求中获取所述版本信息。

步骤102，将服务端保存的所述版本信息对应的多个原始文件转换为一个第一当前版本文件。

基于前述步骤101，服务端在获取到客户端当前软件的版本信息后，可以先获取服务端保存的所述版本信息对应的多个原始文件，比如：服务端可以从非易失性存储器中获取所述版本信息对应的多个原始文件。所述原始文件可以包括：CSS文件、JS文件等。

在本步骤中，服务端可以将所述版本信息对应的多个原始文件转换为一个文件，为便于描述，在本实施例中，将服务端保存的所述版本信息对应的多个原始文件转换后的文件称为第一当前版本文件。

具体地，服务端可以基于FLAT协议以及预设的排序规则，将所述多个原始文件转换为第一当前版本文件。其中，所述FLAT协议为一种自定义的文件协议，用于实现多个文件到一个文件的转换。转换后得到的一个文件由一系列item组成，每个item用于描述转换前的多个文件中的每一个，item的格式通常为：文件的名称+字节数+文件的内容。在本实施例中，转换后的所述第一当前版本文件的每个item可以为：原始文件的名称+字节数+该原始文件的内容。所述排序规则为各个item的先后顺序，所述排序规则可以由开发人员进行设置，比如：所述排序规则可以为文件名称的顺序、文件时间前后的顺序、文件大小的顺序等，本申请对此不作特殊限制。

步骤103，将最新版本对应的多个新版本文件转换为一个第一目标版本文件。

在本实施例中，服务端还可以获取最新版本对应的多个新版本文件，然后将所述多个新版本文件转换为一个文件，为便于区分，将所述多个新版本文件转换后得到的文件成为第一目标版本文件。服务端可以基于FLAT协议以及预设的排序规则将所述多个新版本文件转换为一个第一目标版本文件，具体可以参考前述步骤102的描述，在此不再一一赘述。

步骤104，根据所述第一目标版本文件生成所述第一当前版本文件的增量文件。

基于前述步骤102和103，服务端可以根据所述第一目标版本文件生成所述第一当前版本文件的差量文件，在本实施例中，可以将所述差量文件称为增量文件。

步骤105，将所述增量文件发送给客户端，以供客户端进行更新。

基于前述步骤104，服务端在生成所述增量文件之后，可以将所述增量文件发送给客户端，客户端在接收到所述增量文件之后，可以进行增量的更新。

图2是本申请一示例性实施例示出的另一种客户端软件的更新方法的流程示意图。

请参考图2，所述客户端软件的更新方法可以应用在客户端，包括有以下步骤：

步骤201，将本地当前版本目录中的多个原始文件转换为一个第二当前版本文件。

在本实施例中，客户端本地缓存的CSS文件、JS文件等离线文件通常以目录(也可以称为文件夹)的方式进行保存，一个目录中通常包括有多个文件。

在本步骤中，客户端可以获取本地保存的当前版本目标中的当前版本的多个原始文件，然后可以基于FLAT协议以及与服务端相同的排序规则，将所述本地当前版本目录中的多个原始文件转换为一个文件，在本实施例中，为便于与前述服务端的处理过程进行区分，可以将经由客户端转换后得到的文件称为第二当前版本文件。

可选的，在本申请另一实施例中，客户端在将所述多个原始文件转换为一个第二当前版本文件时，可以忽略所述原始文件的特定属性，以确保后续文件增量更新过程的顺利进展。所述特定属性通常由开发人员进行设置，比如：文件生成时间、文件权限等不影响文件使用的属性。

步骤202，接收服务端发送的增量文件。

在本实施例中，客户端在进行更新时，接收服务端发送的增量文件，比如：客户端可以在发送更新请求后，接收服务端根据所述更新请求返回的增量文件，客户端也可以接收服务端主动推送的增量文件，本申请对此不作特殊限制。所述增量文件由服务端根据客户端当前软件的版本信息生成，具体可以参考前述图1所示的实施例中的描述过程，在此不再一一赘述。

步骤203，将所述增量文件和所述第二当前版本文件合并为第二目标版本文件。

基于前述步骤201和步骤202，客户端可以依据相关技术中提供的文件合并方法，将所述增量文件和所述第二当前版本文件进行合并，以得到第二目标版本文件。

需要说明的是，在本申请中，并不限制前述步骤201和步骤202的执行顺序，在实际应用中，客户端也可以在接收到增量文件后，执行步骤201将将本地当前版本目录中的多个原始文件转换为一个第二当前版本文件，即可以先执行步骤202，然后再执行步骤201。

步骤204，将所述第二目标版本文件分解为多个新版本文件。

基于前述步骤203，客户端通过合并得到所述第二目标版本文件后，可以将所述第二目标版本文件进行分解，以得到多个新版文件。由于所述第二目标版本文件为通过FLAT协议转换后得到的文件，客户端可以根据FLAT文件的构造对所述第二目标版本文件进行分解，比如：将所述第二目标版本文件中的每个item分解为一个新版本文件，从而得到多个新版本文件。

步骤205，用所述多个新版本文件替换所述多个原始文件，以形成目标版本目录。

基于前述步骤204，客户端可以用所述多个新版本文件替换本地当前版本目录中的多个原始文件，进而将本地当前版本目录更新为目标版本目录，实现增量的更新。

由以上描述可以看出，本申请服务端可以将客户端当前版本与目标版本的增量文件发送给客户端，客户端可以将本地当前版本目录中的多个原始文件转换为一个第二当前版本文件，然后将增量文件与第二当前版本文件进行合并后再分解为多个新版本文件，从而实现对离线文件的增量更新，大大节省了更新过程中的流量消耗。

可选的，在本申请另一实施例中，为确保增量更新的顺利进行，本申请还提供有增量更新过程中校验方案。具体地，服务端可以在发送增量文件给客户端的同时发送第一校验因子和第二校验因子给客户端，客户端在根据所述第一校验因子和所述第二校验因子进行校验通过后进行增量更新。

其中，所述第一校验因子由服务端为第一当前版本文件生成，比如：服务端可以采用MD5(Message Digest Algorithm，摘要信息算法)算法为所述第一当前版本文件生成所述第一校验因子，当然，服务端也可以采用其他算 法生成所述第一校验因子，比如：CRC算法(Cyclic Redundancy Check，循环冗余校验)等。所述第二校验因子由服务端为增量文件生成，服务端可以采用与生成第一校验因子相同的算法为所述增量文件生成第二校验因子，服务端也可以采用不同于生成第一校验因子的算法为所述增量文件生成第二校验因子，本申请对此不作特殊限制。

在本实施例中，客户端在接收到所述第一校验因子和所述第二校验因子之后，进行校验。具体地，客户端采用与服务端生成所述第一校验因子相同的算法为第二当前版本文件生成第三校验因子，然后判断所述第三校验因子是否与所述第一校验因子相同，如果相同，则说明服务端保存的客户端当前软件的版本信息对应的多个原始文件与客户端本地保存的当前版本目录中的多个原始文件相同，如果不相同，则说明服务端保存的客户端当前软件的版本信息对应的多个原始文件与客户端本地保存的当前版本目录中的多个原始文件不相同，可能是服务端获取到的客户端软件当前版本有误，停止增量更新的过程。客户端还会采用与服务端生成第二校验因子相同的算法为接收到的增量文件生成第四校验因子，然后判断所述第四校验因子是否与所述第二校验因子相同，如果相同，则说明网络传输没有丢包，客户端接收到的增量文件就是服务端生成的增量文件，如果不相同，则说明客户端接收到的增量文件不是服务端生成的增量文件，停止增量更新的过程。

在本实施例中，当客户端确认所述第三校验因子与所述第一校验因子相同，且所述第四校验因子与所述第二校验因子相同时，将所述增量文件和所述第二当前版本文件合并为第二目标版本文件，以进行增量更新的过程，本申请在此不再一一赘述。

与前述客户端软件的更新方法的实施例相对应，本申请还提供了客户端软件的更新装置的实施例。

本申请客户端软件的更新装置的实施例可以分别应用在终端和服务端上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在终端和服务端 的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图3所示，为本申请应用在服务端中的客户端软件的更新装置所在服务端的一种硬件结构图，除了图3所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的服务端通常根据该服务端的实际功能，还可以包括其他硬件，对此不再赘述。

图4是本申请一示例性实施例示出的一种客户端软件的更新装置的结构示意图。

请参考图4，所述客户端软件的更新装置300可以应用在图3所示的服务端中，包括有：版本获取单元301、第一转换单元302、第二转换单元303、增量生成单元304、增量发送单元305、第一生成单元306、第二生成单元307以及因子发送单元308。

其中，所述版本获取单元301，获取客户端当前软件的版本信息；

所述第一转换单元302，将服务端保存的所述版本信息对应的多个原始文件转换为一个第一当前版本文件；

所述第二转换单元303，将最新版本对应的多个新版本文件转换为一个第一目标版本文件；

所述增量生成单元304，根据所述第一目标版本文件生成所述第一当前版本文件的增量文件；

所述增量发送单元305，将所述增量文件发送给客户端，以供客户端进行更新。

所述第一生成单元306，为所述第一当前版本文件生成第一校验因子；

所述第二生成单元307，为所述增量文件生成第二校验因子；

所述因子发送单元308，将所述第一校验因子和所述第二校验因子发送给客户端，以供客户端进行校验，并在校验通过时进行更新。

可选的，所述第一转换单元302，具体基于FLAT协议以及预设的排序规则，将服务端保存的所述版本信息对应的多个原始文件转换为一个第一当前版本文件；

所述第二转换单元303，具体基于FLAT协议以及所述排序规则，将最新版本对应的多个新版本文件转换为一个第一目标版本文件。

图5是本申请一示例性实施例示出的另一种用于客户端软件的更新装置的一结构示意图。

如图5所示，为本申请应用在终端中的客户端软件的更新装置所在终端的一种硬件结构图，除了图3所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的终端通常根据该终端的实际功能，还可以包括其他硬件，对此不再赘述。

图6是本申请一示例性实施例示出的一种客户端软件的更新装置的结构示意图。

请参考图6，所述客户端软件的更新装置500可以应用在图5所示的终端中，包括有：第三转换单元501、增量接收单元502、增量合并单元503、文件分解单元504、文件替换单元505、因子接收单元506、第三生成单元507、第四生成单元508。

其中，所述第三转换单元501，将本地当前版本目录中的多个原始文件转换为一个第二当前版本文件；

所述增量接收单元502，接收服务端发送的增量文件；

所述增量合并单元503，将所述增量文件和所述第二当前版本文件合并为第二目标版本文件；

所述文件分解单元504，将所述第二目标版本文件分解为多个新版本文件；

所述文件替换单元505，用所述多个新版本文件替换所述多个原始文件，以形成目标版本目录。

所述因子接收单元506，所述将所述增量文件和所述第二当前版本文件合并为第二目标版本文件之前，接收服务端发送的第一校验因子和第二校验因子；

所述第三生成单元507，为所述第二当前版本文件生成第三校验因子；

所述第四生成单元508，为所述增量文件生成第四校验因子；

所述增量合并单元503，具体在所述第三校验因子和所述第四校验因子分别与所述第一校验因子和所述第二校验因子相同时，将所述增量文件和所述第二当前版本文件合并为第二目标版本文件。

可选的，所述第三转换单元501，具体基于FLAT协议以及预设的排序规则，将本地当前版本目录中的多个原始文件转换为一个第二当前版本文件。

可选的，所述第三转换单元501，具体在将所述多个原始文件转换为一个第二当前版本文件时，忽略所述原始文件的特定属性。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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