一种前端版本更新检测方法、装置、设备和存储介质

技术领域

本申请涉及计算机领域，尤其涉及一种前端版本更新检测方法、装置、设备和存储介质。

背景技术

随着互联网技术的发展，前端应用因其灵活性高、开发成本低、制作周期短等优势，越来越广泛的被应用。在如金融科技等领域，如银行、金融机构等企业内，由于金融交易类型和交易业务的不断迭代更新(如贷款业务从小微贷款业务扩展到融合贷款业务、自营贷款业务等)，使得前端应用随着交易业务等的迭代和发展而需要实时更新版本。为了避免客户端需要频繁发版的问题，前端应用往往迭代快速和经常需要更新。

前端应用的更新后，有时会因缓存的原因造成当前浏览器加载的应用和现有服务器的应用版本不一致，当本地数据的存取、逻辑操作、前端应用跟后端应用的交互和应用版本有关联时，也可能会因版本更新后的缓存原因，导致逻辑处理错误，最终导致功能异常。

发明内容

有鉴于此，为了解决现有技术存在的问题，本申请实施例提供了一种可应用于如金融科技等领域或其他领域的前端版本更新检测方法、装置、设备和存储介质。

第一方面，本申请提供一种前端版本更新检测方法，包括：

获取前端项目中待打包的第一版本信息；

监听所述前端项目中目标页面发生的切换事件，以确定所述目标页面的当前页面可见性属性；

若当前页面可见性属性为可见时，发起打包请求；其中，所述打包请求用于指示打包所述第一版本信息；

判断预先保存的第二版本信息与打包的所述第一版本信息是否相等，若不相等，则触发执行自动刷新流程，以更新所述前端项目的当前版本信息。

在可选的实施方式中，若所述第二版本信息与所述第一版本信息相等，则确定所述前端项目的当前版本信息已更新。

在可选的实施方式中，所述判断预先保存的第二版本信息与所述第一版本信息是否相等，包括：

分别提取预先保存的第二版本信息与所述第一版本信息中的目标变量；其中，所述目标变量为提交哈希值；

将所述第二版本信息与所述第一版本信息中的目标变量对应进行比对，以确定所述第二版本信息与所述第一版本信息是否相等。

在可选的实施方式中，在所述获取前端项目中待打包的第一版本信息之后，还包括：

通过目标脚本将所述第一版本信息转换为JSON文件，并将所述JSON文件存储至所述前端项目的公开目录处；

在所述发起打包请求之后，还包括：

将所述公开目录内存储的所述JSON文件复制至所述前端项目的根目录处。

在可选的实施方式中，若所述当前页面可见性属性为不可见时，则暂停后续的处理流程。

在可选的实施方式中，所述方法还包括：

更改目标服务器网页设置的属性值为禁止使用缓存，所述目标服务器用于部署所述前端项目的前端静态资源。

在可选的实施方式中，所述第一版本信息和所述第二版本信息分别包括：版本分支号、提交人信息、提交哈希值、提交时间、提交参数。

第二方面，本申请提供一种前端版本更新检测装置，包括：

获取模块，用于获取前端项目中待打包的第一版本信息；

监听模块，用于监听所述前端项目中目标页面发生的切换事件，以确定所述目标页面的当前页面可见性属性；

发起模块，用于若当前页面可见性属性为可见时，发起打包请求；其中，所述打包请求用于指示打包所述第一版本信息；

更新模块，用于判断预先保存的第二版本信息与打包的所述第一版本信息是否相等，若不相等，则触发执行自动刷新流程，以更新所述前端项目的当前版本信息。

第三方面，本申请提供一种计算机设备，所述计算机设备包括存储器和至少一个处理器，所述存储器存储有计算机程序，所述处理器用于执行所述计算机程序以实施前述的前端版本更新检测方法。

第四方面，本申请提供一种计算机存储介质，其存储有计算机程序，所述计算机程序被执行时，实施根据前述的前端版本更新检测方法。

本申请实施例具有如下有益效果：

本申请实施例提供了一种前端版本更新检测方法，该方法包括：获取前端项目中待打包的第一版本信息；监听前端项目中目标页面发生的切换事件，以确定目标页面的当前页面可见性属性；若当前页面可见性属性为可见时，发起打包请求；其中，打包请求用于指示打包第一版本信息；判断预先保存的第二版本信息与第一版本信息是否相等，若不相等，则触发执行自动刷新流程，以更新前端项目的当前版本信息。本实施例通过在前端项目发布版本后，自动化获取并打包对应的第一版本信息，并根据该第一版本信息以对前端项目的版本更新进行检测；该版本检测更新过程完全纯前端自主实现，提高前端项目版本更新的检测效率，节省检测成本，以保证当前浏览器加载和显示的版本信息和所保存的版本信息一致。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对本申请保护范围的限定。在各个附图中，类似的构成部分采用类似的编号。

图1示出了本申请实施例中前端版本更新检测方法的第一个实施方式示意图；

图2示出了本申请实施例中前端版本更新检测方法的第二个实施方式示意图；

图3示出了本申请实施例中前端版本更新检测方法的第三个实施方式示意图；

图4示出了本申请实施例中前端版本更新检测方法的第四个实施方式示意图；

图5示出了本申请实施例中前端版本更新检测方法的第五个实施方式示意图；

图6示出了本申请实施例中前端版本更新检测装置的一个结构示意图。

具体实施方式

下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。

通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

在下文中，可在本申请的各种实施例中使用的术语“包括”、“具有”及其同源词仅意在表示特定特征、数字、步骤、操作、元件、组件或前述项的组合，并且不应被理解为首先排除一个或更多个其它特征、数字、步骤、操作、元件、组件或前述项的组合的存在或增加一个或更多个特征、数字、步骤、操作、元件、组件或前述项的组合的可能性。

此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

除非另有限定，否则在这里使用的所有术语(包括技术术语和科学术语)具有与本申请的各种实施例所属领域普通技术人员通常理解的含义相同的含义。所述术语(诸如在一般使用的词典中限定的术语)将被解释为具有与在相关技术领域中的语境含义相同的含义并且将不被解释为具有理想化的含义或过于正式的含义，除非在本申请的各种实施例中被清楚地限定。

在如金融科技等领域，如银行、金融机构等企业内，由于金融交易类型和交易业务的不断迭代更新(如贷款业务从小微贷款业务扩展到融合贷款业务、自营贷款业务等)，使得前端应用随着交易业务等的迭代和发展而需要实时更新版本。为了避免客户端需要频繁发版的问题，前端应用往往迭代快速和经常需要更新。为了避免客户端APP需要频繁发版的问题，前端应用往往迭代快速和经常需要更新。

前端应用的更新后，有时会因缓存的原因造成当前浏览器加载的应用和现有服务器的应用版本不一致，或者部分资源不一致，导致页面异常，页面布局错乱等显示问题；当本地数据的存取、逻辑操作、前端应用跟后端应用的交互和应用版本有关联时，也可能会因版本更新后的缓存原因，导致逻辑处理错误，最终导致功能异常。因此，无需对前端网页的当前版本信息进行实时检测。

目前业内常见的实现方案有3种：

方案一，定时轮询调用后端接口检测版本更新。

方案二，使用服务端推送技术(即Server-Sent Events，SSE)来检测版本更新。

方案三：使用WebSocket实时通信来检测版本更新。

但是这三种实现方案都有一些问题：首先，定时轮询调用后端接口检测版本更新会对服务器端和客户端造成一定的负担，而且轮询时间间隔不好控制，轮询时间间隔太短太频繁，会增加后端服务器请求压力、对前端性能也有一定的影响，轮询时间间隔太久，又不能及时更新版本内容，会影响用户体验。其次，以上三种方案都需要后端配合，需要增加额外的沟通成本和实施成本。最后，大企业后端服务架构和流程普遍比较复杂，使用服务器推送或者websocket方案会影响到现有项目的架构调整，影响面较大，而且实施成本较高。

基于此，本申请实施例提供了一种前端版本更新检测方法，通过在前端项目发布版本后，自动化获取并打包对应的第一版本信息，并根据该第一版本信息以对前端项目的版本更新进行检测；其中，该版本检测更新过程完全纯前端自主实现，减少前端与后端之间的数据交互，从而提高检测效率，节省检测成本。

请参照图1，下面对该方法进行详细说明。其中，本实施例可通过服务器或终端设备进行实现，本实施例具体以服务器为例进行说明。

S10，获取前端项目中待打包的第一版本信息。

服务器获取前端项目当前的版本信息，该版本信息作为第一版本信息，其中，前端项目的数量在此不做限定，进而，本实施例可实现至少一个前端项目的版本信息的同步检测。

具体地，采用目标脚本(如nodejs编写脚本)来获取前端项目中git相关的版本信息，并将其作为第一版本信息。其中，目标脚本可保存至前端项目的scripts目录处。

进一步地，第一版本信息包括版本分支号、提交人信息、提交哈希值(即提交的commit-sha)、提交时间、提交参数等，该提交参数可以是提交message信息等参数。需说明的是，第一版本信息的具体设置可根据实际需求进行设置，在此不做限定。

在一实施方式中，如图2所示，本实施例还具体包括如下步骤：

S70，通过目标脚本将第一版本信息转换为JSON文件，并将JSON文件存储至前端项目的公开目录(即public目录)处。

在本实施例中，在获取到第一版本信息后，再通过目标脚本将第一版本信息以JSON文件形式保存至前端项目的公开目录处，进而方便前端页面在构建工具打包第一版本信息时将第一版本信息拷贝到前端项目的dist根目录下。

需要说明的是，每次使用前端页面构建工具打包版本信息之前都会执行nodejs编写的目标脚本，来获取本次打包的版本信息并把版本信息存放到前端项目的public目录下。

S20，监听前端项目中目标页面发生的切换事件，以确定目标页面的当前页面可见性属性。

S30，若当前页面可见性属性为可见时，发起打包请求。

通过设置一监听器，来监听前端项目中目标页面发生的切换事件(即visibilitychange事件)，进而确定目标页面的当前页面可见性属性。

具体而言，在前端项目的app.js文件中，前端项目中目标页面更改属性操作，如更改显示和隐藏操作时，会触发visibilitychange事件，进而可通过监听器来监听目标页面的显示和隐藏操作，以确定目标页面的当前页面可见性。若监听到目标页面的显示操作，则确定当前页面可见性属性为真(即当前页面可见性属性为可见)；而若监听到目标页面的隐藏操作，则确定当前页面可见性属性为假(即当前页面可见性属性为不可见)。

进一步地，若当前页面可见性属性为可见时，则发起打包请求，其中，打包请求用于指示打包第一版本信息。反之，若当前页面可见性属性为不可见时，则暂停后续的处理流程。

在一实施方式中，如图3所示，本实施例还具体包括如下步骤：

S80，将公开目录内存储的JSON文件复制至前端项目的根目录处。

将保存在前端项目的公开目录处的JSON文件复制到前端项目的根目录处(即dist根目录)，以方便后续对第一版本信息进行打包。

具体而言，在监听到显示操作后，发起打包请求，以请求生产环境打包放在dist根目录下的第一版本信息。

S40，判断预先保存的第二版本信息与打包的第一版本信息是否相等。

通过接口来请求获取与前端项目关联的预先保存的第二版本信息；其中，该第二版本信息包括版本分支号、提交人信息、提交哈希值、提交时间、提交参数。也即是，第一版本信息与第二版本信息所包含的具体参数类型一致。

可以理解，在实现前端项目投产时，所保存的第二版本信息即是用户可读取的前端项目当前的版本信息；而所获取的第一版本信息即为前端项目的实际版本信息；通过将这两个版本信息进行比对，以判断前端项目投产时的当前版本信息是否已被更新。

进一步地，如图4所示，上述的S40具体包括如下步骤：

S41，分别提取预先保存的第二版本信息与第一版本信息中的目标变量。

S42，将第二版本信息与第一版本信息中的目标变量对应进行比对，以确定第二版本信息与第一版本信息是否相等。

在本实施例中，若需确定第一版本信息和第二版本信息是否相等，可仅对比第一版本信息和第二版本信息中的同一目标变量的值，进而将其比对结果作为第一版本信息与第二版本信息是否相等的判定结果。

可以理解，分别从第一版本信息和第二版本信息中提取出同一目标变量，其中，目标变量可以为提交哈希值(即commit-sha)。

进一步地，若第一版本信息中的提交哈希值与第二版本信息中的提交哈希值相等，则确定第一版本信息与第二版本信息相等；反之，若第一版本信息中的提交哈希值与第二版本信息中的提交哈希值不相等，则确定第一版本信息与第二版本信息不相等。

S50，若第二版本信息与第一版本信息不相等，则触发执行自动刷新流程，以更新前端项目的当前版本信息。

S60，若第二版本信息与第一版本信息相等，则确定前端项目的当前版本信息已更新。

在本实施例中，将第一版本信息与第二版本信息进行对比，进而根据两个版本信息的对比结果来确定前端项目的当前版本信息是否更新。

若第一版本信息与第二版本信息相等，则确定前端项目的当前版本信息已更新，进而无需对其版本信息做更新处理。这也就说明，当前保存的第二版本信息即为第一版本信息。

反之，若第一版本信息与第二版本信息不相等，则确定前端项目的当前版本信息未更新，进而执行location.reload()命令，触发执行自动刷新流程，以更新前端项目的当前版本信息，使其前端项目的当前版本信息为最新的版本信息，并保存最新的版本信息。也即是，删除保存的第二版本信息，并将第一版本信息作为当前版本信息进行保存。

作为一种可选的实施方式，如图5所示，本申请实施例还具体包括如下步骤：

S90，更改目标服务器网页设置的属性值为禁止使用缓存。

在本实施例中，将用于部署前端项目的前端静态资源的服务器作为目标服务器，该目标服务器可以是nginx服务器。而后，更改该目标服务器网页设置的属性值为禁止使用缓存。

具体而言，前端页面禁止使用缓存(no-store)，可防止用户请求到缓存的前端页面，以配合实现用户可以在不主动刷新前端页面的情况下，及时拿到投产后的最新资源包，避免用户访问到旧版本的内容，影响用户体验。

本申请实施例在前端项目发布版本后，自动化获取并打包对应的第一版本信息，并根据该第一版本信息以对前端项目的版本更新进行检测；此外，该版本检测更新过程完全纯前端自主实现，不依赖于后端，从而使得减少与后端开发人员额外的沟通成本和实施成本；更进一步的，本实施例可使得前端项目投产后，用户可以在不主动刷新前端页面的情况下，及时拿到投产后的最新资源包，避免用户访问到旧版本的内容，影响用户体验。

请参照图6，本申请实施例还提供了一种前端版本更新检测装置，该装置包括：

获取模块110，用于获取前端项目中待打包的第一版本信息；

监听模块120，用于监听所述前端项目中目标页面发生的切换事件，以确定所述目标页面的当前页面可见性属性；

发起模块130，用于若当前页面可见性属性为可见时，发起打包请求；其中，所述打包请求用于指示打包所述第一版本信息；

更新模块140，用于判断预先保存的第二版本信息与打包的所述第一版本信息是否相等，若不相等，则触发执行自动刷新流程，以更新所述前端项目的当前版本信息。

可以理解，上述的前端版本更新检测装置对应于上述实施例的前端版本更新检测方法；上述实施例中的任何可选项也适用于本实施例，这里不再详述。

本申请实施例还提供了一种计算机设备，该所述计算机设备包括存储器和至少一个处理器，所述存储器存储有计算机程序，所述处理器用于执行所述计算机程序以实施上述实施例的前端版本更新检测方法。

存储器可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据计算机设备的使用所创建的数据(比如第一版本信息、第二版本信息等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

本申请实施例还提供了一种计算机存储介质，所述计算机存储介质存储有计算机可运行指令，所述计算机可运行指令在被处理器调用和运行时，所述计算机可运行指令促使所述处理器运行上述实施例的前端版本更新检测方法的步骤。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和结构图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，结构图和/或流程图中的每个方框、以及结构图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块或单元可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或更多个模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是智能手机、个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

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