CN114035822A - 一种文件更新方法及设备 - Google Patents

Abstract

本申请公开了一种文件更新方法及设备，用以不受签名校验的文件限制，实现文件的增量更新，从而提高文件更新效率，降低传输延时，节约网络资源。本申请提供的文件更新方法包括：当收到客户端发送的文件更新请求时，从所述文件更新请求中获取所述客户端当前本地的文件版本号；从服务端查找所述文件版本号对应的差分文件，并下发给所述客户端；其中，所述差分文件，是所述服务端将需要下发给客户端的更新文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算后得到差分文件。

Description

一种文件更新方法及设备

技术领域

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

背景技术

现有的文件更新方案，对需要签名校验的文件无法做到增量更新，即无法仅将新增部分的文件发送给客户端，只能全量更新，即服务端下发包含所有文件内容的全量文件给客户端，该全量文件中包含了客户端已有版本的文件内容，因此这种文件更新方式效率较低，延时较大，占用资源较多。而目前大多数的应用升级包都是需要验证签名的。

发明内容

本申请实施例提供了一种文件更新方法及设备，用以不受签名校验的文件限制，实现文件的增量更新，从而提高文件更新效率，降低传输延时，节约网络资源。

在服务端，本申请实施例提供的一种文件更新方法包括：

当收到客户端发送的文件更新请求时，从所述文件更新请求中获取所述客户端当前本地的文件版本号；

从服务端查找所述文件版本号对应的差分文件，并下发给所述客户端；其中，所述差分文件，是所述服务端将需要下发给客户端的更新文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算后得到差分文件。

所述方法通过服务端将需要下发给客户端的更新文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算后得到差分文件，当收到客户端发送的文件更新请求时，从所述文件更新请求中获取所述客户端当前本地的文件版本号，从服务端查找所述文件版本号对应的差分文件，并下发给所述客户端，从而不受文件是否需要验证签名的限制，实现了文件的增量更新，从而提高了文件更新效率，降低了传输延时，节约了网络资源。

可选地，所述差分文件是预先采用如下步骤生成的：

步骤一、确定需要下发给客户端的更新文件；

步骤二、判断所述更新文件是否有签名校验机制；如果是，则执行步骤四，否则执行步骤三；

步骤三、对所述更新文件进行压缩，得到压缩文件；

步骤四、将所述更新文件或所述更新文件的压缩文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算，得到差分文件。

可选地，基于有限状态熵FSE算法，对所述更新文件进行压缩。

可选地，所述全量文件有多个版本号对应的全量文件，将所述更新文件或所述更新文件的压缩文件，分别与每一所述版本号的全量文件进行差分运算，得到每一所述版本号对应的差分文件。

在客户端，本申请实施例提供的一种文件更新方法，包括：

向服务端发送文件更新请求，其中携带客户端当前本地的文件版本号；

接收所述服务端发送的与所述文件版本号对应的差分文件；

基于所述差分文件，和客户端当前已有的所述文件版本号对应的文件，得到更新文件。

可选地，所述差分文件，是所述服务端将所述更新文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算后得到差分文件。

本申请实施例提供的一种服务端设备，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行上述服务端的文件更新方法。

本申请实施例提供的一种客户端设备，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行上述客户端的文件更新方法。

本申请另一实施例提供了一种计算设备，其包括存储器和处理器，其中，所述存储器用于存储程序指令，所述处理器用于调用所述存储器中存储的程序指令，按照获得的程序执行上述任一种方法。

本申请另一实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使所述计算机执行上述任一种方法。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅是本申请的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的文件更新的整体流程示意图；

图2为本申请实施例提供的文件更新的具体流程示意图；

图3为本申请实施例提供的文件更新的具体流程示意图；

图4为本申请实施例提供的编码方式示意图；

图5为本申请实施例提供的更新事件概率区间的示意图；

图6为本申请实施例提供的对待压缩文件进行预处理生成字典文件的示意图；

图7为本申请实施例提供的服务端的文件更新方法的流程示意图；

图8为本申请实施例提供的客户端的文件更新方法的流程示意图；

图9为本申请实施例提供的服务端的文件更新装置的结构示意图；

图10为本申请实施例提供的客户端的文件更新装置的结构示意图。

具体实施方式

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

本申请实施例提供了一种文件更新方法及设备，用以不受签名校验的文件限制，实现文件的增量更新，从而提高文件更新效率，降低传输延时，节约网络资源。

其中，方法和设备是基于同一申请构思的，由于方法和设备解决问题的原理相似，因此方法和设备的实施可以相互参见，重复之处不再赘述。

下面结合说明书附图对本申请各个实施例进行详细描述。需要说明的是，本申请实施例的展示顺序仅代表实施例的先后顺序，并不代表实施例所提供的技术方案的优劣。

术语解释：

cs架构：一种客户端(client)到服务端(server)的开发架构，用户通过下载客户端程序，在客户端程序中使用功能。

信息熵：一种描述信息量大小、价值高低的数学表达方式。是发生一个事件的平均信息量大小。

熵编码：一种编码格式，使得使用的存储空间接近信息熵。

FSE：有限状态熵，通过有限个状态去逼近信息熵。

patch：通过差分文件(patch文件)和源文件合成新文件算法。

diff：通过源文件和新文件计算差分文件算法。

霍夫曼编码：一种熵编码实现。

MD5：信息摘要算法(Message-Digest Algorithm)，一种被广泛使用的密码散列函数，可以产生出一个128位(16字节)的散列值(hash value)，用于确保信息传输完整一致。

熵编码、FSE、长距离匹配查找算法以及基于字典的数据训练，是本申请实施例提供的技术方案得以实现的基础技术。其中：

熵编码可以以最优的编码方式对信息进行编码。

FSE是一种结合了霍夫曼编码(huffman encoding)和算术码(arithmeticencoding)各自优点的一种编码方式，使得即有压缩率又有速度。其中，霍夫曼编码的优点在于只需要进行位运算，编码和解码的速度都比较快；缺点则是对于每一个事件的概率只能通过整数个比特位去做近似编码，无法做到编码后的空间使用接近信息熵；算术码则可以用任意精度去逼近信息熵，缺点则是效率较低。

长距离匹配查找算法，是针对较大文件进行压缩的优化，在传统的基于历史数据字典的压缩算法中，由于查找窗口的大小限制，导致对于长距离的重复数据无法做到去除冗余。

字典训练：任何对数据进行压缩的算法都是基于前置内容训练而推动的，也就是说会对前面的数据进行词频统计，然后存入词典，这样后面有同样的数据出现就会被替换，这样会使得后面对数据的压缩率更高，比如信息开头有一个abc数据，将之存入字典，后续如果再出现abc就可以用一个字符来代替，如果后面出现的多，压缩效率就比较高。然后对于较小文件来说，没有足够多的前置数据进行训练会导致后续的压缩率不好，因为无法获取足够的信息来建立字典。而字段训练则是一种提前对数据进行训练，从而提前得到较好的字典。

本申请实施例，主要解决的问题是对于client端需要进行版本更新或者应用资源更新时，资源文件或者版本文件太大导致下载慢、占用server端带宽大的问题。

就目前的技术方案来说，有两个主要的问题：

第一，对于需要签名的版本文件(如Android的apk，ios的iap)无法做增量更新；

第二，对zip等不需要签名验证的文件进行增量更新时，渐进式增量只能连续升级，无法做到跳跃式升级，导致每次更新需要耗费更多的流量和时间成本，给用户极差的体验。

本申请实施例提供的技术方案，就是针对cs架构，解决更新文件较大的问题，使得每次下载较小的文件即可完成更新(或者称为升级)。

本申请实施例提供的技术方案适用于任何cs架构的系统，以及任何文件格式。

参见图1，本申请实施例提供的文件更新方法包括如下步骤：

S101、服务(Server)端获取到需要下发到客户(client)端的更新文件(或者称为安装包)，该更新文件例如记为cn。

例如图2所示，通过版本管理后台界面，向版本管理后台发送请求，上传需要下发到客户(client)端的版本的更新文件(或者称为安装包)，使得后台可以通过差分引擎计算差分文件。

S102、Server端判断更新文件cn是否有文件签名校验机制，如果是，保存更新文件cn并进入步骤S104，否则，进入步骤S103。

S103、Server端对更新文件cn进行基于FSE的压缩，生成压缩文件，记为cn.zst文件并保存。

通过该步骤，可以缩小更新文件占用的空间。

本申请实施例中，用FSE的方式来压缩文件，并在下一步中，用压缩文件来计算差分文件，而目前计算文件差分时，是没有采用这样的处理方式的。本申请实施例中给出的该处理方式，可以降低数据处理量，提高差分效率，以及缩小差分文件，从而可以降低差分文件的传输时延，降低对带宽的需求，并提高文件更新效率。

S104、Server端通过将更新文件cn或者更新文件的压缩文件cn.zst，和server端与所述更新文件cn对应的已有的全量文件，分别进行diff运算，即差分运算，生成对应的差分文件，记为cn_vn.patch文件并保存。

例如，如果server端现在有更新文件cn对应的3个版本的全量文件，记为c1、c2、c3，则将会生成3个版本的差分文件(patch文件)，分别为cn_v1.patch、cn_v2.patch、cn_v3.patch。

现有技术中，对于已经计算出的更新包，只能连续更新，无法做到直接升级，比如目前有5个更新包，分别为v1到v5，用户只能依次从v1、v2、v3、v4、v5这样连续不间断的进行升级。因为，每一个版本都是基于上一版本的升级。

而通过本申请实施例提供的方案，客户端可以实现跳跃式升级，例如，若客户端当前的文件版本是v1，可以直接获取差分文件cn_v3.patch，实现从版本v1直接升级到版本v3，而无需版本v2的升级过程。因为，本申请实施例提供的任一版本的差分文件，不是基于上一版本的差分文件，而是基于源文件的差分文件，因此其包含了与源文件相比所有的差异数据。

S105、client端携带当前本地已有的文件(记为base_n)版本号，到server端请求更新。

当前本地已有的文件，也可以称当前本地已有的资源包。

S106、Server端获取到client端上传的版本号，选择与该版本好匹配的patch文件并进行下发。

S107、client端下载对应的patch文件到本地，并和本地的base_n进行patch运算，即可得到server端保存的cn或者cn.zst文件，并更新base_n文件。

例如图2所示，client端发送的更新请求中携带当前版本号、本地文件的MD5值、差分算法版本等，使得Server端通过当前版本号、本地文件MD5、差分算法版本等，查询更新包信息，其中包括patch文件的URL地址，如果没有patch文件则把全量文件的URL地址添加到更新包信息中，并把更新包信息发给客户端，客户端通过更新包信息中的URL地址下载patch文件或全量文件。

client端获取的如果是patch文件，则通过算法合成新版本的全量文件校验文件；如果是全量文件，则按照现有技术执行全量更新流程。

另外，例如参见图3，在服务端，版本管理后台管理端(可以通过版本管理后台界面)上传新版本页面给版本管理后台，并提供对更新包的增、删、改、查等基本操作。版本管理后台保存更新版本全量包并计算保存MD5；通过差分算法版本和已有版本分别计算出差量包p(n)和对应的MD5；并且，将相关信息存入数据库。之后，服务端(具体可以是版本管理后台)收到客户端的更新请求(携带客户端当前版本号、差分算法版本号、本地程序包的MD5)后，还可以判断是否有更新，即客户端请求的更新文件是否存在；

如果是，则进一步检查是否有匹配的MD5原包和差分算法版本，如果有，则取出对应的增量包MD5和URL(Uniform Resource Locator，统一资源定位器)，以及全量包MD5和URL，以构建返回报文，并标记该报文为增量更新；若没有，则全量包MD5和URL，以构建返回报文，并标记该报文为全量更新；

如果没有更新，则构建返回报文，并标记该报文为无更新。

那么相应地，客户端收到服务端返回的报文后，若没有更新，则提示用户无更新；如果有更新，进一步根据报文标记，判断是增量更新还是全量更新；如果是全量更新，则执行全量更新流程，如果是增量更新，则通过报文中写的URL下载增量包，即上述的patch文件；进一步的，还可以对下载的增量包进行MD5校验，如果校验通过，则通过sdk(一种软件开发工具)合成更新包；否则，执行全量更新流程；

其中，通过sdk合成更新包后，进一步还可以对合成的更新包MD5校验，以及签名校验，如果校验通过，则执行升级安装流程，否则，执行全量更新流程。

上述步骤S103中使用了基于FSE的高压缩算法，对可压缩文件进行压缩，这是后面能进行高效diff和patch的理论基础。

FSE是一种集霍夫曼编码和算术码优点的熵编码算法。

霍夫曼编码是一种最有效的二进制编码，从信息量的角度出发，将消息量以二进制的方式进行编码，同时让信息量最小的(信息熵更小)事件用更短的bit位数进行编码。如对于事件a、b、c、d、e，对应的发生概率分别为0.4、0.2、0.2、0.1、0.1，则事件a,b,c,d,e分别会用00，10，11，010，011来表示；

如图4所示，给出了上述的编码方式的举例说明。

可以发现霍夫曼编码速度是比较快的，因为都是bit位运算，但是对于一个事件只能用整数个bit位去表示，这样只能近似逼近信息熵。

所以又引入了算术码，它也是一种熵编码，它和其他编码的将信息中的符号进行逐个编码不同，它可以将一条信息编码为一个0-1之间的数，对于信息中的每一个事件都可以精确的用一个浮点区间数来表示，从而弥补了霍夫曼编码的不精确问题，但是它带来的问题则是效率较低，因为涉及到大量的浮点运算。

对于一段信息有{a,b,c,d}4个事件，分别对应的概率为{0.1,0.4.,0.2,0.3},如果需要编码信息为abcddc，则将会采用如下方式进行编码：

第一步：生成事件概率表：

事件	a	b	c	d
					概率区间	[0,0.1)	[0.1,0.5)	[0.5,0.7)	[0.7,1)

可以发现每一个事件都由[L,H)区间来表示。

第二步：读取信息中的a，则区间更新为[0，0.1)。

第三步：依次读取后面事件，并执行公式L＝L+(H-L)*L，和H＝L+(H-L)*H。

上述公式是用于将一个概率从一个较大范围映射到更小的范围区间内。

例如，事件b的概率占当前区间的0.1-0.5，所以更新区间为[0+0.1*0.1,0+0.1*0.1+0.1*0.5)＝[0.01,0.06)，如图5所示。

第四部：重复第三步直到完成对所有事件的编码。

最后会得到一个区间，只需要在此区间任意取一个浮点数即可。

FSE的理论基础是Jarek Duda提出的非对称数系(Asymmetric Numeral System，ANS)。他维持了一张FSE Table，通过查表得到对应的状态(从这个角度讲他又是一个有限状态机)，总共有4096个状态。每一个字符会有多个状态的输出，对应它的信息熵。比如某个信息中A的出现次数为5，那么对应的状态概率为5/4096。这样它的信息熵为log(5/4096)＝9.68。如果用霍夫曼编码的话只能用整数表示，无法得到精确值9.68。FSE则是通过将4096划分为5个区，由不同概率p可以输出到对应的区位中，很容易证明可以调整p来使得最后的平均码长为9.68。然而FSE并没有进行大量的浮点运算，而是通过查表的方式进行，这样就在保持压缩率的前提下，大大提高的压缩速度。

另外，本申请实施例中，还提出了基于动态字典压缩的改进。动态字典压缩算法是目前主流压缩算法采用的一种技术，它通过不断的更新词频字典，使得之后的数据压缩率更好，前面几KB基本上没有字典可供其替换压缩，所以对于较少的数据来说(几m以下的数据)压缩率往往不好。参见图6，本申请实施例中，通过对待压缩文件进行预处理，生成字典文件，例如对多个小文件进行分析，然后生成字典。在压缩文件的时候不再进行动态字典的建立，直接使用之前生成的字典文件。

本申请实施例从另一个角度来计算diff或patch，其原理其实是将原文件作为字典文件，来对新文件进行压缩，生成的压缩文件即为patch文件；在进行还原时将原文件作为字典来解压patch文件即可。

综上所述，本申请实施例提供的技术方案中，使用基于FSE的熵编码算法，进行数据压缩；使用预处理待压缩文件，并生成字典文件，用于压缩算法，将diff或patch转化为压缩和解压的操作；server端通过基于上述核心技术的diff和patch，对资源和版本文件进行diff操作，然后下发diff文件到client端，client通过patch合成真正的server端文件。

其中，本申请实施例通过差分算法、进行数据压缩，解决了下载全量更新文件的耗时、耗流量的问题。

本申请实施例基于FSE的压缩算法，FSE并没有进行大量的浮点运算，而是通过查表的方式进行，既保证了压缩率，同时也有较高的压缩速度。

本申请实施例不依赖于文件的diff和patch，可以对任何文件进行差分，也可以直接合成目标文件，解决了当下逐步更新的缓慢过程。

参见图7，在服务端，本申请实施例提供的一种文件更新方法包括：

S701、当收到客户端发送的文件更新请求时，从所述文件更新请求中获取所述客户端当前本地的文件版本号；

S702、从服务端查找所述文件版本号对应的差分文件，并下发给所述客户端；其中，所述差分文件，是所述服务端将需要下发给客户端的更新文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算后得到差分文件。

可选地，所述差分文件是预先采用如下步骤生成的：

步骤一、确定需要下发给客户端的更新文件；

步骤二、判断所述更新文件是否有签名校验机制；如果是，则执行步骤四，否则执行步骤三；

步骤三、对所述更新文件进行压缩，得到压缩文件；

步骤四、将所述更新文件或所述更新文件的压缩文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算，得到差分文件。

可选地，基于有限状态熵FSE算法，对所述更新文件进行压缩。

可选地，所述全量文件有多个版本号对应的全量文件，将所述更新文件或所述更新文件的压缩文件，分别与每一所述版本号的全量文件进行差分运算，得到每一所述版本号对应的差分文件。

相应地，参见图8，在客户端，本申请实施例提供的一种文件更新方法，包括：

S801、向服务端发送文件更新请求，其中携带客户端当前本地的文件版本号；

S802、接收所述服务端发送的与所述文件版本号对应的差分文件；

S803、基于所述差分文件，和客户端当前已有的所述文件版本号对应的文件，得到更新文件。

可选地，所述差分文件，是所述服务端将所述更新文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算后得到差分文件。

参见图9，本申请实施例提供的一种服务端设备，包括：

存储器520，用于存储程序指令；

处理器500，用于调用所述存储器中存储的程序指令，按照获得的程序执行：

当收到客户端发送的文件更新请求时，从所述文件更新请求中获取所述客户端当前本地的文件版本号；

从服务端查找所述文件版本号对应的差分文件，并下发给所述客户端；其中，所述差分文件，是所述服务端将需要下发给客户端的更新文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算后得到差分文件。

可选地，所述差分文件是预先采用如下步骤生成的：

步骤一、确定需要下发给客户端的更新文件；

步骤二、判断所述更新文件是否有签名校验机制；如果是，则执行步骤四，否则执行步骤三；

步骤三、对所述更新文件进行压缩，得到压缩文件；

步骤四、将所述更新文件或所述更新文件的压缩文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算，得到差分文件。

可选地，基于有限状态熵FSE算法，对所述更新文件进行压缩。

可选地，所述全量文件有多个版本号对应的全量文件，将所述更新文件或所述更新文件的压缩文件，分别与每一所述版本号的全量文件进行差分运算，得到每一所述版本号对应的差分文件。

收发机510，用于在处理器500的控制下接收和发送数据。

其中，在图9中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器500代表的一个或多个处理器和存储器520代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发机510可以是多个元件，即包括发送机和接收机，提供用于在传输介质上与各种其他装置通信的单元。处理器500负责管理总线架构和通常的处理，存储器520可以存储处理器500在执行操作时所使用的数据。

处理器500可以是中央处埋器(CPU)、专用集成电路(Application SpecificIntegrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或复杂可编程逻辑器件(Complex Programmable Logic Device，CPLD)。

参见图10，本申请实施例提供的一种客户端设备，包括：

存储器620，用于存储程序指令；

处理器600，用于调用所述存储器中存储的程序指令，按照获得的程序执行：

向服务端发送文件更新请求，其中携带客户端当前本地的文件版本号；

接收所述服务端发送的与所述文件版本号对应的差分文件；

基于所述差分文件，和客户端当前已有的所述文件版本号对应的文件，得到更新文件。

可选地，所述差分文件，是所述服务端将所述更新文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算后得到差分文件。

收发机610，用于在处理器600的控制下接收和发送数据。

其中，在图10中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器600代表的一个或多个处理器和存储器620代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发机610可以是多个元件，即包括发送机和接收机，提供用于在传输介质上与各种其他装置通信的单元。针对不同的用户设备，用户接口630还可以是能够外接内接需要设备的接口，连接的设备包括但不限于小键盘、显示器、扬声器、麦克风、操纵杆等。

处理器600负责管理总线架构和通常的处理，存储器620可以存储处理器600在执行操作时所使用的数据。

可选的，处理器600可以是CPU(中央处埋器)、ASIC(Application SpecificIntegrated Circuit，专用集成电路)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)或CPLD(Complex Programmable Logic Device，复杂可编程逻辑器件)。

本申请实施例提供了一种计算设备，该计算设备具体可以为桌面计算机、便携式计算机、智能手机、平板电脑、个人数字助理(Personal Digital Assistant，PDA)等。该计算设备可以包括中央处理器(Center Processing Unit，CPU)、存储器、输入/输出设备等，输入设备可以包括键盘、鼠标、触摸屏等，输出设备可以包括显示设备，如液晶显示器(Liquid Crystal Display，LCD)、阴极射线管(Cathode Ray Tube，CRT)等。

存储器可以包括只读存储器(ROM)和随机存取存储器(RAM)，并向处理器提供存储器中存储的程序指令和数据。在本申请实施例中，存储器可以用于存储本申请实施例提供的任一所述方法的程序。

处理器通过调用存储器存储的程序指令，处理器用于按照获得的程序指令执行本申请实施例提供的任一所述方法。

本申请实施例提供了一种计算机可读存储介质，用于储存为上述本申请实施例提供的装置所用的计算机程序指令，其包含用于执行上述本申请实施例提供的任一方法的程序。

所述计算机可读存储介质可以是计算机能够存取的任何可用介质或数据存储设备，包括但不限于磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NANDFLASH)、固态硬盘(SSD))等。

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

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

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

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

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种文件更新方法，其特征在于，该方法包括：

当收到客户端发送的文件更新请求时，从所述文件更新请求中获取所述客户端当前本地的文件版本号；

从服务端查找所述文件版本号对应的差分文件，并下发给所述客户端；其中，所述差分文件，是所述服务端将需要下发给客户端的更新文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算后得到差分文件。

2.根据权利要求1所述的方法，其特征在于，所述差分文件是预先采用如下步骤生成的：

步骤一、确定需要下发给客户端的更新文件；

步骤二、判断所述更新文件是否有签名校验机制；如果是，则执行步骤四，否则执行步骤三；

步骤三、对所述更新文件进行压缩，得到压缩文件；

步骤四、将所述更新文件或所述更新文件的压缩文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算，得到差分文件。

3.根据权利要求2所述的方法，其特征在于，基于有限状态熵FSE算法，对所述更新文件进行压缩。

4.根据权利要求2所述的方法，其特征在于，所述全量文件有多个版本号对应的全量文件，将所述更新文件或所述更新文件的压缩文件，分别与每一所述版本号的全量文件进行差分运算，得到每一所述版本号对应的差分文件。

5.一种文件更新方法，其特征在于，该方法包括：

向服务端发送文件更新请求，其中携带客户端当前本地的文件版本号；

接收所述服务端发送的与所述文件版本号对应的差分文件；

基于所述差分文件，和客户端当前已有的所述文件版本号对应的文件，得到更新文件。

6.根据权利要求5所述的方法，其特征在于，所述差分文件，是所述服务端将所述更新文件，与所述服务端已有的与所述更新文件相对应的全量文件进行差分运算后得到差分文件。

7.一种服务端设备，其特征在于，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行权利要求1至4任一项所述的方法。

8.一种客户端设备，其特征在于，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行权利要求5或6所述的方法。

9.一种计算设备，其特征在于，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行权利要求1至6任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使所述计算机执行权利要求1至6任一项所述的方法。

Images