CN114995859A

CN114995859A - 页面热更新方法、装置、设备及存储介质

Info

Publication number: CN114995859A
Application number: CN202210753752.XA
Authority: CN
Inventors: 方启涵; 梁沛聪; 李琪
Original assignee: WeBank Co Ltd
Current assignee: WeBank Co Ltd
Priority date: 2022-06-29
Filing date: 2022-06-29
Publication date: 2022-09-02
Also published as: WO2024000955A1

Abstract

本申请提供一种页面热更新方法、装置、设备及存储介质，该方法包括：终端设备通过获取配置信息，根据待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息，在能够获取目标子配置信息时，根据目标子配置信息对虚拟DOM进行配置，获取配置后的虚拟DOM，并根据配置后的虚拟DOM对待渲染页面进行渲染。通过对虚拟DOM进行配置，并将配置后的虚拟DOM直接渲染到页面中，代替了现有技术组中先渲染页面后再触发真实DOM修改的方式，提高了页面热更新效率，解决了应用程序在热更新时存在的应用卡顿、白屏时间较长的问题。

Description

页面热更新方法、装置、设备及存储介质

技术领域

本申请涉及金融科技技术领域，尤其涉及一种页面热更新方法、装置、设备及存储介质。

背景技术

近年来，随着金融科技的推广与蓬勃发展，用户日常生活中越来越多的线下银行业务均可以通过互联网银行应用实现，有效的提高了用户处理银行业务的效率和便捷性。而页面热更新是一项在互联网银行应用中运用广泛的技术，常运用于前端代码存在缺陷、关联系统存在缺陷或服务故障、营销或运营发生事故等异常场景，可达到降低资金损失以及客户投诉的目的。

现有技术中，目前页面热更新是通过终端设备从远程后端服务器中获取配置信息，当运行在终端设备的应用程序页面渲染时触发页面热更新逻辑，寻找应用程序中需要运用页面热更新的组件，并利用应用文档对象模型(Document Object Model，DOM)修改的接口在该组件内部根据配置信息进行局部更新修改，最终将修改后的结果重新更新到页面上，从而对页面进行页面热更新的目的。

然而，在根据修改后的结果修改真实DOM，以使将修改后的结果重新更新到页面上时，会触发页面的重新渲染，在重新渲染的过程中应用会对节点大小和位置进行重新计算，需要占用大量的计算资源，存在页面热更新效率低、应用卡顿以及用户使用体验较差的问题。

发明内容

本申请提供一种页面热更新方法、装置、设备及存储介质，以解决页面热更新效率低、应用卡顿以及用户使用体验较差的问题。

第一方面，本申请实施例提供一种页面热更新方法，包括：

获取配置信息，所述配置信息用于对目标应用程序中的待渲染页面进行热更新；

根据所述待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从所述配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息；

在能够获取目标子配置信息时，根据所述目标子配置信息对所述虚拟DOM进行配置，获取配置后的虚拟DOM；

根据所述配置后的虚拟DOM对所述待渲染页面进行渲染。

在第一方面的一种可能设计中，所述获取配置信息，包括：

从服务器获取初始配置信息；

根据所述初始配置信息中的路由、标签、样式类名以及样式属性值四者的对应关系，将所述路由作为第一层子节点、将所述标签作为第二层子节点、将所述样式类名作为第三层子节点、将所述样式属性值作为第四层子节点，对所述初始配置信息进行树状结构处理，获取所述配置信息。

可选的，所述根据所述待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从所述配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息，包括：

根据所述目标路由、所述目标标签以及所述目标样式类名，依次遍历所述配置信息中的第一层子节点、第二层子节点以及第三层子节点，判断是否存在所述目标路由、所述目标标签以及所述目标样式类名对应的目标样式属性值，所述目标子配置信息包括目标路由、目标标签、目标样式类名以及目标样式属性值。

可选的，所述从服务器获取初始配置信息之前，所述方法还包括：

向所述服务器发送异步请求，所述异步请求用于获取所述初始配置信息；

根据所述目标应用程序中预先加载的预设插件，注册纯函数组件，所述预设插件用于检测是否接收到所述服务器返回的所述初始配置信息；

根据所述纯函数组件的类型以及所述纯函数组件的上下文信息，创建所述虚拟DOM。

可选的，所述根据所述目标子配置信息对所述虚拟DOM进行配置，获取配置后的虚拟DOM，包括：

根据所述目标子配置信息，对所述虚拟DOM的上下文信息进行配置，获取所述配置后的虚拟DOM。

在第一方面的另一种可能设计中，在所述获取配置信息之后，所述方法还包括：

获取所述待渲染页面的URL与基础域名；

根据所述URL与所述基础域名，确定所述待渲染页面的目标路由。

在第一方面的再一种可能设计中，在所述根据所述待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从所述配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息之后，所述方法还包括：

在不能获取所述目标子配置信息时，根据所述虚拟DOM对所述待渲染页面进行渲染。

第二方面，本申请实施例提供一种页面热更新装置，包括：

获取模块，用于获取配置信息，所述配置信息用于对目标应用程序中的待渲染页面进行热更新；

处理模块，用于根据所述待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从所述配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息；

所述获取模块，还用于在能够获取目标子配置信息时，根据所述目标子配置信息对所述虚拟DOM进行配置，获取配置后的虚拟DOM；

所述处理模块，还用于根据所述配置后的虚拟DOM对所述待渲染页面进行渲染。

在第二方面的一种可能设计中，所述获取模块，具体用于：

从服务器获取初始配置信息；

可选的，处理模块具体用于：

可选的，该装置还包括：

发送模块，用于向所述服务器发送异步请求，所述异步请求用于获取所述初始配置信息；

所述处理模块，还用于根据所述目标应用程序中预先加载的预设插件，注册纯函数组件，所述预设插件用于检测是否接收到所述服务器返回的所述初始配置信息；

所述处理模块，还用于根据所述纯函数组件的类型以及所述纯函数组件的上下文信息，创建所述虚拟DOM。

可选的，所述获取模块，具体用于：

在第二方面的另一种可能设计中，在所述获取配置信息之后，所述获取模块，还用于获取所述待渲染页面的URL与基础域名；

所述处理模块，还用于根据所述URL与所述基础域名，确定所述待渲染页面的目标路由。

在第二方面的再一种可能设计中，在所述根据所述待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从所述配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息之后，所述处理模块，还用于：

第三方面，本申请实施例提供一种终端设备，包括：处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序指令，所述处理器执行所述计算机程序指令时用于实现第一方面以及各可能设计提供的方法。

第四方面，本申请实施例可提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现第一方面以及各可能设计提供的方法。

本申请实施例提供的页面热更新方法、装置、设备及存储介质，终端设备通过获取配置信息，根据待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息，在能够获取目标子配置信息时，根据目标子配置信息对虚拟DOM进行配置，获取配置后的虚拟DOM，并根据配置后的虚拟DOM对待渲染页面进行渲染。在本技术方案中，通过对虚拟DOM进行配置，并将配置后的虚拟DOM直接渲染到页面中，代替了现有技术组中先渲染页面后再触发真实DOM修改的方式，减少了渲染任务的次数，进而减少了应用程序的回流，提高了页面热更新效率，解决了应用程序在热更新时存在的应用卡顿、白屏时间较长的问题。用户在使用目标应用程序时，与没有接入页面热更新技术的应用程序无异，接近于无感，从而提升了用户体验。同时，本方案在上下文信息的判断逻辑，也可有效降低因方案改造所带来的代码测试覆盖率风险，可提升在金融科技领域所要求的系统稳定性。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为现有技术中页面热更新方法的流程示意图；

图2为本申请实施例提供的页面热更新方法实施例一的流程示意图；

图3为本申请实施例提供的配置信息的结构示意图；

图4为本申请实施例提供的页面热更新方法实施例二的流程示意图；

图5为本申请实施例提供的页面热更新方法实施例三的流程示意图；

图6为本申请实施例提供的页面热更新方法实施例四的流程示意图；

图7为本申请实施例提供的页面热更新方法实施例五的流程示意图；

图8为本申请实施例提供的页面热更新装置的结构示意图；

图9为本申请实施例提供的终端设备的结构示意图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

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

在介绍本申请的实施例之前，首先对本申请实施例所涉及的名词进行解释：

DOM：是超文本标记语言(Hyper Text Markup Language，HTML)和可扩展标记语言(Extensible Markup Language，XML)文档的编程接口。它提供了对文档的结构化的表述，并定义了一种方式可以使从应用程序中对该结构进行访问，从而改变文档的结构、样式和内容。DOM将文档解析为一个由节点和对象(包含属性和方法的对象)组成的结构集合。简言之，它会将全球广域网(World Wide Web，web)页面和脚本或程序语言连接起来。

虚拟DOM：指一种编程概念，意为将目标所需的用户界面(User Interface，UI)通过数据结构“虚拟”地表示出来，保存在内存中，并与真实的DOM保持同步。由于真实的DOM的属性十分庞大，计算和操作的过程会存在性能损耗问题，使用内存中的虚拟DOM替代部分DOM的计算和操作可以有效提升应用的性能。

页面热更新：指一种不依赖于发布新的版本、或在不修改源代码的情况下，通过远程下发配置信息的方式，修改特定页面、特定元素上的文本、属性、样式或事件句柄，从而改变页面呈现效果或用户交互的技术。

回流：在整个渲染过程中，对节点大小和位置进行重新计算。

本申请具体的应用场景如下：图1为现有技术中页面热更新方法的流程示意图。其中，JavaScript(简称：JS)进程与渲染进程运行于终端设备，该终端设备与服务器通过无线方式进行通信交互。JS进程用于从服务器中获取并存储配置信息，渲染进程用于根据该配置信息对页面进行渲染，以达到对页面进行热更新的目的。

如图1所示，现有技术中页面热更新方法主要包括以下步骤：

步骤1、渲染进程解析HTML页面。

步骤2、渲染进程加载JS脚本，以使运行JS进程。

步骤3、JS进程从服务器中同步拉取HTML页面的配置信息。

步骤4、JS进程将该配置信息存储至内存中。

步骤5、渲染进程从内存中获取该配置信息，并对HTML页面进行渲染。

步骤6、在HTML页面渲染时，渲染进程触发页面热更新逻辑。

步骤7、JS进程根据该热更新逻辑，获取需要修改的第一内容。

步骤8、JS进程根据该第一内容以及配置信息，修改HTML页面的第一DOM。

步骤9、渲染进程根据该第一DOM，对HTML页面进行重新渲染，以实现对HTML页面进行热更新的目的。

当HTML页面每次触发重新渲染时，都需要重新执行步骤6-步骤9，对需要局部更新的内容进行再次修改以达到预期。示例性的，触发重新渲染的流程可以通过下述步骤实现：

步骤10、渲染进程对HTML页面进行渲染。

步骤11、JS进程运行时触发重新渲染。

步骤12、渲染进程触发页面热更新逻辑。

步骤13、JS进程根据该热更新逻辑，获取需要修改的第二内容。

步骤14、JS进程根据该第二内容以及配置信息，修改HTML页面的第二DOM。

步骤15、渲染进程根据该第二DOM，对HTML页面进行重新渲染。

然而，在修改DOM时，会触发页面的重新渲染，而重新渲染页面的行为会引起应用程序的回流，导致存在如占用内存、占用中央处理器(Central Processing Unit，CPU)运算能力等的问题。同时，若有多个组件同时执行更新流程，则会多次触发回流，致使在短时间内会产生大量的计算数据，存在性能瓶颈、应用卡顿以及页面热更新效率低的问题，严重影响正常场景下的用户体验。

针对上述问题，本申请的发明构思如下：由于现有技术中需要先对页面进行渲染，之后再触发真实DOM的修改过程，也就是说现有技术中存在至少两次渲染过程。基于此，发明人发现，由于Vue框架在对组件进行渲染前，都会调用该组件内的render函数，并从render函数的返回值中获取虚拟DOM，以使Vue框架将该虚拟DOM转化为真实DOM并渲染到页面上。因此，在视图更新前(也就是页面渲染前)，根据配置信息对虚拟DOM进行配置，并根据配置后的虚拟DOM对页面进行渲染。由于在视图更新前先对配置信息进行拦截，此时页面的DOM还没有发生变更，从而减少了页面渲染次数，解决了应用卡顿的问题，提高了页面热更新效率，保证了用户的使用体验。

下面，通过具体实施例对本申请的技术方案进行详细说明。

需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图2为本申请实施例提供的页面热更新方法实施例一的流程示意图。如图2所示，该页面热更新方法可以包括如下步骤：

S201、获取配置信息。

本实施例的执行主体为终端设备，终端设备与服务器通过无线方式进行数据交互。服务器中存储有配置信息，该配置信息用于对运行在终端设备中的目标应用程序的待渲染页面进行热更新，该配置信息包括路由、标签、样式类名以及样式属性值。其中，路由为页面的唯一标识。

示例性的，配置信息可以通过表1进行表示。

表1

由表1所示，配置信息可以包括多个子配置信息，如其中一个子配置信息可以为路由1、标签10、样式类名10以及样式属性值10。应理解，配置信息还可以包括其他内容和表现形式，可以根据实际情况进行确定，本申请实施例对此不进行具体限制。

在另一种示例中，图3为本申请实施例提供的配置信息的结构示意图。如图3所示，配置信息还可以为树状结构，其中路由为第一层子节点、标签为第二层子节点、样式类名为第三层子节点、样式属性值为第四层子节点。该配置信息包括多个子配置信息，如其中一个子配置信息可以为路由3、标签30、样式类名30以及样式属性值30。

在一种可能的实现方式中，终端设备可以基于初始化的接口向服务器发送配置信息获取请求，以使通过该接口从服务器返回的响应信息中获取配置信息。

可选的，该配置信息获取请求可以为异步请求，也可以为同步请求。该响应信息还可以包括状态码，该状态码用于指示该响应信息中是否携带有配置信息。

可选的，目标应用程序可以为安装在终端设备中的基于Vue框架的应用程序。该目标应用程序的主函数入口预先加载有预设插件，该预设插件用于检测终端设备是否获取到配置信息。举例来说，该预设插件中可以预先定义有私有变量(如：requestResult)，该私有变量具有初始赋值(如：false)。在状态码指示响应信息中携带有配置信息时，将上述私有变量的赋值由初始赋值修改为成功的枚举值(如true)，以使实现检测终端设备是否获取到配置信息的目的。

S202、根据待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息。

在一种可能的实现方式中，在配置信息结构为表格时，则根据目标路由、目标标签和目标样式类名在上述表格中查询是否存在对应的目标样式属性值。若存在，则代表能够从配置信息中获取目标子配置信息，目标子配置信息包括目标路由、目标标签、目标样式类名以及目标样式属性值；若不能，则代表不能从配置信息中获取目标子配置信息。

在一种可能的实现方式中，在配置信息结构为树状结构时，根据目标路由、目标标签以及目标样式类名，依次遍历配置信息中的第一层子节点、第二层子节点以及第三层子节点，判断是否存在目标路由、目标标签以及目标样式类名对应的目标样式属性值。

示例性的，根据目标路由遍历配置信息的第一层子节点，在第一层子节点与目标路由不一致时，则直接跳过，在第一层子节点与目标路由一致时，则将该第一层子节点确定为目标第一层子节点。进一步的，根据目标标签遍历目标第一层子节点对应的第二层子节点，从上述第二层子节点中确定出目标第二层子节点。进一步的，根据目标样式类名遍历目标第二层子节点对应的第三层子节点，从上述第三层子节点中确定出目标第三层子节点，获取目标第三层子节点对应的目标第四层子节点，该目标第四层子节点即为目标样式属性值。

在上述方法中，由于配置信息具有明显的父子级关系，示例性的，一个路由可以对应多个标签，每个标签对应多个样式类名。因此，通过利用上述父子级关系，无需遍历配置信息中的全部数据，有效的节约了处理时间，提高了处理效率。

可选的，虚拟DOM是预先根据预设插件创建的。示例性的，可以预先根据该预设插件注册纯函数组件，并根据该纯函数组件的类型以及该纯函数组件的上下文信息(也可以称为上下文相关选项)创建该虚拟DOM。每个纯函数组件的路由、标签以及类名都是固定的。虚拟DOM的创建过程可以参照图4所示的实施例，此处不再赘述。

可选的，虚拟DOM的数量可以为1个，也可以为多个，本申请实施例不对虚拟DOM的数量进行限定。

S203、在能够获取目标子配置信息时，根据目标子配置信息对虚拟DOM进行配置，获取配置后的虚拟DOM。

在一种可能的实现方式中，在获取目标子配置信息后，根据目标样式属性值的类型，确定配置方式，并根据该配置方式对虚拟DOM的上下文信息进行配置，从而获取配置后的虚拟DOM。根据目标样式属性值的类型，确定对上下文信息进行配置的方式，从而提高了配置的准确度，进而提高页面的渲染效果。

示例性的，假设目标样式属性值的类型为文本类型，该目标样式属性值包括目标文本和替换文本。则利用虚拟DOM为树状结构的特点，对上下文信息中的各上下文子节点类型进行判断，若该上下文子节点类型为文本类型，且该上下文子节点内的文本为目标文本，则使用文本替换器将该上下文子节点内的目标文本替换为替换文本，从而实现文本的替换效果。可选的，目标样式属性值可以为界面热目标文本以及更新文本等。

示例性的，假设目标样式属性值的类型为属性类型，该目标样式属性值包括待替换属性，将待替换属性与上下文信息中的原属性对象进行深度对象合并。可选的，在目标样式类名与原属性对象对应的样式类名相同时，则优先使用待替换属性，并将合并后的样式属性值设置回上下文信息。

示例性的，假设目标样式属性值的类型为事件类型，该目标样式属性值包括拦截事件名，则查看上下文信息中的“事件监听器对象”。当“事件监听器对象”中存在拦截事件名时，则删除该事件对应的句柄，并创建一个新的无逻辑的空函数挂载到该事件的句柄上，当该拦截事件触发时，对应句柄的函数内并没有实际逻辑执行，从而实现事件的拦截效果。

进一步的，接下来通过三个具体的示例对本步骤进行具体说明。

示例1、从目标子配置信息中取出类型字段(目标样式属性值)记为type，若type类型含有文本类型(则说明目标样式属性值的类型为文本类型)，并且目标子配置信息中的目标文本、替换文本分别为“测试”、“替换后”，则查找上下文信息中所有包含“测试”的文本，并修改为“替换后”，配置后的上下文信息可以如下表示：

context：{

data:{className:"test",attrs:{align:"center"}},

children:"替换后文本"

}

进一步的，将配置后的上下文信息传入到createElement(虚拟DOM的创建方法)作为入参，获取配置后的虚拟DOM，根据配置后的虚拟DOM对待渲染页面进行渲染的预期效果将会是：

<div class＝"test"align＝"center">替换后文本</div>

示例二、同理，假设type类型含有属性类型，且目标样式属性值里“待替换属性”可以如下表示：

{align:"left"}

将上下文信息中attrs原属性对象与待替换属性进行对象合并，获取的配置后的上下文信息可以如下表示：

context：{

data:{className:"test",attrs:{align:"left"}},

children:"替换后文本"

}

进一步的，将配置后的上下文信息传入到createElement作为入参，获取配置后的虚拟DOM，根据配置后的虚拟DOM对待渲染页面进行渲染的预期效果将会是：

<div class＝"test"align＝"left">替换后文本</div>

示例三、若type类型含有事件类型，且目标样式属性值里的拦截事件为“click”点击事件，则访问该上下文信息下的listeners对象，该对象是用于存放组件的事件监听器对象，将该对象中的“click”的键值对删除，并创建一个空函数挂载上去，可实现点击事件的拦截效果。

S204、根据配置后的虚拟DOM对待渲染页面进行渲染。

在一种可能的实现方式中，将该配置后的虚拟DOM确定为待渲染的内容，之后利用Vue渲染引擎将该待渲染的内容渲染至待渲染页面中。可选的，为了进一步节约计算资源，在生成配置后的虚拟DOM后可以暂时将其进行存储，按照预设频率对暂时存储的多个配置后的虚拟DOM进行合并，并根据合并后的虚拟DOM对待渲染页面进行渲染。

可选的，预设频率可以为5分钟1次，30分钟1次或1小时1次等，可以根据实际情况进行限定，本申请实施例对此不进行具体限定。

示例性的，假设配置后的上下文信息为以下数据时：

context：{

data:{className:"test",attrs:{align:"left"}},

children:"替换后文本"

}

根据该配置后的上下文信息对应的配置后的虚拟DOM对待渲染页面进行渲染后的结果将是：

<div class＝"test"align＝"left">替换后文本</div>

本申请实施例提供的页面热更新方法，终端设备通过获取配置信息，根据待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息，在能够获取目标子配置信息时，根据目标子配置信息对虚拟DOM进行配置，获取配置后的虚拟DOM，并根据配置后的虚拟DOM对待渲染页面进行渲染。在本技术方案中，通过对虚拟DOM进行配置，并将配置后的虚拟DOM直接渲染到页面中，代替了现有技术组中先渲染页面后再触发真实DOM修改的方式，减少了渲染任务的次数，进而减少了应用程序的回流，提高了页面热更新效率，解决了应用程序在热更新时存在的应用卡顿、白屏时间较长的问题。用户在使用目标应用程序时，与没有接入页面热更新技术的应用程序无异，接近于无感，从而提升了用户体验。同时，本方案在上下文信息的判断逻辑，也可有效降低因方案改造所带来的代码测试覆盖率风险，可提升在金融科技领域所要求的系统稳定性。

可选的，在一些实施例中，基于上述任一实施例，S201可以通过如下步骤实现：

从服务器获取初始配置信息，根据初始配置信息中的路由、标签、样式类名以及样式属性值四者的对应关系，将路由作为第一层子节点、将标签作为第二层子节点、将样式类名作为第三层子节点、将样式属性值作为第四层子节点，对初始配置信息进行树状结构处理，获取配置信息。

示例性的，从服务器获取初始配置信息后，可以判断预设插件内部的配置中心是否已经初始化，若未初始化，则根据初始配置信息对配置中心进行初始化处理。初始化过程可以为：从初始配置信息中获取路由字段，将路由字段作为对象的key，value值为路由字段相同的初始配置信息集合；进一步，对该初始配置信息集合进行遍历，将标签字段作为对象的key，value值为标签字段相同的初始配置信息集合；进一步，对该初始配置信息集合进行遍历，将样式类名字段作为对象的key，value值为样式类名字段相同的初始配置信息集合，这样配置中心即为一个三层嵌套结构的对象，分别是路由、标签、样式类名三个层级。

在该方式下，针对于S202来说，可以将目标路由、目标标签和目标样式类名作为各个层级的key值，采用前序遍历的方式遍历各层级节点，当样式类名层级有查询到对应的目标样式属性值时即结束遍历，将目标路由、目标标签、目标样式类名以及目标样式属性值作为目标子配置信息返回。

示例性的，假设目标路由、目标标签和目标样式分别为“main/home”、“div”、“test”，则通过初始化后的配置中心以main/home”为key查看是否存在对应的值，若存在则在该值中以“div”为key查找是否存在对应的值，若存在则在该值中以“test”为key查找是否存在对应的值，若存在则将该值确定为目标样式属性值，在无法获取对应的值时直接结束计算。

在又一示例中，查询到的目标子配置信息可以为：

{

"page":"main/home","element":"div","className":"test"，......

进一步的，接下来通过一个具体的示例对初始化过程进行具体说明。

在初始化配置中心时，假设初始配置信息为以下数据结构(示例中省略了部分配置信息的字段)：

[

{"page":"main/home","element":"div","className":"test"},

{"page":"main/home","element":"div","className":"test2"},

{"page":"main/home","element":"p","className":"test2"},

{"page":"main/other","element":"div","className":"other-class"}

]

可以看到，初始配置信息为数组结构，对其进行遍历并取出路由字段，去重后作为key值分类存放，配置内容将会得到以下对象：

{"main/home":{},"main/other":{}}

同时，以同样的方式取出标签字段(element)，去重后分类存放，可以得到：

{

"main/home":{"div":{},"p":{}},

"main/other":{"div":{}}

进一步的，以同样的方式取出样式类名字段(className)，将全部提取出的数据存入配置中心，最终获取的配置信息可以如下表示：

{

"main/home":{

"div":{"test":{...},"test2":{...}},

"p":{"test2":{...}}

},

"main/other":{"div":{"other-class":{...}}}

}

由于配置信息中包括多个子配置信息，在现有技术中，主要是通过组件的唯一标识确定组件对应的子配置信息。然而，在源码中定义标识值是一个不安全的操作。由于标识值不是动态生成的，可能会有重复的问题，导致同一个唯一标识可能被多次运用。且，在代码中编写标识值，每个组件都需要预埋一个属性，也增加了开发人员的使用成本。在现有技术中，还可以多个筛选条件匹配的方式，替代唯一标识匹配的方式。但一般较少进行这样的操作，原因是其需要依赖于对DOM元素进行访问，每个DOM元素的内部属性值都需要被访问多次。DOM元素的读写相对于常规对象的读写需要耗费更多性能，同时占用的内存也更多，在render函数中使用虚拟DOM完成该步骤可以带来效率和性能上的提升。同时，因许多属性值是动态绑定的、具有逻辑控制的，也有可能是Vue框架上私有变量，不一定能在实际渲染的DOM元素上通过接口访问得到，在可操作的配置项数量上十分有限，无法实现全部覆盖。

而上述实施例中，由于路由、标签、样式类名、样式属性值为具有明显父子级关系的维度，而纯函数组件的路由、标签、类名都是确定的，因此，可以通过纯函数组件的路由、标签、类名从配置信息中确定出准确的子配置信息。且，这种通过三种已知的、确定的参数匹配某个未知的参数的方式，在接入相关功能前不需要进行大幅度改造，可避免在源码预埋入额外的、与业务逻辑无关的标识值，减少预埋所带来的工作量，也避免了唯一标识重复的问题。

可选的，图4为本申请实施例提供的页面热更新方法实施例二的流程示意图。如图4所示，基于上述任一实施例，从服务器获取初始配置信息之前，该页面热更新方法还可以包括如下步骤：

S401、向服务器发送异步请求。

其中，异步请求用于获取初始配置信息，该异步请求也就是上文中的配置信息获取请求。

S402、根据目标应用程序中预先加载的预设插件，注册纯函数组件。

在一种可能的实现方式中，可以使用Vue.extend应用程序接口(ApplicationProgramming Interface，API)动态创建初始组件，并将该初始组件的功能性(functional)参数设置为真值(也可以称为正值)。同时，为初始组件定义一个自定义属性，该自定义属性用于存放初始组件的类型值。之后，通过Vue框架创建组件时，根据该functional参数的值将初始组件设置为纯函数组件，该定义属性用于存放纯函数组件的类型值。

其中，预设插件用于检测是否接收到服务器返回的初始配置信息。

可选的，预设插件中预先定义有私有变量具备响应式(可以通过将私有变量作为入参传入Vue.observable实例方法实现)，在私有变量的赋值为成功的枚举值时，则通知所有依赖与该私有变量的纯函数组件。

可选的，自定义属性还可以用于对传入的值做有效性校验，校验的逻辑是判断传入值是否是DOM上真实存在的标签。

应理解，注册纯函数组件的目的是Vue框架会额外为纯函数组件提供一个选项为render函数，可用于修改或自定义渲染的内容。

S403、根据纯函数组件的类型以及纯函数组件的上下文信息，创建虚拟DOM。

通过Vue框架为纯函数组件传入纯函数组件的上下文信息以及虚拟DOM的创建方法，根据虚拟DOM的创建方法以及纯函数组件的类型创建一个原生DOM，并从上下文信息中解构得到所有事件和属性值，不做任何修改地透传到创建好的原生DOM中，得到虚拟DOM。

可选的，纯函数组件的类型可以通过自定义属性确定。

可选的，虚拟DOM的目标标签是根据自定义属性确定的。

示例性的，加入render函数第一个参数(虚拟DOM的创建方法)名为createElement，第二个参数(上下文信息)为对象结构名为context，其中data为预期传递给纯函数组件的整个数据对象、children为子节点；若组件的使用方定义了一个align属性为“center”、class类名为“test”、子节点为文本“测试文本”，Vue框架会将context设置为以下数据结构：

context：{

data:{

className:"test",

attrs:{align:"center"}

},

children:"测试文本"

}

若当前组件传入的类型值是“div”，首先调用createElement，并将字符串“div”、变量context分别传入作为createElement的入参，可获得一个HTML DIV标签的虚拟DOM，该虚拟DOM在页面上的渲染结果预期将会是：

由于应用程序引擎单线程的设计，在同步请求的过程中会阻塞掉其他JS和渲染进程的执行；因接口请求的耗时是取决于终端的网络情况，应用在这个时间段内会有白屏效果且时间不固定，导致用户体验不佳；若不等待接口返回，先执行页面初始渲染，页面热更新逻辑只能等待下一次框架有渲染任务时才能触发，相当于在这段时间内有益效果无法生效；而渲染任务什么时候再次触发是无法预测的，也使得这种方式变得不可靠。在本申请实施例中，通过使用异步请求，有效解决同步请求存在的问题，并在发送异步请求之后创建虚拟DOM，有效地利用了发送异步请求与接收服务器返回的初始配置信息的时间，提高了页面热更新的效率。

可选的，还可以通过目标应用程序的其他业务逻辑触发页面热更新，从而获取配置信息，比如其他响应式数据的修改或发生了交互行为等。

示例性的，在目标应用程序运行过程中，存在用户交互或是其他逻辑处理。以将纯函数组件的文本渲染内容改成“测试文本2”为例，此时由于发生了重新渲染的行为，上下文信息会被重新设置为：

context：{

data:{

className:"test",

attrs:{align:"center"}

},

children:"测试文本2"

}

上述数据在待渲染页面上会被渲染的结果是：

由于在render函数执行过程中，会再次将上下文信息修改为运用界面热更新后的内容，使得最终在页面上的实际渲染的内容还是：

<div class＝"test"align＝"left">替换后文本2</div>

这使得，本方案不会因再次触发渲染而导致界面热更新失效，在不同场景下，发生重新渲染后本方案的有益效果仍能体现。

可选的，图5为本申请实施例提供的页面热更新方法实施例三的流程示意图。如图5所示，基于上述任一实施例，在获取配置信息之后，该页面热更新方法还可以包括如下步骤：

S501、获取待渲染页面的URL与基础域名。

在一种可能的实现方式中，可以获取目标应用程序的Location全局对象，从该Location全局对象获取待渲染页面的统一资源定位系统(uniform resource locator，URL)与基础域名。

S502、根据URL与基础域名，确定待渲染页面的目标路由。

在一种可能的实现方式中，将URL截去基础域名得到待渲染页面的目标路由(也可以称为路由哈希)。在基于Vue框架的应用程序里，路由哈希是区分每个页面的唯一标识，会自动拼接到URL上。

示例性的，假设待渲染页面是位于“www.webank.com”域下、路由为“main/home”，访问页面的Location对象，将会得到以下对象：

{

origin:"https://www.webank.com",

href:"https://www.webank.com/#/main/home"

}

其中，origin为基础域名、href为待渲染页面的URL，由href截去origin的部分与“#”号连接的部分，便可以确定待渲染页面的目标路由为“main/home”。

在上述实施例中，根据待渲染页面的URL与基础域名确定待渲染页面的目标路由，保证了后续对待渲染页面进行渲染处理的准确性。

可选的，在一些实施例中，基于上述实施例，在根据待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息之后，该页面热更新方法还可以包括如下步骤：

在不能获取目标子配置信息时，根据虚拟DOM对待渲染页面进行渲染。

在该实施例中，在不能获取目标子配置信息时，直接根据虚拟DOM对待渲染页面进行渲染，渲染后的页面将会是未运用界面热更新的效果，这样处理后该组件可达到无副作用的效果。

示例性的，此时纯函数组件在页面上的渲染结果将会是：

其中，无副作用可使得相关工作人员在接入该类注册纯函数组件的时候没有引入额外新增的DOM元素、用户的交互事件和属性也可以得以保留，对于没有配置界面热更新的注册纯函数组件，最终引擎将其渲染到页面上的内容，跟接入前的内容是一致的，也可以理解是一种侵入性较小的方案。

图6为本申请实施例提供的页面热更新方法实施例四的流程示意图。其中，框架层以及目标应用程序部署于终端设备中。如图6所示，基于上述任一实施例的基础上，该页面热更新方法可以包括如下步骤：

S601、框架层在目标应用程序的主函数入口引入并加载预设插件。

S602、框架层根据预设插件创建响应式变量。

其中，该响应式变量为上述实施例中的私有变量。

S603、框架层向服务器发送异步请求。

S604、框架层动态创建纯函数组件。

S605、框架层接收服务器返回的配置信息，触发纯函数组件中的render函数的执行。

S606、框架层在render函数执行后，获取配置后的虚拟DOM，并将配置后的虚拟DOM推送至目标应用程序的渲染线程。

同时，还可以通过其他渲染任务触发纯函数组件中的render函数的执行。

图7为本申请实施例提供的页面热更新方法实施例五的流程示意图。如图7所示，基于上述实施例的基础上，S606可以包括通过如下步骤实现：

S701、根据目标应用程序中预先加载的预设插件，注册纯函数组件，并根据纯函数组件的类型以及纯函数组件的上下文信息，创建虚拟DOM。

S702、判断响应信息中是否携带有配置信息。若否，则执行步骤S707；若是，则执行S703。

S703、判断纯函数组件中的配置中心是否初始化，若是，则执行S704，若否，则执行S708，

S704、获取待渲染页面的目标路由，虚拟DOM的目标标签和目标样式。

S705、判断是否能够从配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息，若是则执行S706，若否则执行S707。

S706、根据目标子配置信息对虚拟DOM进行配置。

S707、将当前的虚拟DOM确定为目标虚拟DOM，以使根据该目标虚拟DOM对待渲染页面进行渲染。S707执行后结束流程。

S708、对配置中心执行初始化操作，之后执行S704。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图8为本申请实施例提供的页面热更新装置的结构示意图。如图8所示，该页面热更新装置包括：

获取模块801，用于获取配置信息，配置信息用于对目标应用程序中的待渲染页面进行热更新；

处理模块802，用于根据待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息；

获取模块801，还用于在能够获取目标子配置信息时，根据目标子配置信息对虚拟DOM进行配置，获取配置后的虚拟DOM；

处理模块802，还用于根据配置后的虚拟DOM对待渲染页面进行渲染。

在本申请实施例的一种可能设计中，获取模块801，具体用于：

从服务器获取初始配置信息；

根据初始配置信息中的路由、标签、样式类名以及样式属性值四者的对应关系，将路由作为第一层子节点、将标签作为第二层子节点、将样式类名作为第三层子节点、将样式属性值作为第四层子节点，对初始配置信息进行树状结构处理，获取配置信息。

可选的，处理模块802具体用于：

根据目标路由、目标标签以及目标样式类名，依次遍历配置信息中的第一层子节点、第二层子节点以及第三层子节点，判断是否存在目标路由、目标标签以及目标样式类名对应的目标样式属性值，目标子配置信息包括目标路由、目标标签、目标样式类名以及目标样式属性值。

可选的，该装置还包括：

发送模块，用于向服务器发送异步请求，异步请求用于获取初始配置信息；

处理模块802，还用于根据目标应用程序中预先加载的预设插件，注册纯函数组件，预设插件用于检测是否接收到服务器返回的初始配置信息；

处理模块802，还用于根据纯函数组件的类型以及纯函数组件的上下文信息，创建虚拟DOM。

可选的，获取模块801，具体用于：

根据目标子配置信息，对虚拟DOM的上下文信息进行配置，获取配置后的虚拟DOM。

在本申请实施例的另一种可能设计中，在获取配置信息之后，获取模块801，还用于获取待渲染页面的URL与基础域名；

处理模块802，还用于根据URL与基础域名，确定待渲染页面的目标路由。

在本申请实施例的再一种可能设计中，在根据待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息之后，处理模块802，还用于：

本申请实施例提供的页面热更新装置，可用于执行上述任一实施例中的页面热更新方法，其实现原理和技术效果类似，在此不再赘述。

需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。此外，这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

图9为本申请实施例提供的终端设备的结构示意图。如图9所示，该终端设备可以包括：处理器901、存储器902及存储在所述存储器902上并可在处理器901上运行的计算机程序指令，所述处理器901执行所述计算机程序指令时实现前述任一实施例提供的页面热更新方法。

可选的，该终端设备的上述各个器件之间可以通过系统总线连接。

存储器902可以是单独的存储单元，也可以是集成在处理器中的存储单元。处理器的数量为一个或者多个。

可选的，终端设备还可以包括与其他设备进行交互的接口。

应理解，处理器901可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

系统总线可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。存储器可能包括随机存取存储器(randomaccess memory，RAM)，也可能还包括非易失性存储器(non-volatile memory，NVM)，例如至少一个磁盘存储器。

实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一可读取存储器中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储器(存储介质)包括：只读存储器(read-only memory，ROM)、RAM、快闪存储器、硬盘、固态硬盘、磁带(英文：magnetic tape)、软盘(英文：floppy disk)、光盘(英文：optical disc)及其任意组合。

本申请实施例提供的终端设备，可用于执行上述任一方法实施例提供的页面热更新方法，其实现原理和技术效果类似，在此不再赘述。

本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行上述页面热更新方法。

上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器，电可擦除可编程只读存储器，可擦除可编程只读存储器，可编程只读存储器，只读存储器，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。

可选的，将可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits，ASIC)中。当然，处理器和可读存储介质也可以作为分立组件存在于设备中。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中，至少一个处理器可以从该计算机可读存储介质中读取该计算机程序，所述至少一个处理器执行所述计算机程序时可实现上述页面热更新方法。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。

Claims

1.一种页面热更新方法，其特征在于，包括：

根据所述待渲染页面的目标路由、预先建立的虚拟应用文档对象模型DOM的目标标签和目标样式类名，判断是否能够从所述配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息；

根据所述配置后的虚拟DOM对所述待渲染页面进行渲染。

2.根据权利要求1所述的方法，其特征在于，所述获取配置信息，包括：

从服务器获取初始配置信息；

3.根据权利要求2所述的方法，其特征在于，所述根据所述待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从所述配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息，包括：

4.根据权利要求2或3所述的方法，其特征在于，所述从服务器获取初始配置信息之前，所述方法还包括：

5.根据权利要求4所述的方法，其特征在于，所述根据所述目标子配置信息对所述虚拟DOM进行配置，获取配置后的虚拟DOM，包括：

6.根据权利要求1至3任一项所述的方法，其特征在于，在所述获取配置信息之后，所述方法还包括：

获取所述待渲染页面的页面统一资源定位系统URL与基础域名；

7.根据权利要求1所述的方法，其特征在于，在所述根据所述待渲染页面的目标路由、预先建立的虚拟DOM的目标标签和目标样式类名，判断是否能够从所述配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息之后，所述方法还包括：

8.一种页面热更新装置，其特征在于，包括：

处理模块，用于根据所述待渲染页面的目标路由、预先建立的虚拟应用文档对象模型DOM的目标标签和目标样式类名，判断是否能够从所述配置信息中获取目标路由、目标标签和目标样式类名对应的目标子配置信息；

9.一种终端设备，包括：处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序指令，其特征在于，所述处理器执行所述计算机程序指令时用于实现如权利要求1至7任一项所述的页面热更新方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至7任一项所述的页面热更新方法。