客户端应用更新方法及客户端

摘要

本申请公开了一种客户端应用更新方法及客户端，所述方法包括：通过第一端口向服务器侧发送第一应用的本地版本；通过第一端口接收第一应用更新至第一版本的更新信息；第一版本高于本地版本；基于更新信息下载第一应用更新至第一版本的更新包；在第一应用的可写目录中解压更新包，将资源数据库中本地版的文件名映射关系表复制而生成第一版本的文件名映射关系表；将更新包更新后的更新或新增的文件条目写入第一版本的文件名映射关系表，并将第一版本的文件名映射关系表中更新或新增的文件条目的存储位置更新为解压的实际存储位置；将配置数据库中的第一应用的版本值设置为第一版本。本申请支持应用的多个版本的资源文件并存，避免版本回滚时重复下载。

说明书

技术领域

本申请实施例涉及应用更新技术，尤其涉及一种客户端应用更新方法及客户端。

背景技术

游戏内更新，也叫游戏内更，是指游戏客户端启动之后，通过网络下载增量更新包，然后更新本地游戏版本的过程。游戏强更新，也叫游戏强更，是指游戏客户端启动之后，用户收到提示，跳转至应用商店下载游戏新版本的完整安装包进行更新的过程。相比于强更，内更的速度和用户体验更好。

游戏客户端在启动阶段会先与vmsapi接口进行通信，检查版本更新，然后与用户帐号和区服管理模块(global server)通信，进行登录验证以及获取分区列表，最后根据用户选择的区服与对应的游戏服务器(game server)通信，进行游戏。

对于游戏更新，客户端只存一份资源，当进行升级更新时，采用覆盖更新，原游戏将不复存在且不能回退至原游戏状态。或者，客户端每个版本都存一份资源，当进行升级更新时，保留旧版本，同时进行增量更新，这会导致客户端的存储空间被大量占用；更新后没有变化的资源并不能复用，造成存储空间的浪费。

发明内容

有鉴于此，本申请实施例提供一种客户端应用更新方法及客户端。

根据本申请的第一方面，提供一种客户端应用更新方法，包括：

通过第一端口向服务器侧发送第一应用的本地版本；

通过所述第一端口接收所述第一应用更新至第一版本的更新信息；所述第一版本高于所述本地版本；

基于所述更新信息下载所述第一应用更新至所述第一版本的更新包；

在所述第一应用的可写目录中解压所述更新包，将资源数据库中所述本地版的文件名映射关系表复制而生成所述第一版本的文件名映射关系表；

将所述更新包更新后的更新或新增的文件条目写入所述第一版本的文件名映射关系表，并将所述第一版本的文件名映射关系表中更新或新增的文件条目的存储位置更新为解压的实际存储位置；

将配置数据库中的所述第一应用的版本值设置为所述第一版本。

作为一种实现方式，所述方法还包括：

为所述第一应用的运行文件设置静态目录和版本目录；

无需更新的运行文件存储于所述静态目录中；

需内更新的运行文件存储于所述版本目录中；其中，需内更新的运行文件的文件名以该运行文件的哈希值作为文件名。

作为一种实现方式，所述方法还包括：

将所述资源数据库设置于版本目录中；

在所述资源数据库中为所述第一应用建立资源的原始文件名和重命名之后的文件名映射关系。

作为一种实现方式，所述文件名映射关系表中包括以下至少之一：

文件类型、文件名、安装或更新后文件大小、文件哈希值、安装或更新后文件存放路径、文件存储位置。

作为一种实现方式，所述方法还包括：

所述更新包安装后首次启动时，在配置数据库中获取所述第一应用的版本信息，基于所述版本信息在所述资源数据库中调用与查找的版本信息对应的文件名映射关系表，基于所调用的文件名映射关系表获取文件的路径信息，基于所述路径信息加载对应的文件。

作为一种实现方式，所述方法还包括：

通过所述第一端口接收所述第一应用未更新的信息，获取用户帐号和区服管理模块地址，向所述用户帐号和区服管理模块发起业务请求，获取分区列表；

响应于分区选择指令，根据所选分区对应的端口地址，与业务服务器建立通信链路进行通信。

根据本申请的第二方面，提供一种客户端，包括：

发送单元，用于通过第一端口向服务器侧发送第一应用的本地版本；

接收单元，用于通过所述第一端口接收所述第一应用更新至第一版本的更新信息；所述第一版本高于所述本地版本；

下载单元，用于基于所述更新信息下载所述第一应用更新至所述第一版本的更新包；

加载单元，用于在所述第一应用的可写目录中解压所述更新包，将资源数据库中所述本地版的文件名映射关系表复制而生成所述第一版本的文件名映射关系表；

更新单元，用于将所述更新包更新后的更新或新增的文件条目写入所述第一版本的文件名映射关系表，并将所述第一版本的文件名映射关系表中更新或新增的文件条目的存储位置更新为解压的实际存储位置；

配置单元，用于将配置数据库中的所述第一应用的版本值设置为所述第一版本。

作为一种实现方式，所述客户端还包括：

设置单元，用于为所述第一应用的运行文件设置静态目录和版本目录；

存储单元，用于将无需更新的运行文件存储于所述静态目录中；

需内更新的运行文件存储于所述版本目录中；其中，需内更新的运行文件的文件名以该运行文件的哈希值作为文件名。

作为一种实现方式，所述客户端还包括：

设置单元，用于在版本目录设置将所述资源数据库；在所述资源数据库中为所述第一应用建立资源的原始文件名和重命名之后的文件名映射关系。

作为一种实现方式，所述客户端还包括：

调用单元，用于在所述更新包安装后首次启动时，在配置数据库中获取所述第一应用的版本信息，基于所述版本信息在所述资源数据库中调用与查找的版本信息对应的文件名映射关系表，基于所调用的文件名映射关系表获取文件的路径信息，基于所述路径信息加载对应的文件。

本申请实施例提供的客户端应用更新方法及客户端，通过对客户端的应用中的资源文件设置静态目录和版本目录，将无需内更的资源文件存储于静态目录中，而需内更新的运行文件存储于版本目录中，而对于需内更的文件，以文件的哈希值作为其文件名，每次更新后，需要建立更新后相应版本的文件名映射关系表，将不同版本的相关文件存储于对应的文件名映射关系表中。如此，本申请实施例支持应用的多个版本的资源文件并存，避免版本回滚时重复下载，版本回滚时可以用于实现游戏灰度更新，同时复用没有变化的资源文件。本申请实施例的应用更新不是覆盖式更新，避免了更新过程中断或者出错影响客户端。

附图说明

图1为本申请实施例提供的客户端应用更新方法流程示意图；

图2为客户端应用更新流程示意图；

图3为客户端应用更新另一流程示意图；

图4为本申请实施例提供的客户端的组成结构示意图。

具体实施方式

本申请实施例的技术方案支持应用的多个版本的资源文件并存，避免版本回滚时重复下载。版本回滚可以用于实现游戏灰度更新。同时复用没有变化的资源文件。本申请实施例的技术方案不是覆盖式更新，避免更新过程中断或者出错影响客户端。以下结合示例，详细阐明本申请实施例的技术方案的实质。本申请实施例以游戏为例进行说明，需要说明的是，任何应用均可通过本申请实施例的方式进行应用升级，本申请实施例并不限于游戏应用的更新。

图1为本申请实施例提供的客户端应用更新方法流程示意图，如图1所示，本申请实施例的客户端应用更新方法包括以下处理步骤：

步骤101，通过第一端口向服务器侧发送第一应用的本地版本。

本申请实施例中，第一端口可以是vmsapi接口，该vmsapi接口是与网络服务器通信获取应用版本相关信息的端口。客户端client可以发送相关请求消息给vmsapi，检查版本更新。vmsapi返回响应消息，以确定当前本地版本是否与服务器侧的版本一致，若当前版本低于服务器侧的版本，则返回更新文件下载地址，否则返回global server地址，以供客户端发起相关业务，如开始进行游戏等。

步骤102，通过所述第一端口接收所述第一应用更新至第一版本的更新信息；所述第一版本高于所述本地版本。

本申请实施例中，当确定客户端的应用版本低于服务器侧的版本时，通过第一端口接收更新相关信息，这里主要是更新数据包的下载信息等。

步骤103，基于所述更新信息下载所述第一应用更新至所述第一版本的更新包。

基于第一端口返回的更新数据包的下载地址，寻址到相应地址进行数据包下载。

步骤104，在所述第一应用的可写目录中解压所述更新包，将资源数据库中所述本地版的文件名映射关系表复制而生成所述第一版本的文件名映射关系表。

本申请实施例中，可更新的资源文件中，还包括文件存储位置信息，其标示该文件不存在、只读、可写等，例如，取值是0，表示文件不存在，取值是1，表示文件只读，取值是2，表示可写。

步骤105，将所述更新包更新后的更新或新增的文件条目写入所述第一版本的文件名映射关系表，并将所述第一版本的文件名映射关系表中更新或新增的文件条目的存储位置更新为解压的实际存储位置。

本申请实施例中，更新或新增的文件条目的存储位置为可写目录。

步骤106，将配置数据库中的所述第一应用的版本值设置为所述第一版本。

将应用的更新包中的文件更新完毕后，本申请实施例的应用由当前的版本更新为第一版本。

本申请实施例中，当前版本和第一版本可以是连续的版本差异，也可以是非连续的版本差异，如当前版本是版本1，第一版本是版本3等。

本申请实施例中，可以为所述第一应用的运行文件设置静态目录和版本目录；

无需更新的运行文件存储于所述静态目录中；

需内更新的运行文件存储于所述版本目录中；其中，需内更新的运行文件的文件名以该运行文件的哈希值作为文件名。

本申请实施例中，将所述资源数据库设置于版本目录中；

在所述资源数据库中为所述第一应用建立资源的原始文件名和重命名之后的文件名映射关系。所述文件名映射关系表中包括以下至少之一：

文件类型、文件名、安装或更新后文件大小、文件哈希值、安装或更新后文件存放路径、文件存储位置。

本申请实施例中，所述更新包安装后首次启动时，在配置数据库中获取所述第一应用的版本信息，基于所述版本信息在所述资源数据库中调用与查找的版本信息对应的文件名映射关系表，基于所调用的文件名映射关系表获取文件的路径信息，基于所述路径信息加载对应的文件。

图2为客户端应用更新流程示意图，如图2所示，client中某应用的版本号为A，线上版本号为A。客户端应用更新流程包括以下步骤：

步骤1、client发送请求给vmsapi，检查版本更新。

步骤2、vmsapi返回消息，没有更新内容需要下载，返回值中附带global server地址。

步骤3、client向global server发起请求，获取分区列表。

步骤4、global server返回分区列表。

步骤5、用户选择了一个分区，client根据分区列表中的IP和端口，向game server发起通信。

步骤6、game server接受连接请求，发出响应。

图3为客户端应用更新另一流程示意图，如图3所示，客户端中的某应用的版本号为A，线上版本号为B，版本B高于版本A。

步骤1、client发送请求给vmsapi，检查版本更新。

步骤2、vmsapi返回消息，提示客户端更新，返回值中附带更新包下载链接和global server地址。

步骤3、客户端向CDN发起下载请求。

步骤4、客户端从CDN下载到7z更新包，完成客户端版本更新，客户端版本号变为B。

步骤5、client重启，再次发送请求给vmsapi，检查版本更新。

步骤6、vmsapi返回消息，没有更新内容需要下载，返回值中附带global server地址。

步骤7、client向global server发起请求，获取分区列表。

步骤8、global server返回分区列表。

步骤9、用户选择了一个分区，client根据分区列表中的IP和端口，向game server发起通信。

步骤10、game server接受连接请求，发出响应。

本申请实施例中，以游戏客户端为例，游戏应用中的文件包括以下文件：配置文件(config)、脚本文件(script)、游戏资源文件(asset)等。这些文件，大部分是能在游戏的后续版本中进行更新的，但是也有一定不会更新的文件，如字体。所以，本申请实施例从是否会更新的角度对上述文件进行划分，分为两类，会更新的：如脚本、数值配置等；不会更新的：如字体等。

本申请实施例中，对于开发环境下，在资源目录(即iOS对应的Resources目录，Android对应的asset目录)下的文件，按照下面的方式存储：

这些文件，存储于手机等电子设备的安装包(如IPA)中时，存放方式会变成如下的状态(本申请实施例中省略了其他不相关的文件)

本申请实施例中，应用中的资源文件存放规则如下：

设置static目录，在static目录里，存放的是不需要内更新的文件，它们的存放方式于开发环境相同，没有发生变化。

设置release目录，其他可以内更新的文件，全部都被重命名，存储于release目录下。在release目录中，文件名称由文件的哈希值确定，这里的哈希运算可以是md5等，可以按照应用的不同版本设置资源数据库，以按版本将资源文件分别存储，以方便应用回退到之前的版本。release目录中，文件是由文件内容决定的，如通过md5确定。例如，对于a.png和b.png两个文件，如果其内容相同，那么重命名之后，它们会是同一个名称。即a和b应该是相同的字符。

本申请实施例中，在资源数据库即名称为reslib的sqlite数据库中，为资源的原始文件名和应用更新之后重命名之后的文件名建立映射关系，reslib里的会把文件名的映射关系按照版本号来分表。比如安装包的版本是100，那么，reslib会有一张名称为version_100的表，表内容举例如下表1所示：

表1

表1中，各字段说明如下：

type：文件类型，可能的取值是config/script/asset等文件类型，

filename：文件名，资源文件在Resources目录下的相对路径；

size：处理完后的文件大小；

md5：处理完之后文件md5；

url：处理完之后的文件存放路径；

location：文件存储位置，可能取值是0：文件不存在，1：只读路径2：可写路径；

只读目录下，内容结构与安装包里的结构完全一致。

客户端首次启动之后，在应用的可写目录结构如下：

因为后续游戏内更新的时候，会向reslib中增加新版本更新后的文件及其文件映射关系，而只读目录下不能修改，所以资源数据库(reslib)从只读目录复制到可写目录。

可写目录下新建了一个setting数据库，里面有一张app_setting的表，是键值(key-value)形式。名为currentVersion的key被设置为100，表示当前客户端版本号是100。

客户端启动后，加载文件的流程，以加载script/main.lua为例，包括以下加载步骤：

1.读出app_setting表中的currentVersion，得知版本号是100。

2.然后去reslib里查找version_100的文件映射关系表。

3.根据表中filename为script/main.lua的记录，得知文件的实际路径是372/1ccbf2921a72959a97de5572ea4e7e5b000174.lua，location是1，表示文件在只读目录里。

本申请实施例中，客户端只会在启动阶段和从内更新之后完成之后从DB读一次currentVersion，不会每次加载资源都读DB。

启动之后，游戏客户端调用vmsapi检查版本更新，将客户端版本号发送给vmsapi，vmsapi给出的返回值入下：

响应值中package数组就是本次更新需要下载的7z文件。例如是从100版本至101版本所需更新的文件，本示例中，只有script/main.lua发生了变化，变化很少，所以只有一个7z文件。如果在更新比较多的时候，package数组里可能会有多个7z文件。

package中的url拼接上resource_url_root前缀之后，就是7z更新包的完整下载地址：

7z更新包里的内容如下：

所有发生变化的文件，会用安装包里同样的规则重命名，然后存储到release目录里。因为从版本100到版本101只有script/main.lua一个文件发生变化，所以这里更新包解压之后，release目录下只有一个文件。

update.sql里是用于更新reslib中version_101表的sql语句。内容如下：

replace into version_101

(″type″，″filename″，″size″，″md5″，″url″，″location″)

values

(′script′，′script/main.lua′，′15533′，′c4c15149aae1278e63f405cd94a0ba94′，

′173/c4c15149aae1278e63f405cd94a0ba94003CAD.1ua′，0)

客户端下载7z文件之后，会解压到可写目录，可写目录更新之后的状态如下：

其中，reslib中的version_100会被复制为version_101，执行update.sql，将version_101中所有location＝0的条目，更新其location为2。

正确设置新版本文件的location之后，reslib中的version_101表如表2所示：

表2

setting数据库中的app_setting表里的currentVersion被更新为101。然后客户端重启Lua，至此，客户端从100版本更新至101版本的流程最终完成。

本申请实施例中，客户端的更新逻辑如下：

1.客户端启动，当前版本号是100。

2.调用vmsapi接口，并从接口响应得知新版本号是101，并获得7z格式的更新包的CDN下载地址。

3.从CDN下载7z更新包。

4.在应用的可写目录(Documents目录)解压7z更新包。

5.将reslib中的version_100复制为version_101。

6.执行update.sql，将变化或者新增的文件条目写入version_101表。

7.将version_101中所有location＝0的文件条目(即本次更新新增的文件或者发生变化的文件)的location值设置为1(1表示iOS上应用的Documents目录)。

8.将setting数据库中app_setting表中的currentVersion值设置为101。

10.重启客户端。

本申请实施例的技术方案，几乎所有应用都可以利用此进行更新，当应用为游戏时，除非底层代码改动，所有的游戏更新内容都可以通过此方案实现内更新。很多游戏发行要求实现游戏灰度更新，即部分玩家先更新。通过此技术方案，可以实现灰度更新以及灰度更新后的版本回滚方案。

图4为本申请实施例提供的客户端的组成结构示意图，如图4所示，本申请实施例的客户端包括：

发送单元40，用于通过第一端口向服务器侧发送第一应用的本地版本；

接收单元41，用于通过所述第一端口接收所述第一应用更新至第一版本的更新信息；所述第一版本高于所述本地版本；

下载单元42，用于基于所述更新信息下载所述第一应用更新至所述第一版本的更新包；

加载单元43，用于在所述第一应用的可写目录中解压所述更新包，将资源数据库中所述本地版的文件名映射关系表复制而生成所述第一版本的文件名映射关系表；

更新单元44，用于将所述更新包更新后的更新或新增的文件条目写入所述第一版本的文件名映射关系表，并将所述第一版本的文件名映射关系表中更新或新增的文件条目的存储位置更新为解压的实际存储位置；

配置单元45，用于将配置数据库中的所述第一应用的版本值设置为所述第一版本。

作为一种实现方式，所述客户端还包括：

设置单元(图4中未示出)，用于为所述第一应用的运行文件设置静态目录和版本目录；

存储单元(图4中未示出)，用于将无需更新的运行文件存储于所述静态目录中；

需内更新的运行文件存储于所述版本目录中；其中，需内更新的运行文件的文件名以该运行文件的哈希值作为文件名。

作为一种实现方式，所述客户端还包括：

设置单元(图4中未示出)，用于在版本目录设置将所述资源数据库；在所述资源数据库中为所述第一应用建立资源的原始文件名和重命名之后的文件名映射关系。

作为一种实现方式，所述客户端还包括：

调用单元(图4中未示出)，用于在所述更新包安装后首次启动时，在配置数据库中获取所述第一应用的版本信息，基于所述版本信息在所述资源数据库中调用与查找的版本信息对应的文件名映射关系表，基于所调用的文件名映射关系表获取文件的路径信息，基于所述路径信息加载对应的文件。

在示例性实施例中，客户端的上述处理单元可以被一个或多个中央处理器(CPU，Central Processing Unit)、图形处理器(GPU，Graphics Processing Unit)、基带处理器(BP，Base Processor)、应用专用集成电路(ASIC，Application Specific IntegratedCircuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable Gate Array)、通用处理器、控制器、微控制器(MCU，Micro ControllerUnit)、微处理器(Microprocessor)、或其他电子元件实现，也可以结合一个或多个射频(RF，Radio Frequency)天线实现，用于执行前述实施例的网络数据收集方法的步骤。

在本公开实施例中，图4示出的客户端中各个模块及单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

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

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

以上所述，仅为本发明的实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。