CN111258623A - 提供应用、文件的服务器及方法、用户终端以及计算机可读存储介质 - Google Patents

Abstract

本发明涉及一种提供应用的服务器，其特征在于，所述服务器包括：应用获取单元，其配置成获取各自具有版本号的第一多个版本的应用；更新生成单元，其配置成以数据块为单位确定所述应用的第一多个版本中的两者之间的差分内容，并进一步根据所述差分内容生成两者之间的第二多个更新包；请求接收单元，其配置成接收来自请求方的请求信息，所述请求信息包括所述请求方的所述应用的当前版本号；以及更新推送单元，其配置成根据所述请求信息从所述第二多个更新包中确定推送给所述请求方的更新包。

Description

提供应用、文件的服务器及方法、用户终端以及计算机可读存 储介质

技术领域

本发明涉及一种提供应用、文件的服务器及方法、用户终端以及计算机可读存储介质，具体而言，涉及一种以数据块为单位来更新应用的机制。

背景技术

随着网络基础设施的发展，能够提供信息服务的终端设备越来越受到人们欢迎，尤其是移动终端近年来得到了飞速发展。终端设备一般是经由软件客户端来提供信息服务的，并且软件客户端可以保持一定频率的更新速度来完善、添加各种功能。传统的软件客户端或文件更新可能需要大量的资源开销，例如需要较大空间来存放更新包，还需要占用较多的网络资源来传输更新包。

发明内容

因此，在一些情况下，为了尽可能地减小文件更新包的大小、提高更新效率和/或节省下载时间，需要制定详细的数据更新策略。本发明提出一种从数据层面的颗粒度出发的文件分块的数据更新策略，该机制仅从服务端仅拉取文件中修改过的内容再合并更新到本地文件中，从而可以减少网络传输时间和提高文件更新效率，具体而言：

根据本发明的一方面，提供一种提供应用的服务器，其特征在于，所述服务器包括：应用获取单元，其配置成获取各自具有版本号的第一多个版本的应用；更新生成单元，其配置成以数据块为单位确定所述应用的第一多个版本中的两者之间的差分内容，并进一步根据所述差分内容生成两者之间的第二多个更新包；请求接收单元，其配置成接收来自请求方的请求信息，所述请求信息包括所述请求方的所述应用的当前版本号；以及更新推送单元，其配置成根据所述请求信息从所述第二多个更新包中确定推送给所述请求方的更新包。

在本申请的一些实施例中，可选地，所述更新生成单元确定两者中存在差异的文件并形成差分文件列表；并且将所述差分文件列表中的文件以数据块为单位确定两者之间的差分内容。

在本申请的一些实施例中，可选地，所述更新生成单元将两者中较早版本的所述差分文件列表中的文件以定长数据块为单位进行分隔，以生成基准分隔版本；并且将两者中较晚版本的所述差分文件列表中的文件以所述基准分隔版本为基准确定与所述基准分隔版本之间的区别来形成所述差分内容。

在本申请的一些实施例中，可选地，所述更新生成单元将两者中较晚版本的所述差分文件列表中的文件进行分隔，以生成目标分隔版本，并且使得所述基准分隔版本与所述目标分隔版本之间的字节分隔相关程度最高；并且确定所述基准分隔版本与所述目标分隔版本之间的区别来形成所述差分内容。

在本申请的一些实施例中，可选地，所述定长数据块包括第三多个长度的定长数据块，所述更新生成单元生成两者之间的第三多个差分内容，并进一步根据所述第三多个差分内容生成所述应用的第一多个版本的两者之间的第二多个更新包。

在本申请的一些实施例中，可选地，所述请求信息还包括所述请求方的网络信息，所述更新推送单元被配置成根据所述当前版本号和所述网络信息确定推送给所述请求方的更新包。

在本申请的一些实施例中，可选地，所述请求信息还包括所述请求方的硬件信息，所述更新推送单元被配置成根据所述当前版本号和所述硬件信息确定推送给所述请求方的更新包。

在本申请的一些实施例中，可选地，所述更新推送单元被配置成根据所述当前版本号以及所述应用的最新版本号确定推送给所述请求方的更新包。

在本申请的一些实施例中，可选地，所述请求信息还包括所述请求方的所述应用的期望版本号，所述更新推送单元被配置成根据所述当前版本号和所述期望版本确定推送给所述请求方的更新包。

在本申请的一些实施例中，可选地，所述请求信息还包括所述请求方的操作系统版本号，所述更新推送单元被配置成根据所述当前版本号和所述操作系统版本号确定推送给所述请求方的更新包。

在本申请的一些实施例中，可选地，所述更新生成单元还生成与所述第二多个更新包中的每一者对应的校验码，并且所述更新推送单元确定推送给所述请求方的更新包并推送对应的校验码。

在本申请的一些实施例中，可选地，所述更新推送单元确定推送给所述请求方的更新包并推送对应的下载地址。

根据本发明的另一方面，提供一种用户终端，其特征在于，所述用户终端包括：请求单元，其配置成向服务端发送请求信息，所述请求信息包括所述用户终端中的应用的当前版本号；接收单元，其配置成接收所述服务端发送的根据所述请求信息确定的更新包，其中所述更新包是以数据块为单位确定所述应用的版本之间差分内容而生成的；以及合并单元，其配置成将所述应用的当前版本与所述更新包合并以更新所述应用。

在本申请的一些实施例中，可选地，所述请求信息还包括所述用户终端的网络信息，所述更新包是根据所述当前版本号和所述网络信息确定的。

在本申请的一些实施例中，可选地，所述请求信息还包括所述用户终端的硬件信息，所述更新包是根据所述当前版本号和所述硬件信息确定的。

在本申请的一些实施例中，可选地，所述更新包是根据所述当前版本号和所述应用的最新版本号确定的。

在本申请的一些实施例中，可选地，所述请求信息还包括所述应用的期望版本号，所述更新包是根据所述当前版本号和所述期望版本号确定的。

在本申请的一些实施例中，可选地，所述请求信息还包括所述用户终端的操作系统版本号，所述更新包是根据所述当前版本号和所述操作系统版本号确定的。

在本申请的一些实施例中，可选地，所述接收单元还配置成接收所述服务端发送的与所述更新包对应的校验码，所述合并单元还配置成根据所述校验码校验所述更新包的有效性，并在通过校验后将所述应用的当前版本与所述更新包合并以更新所述应用。

在本申请的一些实施例中，可选地，接收单元接收所述服务端发送的根据所述当前版本号确定的更新包包括：所述接收单元接收所述服务端发送的所述更新包的下载地址，并且经由所述下载地址下载所述更新包。

根据本发明的另一方面，提供一种提供文件的服务器，其特征在于，所述服务器包括：文件获取单元，其配置成获取各自具有版本号的第一多个版本的文件；更新生成单元，其配置成以数据块为单位确定所述文件的第一多个版本中的两者之间的差分内容，并进一步根据所述差分内容生成两者之间的第二多个更新包；请求接收单元，其配置成接收来自请求方的请求信息，所述请求信息包括所述请求方的所述文件的当前版本号；以及更新推送单元，其配置成根据所述请求信息从所述第二多个更新包中确定推送给所述请求方的更新包。

在本申请的一些实施例中，可选地，所述更新生成单元将两者中较早版本的文件以定长数据块为单位进行分隔，以生成基准分隔版本；并且将两者中较晚版本的文件以所述基准分隔版本为基准确定与所述基准分隔版本之间的区别来形成所述差分内容。

在本申请的一些实施例中，可选地，所述更新生成单元将两者中较晚版本的文件进行分隔，以生成目标分隔版本，并且使得所述基准分隔版本与所述目标分隔版本之间的字节分隔相关程度最高；并且确定所述基准分隔版本与所述目标分隔版本之间的区别来形成所述差分内容。

根据本发明的另一方面，提供一种用户终端，其特征在于，所述用户终端包括：请求单元，其配置成向服务端发送请求信息，所述请求信息包括所述用户终端中的文件的当前版本号；接收单元，其配置成接收所述服务端发送的根据所述请求信息确定的更新包，其中所述更新包是以数据块为单位确定所述文件的版本之间差分内容而生成的；以及合并单元，其配置成将所述文件的当前版本与所述更新包合并以更新所述文件。

根据本发明的另一方面，提供一种提供文件的方法，其特征在于，所述方法包括如下步骤：获取各自具有版本号的第一多个版本的文件；以数据块为单位确定所述文件的第一多个版本中的两者之间的差分内容，并进一步根据所述差分内容生成两者之间的第二多个更新包；接收来自请求方的请求信息，所述请求信息包括所述请求方的所述文件的当前版本号；以及根据所述请求信息从所述第二多个更新包中确定推送给所述请求方的更新包。

根据本发明的另一方面，提供一种更新文件的方法，其特征在于，所述方法包括如下步骤：向服务端发送请求信息，所述请求信息包括文件的当前版本号；接收所述服务端发送的根据所述请求信息确定的更新包，其中所述更新包是以数据块为单位确定所述文件的版本之间差分内容而生成的；以及将所述文件的当前版本与所述更新包合并以更新所述文件。

根据本发明的另一方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令由处理器执行时，使得所述处理器执行如上文所述的任意一种更新文件的方法。

附图说明

从结合附图的以下详细说明中，将会使本发明的上述和其他目的及优点更加完整清楚，其中，相同或相似的要素采用相同的标号表示。

图1示出了根据本发明的一个实施例的提供应用的服务器的示意图。

图2示出了根据本发明的一个实施例的用户终端的示意图。

图3示出了根据本发明的一个实施例的提供应用的方法的流程的示意图。

图4示出了根据本发明的一个实施例的更新应用的方法的流程的示意图。

图5示出了根据本发明的一个实施例的提供应用的方法的示意图。

图6示出了根据本发明的一个实施例的提供应用的方法的示意图。

图7示出了根据现有技术的提供应用的方法的流程的示意图；

图8根据本发明的一个实施例示意性地示出了文件的差异；

图9根据本发明的一个实施例示意性地示出了不同分割方式。

具体实施方式

出于简洁和说明性目的，本文主要参考其示范实施例来描述本发明的原理。但是，本领域技术人员将容易地认识到相同的原理可等效地应用于所有类型的提供应用、文件的服务器及方法、用户终端以及计算机可读存储介质，并且可以在其中实施这些相同或相似的原理，任何此类变化不背离本专利申请的真实精神和范围。

现有的更新方案通常有两种方式，一种是全量同步更新，另一种是增量更新。全量同步更新中应用程序每次都从服务端拉取全量数据并覆盖更新到应用程序本地文件中。全量更新的缺点是当文件变化很小的时候，也需要下载整个文件包，不仅浪费用户流量，也浪费下载时间，因而影响用户体验。增量更新流程如图7所示，增量更新只拉取修改过的文件部分，比起全量更新，下载全部文件，大大减小了更新的数据量大小，从而节约了下载时间和下载所需流量。如图所示，增量更新通常包括以下流程：S71：服务端生成各版本的差分文件包；S72：客户端向服务端发起数据同步请求；S73：客户端下载差分文件更新包并校验更新包的有效性；S74：客户端解压差分文件更新包；S75：客户端将差分文件覆盖到本地文件。增量更新方式主要是应用程序从服务端拉取文件更新包，并覆盖到本地文件中。

增量更新方式是根据当前客户端的文件版本号从服务端仅拉取修改过的文件，再把文件覆盖到应用程序的本地目录中。其缺点就是如果某个文件比较大，即使对其仅做了很小的改动，也要下载整个文件，这也会浪费了下载时间和流量。

可见，增量更新方式从文件层面的颗粒度来发现不同版本的应用之间的差异并据此形成更新包；本申请将从数据层面的颗粒度来寻找不同版本的应用之间的差异并据此形成更新方案，以此来探讨可以期待进一步压缩数据等优点。

在本申请的上下文中，“第一多个”、“第二多个”等均表示“多个”，其中的“第一”、“第二”等仅用于区分紧随的不同的主体，在有些情况下“第一”可以等于“第二”，有些情况下则不等。此外，在不违背本申请的基本原理的情况下，若无特别说明，“多个”也可能包括“一个”这种特殊情形。

本发明的一方面提供了一种提供应用的服务器，具体而言，服务器可以向多种用户侧的终端提供应用或其更新，用户侧的终端包括但不限于移动电话、平板电脑、个人计算机、智能穿戴设备等，图1示出了根据本发明的一个实施例的提供应用的服务器的示意图。如图所示，服务器10包括应用获取单元102、更新生成单元104、请求接收单元106以及更新推送单元108。图1中还图示了以虚线框线示出的GIT服务器“GIT”和用户侧终端20，此二者是出于帮助理解本申请原理的目的而示出的，并非是服务器10的组成部分。GIT服务器是一种常用的数据托管平台，其可以利用分布式版本控制系统保存应用文件。

服务器10的应用获取单元102被配置成获取来自GIT服务器的应用。例如，应用获取单元102可以根据GIT服务器上的提交记录获取不同版本的应用。例如，应用获取单元102可以获取到有第一多个版本的应用，并且每个版本的应用都具有自己的版本号。一般而言，版本号的命名可以反映出应用的新旧，较大的版本号对应较晚的版本，如“ver. 2.5”比“ver. 1.6”更新，其中“2”和“1”是应用的主版本号。在本发明的其他示例中，可以连同版本号保存该版本的应用的发布时间，因而还可以通过发布时间来确定应用的新旧。

服务器10的更新生成单元104被配置成以数据块为单位确定应用的第一多个版本中的两者之间的差分内容。以数据块为单位即比较文件之间的字节差异，这是一种从数据层面的颗粒度出发的文件分块的数据更新策略。

举例来说，如图8所示，如果文件1包括四个数据块A、B、C和D，文件2包括四个数据块A、B、F和D，那么二者以数据块为单位确定的差异即为第三个数据块。当然，本申请的该方面并不限制数据块的大小，其可以为1个字节或数个字节。例如，在预期文件差异不大的情况下可以以较大的数据块为单位进行比较来确定二者间的差分内容，而在预期文件差异较大或文件本身较小的情况下可以以较小的数据块为单位进行比较来确定二者间的差分内容。上文记载了确定应用的第一多个版本中的两者之间的差分内容，其中第一多个版本可以是应用的全部版本，也可以是应用的某些挑选的版本。

例如，若应用X存在4个版本，可以确定4个版本中的任意两者之间的差分内容，若其中某个版本的发行量不高（即极少甚至没有用户下载了该版本的应用），还可以确定4个版本中的其他3个版本的任意两者（即，指定两者）之间的差分内容。

更新生成单元104可以进一步地根据差分内容生成两者之间的更新包，更新包的数量可以为第二多个。继续上面的例子，可以确定4个版本中的任意两者之间的差分内容并得到6个更新包，若确定4个版本中的其他3个版本的任意两者之间的差分内容则可以得到3个更新包。

在本申请的一些示例中，若考虑到数据块单位的大小差异，还可以得到更多的更新包。继续上面的例子，若采用了2中不同大小的数据块单位（甲单位和乙单位），则可以得到如下的更新包：

对于甲单位而言，可以确定4个版本中的任意两者之间的差分内容并得到6个更新包（若确定4个版本中的其他3个版本的任意两者之间的差分内容则可以得到3个更新包）。

对于乙单位而言，可以确定4个版本中的任意两者之间的差分内容并得到6个更新包（若确定4个版本中的其他3个版本的任意两者之间的差分内容则可以得到3个更新包）。

综合以上，根据选取的“第一多个”的范围和数据块单位的数量，更新包的数量可能为第二多个。

服务器10的请求接收单元106被配置成接收来自请求方（用户侧终端20）的请求信息，请求信息包括请求方的应用的当前版本号。请求方一般而言总是想要升级到最新的版本，因而若接收单元106接收到的请求信息只有请求方的应用的当前版本号，服务器10例如可以推断请求方想要升级到最新的版本，当然也可以是设置的其他版本。

服务器10的更新推送单元108被配置成根据请求信息从第二多个更新包中确定推送给请求方的更新包。例如，请求信息中包括的当前版本号为“ver. 2.5”，最新版本号为“ver. 2.9”，那么更新推送单元108将从第二多个更新包中找到“ver. 2.5”与“ver. 2.9”之间的更新包并推送给请求方。

存在这样一种情况，请求信息中包括的当前版本号较为老旧，极少甚至没有用户从该版本升级到最新版本，因而服务器10可能并未为此情形生成并预存更新包。例如，请求信息中包括的当前版本号为“ver. 2.5”，最新版本号为“ver. 2.9”，但是已经生成并预存的第二多个更新包中并不包括“ver. 2.5”到“ver. 2.9”的更新包。另一方面，服务器10已经生成并预存了“ver. 2.5”与“ver. 2.7”之间的更新包（更新包K），还生成并预存了“ver.2.7”与“ver. 2.9”之间的更新包（更新包L）。此时，更新推送单元108可以将更新包K和更新包L一并推送给请求方，从而实现版本之间的接续升级。

此外，还可以以如下方式解决老旧版本的升级问题。例如，请求信息中包括的当前版本号为“ver. 2.5”，最新版本号为“ver. 2.9”，更新推送单元108没有找到“ver. 2.5”到“ver. 2.9”的更新包。此时，更新推送单元108可以请求更新生成单元现场生成“ver. 2.5”到“ver. 2.9”的更新包并推送给请求方。这个解决方法也受本申请的权利要求所保护。即，本申请的第二多个更新包是可以根据需要动态扩充的。

此外，如果请求信息中的当前版本号已经是最新版本号了，此时推送给请求方的更新包为空包，或者说是一种告知其已经为最新版本的响应消息。这种空包可以认为是基于相同的两者（例如，“ver. 2.5”与“ver. 2.5”）生成的，亦即，若两个版本的文件数据完全一样，则以数据块为单位确定的差分内容为空，所生成的更新包为空包。

在本申请的一些实施例中，更新生成单元104先确定上文中的某两者中存在差异的文件并形成差分文件列表，再将差分文件列表中的文件以数据块为单位确定两者之间的差分内容。本领域技术人员在阅读本申请时可以领会，两者中可能会存在完全一样的文件，这时可以不需要对这些完全一样的文件以数据块为单位确定其间的差分内容。可以利用现有的方法确定两个文件之间是否存在差异，例如可以先比较文件的大小，还可以进行字节比对。图5示出了根据本发明的一个实施例的提供应用的方法的示意图，如图所示，应用的“ver 5.1”版本与“ver 6.1”版本之间存在大量相同的文件，“ver 6.1”版本仅就以下内容对“ver 5.1”版本作了修改：

增加了3个文件：a.dex、b.gif和c.jpg；

删除了2个文件：m.xml和n.gif；

修改了3个文件：001.xml、002.xml和003.xml

更新生成单元104可以根据以上存在差异的文件形成差分文件列表，如图的右侧所示。

进一步地，更新生成单元104可以将差分文件列表中的文件以数据块为单位确定两者之间的差分内容。由于增加的文件没有出现在较早的版本中，因而可以复制整个文件到更新包中，并可以在文件命名后添加诸如“.add”的后缀（例如，a.dex.add、b.gif.add和c.jpg.add）。另一方面，由于删除的文件将被彻底移除，因而可以将这些文件记录在诸如“delete.txt”的文件中。再一方面，更新生成单元104可以将差分文件列表中的修改的文件以数据块为单位确定两者之间的差分内容，并形成对应的文件，这些文件可以诸如以“.chg”为后缀（例如，001.xml.chg、002.xml.chg和003.xml.chg）。更新生成单元104最后可以将这些差分内容（文件）打包成一个文件以形成更新包。需要说明的是，在本申请的一些实施例中“以数据块为单位确定差分内容”在添加、删除文件时将整个文件都作为差分内容，即若判断出是添加、删除文件时才将整个文件作为数据块单位，这是本申请的一些实施例中的特例。但是，本领域技术人员在阅读本申请时应当领会，不可能从将差分文件列表中的文件作为差分包的传统增量更新方案中推导出本申请中记载的“以数据块为单位确定差分内容”这样的技术方案。

在本申请的一些实施例中，更新生成单元104将两者中较早版本的差分文件列表中的文件以定长数据块为单位进行分隔，以生成基准分隔版本；并且将两者中较晚版本的差分文件列表中的文件以基准分隔版本为基准确定与基准分隔版本之间的区别来形成差分内容。如图6所示，可以以如下方式生成差分内容（上例中的001.xml.chg）。首先，将较早版本中的001.xml以定长数据块为单位进行分隔，例如，图中以4个字节为单位进行分割生成了基准分割版本。然后，将较晚版本中的001.xml以基准分隔版本为基准（例如，以逐字节对比的形式）确定其与基准分隔版本之间的区别。具体而言，如图6所示，区别在于在新版本中自左起第2个定长数据块中增加了“ab”两个字符（即第2个定长数据块变更成了“56ab78”），第4个定长数据块中删除了字符“6”（即第4个定长数据块变更成了“345”）。此时，更新生成单元104可以根据以上的区别来形成差分内容001.xml.chg，001.xml.chg中记载了第2个定长数据块变更成了“56ab78”、第4个定长数据块变更成了“345”这两处改变。

在本申请的一些实施例中，更新生成单元104将两者中较晚版本的差分文件列表中的文件进行分隔，以生成目标分隔版本，并且使得基准分隔版本与目标分隔版本之间的字节分隔相关程度最高。继续参考图6，如上文所述的，将较早版本中的001.xml以定长数据块为单位进行分隔，例如，图中以4个字节为单位进行分割生成了基准分割版本。其次，更新生成单元104将较晚版本中的001.xml进行分隔以生成目标分隔版本，这一分割过程使得基准分隔版本与目标分隔版本之间的字节分隔相关程度最高。字节分隔相关程度是基准分隔版本与目标分隔版本中分割块相同的数量的度量：字节分隔相关程度越高，基准分隔版本与目标分隔版本中分割块相同的数量越多；反之，字节分隔相关程度越低，基准分隔版本与目标分隔版本中分割块相同的数量越少。从减少差分内容的规模角度出发，显然字节分隔相关程度越高越好，此时需要编码差分内容也会越少。字节分隔相关程度计算方法的一个示例如下：假设存在一个文件A，如图9所示，其内容为“1234567890123456”，并且A被以4个字节为单位进行分割生成了基准分割版本。还存在与A完全一样的文件B，要对B分割以形成目标分隔版本。对B的分割例如存在如下所示的三种方式。

就分割方式1而言，目标分隔版本中的每个分割块都与基准分割版本中的对应分割块相同。定义若分割块N的内容相同则其相关度为1，若分割块N的内容不同则其相关度为0。在分割方式1，基准分割版本和目标分隔版本中的分割块1、分割块2、分割块3和分割块4的相关度都为1，基准分隔版本与目标分隔版本之间的字节分隔相关程度为各个分割块的相关度的平均数，因而在分割方式1中基准分隔版本与目标分隔版本之间的字节分隔相关程度为1。

就分割方式2而言，基准分割版本和目标分隔版本中的分割块1和分割块2的相关度为0，分割块3和分割块4的相关度为1，因而在分割方式2中基准分隔版本与目标分隔版本之间的字节分隔相关程度为0.5。

就分割方式3而言，基准分割版本和目标分隔版本中的分割块1、分割块2、分割块3和分割块4的相关度都为0，因而在分割方式3中基准分隔版本与目标分隔版本之间的字节分隔相关程度为0。

更新生成单元104在生成目标分隔版本后进一步确定基准分隔版本与目标分隔版本之间的区别来形成差分内容。

参见图6，其中较晚版本的001.xml已经被分割成目标分隔版本，且基准分隔版本与目标分隔版本之间的字节分隔相关程度最高（为0.5）。此时，如上文所记载的，基准分隔版本与目标分隔版本之间区别在于在新版本中自左起第2个定长数据块中增加了“ab”两个字符（即第2个定长数据块变更成了“56ab78”），第4个定长数据块中删除了字符“6”（即第4个定长数据块变更成了“345”）。据此，可以形成图中示出的差分内容（001.xml.chg）：

{“chunkSize”:4,”data”:[[0,1],”56ab78”,[2,1],”356”]}

其中，“chunkSize”:4表示文件分割块大小为4个字节。”data”:后记载的是文件内容：[0,1]表示第一个分割块没有被更改；”56ab78”表示第2个分割块被更改为”56ab78”；[2,1]表示第3个分割块没有被更改；”356”表示第4个分割块被更改为”356”。

在本申请的一些实施例中，定长数据块包括第三多个长度的定长数据块，更新生成单元104生成两者之间的第三多个差分内容，并进一步根据第三多个差分内容生成应用的第一多个版本的两者之间的第二多个更新包。图6中记载了分割块大小为4个字节，但是还可以以其他长度的定长数据块为单位来分隔形成基准分隔版本和目标分隔版本。若将定长数据块选得较大些，可以减少计算上的开销，但是生成的更新包体积可能会更大点；反之，若将定长数据块选得较小些，可能会增加计算上的开销，但是生成的更新包体积可能会更小点。可见，可以根据实际需要来选取不同的数据块单位颗粒度。若以第三多个长度的定长数据块为单位计算应用的A版本与B版本之间的差分内容，则更新生成单元104可以形成第三多个差分内容。相应地，应用的A版本与C版本之间也可以形成多个差分内容，……，以此类推。将这些差分内容分别按版本升级要求打包则可以形成多个更新包。

在本申请的一些实施例中，请求信息还可以包括请求方的网络信息，更新推送单元108被配置成根据当前版本号和网络信息确定推送给请求方的更新包，网络信息可以反映用户侧终端20以何种网络形态接入到网络中。在一些示例中，用户侧终端20可能以不同的网络接入到提供更新包的服务器10。若用户侧终端20使用移动蜂窝数据网接入到网络中，由于蜂窝数据可能是按量计费的且带宽可能受限，这时候可以选取体积较小的更新包发送到用户侧终端20（用户侧终端20在更新时可能要消耗更多的硬件资源和电力）。另一方面，若用户侧终端20使用无线局域网接入到网络，这时候可以选取体积较大的更新包发送到用户侧终端20（用户侧终端20在更新时可能要消耗更少的硬件资源和电力）。

在本申请的一些实施例中，请求信息还可以包括请求方的硬件信息，更新推送单元108被配置成根据当前版本号和硬件信息确定推送给请求方的更新包。用户侧终端20（请求方）的其他硬件信息例如可以为处理器信息等。例如，若用户侧终端20使用比较低端的入门级处理器，这时候为了减少用户侧终端20在更新过程因计算能力不足而导致等待时间较长等情况的发生，可以选取体积较大的更新包发送到用户侧终端20；反之，亦成立。

在本申请的一些实施例中，更新推送单元108被配置成根据当前版本号以及应用的最新版本号确定推送给请求方的更新包。尽管上文中介绍了可以根据当前版本号来确定更新包，但是更一般地，用户侧终端20可能期望更新到最新版本。上文中的示例中推送的更新包不一定是更新到最新版本，服务器10还可以根据设置推送例如更新到最新版本（内测版）等其他版本。

在本申请的一些实施例中，请求信息还包括请求方的应用的期望版本号，更新推送单元108被配置成根据当前版本号和期望版本确定推送给请求方的更新包。例如，某些用户侧终端20可能仅对主版本感兴趣，而对小改版并不关注，此时期望版本号可以为各种主版本号。

在本申请的一些实施例中，请求信息还包括请求方的操作系统版本号，更新推送单元108被配置成根据当前版本号和操作系统版本号确定推送给请求方的更新包。在一些示例中，用户侧终端20可能为不同版本的操作系统，例如Android 5.0和Android 6.0。但是，某些更新包可能只支持诸如Android 6.0及之后的版本。此时，用户侧终端20可以发送当前版本号和操作系统版本号（诸如Android 5.0）来请求更新包。

在本申请的一些实施例中，更新生成单元104还生成与第二多个更新包中的每一者对应的校验码，并且更新推送单元108确定推送给请求方的更新包并推送对应的校验码。此时，用户侧终端20可以同时接收到更新包和校验码，因而可以根据校验码校验更新包的有效性。

在本申请的一些实施例中，更新推送单元108确定推送给请求方的更新包并推送对应的下载地址。服务器10推送给请求方的更新包一般体积较大，这时服务器10可以以推送下载地址的方式将更新包推送给请求方。

根据本发明的另一方面，提供一种用户终端。需要说明的是，该实施例中的用户终端是与图1所对应的实施例的服务器配套的，因而其中的某些技术细节可以从上文得到印证和补充。如图2所示，用户终端20包括请求单元202、接收单元204和合并单元206。图2中还图示了以虚线框线示出的服务器10，这是出于帮助理解本申请原理的目的而示出的，并非是用户终端20的组成部分。用户终端20的请求单元202被配置成向服务端发送请求信息，请求信息包括用户终端20中的应用的当前版本号。接收单元204被配置成接收服务端发送的根据当前版本号确定的更新包，其中更新包是以数据块为单位确定应用的版本之间差分内容而生成的。以数据块为单位即比较文件之间的字节差异，这是一种从数据层面的颗粒度出发的文件分块的数据更新策略。如上文所描述的，本申请的该方面并不限制数据块的大小，其可以为1个字节或数个字节。例如，在预期文件差异不大的情况下可以以较大的数据块为单位进行比较来确定二者间的差分内容，而在预期文件差异较大或文件本身较小的情况下可以以较小的数据块为单位进行比较来确定二者间的差分内容。合并单元206被配置成将应用的当前版本与更新包合并以更新应用。例如，合并单元206可以将更新包中的内容与原文件合并并保存到临时文件中，然后将临时文件覆盖到本地文件以完成应用的更新。

在本申请的一些实施例中，请求信息还可以包括用户终端20的网络信息，服务器10可以根据当前版本号和网络信息确定推送给用户终端20的更新包，网络信息可以反映用户终端20以何种网络形态接入到网络中。在一些示例中，用户终端20可能以不同的网络接入到提供更新包的服务器10。若用户终端20使用移动蜂窝数据网接入到网络中，由于蜂窝数据可能是按量计费的且带宽可能受限，这时候可以选取体积较小的更新包发送到用户终端20（用户终端20在更新时可能要消耗更多的硬件资源和电力）。另一方面，若用户终端20使用无线局域网接入到网络，这时候可以选取体积较大的更新包发送到用户终端20（用户终端20在更新时可能要消耗更少的硬件资源和电力）。

在本申请的一些实施例中，请求信息还可以包括用户终端20的硬件信息，服务器10可以根据当前版本号和硬件信息确定推送给用户终端20的更新包。用户终端20的其他硬件信息例如可以为处理器信息等。例如，若用户终端20使用比较低端的入门级处理器，这时候为了减少用户终端20在更新过程因计算能力不足而导致等待时间较长等情况的发生，可以选取体积较大的更新包发送到用户终端20；反之，亦成立。

在本申请的一些实施例中，服务器10可以根据当前版本号以及应用的最新版本号确定推送给用户终端20的更新包。尽管上文中介绍了可以根据当前版本号来确定更新包，但是更一般地，用户终端20可能期望更新到最新版本。上文中的示例中推送的更新包不一定是更新到最新版本，服务器10还可以根据设置推送例如更新到最新版本（内测版）等其他版本。

在本申请的一些实施例中，请求信息还包括用户终端20的应用的期望版本号，服务器10可以根据当前版本号和期望版本确定推送给用户终端20的更新包。例如，某些用户终端20可能仅对主版本感兴趣，而对小改版并不关注，此时期望版本号可以为各种主版本号。

在本申请的一些实施例中，请求信息还包括用户终端20的操作系统版本号，服务器10可以根据当前版本号和操作系统版本号确定推送给用户终端20的更新包。在一些示例中，用户终端20可能为不同版本的操作系统，例如Android 5.0和Android 6.0。但是，某些更新包可能只支持诸如Android 6.0及之后的版本。此时，用户终端20可以发送当前版本号和操作系统版本号（诸如Android 5.0）来请求更新包。

在本申请的一些实施例中，服务器10还生成与第二多个更新包中的每一者对应的校验码，并且服务器10可以确定推送给用户终端20的更新包并推送对应的校验码。此时，用户终端20可以同时接收到更新包和校验码，因而可以根据校验码校验更新包的有效性。

在本申请的一些实施例中，服务器10可以确定推送给用户终端20的更新包并推送对应的下载地址。服务器10推送给用户终端20的更新包一般体积较大，这时服务器10可以以推送下载地址的方式将更新包推送给用户终端20。

以上介绍了提供应用的服务器等，但是本发明的一般原理也适用于更新普通文件。根据本发明的另一方面，提供一种提供文件的服务器。在不违背该实施例的基本原理的情况下，该实施例可以参照图1所对应的实施例来实施。服务器包括：文件获取单元，其配置成获取各自具有版本号的第一多个版本的文件；更新生成单元，其配置成以数据块为单位确定文件的第一多个版本中的两者之间的差分内容，并进一步根据差分内容生成两者之间的第二多个更新包；请求接收单元，其配置成接收来自请求方的请求信息，请求信息包括请求方的文件的当前版本号；以及更新推送单元，其配置成根据请求信息从第二多个更新包中确定推送给请求方的更新包。

在本申请的一些实施例中，可选地，更新生成单元将两者中较早版本的文件以定长数据块为单位进行分隔，以生成基准分隔版本；并且将两者中较晚版本的文件以基准分隔版本为基准确定与基准分隔版本之间的区别来形成差分内容。

在本申请的一些实施例中，可选地，更新生成单元将两者中较晚版本的文件进行分隔，以生成目标分隔版本，并且使得基准分隔版本与目标分隔版本之间的字节分隔相关程度最高；并且确定基准分隔版本与目标分隔版本之间的区别来形成差分内容。

以上介绍了接收应用的用户终端等，但是本发明的一般原理也适用于接收普通文件。根据本发明的另一方面，提供一种用户终端，在不违背该实施例的基本原理的情况下，该实施例可以参照图2所对应的实施例来实施。用户终端包括：请求单元，其配置成向服务端发送请求信息，请求信息包括用户终端中的文件的当前版本号；接收单元，其配置成接收服务端发送的根据请求信息确定的更新包，其中更新包是以数据块为单位确定文件的版本之间差分内容而生成的；以及合并单元，其配置成将文件的当前版本与更新包合并以更新文件。

根据本发明的另一方面，提供一种提供应用的方法，参见图3，该方法包括如下步骤。S302：获取各自具有版本号的第一多个版本的应用；S304：以数据块为单位确定应用的第一多个版本中的两者之间的差分内容，并进一步根据差分内容生成两者之间的第二多个更新包；S306：接收来自请求方的请求信息，请求信息包括请求方的应用的当前版本号；S308：根据请求信息从第二多个更新包中确定推送给请求方的更新包。

在本发明的一些示例中，S304又可以具体包括：确定两者中存在差异的文件并形成差分文件列表；并且将差分文件列表中的文件以数据块为单位确定两者之间的差分内容。

在本发明的一些示例中，更具体地，可以将两者中较早版本的差分文件列表中的文件以定长数据块为单位进行分隔，以生成基准分隔版本；并且将两者中较晚版本的差分文件列表中的文件以基准分隔版本为基准确定与基准分隔版本之间的区别来形成差分内容。

在本发明的一些示例中，更具体地，可以将两者中较晚版本的差分文件列表中的文件进行分隔，以生成目标分隔版本，并且使得基准分隔版本与目标分隔版本之间的字节分隔相关程度最高；并且确定基准分隔版本与目标分隔版本之间的区别来形成差分内容。

在本发明的一些示例中，更具体地，定长数据块包括第三多个长度的定长数据块，可以生成两者之间的第三多个差分内容，并进一步根据第三多个差分内容生成应用的第一多个版本的两者之间的第二多个更新包。

在本发明的一些示例中，更具体地，请求信息还包括请求方的网络信息，可以被配置成根据当前版本号和网络信息确定推送给请求方的更新包。在本发明的一些示例中，更具体地，请求信息还包括请求方的硬件信息，可以根据当前版本号和硬件信息确定推送给请求方的更新包。在本发明的一些示例中，更具体地，可以根据当前版本号以及应用的最新版本号确定推送给请求方的更新包。在本发明的一些示例中，更具体地，请求信息还包括请求方的应用的期望版本号，可以根据当前版本号和期望版本确定推送给请求方的更新包。在本发明的一些示例中，更具体地，请求信息还包括请求方的操作系统版本号，可以根据当前版本号和操作系统版本号确定推送给请求方的更新包。当然，本领域技术人员应当领会，请求信息的内容可以是以上一种或多种示例的组合，这同样适用于装置权利要求。

根据本发明的另一方面，提供一种提供文件的方法，参见图3，该方法包括如下步骤。S302：获取各自具有版本号的第一多个版本的文件；S304：以数据块为单位确定文件的第一多个版本中的两者之间的差分内容，并进一步根据差分内容生成两者之间的第二多个更新包；S306：接收来自请求方的请求信息，请求信息包括请求方的文件的当前版本号；S308：根据请求信息从第二多个更新包中确定推送给请求方的更新包。

根据本发明的另一方面，提供一种更新文件（包括应用）的方法。参见图4，该方法包括如下步骤。S402：向服务端发送请求信息，请求信息包括文件的当前版本号；S404：接收服务端发送的根据请求信息确定的更新包，其中更新包是以数据块为单位确定文件的版本之间差分内容而生成的；S406：将文件的当前版本与更新包合并以更新文件。

在本发明的一些示例中，更具体地，请求信息还包括请求方的网络信息，可以被配置成根据当前版本号和网络信息确定推送给请求方的更新包。在本发明的一些示例中，更具体地，请求信息还包括请求方的硬件信息，可以根据当前版本号和硬件信息确定推送给请求方的更新包。在本发明的一些示例中，更具体地，可以根据当前版本号以及文件的最新版本号确定推送给请求方的更新包。在本发明的一些示例中，更具体地，请求信息还包括请求方的文件的期望版本号，可以根据当前版本号和期望版本确定推送给请求方的更新包。在本发明的一些示例中，更具体地，请求信息还包括请求方的操作系统版本号，可以根据当前版本号和操作系统版本号确定推送给请求方的更新包。当然，本领域技术人员应当领会，请求信息的内容可以是以上一种或多种示例的组合，这同样适用于装置权利要求。

根据本发明的另一方面，提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，其特征在于，当指令由处理器执行时，使得处理器执行上文所述的任意一种提供文件（或者应用）的方法或更新文件（或者应用）的方法。

在本发明的一个示例中，处于完整说明本发明的基本原理考虑，本发明的更新文件的方法可以包括如下步骤：把要发布的文件提交到GIT服务器；服务端根据GIT服务器上的提交版本记录计算不同版本间的差分文件，并生成增量差分更新包；客户端把当前的文件版本号发给服务端以请求最新版本；如果服务端的最新版本号与客户端的版本号不同，则返回增量更新差分更新包的下载地址和校验值；客户端从服务端下载增量差分更新包，并校验增量更新文件包是否有效；客户端解压增量差分更新包；客户端根据每个增量更新文件，与原文件合并，并保存到临时文件；客户端合并完成后，将临时文件覆盖到本地目录文件，形成最新版本。

综合以上可见，本发明提出了一种从数据层面的颗粒度出发的文件分块的数据更新策略，该机制仅从服务端仅拉取文件中修改过的内容再合并更新到本地文件中，从而可以减少网络传输时间和提高文件更新效率。需要说明的是，附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或者在一个或多个硬件模块或集成电路中实现这些功能实体，或者在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

以上例子主要说明了本发明的提供应用、文件的服务器及方法、用户终端以及计算机可读存储介质。尽管只对其中一些本发明的实施方式进行了描述，但是本领域普通技术人员应当了解，本发明可以在不偏离其主旨与范围内以许多其他的形式实施。因此，所展示的例子与实施方式被视为示意性的而非限制性的，在不脱离如所附各权利要求所定义的本发明精神及范围的情况下，本发明可能涵盖各种的修改与替换。

Claims (27)

1.一种提供应用的服务器，其特征在于，所述服务器包括：

应用获取单元，其配置成获取各自具有版本号的第一多个版本的应用；

更新生成单元，其配置成以数据块为单位确定所述应用的第一多个版本中的两者之间的差分内容，并进一步根据所述差分内容生成两者之间的第二多个更新包；

请求接收单元，其配置成接收来自请求方的请求信息，所述请求信息包括所述请求方的所述应用的当前版本号；以及

更新推送单元，其配置成根据所述请求信息从所述第二多个更新包中确定推送给所述请求方的更新包。

2. 根据权利要求1所述的服务器，其特征在于：

所述更新生成单元确定两者中存在差异的文件并形成差分文件列表；并且

将所述差分文件列表中的文件以数据块为单位确定两者之间的差分内容。

3. 根据权利要求2所述的服务器，其特征在于：

所述更新生成单元将两者中较早版本的所述差分文件列表中的文件以定长数据块为单位进行分隔，以生成基准分隔版本；并且

将两者中较晚版本的所述差分文件列表中的文件以所述基准分隔版本为基准确定与所述基准分隔版本之间的区别来形成所述差分内容。

4. 根据权利要求3所述的服务器，其特征在于：

所述更新生成单元将两者中较晚版本的所述差分文件列表中的文件进行分隔，以生成目标分隔版本，并且使得所述基准分隔版本与所述目标分隔版本之间的字节分隔相关程度最高；并且

确定所述基准分隔版本与所述目标分隔版本之间的区别来形成所述差分内容。

5.根据权利要求3或4所述的服务器，其特征在于，所述定长数据块包括第三多个长度的定长数据块，所述更新生成单元生成两者之间的第三多个差分内容，并进一步根据所述第三多个差分内容生成所述应用的第一多个版本的两者之间的第二多个更新包。

6.根据权利要求1所述的服务器，其特征在于，所述请求信息还包括所述请求方的网络信息，所述更新推送单元被配置成根据所述当前版本号和所述网络信息确定推送给所述请求方的更新包。

7.根据权利要求1所述的服务器，其特征在于，所述请求信息还包括所述请求方的硬件信息，所述更新推送单元被配置成根据所述当前版本号和所述硬件信息确定推送给所述请求方的更新包。

8.根据权利要求1所述的服务器，其特征在于，所述更新推送单元被配置成根据所述当前版本号以及所述应用的最新版本号确定推送给所述请求方的更新包。

9.根据权利要求1所述的服务器，其特征在于，所述请求信息还包括所述请求方的所述应用的期望版本号，所述更新推送单元被配置成根据所述当前版本号和所述期望版本确定推送给所述请求方的更新包。

10.根据权利要求1所述的服务器，其特征在于，所述请求信息还包括所述请求方的操作系统版本号，所述更新推送单元被配置成根据所述当前版本号和所述操作系统版本号确定推送给所述请求方的更新包。

11.根据权利要求1所述的服务器，其特征在于，所述更新生成单元还生成与所述第二多个更新包中的每一者对应的校验码，并且所述更新推送单元确定推送给所述请求方的更新包并推送对应的校验码。

12.根据权利要求1所述的服务器，其特征在于，所述更新推送单元确定推送给所述请求方的更新包并推送对应的下载地址。

13.一种用户终端，其特征在于，所述用户终端包括：

请求单元，其配置成向服务端发送请求信息，所述请求信息包括所述用户终端中的应用的当前版本号；

接收单元，其配置成接收所述服务端发送的根据所述请求信息确定的更新包，其中所述更新包是以数据块为单位确定所述应用的版本之间差分内容而生成的；以及

合并单元，其配置成将所述应用的当前版本与所述更新包合并以更新所述应用。

14.根据权利要求13所述的用户终端，其特征在于，所述请求信息还包括所述用户终端的网络信息，所述更新包是根据所述当前版本号和所述网络信息确定的。

15.根据权利要求13所述的用户终端，其特征在于，所述请求信息还包括所述用户终端的硬件信息，所述更新包是根据所述当前版本号和所述硬件信息确定的。

16.根据权利要求13所述的用户终端，其特征在于，所述更新包是根据所述当前版本号和所述应用的最新版本号确定的。

17.根据权利要求13所述的用户终端，其特征在于，所述请求信息还包括所述应用的期望版本号，所述更新包是根据所述当前版本号和所述期望版本号确定的。

18.根据权利要求13所述的用户终端，其特征在于，所述请求信息还包括所述用户终端的操作系统版本号，所述更新包是根据所述当前版本号和所述操作系统版本号确定的。

19.根据权利要求13所述的用户终端，其特征在于，所述接收单元还配置成接收所述服务端发送的与所述更新包对应的校验码，所述合并单元还配置成根据所述校验码校验所述更新包的有效性，并在通过校验后将所述应用的当前版本与所述更新包合并以更新所述应用。

20.根据权利要求13所述的用户终端，其特征在于，接收单元接收所述服务端发送的根据所述当前版本号确定的更新包包括：所述接收单元接收所述服务端发送的所述更新包的下载地址，并且经由所述下载地址下载所述更新包。

21.一种提供文件的服务器，其特征在于，所述服务器包括：

文件获取单元，其配置成获取各自具有版本号的第一多个版本的文件；

更新生成单元，其配置成以数据块为单位确定所述文件的第一多个版本中的两者之间的差分内容，并进一步根据所述差分内容生成两者之间的第二多个更新包；

请求接收单元，其配置成接收来自请求方的请求信息，所述请求信息包括所述请求方的所述文件的当前版本号；以及

更新推送单元，其配置成根据所述请求信息从所述第二多个更新包中确定推送给所述请求方的更新包。

22. 根据权利要求21所述的服务器，其特征在于：

所述更新生成单元将两者中较早版本的文件以定长数据块为单位进行分隔，以生成基准分隔版本；并且

将两者中较晚版本的文件以所述基准分隔版本为基准确定与所述基准分隔版本之间的区别来形成所述差分内容。

23. 根据权利要求22所述的服务器，其特征在于：

所述更新生成单元将两者中较晚版本的文件进行分隔，以生成目标分隔版本，并且使得所述基准分隔版本与所述目标分隔版本之间的字节分隔相关程度最高；并且

确定所述基准分隔版本与所述目标分隔版本之间的区别来形成所述差分内容。

24.一种用户终端，其特征在于，所述用户终端包括：

请求单元，其配置成向服务端发送请求信息，所述请求信息包括所述用户终端中的文件的当前版本号；

接收单元，其配置成接收所述服务端发送的根据所述请求信息确定的更新包，其中所述更新包是以数据块为单位确定所述文件的版本之间差分内容而生成的；以及

合并单元，其配置成将所述文件的当前版本与所述更新包合并以更新所述文件。

25.一种提供文件的方法，其特征在于，所述方法包括如下步骤：

获取各自具有版本号的第一多个版本的文件；

以数据块为单位确定所述文件的第一多个版本中的两者之间的差分内容，并进一步根据所述差分内容生成两者之间的第二多个更新包；

接收来自请求方的请求信息，所述请求信息包括所述请求方的所述文件的当前版本号；以及

根据所述请求信息从所述第二多个更新包中确定推送给所述请求方的更新包。

26.一种更新文件的方法，其特征在于，所述方法包括如下步骤：

向服务端发送请求信息，所述请求信息包括文件的当前版本号；

接收所述服务端发送的根据所述请求信息确定的更新包，其中所述更新包是以数据块为单位确定所述文件的版本之间差分内容而生成的；以及

将所述文件的当前版本与所述更新包合并以更新所述文件。

27.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令由处理器执行时，使得所述处理器执行如权利要求25或26的方法。

Images