掌桥专利:专业的专利平台
掌桥专利
首页

版本更新方法及相关设备

文献发布时间:2023-06-19 13:49:36


版本更新方法及相关设备

技术领域

本发明涉及计算机技术领域,尤其涉及一种版本更新方法及相关设备。

背景技术

在模型-视图-视图模型(Model-View-ViewModel,MVVM)前端架构中,以单页Web应用(single page web application,SPA)为用户提供浏览页面。其中,SPA是一种只提供一页Web页面的应用,通过加载单个页面并在用户与应用程序交互时动态更新该页面的Web应用程序。

目前,对SPA进行版本更新的方式通常为:在SPA新版本发布后,人工启动加载程序,加载SPA新版本,实现对原有的SPA进行版本更新。

然而,在SPA为全量更新的情况下,若SPA在更新过程中未产生路由更新,则用户客户端的浏览器不会部署静态资源,这样,如果有用户访问浏览页面,则该浏览页面会加载前一版本SPA的静态资源,造成页面报错。

发明内容

本发明实施例提供一种版本更新方法及相关设备,以解决现有技术中需要人工对SPA进行版本更新,容易引起SPA页面报错的技术问题。

第一方面,本发明实施例提供了一种版本更新方法,包括:

在接收到与目标应用对应的更新文件的情况下,打包所述更新文件并生成所述更新文件对应的第一版本号,所述目标应用为单页面应用;

将所述更新文件和所述第一版本号合并为脚本文件;

在所述目标应用产生路由更新的情况下,对所述第一版本号进行验证;

在验证通过的情况下,使用所述脚本文件更新所述目标应用。

第二方面,本发明实施例提供了一种版本更新装置,包括:

打包模块,用于在接收到与目标应用对应的更新文件的情况下,打包所述更新文件并生成所述更新文件对应的第一版本号,所述目标应用为单页面应用;

合并模块,用于将所述更新文件和所述第一版本号合并为脚本文件;

验证模块,用于在所述目标应用产生路由更新的情况下,对所述第一版本号进行验证;

更新模块,用于在验证通过的情况下,使用所述脚本文件更新所述目标应用。

第三方面,本发明实施例提供了一种通信设备,包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述计算机程序被所述处理器执行时实现上述版本更新方法的步骤。

第四方面,本发明实施例提供了一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现上述用户行为分析方法的步骤。

本发明实施例中,在接收到与目标应用对应的更新文件的情况下,打包更新文件并生成更新文件对应的第一版本号;将更新文件和第一版本号合并为脚本文件;在目标应用产生路由更新的情况下,对第一版本号进行验证;在验证通过的情况下,使用脚本文件更新目标应用。本发明实施例中,在目标应用产生路由更新的情况下,也就是用户使用的客户端在部署全部的静态资源之后,对脚本文件中的第一版本号进行验证;在验证通过后,使用脚本文件更新目标应用。这样,版本更新过程中,在确保部署全部的静态资源之后,才使用脚本文件更新目标应用,以此防止浏览页面报错,进而提高了版本更新的效率。

附图说明

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

图1是现有技术中版本更新的流程示意图;

图2是本发明实施例提供的版本更新方法的流程图;

图3是本发明实施例提供的版本更新方法的应用流程示意图;

图4是本发明实施例提供的版本更新切割装置的结构图;

图5是本发明实施例提供的通信设备的结构图。

具体实施方式

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

请参阅图1,图1是现有技术中版本更新的流程示意图。如图1所示,现有的版本更新的流程通常为:研发人员发布新版本应用,由于SPA只能与对应的服务器通信,因此在发布新版本应用后,需要通知产品业务人员手动刷新旧版本应用,对新版本应用进行验证,随后人工启动加载程序,加载新版本应用,实现版本更新。

在上述版本更新过程中,需要产品业务人员人工进行版本更新,这降低了版本更新的效率。并且,在更新过程中,若浏览器未部署完全部静态资源,且接收到用户访问浏览页面的请求的情况下,将造成浏览页面报错。

其中,上述浏览页面是由浏览器提供的服务,浏览页面可以在浏览器用中运行,或者,在将浏览器内置于第三方应用,使得浏览页面在第三方应用中运行。上述浏览器可以是浏览器插件、浏览器小程序等。

为了解决上述存在的技术问题,本发明实施例提供了一种版本更新方法,该版本更新方法可以应用于服务器端。请参见图2,图2是本发明实施例提供的版本更新方法的流程图,如图2所示,包括以下步骤:

101,在接收到与目标应用对应的更新文件的情况下,打包所述更新文件并生成所述更新文件对应的第一版本号。

上述目标应用为SPA应用;上述脚本文件可以是文件类型为js的文件,上述脚本文件又称为js文件。

本步骤中,在接收到目标应用对应的更新文件的情况下,可以调用Jsonp模式,打包该更新文件,并生成该更新文件对应的第一版本号。具体的如何生成版本号的方式请参见后续实施例。

其中,上述更新文件可以理解为研发人员发布的新版本应用的安装包;上述Jsonp是浏览页面的一种调用元素的模式,应用该模式的浏览页面可以从其他服务器中调用元素,实现跨域数据访问。

102,将所述更新文件和所述第一版本号合并为脚本文件。

本步骤中,在生成第一版本号以及打包该更新文件后,将更新文件和第一版本号合并为脚本文件,该脚本文件可以表示为version.js。这一实施方式中,可以调用文件系统对象将脚本文件创建至目标应用的根目录。

在其他实施例中,在生成更新文件对应的第一版本号后,打包更新文件,基于更新文件生成脚本文件,脚本文件中不包含第一版本号。将第一版本号存储至服务器中,后续可以通过调用相关接口,获取该服务器存储的第一版本号。

本步骤中,将更新文件和第一版本号合并为js形式的脚本文件,这样,在目标应用的版本更新过程中,可以实现跨域数据访问,不需要专门的产品业务人员对目标应用进行人工更新。

103,在所述目标应用产生路由更新的情况下,对第一版本号进行验证。

应理解,目标应用通常有2种方式实现路由更新,第一种方式为hash模式,另一种方式为state模式,具体的实施方式,请参阅后续实施例。

在目标应用产生路由更新的情况下,对脚本文件中的第一版本号进行验证。其中,上述对第一版本号进行验证的方法可以表示为window.checkVersion。或者,在生成第一版本号后,将第一版本号存储至服务器中,在目标应用产生路由更新的情况下,调用相关接口查询服务器存储的第一版本号。具体的如何验证第一版本号的实施方式,请参阅后续实施例。

104,在验证通过的情况下,使用所述脚本文件更新所述目标应用。

本步骤中,若第一版本号验证无误,则可以解析脚本文件,得到更新文件;进而加载更新文件,以更新目标应用。

本发明实施例中,在接收到与目标应用对应的更新文件的情况下,打包更新文件并生成更新文件对应的第一版本号;将更新文件和第一版本号合并为脚本文件;在目标应用产生路由更新的情况下,对第一版本号进行验证;在验证通过的情况下,使用脚本文件更新目标应用。本发明实施例中,在目标应用产生路由更新的情况下,也就是用户使用的客户端在部署全部的静态资源之后,对脚本文件中的第一版本号进行验证;在验证通过后,使用脚本文件更新目标应用。这样,版本更新过程中,在确保部署全部的静态资源之后,才使用脚本文件更新目标应用,以此防止浏览页面报错,进而提高了版本更新的效率。

可选地,所述对所述第一版本号进行验证之前,所述方法包括:

在监听到第一事件的情况下,确定所述目标应用产生路由更新。

本实施例中,上述第一事件可以表示为window.onhashchange,第一事件表征目标应用对应的哈希值发生变化,即上述hash模式。

这种模式下,为目标应用赋予了一个哈希值,若目标应用产生路由更新,目标应用对应的哈希值会发送变化。在监听到第一事件的情况下,通过读取目标应用对应的哈希值,判断目标应用是否产生路由更新。若目标应用对应的哈希值发生改变,则判断目标应用产生路由更新,若目标应用对应的哈希值未发生改变,则判断目标应用未产生路由更新。

本实施例中,设置第一事件,并通过监听第一事件判断目标应用是否发生路由更新,即目标应用对应的浏览器是否已加载全部的静态资源,进而防止浏览页面在后续交互过程中报错。

可选地,所述对所述第一版本号进行验证之前,所述方法包括:

在监听到第二事件的情况下,确定所述目标应用产生路由更新。

本实施例中,上述第二事件可以表示为window.onpopstate,第二事件表征目标应用新增路由记录,即上述state模式。

这种模式下,若目标应用产生路由更新,会产生一条历史记录,通过读取目标应用产生的历史记录,判断目标应用是否产生路由更新。在监听到第二事件的情况下,读取目标应用对应的历史记录,该历史记录可以是路由纪录,若产生了新的路由历史纪录,则确定目标应用产生路由更新;若未产生新的路由历史纪录,则确定目标应用产生路由未更新。

本实施例中,设置第二事件,并通过监听第二事件判断目标应用是否发生路由更新,即目标应用对应的浏览器是否已加载全部的静态资源,进而防止浏览页面在后续交互过程中报错。

可选地,所述生成所述更新文件对应的第一版本号包括:

基于所述更新文件对应的打包时间,生成所述第一版本号;或者

基于所述更新文件对应的通用唯一识别码,生成所述第一版本号;或者

将获取到的用户输入的版本号确定为所述第一版本号。

本实施例中,可以通过下述方法生成第一版本号:

一种可选的实施方式为,获取更新文件对应的打包时间,并基于上述打包时间,动态生成第一版本号。例如,第一版本号中的部分字段用于表征该打包时间。

另一种可选的实施方式为,调用相关工具,生成更新文件对应的通用唯一识别码(Universally Unique Identifier,UUID),并基于上述通用唯一识别码,动态生成第一版本号。例如,第一版本号中的部分字段用于表征该通用唯一识别码。

另一种可选的实施方式为,自定义设置第一版本号,即将用户输入的版本号确定为第一版本号。

另一种可选的实施方式为,获取更新文件对应的打包时间,将该打包时间转换为时间戳,并将该时间戳作为第一版本号。

另一种可选的实施方式为,使用随机数生成算法,生成随机数,并将该随机数作为第一版本号。

应理解,也可以通过其他方式生成第一版本号,本实施例在此不对第一版本号的生成方式做具体限定。

本实施例中,可以基于更新文件对应的打包时间,或更新文件对应的通用唯一识别码,或用户输入的版本号,确定第一版本号,以便在后续版本验证步骤中对第一版本号进行验证。

可选地,所述将所述更新文件和所述第一版本号合并为所述脚本文件之前,所述方法包括:

获取所述更新文件对应的打包时间;

将所述打包时间转换为时间戳;

所述将所述更新文件和所述第一版本号合并为所述脚本文件之后,所述方法包括:

添加所述时间戳至所述脚本文件。

本实施例中,在对更新文件进行打包后,获取打包时间,并将该打包时间转换为时间戳。

一种可选地实施方式为,这里时间戳格式可以是年月日时分秒毫秒(即:yyyyMMddHHmmssSSS),比如打包时间为2021年9月9日21点00分00秒123毫秒,那么可以设置该打包时间对应的时间戳为20210909210000123。

进一步的,在得到脚本文件之后,对脚本文件进行加载之前,添加时间戳至脚本文件。

本实施例中,在生成的脚本文件中加入时间戳,防止生成重复的版本号。这样,在后续将会话存储对象中缓存的版本号与第一版本号进行比较的版本验证步骤中,避免会话存储对象缓存的版本号与第一版本号为同一版本号,进而影响版本验证的结果,以此确保版本验证结果的准确性。上述会话存储对象可以表示为sessionStorage。

可选地,所述将所述更新文件和所述第一版本号合并为所述脚本文件之后,所述方法包括:

使用随机数生成算法,生成随机数;

将所述随机数添加至所述脚本文件。

本实施例中,在得到脚本文件之后,对脚本文件进行加载之前,可以使用预先设置的随机数生成算法,生成随机数,并将该随机数添加至脚本文件。防止生成重复的版本号。

这样,在后续的将会话存储对象中缓存的版本号与第一版本号进行比较的版本验证步骤中,可以避免会话存储对象缓存的版本号与第一版本号为同一版本号,确保版本验证结果的准确性。

可选地,所述对所述第一版本号进行验证包括:

从所述目标应用的会话存储对象中,获取所述目标应用对应的第二版本号;

在所述第二版本号与所述第一版本号不同的情况下,确定验证通过;

在验证通过的情况下,将所述会话存储对象存储的版本号更新为所述第一版本号。

应理解,目标应用的会话存储对象预先存储有目标应用对应的第二版本号;上述第二版本号为目标应用的当前版本号,上述第二版本号可以表示为currVersion,即目标应用未更新之前的版本号。脚本文件中的部分字段与会话存储对象关联,这样,在目标应用产生路由更新的情况下,将脚本文件中的第一版本号作为参考对象,与会话存储对象存储的第二版本号进行比较。

一种可能存在的情况为,第二版本号与第二版本号相同,这种情况下,说明目标应用已更新,则确定验证未通过,不使用脚本文件更新目标应用。

另一种可能存在的情况为,第二版本号与第二版本号不同,或者会话存储对象中不存在第二版本号,这种情况下,说明目标应用未更新,则确定验证通过,使用脚本文件更新目标应用。

在验证通过的情况下,将会话存储对象存储的版本号更新为第一版本号,用于在目标应用的下次更新过程中,验证脚本文件。

本实施例中,通过比较脚本文件中的第一版本号与会话存储对象中存储的第二版本号,确定目标应用的更新状态,以此判断第一版本号是否为最新的版本号。

本发明实施例中,存在2种使用脚本文件更新目标应用的实施方式,即静默更新和询问更新,以下具体说明:

使用静默更新的方式更新目标应用的实施方式为:

可选地,所述在验证通过的情况下,使用所述脚本文件更新所述目标应用包括:

在验证通过的情况下,对所述目标应用进行路由更新;

在对所述目标应用进行路由更新的过程中,解析所述脚本文件,得到更新文件;

加载所述更新文件,获得更新后的应用。

本实施例中,在验证通过的情况下,对目标应用进行路由更新,上述对目标应用进行路由更新可以理解为是刷新目标应用对应的浏览页面。在目标应用进行路由更新的过程中,可以使用JavaScript直译器解析脚本文件,得到更新文件。进一步的,加载更新文件,实现对目标应用的更新。

本实施例中,在验证通过的情况下,自动执行相关操作,实现目标应用的静默更新。

使用询问更新的方式更新目标应用的实施方式为:

可选地,所述在验证通过的情况下,使用所述脚本文件更新所述目标应用包括:

在验证通过的情况下,发送询问信息;

在接收到对所述询问信息的确认指令的情况下,解析所述脚本文件,得到更新文件;

加载所述更新文件,获得更新后的应用。

本实施例中,在验证通过的情况下,发送询问信息,上述询问信息可以是目标应用对应的浏览器显示的弹窗。若接收到对询问信息的确认指令,则使用JavaScript直译器解析脚本文件,得到更新文件,其中,确认指令用于表征更新目标应用。进一步的,加载更新文件,实现对目标应用的更新。

若在预设时间内未接收到对询问信息的确认指令,或者接收到对询问信息的否定指令,则不解析脚本文件,不更新目标应用。

示例性的,在验证通过的情况下,目标应用对应的浏览器显示的弹窗,该弹窗的内容可以为“当前已存在新版本更新,是否立即更新”,并且该弹窗包括2个控件,第一个控件显示有“是”,第二个控件显示有“否”。若接收到用户对第一个控件的触控指令,则将该触控指令视为确认指令,解析脚本文件,进而更新目标应用;若接收到用户对第二个控件的触控指令,则将该触控指令视为否定指令,则不更新目标应用。

本实施例中,在验证通过的情况下,发出询问信息,进而根据用户的操作,自定义设置是否更新目标应用,实现目标应用的询问更新。

为便于理解整体方案,请参阅图3,图3是本发明实施例提供的版本更新方法的应用流程示意图。如图3所示,服务器在接收到更新文件的情况下,动态生成该更新文件的第一版本号;随后生成包含第一版本号的脚本文件,该脚本文件为js文件,并定义版本号的验证方法,上述内容为服务器的编译阶段。服务器全局监听目标应用对应的浏览页面是否发生路由更新。在发生路由更新的情况下,浏览器端使用Jsonp技术加载服务器中的js文件,获取第一版本号;对第一版本号使用上述定义的版本号的验证方法进行验证;在第一版本号不为最新版本号的情况下,浏览器端退出更新,在第一版本号为最新版本号的情况下,使用静默更新或询问更新的方式,浏览器端更新目标应用。

参见图4,图4是本发明实施例提供的版本更新装置的结构图,如图4所示,版本更新装置200包括:

打包模块201,用于在接收到与目标应用对应的更新文件的情况下,打包所述更新文件并生成所述更新文件对应的第一版本号;

合并模块202,用于将所述更新文件和所述第一版本号合并为脚本文件;

验证模块203,用于在所述目标应用产生路由更新的情况下,对所述第一版本号进行验证;

更新模块204,用于在验证通过的情况下,使用所述脚本文件更新所述目标应用。可选地,所述版本更新装置200,还包括:

第一监听模块,用于在监听到第一事件的情况下,确定所述目标应用产生路由更新。

可选地,所述版本更新装置200,还包括:

第二监听模块,用于在监听到第二事件的情况下,确定所述目标应用产生路由更新。

可选地,所述打包模块201,还具体用于:

基于所述更新文件对应的打包时间,生成所述第一版本号;或者

基于所述更新文件对应的通用唯一识别码,生成所述第一版本号;或者

将获取到的用户输入的版本号确定为所述第一版本号。

可选地,所述版本更新装置200,还包括:

获取模块,用于获取所述更新文件对应的打包时间;

转换模块,用于将所述打包时间转换为时间戳;

第一添加模块,用于添加所述时间戳至所述脚本文件。

可选地,所述版本更新装置200,还包括:

生成模块,用于使用随机数生成算法,生成随机数;

第二添加模块,用于将所述随机数添加至所述脚本文件。

可选地,所述验证模块203,具体用于:

从所述目标应用的会话存储对象中,获取所述目标应用对应的第二版本号;

在所述第二版本号与所述第一版本号不同的情况下,确定验证通过;

在验证通过的情况下,将所述会话存储对象存储的版本号更新为所述第一版本号。

可选地,所述更新模块204,具体用于:

在验证通过的情况下,对所述目标应用进行路由更新;

在对所述目标应用进行路由更新的过程中,解析所述脚本文件,得到更新文件;

加载所述更新文件,获得更新后的应用。

可选地,所述更新模块204,还具体用于:

在验证通过的情况下,发送询问信息;

在接收到对所述询问信息的确认指令的情况下,解析所述脚本文件,得到更新文件;

加载所述更新文件,获得更新后的应用。

本发明实施例提供的版本更新装置能够实现如上方法实施例中版本更新方法的各个过程,为避免重复,这里不再赘述。

参见图5,图5是本发明实施例提供的服务器的结构图,如图5所示,该服务器300包括:处理器301、收发机302、存储器303和总线接口,其中:

处理器301,用于执行以下操作:

在接收到与目标应用对应的更新文件的情况下,打包所述更新文件并生成所述更新文件对应的第一版本号;

将所述更新文件和所述第一版本号合并为脚本文件;

在所述目标应用产生路由更新的情况下,对所述第一版本号进行验证;

在验证通过的情况下,使用所述脚本文件更新所述目标应用。

应理解,本实施例中,上述处理器301和收发机302能够实现图2的方法实施例中的各个过程,为避免重复,这里不再赘述。

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

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

本发明实施例还提供一种计算机可读存储介质,计算机可读存储介质上存储有计算机程序,该计算机程序被处理器执行时实现上述版本更新方法实施例的各个过程,且能达到相同的技术效果,为避免重复,这里不再赘述。其中,所述的计算机可读存储介质,如只读存储器(Read-Only Memory,简称ROM)、随机存取存储器(Random Access Memory,简称RAM)、磁碟或者光盘等。

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

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

上面结合附图对本发明的实施例进行了描述,但是本发明并不局限于上述的具体实施方式,上述的具体实施方式仅仅是示意性的,而不是限制性的,本领域的普通技术人员在本发明的启示下,在不脱离本发明宗旨和权利要求所保护的范围情况下,还可做出很多形式,均属于本发明的保护之内。

相关技术
  • 版本更新方法及相关设备
  • 程序版本的更新方法、自助设备和版本控制服务器
技术分类

06120113822957