页面显示方法、装置、设备及计算机可读存储介质

技术领域

本申请属于显示技术领域，尤其涉及一种页面显示方法、装置、设备及计算机可读存储介质。

背景技术

在现有的Vuex框架模式中，当页面组件中的状态发生改变，通过调度(Dispatch)函数提交到Actions，Actions再通过提交(Commit)函数提交到Mutations，由Mutations更改数据仓库中页面组件的状态，状态的改变再渲染到页面组件，实现页面组件的更新显示。

然而，随着计算机技术的发展，页面中的组件数量日益增多。对于日益复杂的页面，若仍采用上述Vuex框架模式，由于Mutations必须是同步操作，当页面的多个组件的状态均发生改变时，将导致页面更新显示效率较低。

发明内容

本申请实施例提供一种在页面显示方法、装置、设备及计算机可读存储介质，能够解决现有技术中页面更新显示效率较低的问题。

第一方面，本申请实施例提供一种页面显示方法，方法包括：

获取目标事件任务，其中，所述目标事件任务由页面的目标组件的状态信息发生变化触发；所述目标事件任务包括N个计算任务，N为大于1的整数；

通过Dinic算法确定worker线程池中最小资源占用的M个worker线程，其中，M为大于1，小于或等于N的整数；

利用所述M个worker线程执行所述N个计算任务，得到所述目标事件任务的执行结果；

利用所述执行结果，更新显示所述页面中的所述目标组件。

第二方面，本申请实施例提供了一种页面显示装置，装置包括：

获取模块，用于获取目标事件任务，其中，所述目标事件任务由页面的目标组件的状态信息发生变化触发；所述目标事件任务包括N个计算任务，N为大于1的整数；

确定模块，用于通过Dinic算法确定worker线程池中最小资源占用的M个worker线程，其中，M为大于1，小于或等于N的整数；

执行模块，用于利用所述M个worker线程执行所述N个计算任务，得到所述目标事件任务的执行结果；

显示模块，用于利用所述执行结果，更新显示所述页面中的所述目标组件。

第三方面，本申请实施例提供了一种页面显示设备，设备包括：

处理器以及存储有计算机程序指令的存储器；

所述处理器执行所述计算机程序指令时实现如第一方面所述的页面显示方法。

第四方面，本申请实施例提供了一种计算机存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如第一方面所述的页面显示方法。

第五方面，本申请实施例提供了一种计算机程序产品，所述计算机程序产品中的指令由电子设备的处理器执行时，使得所述电子设备执行如第一方面所述的页面显示方法。

在本申请实施例中，在获取到由页面组件的状态信息发生变化触发的事件任务之后，可以通过多个worker线程并行处理事件任务的计算任务，实现页面组件的更新，如此，可以提高页面更新显示效率。进一步地，执行事件任务的计算任务的worker线程为通过Dinic算法确定的worker线程池中最小资源占用的worker线程，如此，可以减少页面更新显示占用的内存资源。

附图说明

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

图1是本申请实施例提供的Vue状态管理模式的示意图；

图2是本申请实施例提供的状态管理流程的示意图之一；

图3是本申请实施例提供的状态管理流程的示意图之二；

图4是本申请实施例提供的页面显示方法的流程图；

图5是本申请实施例提供的状态管理的流程示意图之三；

图6是本申请实施例提供的状态管理流程的示意图之四；

图7是本申请实施例提供的页面显示装置的结构图；

图8是本申请实施例提供的页面显示设备的结构图。

具体实施方式

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本申请，而不是限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

为了方便理解，以下对本申请实施例涉及的一些内容进行说明：

前端网络(web)可视化快速开发的发展，大屏等展示窗口承载了越来越多的展示功能以及大量的复杂图表，一个大屏页面或一个电脑(PC)汇总报表页面需要加载并处理大量的细分小图表模块，而同一页面中的不同图表可能因数据结构及呈现形式不同而数据冗余雷同，页面中的各个模块(也可以称为组件)各自从后台请求通信获取数据并各自加载，基于jQuery、React、Vue等框架技术即可实现各模块异步处理加载。

本申请实施例可以适用于Vue框架，Vue框架是一套用于构建用户界面的渐进式框架。与其它大型框架不同的是，Vue被设计为可以自底向上逐层应用。Vue的核心库只关注视图层，不仅易于上手，还便于与第三方库或既有项目整合。另一方面，当与现代化的工具链以及各种支持类库结合使用时，Vue也完全能够为复杂的单页应用提供驱动。

Vue.js是一套构建用户界面的框架(一套完整的解决方案，对项目侵入性大，中途需要更换框架则需要重构整个项目)，只关注视图层，易上手，有配套的第三方类库。可以提高开发效率，帮助减少不必要的文档对象模型(Document Object Model，DOM)操作；双向数据绑定，通过框架提供的指令，前端只需要关注业务逻辑，不关心DOM如何渲染。

本申请实施例涉及到的Web Worker是运行在后台的JavaScript，独立于其他脚本(即页面主处理脚本)，不会影响到页面的性能效率。用户可以继续做任何愿意做的事情：点击、选取内容等等，而此时Web Worker在后台运行。Web Worker可以用于为JavaScript创造多线程环境，允许主线程创建Worker线程，并将一些任务分配给Worker线程运行。在主线程运行的同时，Worker线程在后台运行，两者互不干扰。等到Worker线程完成计算任务，再把结果返回给主线程。这样的好处是，一些计算密集型或高延迟的任务，被Worker线程负担了，主线程(通常负责UI交互)就会很流畅，不会被阻塞或拖慢。

Vue框架常用Vuex框架模式，Vuex是一个专为Vue.js应用程序开发的状态管理模式。它采用集中式存储的方式管理应用的所有组件的状态，并以相应的规则保证状态以一种可预测的方式发生变化。相当于把许多组件中用到的数据提升到一个全局的地方，所有组件都往这个地方存取数据，而不再是受制于组件中的单向数据流。由Vuex集中管理这些数据，并提供操作这些数据的方法。

以下是关于Vuex的核心方案与机制流程介绍：

如图1所示，Vuex对象结构可以包括：

数据仓库(Store)：作为一个容器来包含着前端应用中所有的状态(State)信息，且是Vuex框架的唯一数据源；

Getters(图1未示出)：通过Getters可以派生出一些新的状态；

Mutations：更改(Mutate)Vuex的Store中的状态的唯一方法时提交Mutation；

Actions：Actions提交的是Mutation，而不是直接变更状态。Action可以包含任何的异步操作，但Mutation必须是同步操作。

操作流程步骤上，当组件中的状态发生改变，通过调度(Dispatch)函数提交到Actions，Actions再通过提交(Commit)函数提交到Mutations，此时，状态发生改变都会实时的去渲染(Render)组件。

组件中可以包含视图(View，如模板(Template))、双向绑定的数据(Data)、以及一些方法(Methods)，这3个都写在同一个组件(Component)里面，一般视图触发方法动作，动作影响数据状态，数据状态的改变又反映到视图上来，这样在一个组件内就形成了一个闭环。即当前组件的视图使用当前组件的数据，当前组件的动作(方法)只修改当前组件的数据，不会影响其他组件的数据。

Vuex模式在页面模块的内容动态更新方面，通过Actions进行事件分发与组合的异步操作执行，异步操作出结果后再去提交Mutations。涉及到调用异步接口(API)和分发多重Mutation，在组件中可以使用this.$store.dispatch('页面显示x')分发Action，或者使用mapActions辅助函数将组件的方法映射为store.dispatch调用。

Actions和Mutations作为对事情触发后的管理与执行的解耦环节，目的是为应对通用模块化开发与动态更新的场景，而当超长大屏上展示模块较多、构建的store容器较多、多store之间的组件与数据存在复用需求与协同计算时，现有的模式流程在应对上，便根据各事件触发需求重复遍历了大量流程环节。也衍生出了几方面痛点问题：

1、场景服务不灵活。可视化大屏类系统为保证数据的实时展示能力，在后端通过流数据处理进行快速反馈到前端，未经过复杂、耗时、精细的后台离线计算即把准数据推送到前端，现有Vue模块化框架虽前端主流但无法适应大屏或PC端海量图表等信息内容计算与处理的高效机制支撑。

2、重复计算浪费资源。每个store容器某一节点状态State更新，都需要通过源数据再重新加载处理，并生成完整的虚拟DOM，哪怕State改动很小，也需要完整走一遍事件处理、更新、计算。这个过程就会白白浪费很多浏览器内存资源。

3、前端大量模块的独立数据预处理压力与效率低。前端页面各个独立模块通过从获取信息数据到监听、更新、重新渲染，进行独立的数据组织处理流程，以将原始结构数据根据该模块所需要展示的数据结构进行数据串接、统计、结构调整等数据重新处理，而模块越多，独立数据预处理执行程序越多，尤其在同一类型范围的大型专题分析等页面中会存在同一份原始数据将根据业务分析的不同角度而展示化处理，避免不同请求下对同一数据源进行过多模块函数处理的冗余接口，从而影响客户端响应效率。

基于此，为满足日益复杂的页面，更全面更直观的信息展示要求和前端处理效率，在本申请实施例中，如图2和图3所示，将原有基础通用的事件分发Actions与变更任务Mutations环节进行重构替换设计，利用事件任务并行管理模块替代Actions+Mutations，在事件任务并行管理模块中，可以利用Web Worker及调度相关算法，构建事件任务并行管理的机制进行策略改造，来支撑未来的精细化技术细分能力优化，提升前端海量信息计算类场景下的效率。如此，可以通过任务事件需求与数据源的多线程直连并行处理以及任务调度控制，满足在复杂大屏可视化中海量模块展示的动态更新与数据计算场景。在图2中，虚线分支为相关技术的流程走向，实线分支为本申请实施例的流程走向。

下面结合附图，通过一些实施例及其应用场景对本申请实施例提供的页面显示方法进行详细地说明。

参见图4，图4是本申请实施例提供的页面显示方法的流程图之一。

如图4所示，页面显示方法可以包括以下步骤：

步骤401、获取目标事件任务，其中，所述目标事件任务由页面的目标组件的状态信息发生变化触发；所述目标事件任务包括N个计算任务，N为大于1的整数。

目标组件可以包括页面中的一个或多个组件。目标事件任务可以包括一个或多个事件任务。一个组件的状态信息发生变化可以触发一个事件任务，因此，目标事件任务包括的事件任务的数量可以与目标组件包括的组件的数量相等。

具体实现时，用户可以与页面交互，触发目标组件的状态信息发生变化，触发Vue组件状态更新事件，产生目标事件任务。在获取到目标事件任务之后，可以将目标事件任务拆分为N个计算任务，以通过多线程并行处理目标事件任务中的计算任务，提高事件任务处理效率，进而提高页面更新显示效率。

步骤402、通过Dinic算法确定worker线程池中最小资源占用的M个worker线程，其中，M为大于1，小于或等于N的整数。

worker线程池的数量可以为一个或多个。M个worker线程中的一个worker线程可以执行一个或多个计算任务，具体可根据实际情况决定，本申请实施例对此不作限定。

在本申请实施例中，通过web worker技术来新建worker线程，以对事件任务中的计算任务进行异步并行加载处理，并统一面向数据仓库进行状态变更。

进一步地，可以通过Dinic算法，对worker线程池中的worker线程进行资源监控，扫描得到各worker线程的资源占用情况，在worker线程池中找最小资源占用的worker线程，如此，利用最小资源占用的worker线程执行事件任务的计算任务，可以减少事件任务处理占用的内存资源。

Dinic算法可以分阶段地在层次网络中增广，层次网络由worker线程构成。具体实现时，通过Dinic算法，可以在一次或多次增广中遍历寻找最短增广路，即最小资源占用的worker线程，然后为该worker线程分配一个计算任务，然后再进行重新遍历寻找，直至分配完全部的计算任务。

步骤403、利用所述M个worker线程执行所述N个计算任务，得到所述目标事件任务的执行结果。

通过Dinic算法，每确定M个worker线程中的一个worker线程，即为该worker线程分配一个计算任务。

在一些实施例中，在确定M个worker线程之后，对于M个worker线程中的任一个worker线程，其可以直接执行通过Dinic算法为其分配的计算任务。

在另一些实施例中，在确定M个worker线程之后，可以在M个worker线程中重新分配用于计算N个计算任务的worker线程，以进一步提高计算任务的处理效率，具体可参见下述相关描述，此处不作描述。

步骤404、利用所述执行结果，更新显示所述页面中的所述目标组件。

在本申请实施例中，在通过worker线程执行完目标事件任务后，即可利用目标事件任务的执行结果，直接更新数据仓库中目标组件的状态，利用更新后的目标组件的状态渲染目标组件，实现目标组件在页面中的更新。

本实施例的页面显示方法，在获取到由页面组件的状态信息发生变化触发的事件任务之后，可以通过多个worker线程并行处理事件任务的计算任务，实现页面组件的更新，如此，可以提高页面更新显示效率。进一步地，执行事件任务的计算任务的worker线程为通过Dinic算法确定的worker线程池中最小资源占用的worker线程，如此，可以减少页面更新显示占用的内存资源。

在一些实施例中，所述通过Dinic算法确定worker线程池中最小资源占用的M个worker线程，可以包括：

通过Dinic算法扫描worker线程池中各worker线程的流量信息，其中，所述流量信息包括以下至少一项：状态信息、内存占用信息和数据处理性能信息；

利用所述流量信息确定所述worker线程池中最小资源占用的M个worker线程。

worker线程的状态信息可以用于确定worker线程是处于使用状态还是空闲状态。处于使用状态的worker线程的流量大于处于空闲状态的worker线程的流量。

worker线程的内存占用信息可以用于确定worker线程的内存占用情况。worker线程的内存占用大小与worker线程的流量正相关，即worker线程的内存占用越大，worker线程的流量越大，反之越小。

worker线程的数据处理性能信息可以用于确定worker线程的数据量处理性能。worker线程的数据处理性能信息可以表现为：worker线程中taskMap数据对象体积。worker线程的数据量处理性能与worker线程的流量正相关，即worker线程的数据量处理性能越好，worker线程的流量越大，反之越小。

worker线程的流量与worker线程的资源占用正相关，即worker线程的流量越大，worker线程的资源占用越大，反之越小。

基于此，在本实施例中，可以通过Dinic算法扫描各worker线程的流量信息，以确定最小资源占用的worker线程，如此，可以实现计算任务的流量控制，减少事件任务处理占用的内存资源。

在一些实施例中，所述利用所述M个worker线程执行所述N个计算任务，可以包括：

基于效用函数确定所述M个worker线程中，用于计算所述N个计算任务中第i计算任务的效用最大的目标worker线程，其中，i为小于或等于N的正整数；

利用所述目标worker线程执行所述第i计算任务。

在此实施例中，在通过Dinic算法确定最小资源占用的M个worker线程之后，在执行N个计算任务之前，还可以基于效用函数的启发调度(效用最优调度算法)来实现对N个计算任务的最优调度管理，将任务分配给效用最大的资源，即worker线程进行处理，如此，可以进一步提高事件任务的处理效率。

具体实现时，可以通过效用最优调度算法依次确定用于计算各计算任务的效用最大的worker线程。可以理解地是，随着计算任务的分配与执行，各worker线程的效用会随之发生变化，也就是说，计算任务的分配与执行，会影响各worker线程的效用，进而会影响后续计算任务的分配。

在本实施例中，可以基于效用函数的效用最优调度算法，将各计算任务分配给效用最大的资源执行，如此，可以进一步提高计算任务的处理效率，进而提高事件任务的处理效率。

进一步地，所述基于效用函数确定所述M个worker线程中，用于计算所述N个计算任务中第i计算任务的效用最大的目标worker线程，包括：

根据时间效用函数，确定所述第i计算任务在各worker线程上执行的时间效用值；

根据成本效用函数，确定所述第i计算任务在各worker线程上执行的成本效用值；

根据所述第i计算任务在各worker线程上执行的所述时间效用值和所述成本效用值，确定所述第i计算任务在各worker线程上执行的目标效用值，得到与所述M个worker线程一一对应的M个目标效用值；

将所述M个目标效用值中的最大值对应的worker线程，确定为用于计算所述第i计算任务的效用最大的目标worker线程。

在本实施例中，可以通过计算任务在各worker线程上执行的目标效用值，确定用于计算该计算任务的效用最大的worker线程。具体地，计算任务在各worker线程上执行的目标效用值基于计算任务在各worker线程上执行的时间效用值和成本效用值确定。

计算任务在worker线程上执行的时间效用值，可以反映计算任务在worker线程上执行时所需的时间。计算任务在worker线程上执行的时间效用值与计算任务在worker线程上执行时所需的时间正相关，即计算任务在worker线程上执行时所需的时间越长，计算任务在worker线程上执行的时间效用值越大，也就是说，在满足事件任务的时限要求(deadline)的前提下，尽量在速度慢的资源上执行计算任务，这样，有益于提高计算任务的完成率，且速度慢的资源一般成本较低。

在一些实施例中，所述时间效用函数可以如公式(1)所示，但并不因此限制时间效用函数的具体表现形式，具体可根据实际需求设置，本申请实施例对此不作限定。

其中，U

计算任务在worker线程上执行的成本效用值，可以反映计算任务在worker线程上执行时所需的成本。计算任务在worker线程上执行的成本效用值与计算任务在worker线程上执行时所需的成本负相关，即计算任务在worker线程上执行时所需的成本越小，计算任务在worker线程上执行的成本效用值越大，也就是说，在满足事件任务的预算要求(budget)的前提下，尽量在执行成本较低的资源上执行计算任务，这样，可以降低计算任务的执行成本。

在一些实施例中，所述成本效用函数可以如公式(2)所示，但并不因此限制成本效用函数的具体表现形式，具体可根据实际需求设置，本申请实施例对此不作限定。

其中，U

C

通过上述方式，可以利用时间效用函数和成本效用函数，将计算任务分配至效用最大的资源上执行，可以提高计算任务的完成率，降低计算任务的执行成本。

在一些实施例中，可以直接将所述第i计算任务在各worker线程上执行的时间效用值与成本效用值的和，确定为所述第i计算任务在各worker线程上执行的目标效用值。

在另一些实施例中，所述根据所述第i计算任务在各worker线程上执行的所述时间效用值和所述成本效用值，确定所述第i计算任务在各worker线程上执行的目标效用值，得到与所述M个worker线程一一对应的M个目标效用值，包括：

获取时间效用权重值和成本效用权重值；

将各worker线程的第一值与第二值的和，确定为所述第i计算任务在各worker线程上执行的目标效用值，得到与所述M个worker线程一一对应的M个目标效用值；

其中，各worker线程的所述第一值为各worker线程的所述时间效用值与所述时间效用权重值的乘积，各worker线程的所述第二值为各worker线程的所述成本效用值与所述成本效用权重值的乘积。

在此实施例中，进一步地为时间效用值赋予一个权重值，即时间效用权重值，为成本效用值赋予一个权重值，即成本效用权重值。

时间效用权重值与成本效用权重值的和为1。

在一些可选地实现方式中，时间效用权重值与成本效用权重值可以根据实际需求设置，如：若用户期望减少任务执行时间，可以设置时间效用权重值较大，若用户期望减少任务执行成本，可设置成本效用权重值较大。

在另一些可选地实现方式中，所述时间效用权重值W

其中，

T

T

所有任务(即N个计算任务)的总长度除以计算资源(即worker线程)的平均计算速度的值；

最长的任务的长度除以最快的资源的计算速度的值。

C

在获取到所述第i计算任务在各worker线程上执行的时间效用值与成本效用值之后，可以将时间效用值与时间效用权重值相乘之后，得到第一值，将成本效用值与成本效用权重值相乘之后，得到第二值，之后，将第一值和第二值相加，得到目标效用值。如此，可以提高效用最大的资源的确定可靠性。

在一些实施例中，所述获取目标事件任务，可以包括：

监听所述目标组件对应的至少一个状态信息；

在监听到所述至少一个状态信息中的目标状态信息发生变化的情况下，根据所述目标状态信息，生成目标事件任务。

在一些可选地实现方式中，组件对应的至少一个状态信息可以封装在一标数据结构组中，在此实现方式中，可以通过监听目标组件对应的数据结构组，确定组件的状态信息是否发生变更，可以便于组件的状态信息的监听。

在另一些可选地实现方式中，监听所述目标组件对应的至少一个状态信息可以包括以下至少一项：

监听页面尺寸变化和键盘事件；

监听对象的状态的变化；

监听网络路由的变化，跳转到同一个页面时，统一资源定位系统(UniformResource Locator，Url)改变但视图未重新加载问题；

监听页面浏览器窗口大小变化；

监听状态任意值变化；

监听同一个网络路由，但页面参数发生变化，页面不刷新的问题；

注册监听页面刷新和关闭；

监听网页视图(webview)缓存及跳转时截取Url地址、监听页面变化。

目标状态信息可以包括至少一个状态信息中的一个或多个状态信息。

通过上述方式，可以监听组件的状态信息，基于发生变化的状态信息，生成事件任务，从而可以提高组件更新的可靠性。

需要说明的是，本申请实施例中介绍的多种可选的实施方式，在彼此不冲突的情况下可以相互结合实现，也可以单独实现，对此本申请实施例不作限定。

为方便理解，示例说明如下：

在本申请实施例中，前端所有vue组件的事件任务，全部通过web worker技术来新建线程进行异步并行加载处理，并统一面向数据仓库进行数据变更，并以Dinic资源扫描算法和效用调度分析算法对并行处理任务进行计算流量的控制与管理。

正常情况下数据仓库就是用来存放数据，若是对数据进行处理输出，比如数据要过滤、合并串联或大量图表数据联合计算，如果很多组件都需要使用这个过滤后的数据，比如饼状图组件和曲线图组件、地图等所需要的基础源为同一份或需要相互搭配，可以把这个数据进行统一并行处理与共享，来通过getters进行内外输出。

本申请实施例的设计方案思路如图5所示：

事件任务进入事件任务并行管理模块的主线程(master)中，对线程池中的各worker线程进行计算任务分配，而侧面通过计算流量的算法，即Dinic算法来即时刷新扫描检查各Worker线程流量情况(Worker线程状态>Worker线程内存占用情况>Worker线程taskMap数据对象体积)，来实现计算任务的流量控制。再通过效用最优调度分析算法来进行统一的任务管理调配优化。如此，可以使得前端vue组件的处理流程更灵活、可控，实现前端模块化框架辅助支撑管理的融合型架构，相辅相成。

本申请实施例的技术方案的流程图可以如图6所示，包括以下步骤：

步骤1、store模式管理起步。

vuex的应用核心就是store仓库，它作为一个容器来包含着前端组件中所有的状态信息，且是vuex框架的唯一数据源。

可以通过将store(index.js文件)引入组件并进行初始化赋值，vuex将根store作为root保存，通过_children属性保存子模块引用，以建立一颗module树。通过在根实例中注册store选项，该store实例会注入到根组件下的所有子组件中，且子组件能通过this.$store访问到。

由于Vuex的状态存储是响应式的，从store实例中读取状态最简单的方法就是在计算属性(opens new window)中返回某个状态。首次执行逻辑，将通过new Module将模块中定义的值(state、getter、mutations、actions)挂载到rawModule，将state提取到state上。

接着对store进行模块化处理，可以将store拆分以模块化管理，这对应配置对象的modules属性，即单一状态树，用一个对象就包含了全部的应用层级状态，以便作为一个“唯一数据源“(SSOT(opens new window))。每个组件将仅仅包含一个store实例。单一状态树能够直接地定位任一特定的状态片段，在调试的过程中也能轻易地取得整个当前组件状态的快照。

module树与页面。module树可以包括与多个组件一一对应的状态树。组件对应的状态树用于渲染组件状态。

步骤2、事件任务监听。

Vue组件初始化启动后，本步骤主要为两部分服务构建，一是通过初始化建立对8大类信息的监听，并可以集中封装为一个set数据结构组，以便于对事件进行集合统一的状态变化处理；二是初始化webworker的多线程并发任务管理，以便于通过其master的任务协调进行对事件任务的后续响应操作。

初始化vue组件信息监听：

监听页面尺寸变化和键盘事件；

监听对象的状态的变化；

监听网络路由的变化，跳转到同一个页面时，Url改变但视图未重新加载问题；

监听浏览器(页面浏览器)窗口大小变化；

监听state任意值变化、监听mutations、actions；

同一个路由，但页面参数发生变化，页面不刷新的问题(vue监听路由参数变化重新渲染页面)；

注册监听页面刷新和关闭；

webview缓存及跳转时截取url地址、监听页面变化。

初始化webworker的多线程并发任务管理：

webworker将独立于其他脚本(即页面主处理脚本)，不会影响到当前页面上主要的渲染与加载的性能效率。创建多线程环境后，允许master创建Worker线程，将一些任务分配给后者运行。在主线程运行的同时，Worker线程在后台运行，两者互不干扰。等到Worker线程完成计算任务，再把结果返回给主线程。

步骤3、事件任务资源状态管理。

根据上一步骤的事件监听任务获取，通过Dinic算法进行动态调整webworker的资源管理、任务分配。通过dic算法来扫描Worker线程状态>Worker线程内存占用情况>Worker线程中taskMap数据对象体积，将不同任务分配到不同的Worker线程中。

首先，是Worker线程的管理，包括初始化Worker线程池数量以及每个Worker线程所占用的浏览器内存上限体积定义。

控制web worker线程数：通过Navagitor对象的HardWareConcurrecy属性，可以获取浏览器所属计算机的CPU核心数量，如果CPU有超线程技术，这个值就是实际核心数量的两倍。当然这个属性存在兼容性问题，如果取不到，则默认为4个。默认有多少个CPU线程数就开多少个Worker线程。

如果只开一个线程，工作都在这一个Worker线程里做，不能保证它不阻塞。如果无止尽的开启而不进行控制，可能导致运行海量模块的超大屏可视化应用时，浏览器的内存消耗极高，默认一个web Worker线程的开销大概在5MB左右。

无论这5MB内存是否已被这个Worker线程完全使用，还是说仅仅是给这个Worker线程预规划的内存空间，但这个空间确实是被占用了，并且频繁地创建和终止线程，对性能的消耗也是极大的。所以可以通过Dinic算法来根据浏览器的内存资源(主线程外剩余总内存大小)对Worker线程的工作进行规划和调度的优化，以及对僵尸线程的清理、新线程的开辟等等。

然后，通过Dinic算法对多线程进行资源监控，在众多worker线程池，找最短增广路(即最少资源占用的Worker线程)。

Dinic算法解释及其特性：

网络流：在一个有向图上选择一个源点，一个汇点，每一条边上都有一个流量上限(以下称为容量)，即经过这条边的流量不能超过这个上界，同时，除源点和汇点外，所有点的入流和出流都相等，而源点只有流出的流，汇点只有汇入的流。这样的图叫做网络流。

最短增广路算法：最短增广路的算法思想是每次在层次网络中找一条含弧数最少的增广路进行增广。

Dinic算法的思想是分阶段地在层次网络中增广。它与最短增广路算法不同之处是：最短增广路每个阶段执行完一次广度优先遍历(Breath First Search，BFS)增广后，要重新启动BFS从源点Vs开始寻找另一条增广路；而在Dinic算法中，只需一次DFS过程就可以实现多次增广，DFS过程将会使算法的效率有非常大的提高，这是Dinic算法的巧妙优势之处。

对于任何一条流，流量<＝容量。对于任何一个不是源点或汇点的点u，满足公式(5)，即一个点(除源点和汇点)的入流和出流相等：

∑p∈Ek[p][u]＝＝∑q∈Ek[u][q] (5)

其中，k[i][j]表示i到j的流量。

Dinic算法是一个一次或多次增广的遍历寻找最小资源占用的Worker线程，然后即进行一次任务的重新分配，待分配后再进行重新遍历扫描。Dinic算法引入了一个叫做分层图的概念，函数BFS就是在寻找增广路，而DFS就是在按照增广路进行增广。它会首先通过一次BFS为所有线程点添加一个标号，构成一个层次图，然后在层次图中寻找增广路进行更新。大致算法流程如下：

a)利用BFS对原来的图进行分层，即对每个结点进行标号，这个标号的含义是当前结点距离源点的最短距离(假设每条边的距离都为1)，注意：构建层次图的时候所走的边的残余流量必须大于0。

b)用DFS寻找一条从源点到汇点的增广路，注意:此处寻找增广路的时候要按照层次图的顺序(Worker线程的ID标识)。找到一条路后要根据这条增广路径上的所有边的残余流量的最小值更新所有边的残余流量(即正向弧-l，反向弧+l)。主要包括Worker线程状态(worker的busy is boolean)>Worker线程内存占用情况>Worker线程中taskMap数据对象体积。

c)重复步骤2，当找不到一条增广路的时候，重复步骤1，重新建立层次图，直到从源点不能到达汇点为止，即最终快速扫描总结出最小占用的Worker线程，然后进行事件任务的管理。

最终，根据算法扫描得出的线程资源占用情况进行Worker线程的管理。在每个Worker线程声明了task用来保存收到的任务，是为后期一个Worker线程同时做多个任务做准备的，Worker线程一旦收到请求任务，在请求完后之前，isWorking状态一直都为true。所有Worker线程有任务以后，会直接在主线程发起请求，不会随机派发给某个Worker线程。

步骤4、事件任务效用最优调度管理。

本环节通过一种新的基于效用函数的启发调度(效用最优调度算法)来实现对事件任务多线程的最优调度管理。该算法在调度时使用效用函数法将任务完成时间和运行成本综合考虑，在进行任务分配时，将任务分配给效用最大的资源。

该调度的目标是在优化调度性能，可以采用多指标来综合评价调度算法的性能，是一个多目标综合优化问题，涉及到3方面主要使用的性能指标，即:

1)任务完成率。满足deadline和budget约束，成功完成的任务占所提交任务的比例。

2)任务执行时间。用户向调度器提交任务的时间与调度器完成向用户返回所完成的所有任务的时间差。

3)任务执行成本。每个完成的任务的成本之和。每个完成任务的成本是执行该任务的资源的价格和任务的执行时间之积。

4.1任务效用函数分析

面向多目标worker任务的效用函数设计，首先要求出每个目标的效用函数。

1)任务执行时间的效用函数，我们定义任务T在资源R上执行的时间效用函数为:

其中，T

2)任务执行成本的效用函数，显然任务执行成本越小而应用用户的满意度越高。所以我们定义任务T在资源R上执行的成本效用函数为:

C

其中，C

3)权重的确定。w1和w2分别代表时间效用和成本效用的相对重要性。w1较大，则用户偏好于减少任务执行时间，反之偏好于尽量减少成本。具体定义如下：

w

w

w

w

其中，T

4.2任务调度分配。

假设N表示vue组件数据更新事件所提交的数目，T表示第i个任务，M表示资源的数目，R表示第j个资源。实现逻辑分配如下，将任务T

步骤5、任务执行与处理。

本步骤是根据上一步骤多线程任务协调资源进行的分配管理后所进行的任务执行处理。

根据建立的各个webworker独立的线程程序，后面步骤再根据主线程通信传输过来的模块标记值进行向服务器后台独立发送数据请求，使用XMLHttpRequest对象来做Ajax通信，来获取该模块所需要的特定数据。

将获取到的数据进行独立数据处理，满足大量模块化数据、图表等前端动态信息变更需求的任务处理，包括进行信息化拼接、展示数据的合并简化与逻辑计算，不影响浏览器主线程的加载与渲染效率。

根据各个webworker独立数据处理的效率不同，各自通过postMessage的方式与web浏览器主线程保持独立连接且不相互影响，由于webwrker的特性无法直接调用浏览器页面DOM节点并直接进行数据的信息填充展示。

即在各自webworker根据各自模块业务展示需要进行数据处理完成后的结果数据连同模块唯一标记传输给浏览器主线程，触发主线程的监听数据程序来进行主页面主线程的DOM操作。

//将数据处理后的结果post给主线程

postMessage({tag:XXX，resultObj:数据处理结果js对象})

由于webwrker的特性无法直接调用浏览器页面DOM节点并直接进行数据的信息填充展示，各自webworker将数据处理结果数据连同模块唯一标记传输给浏览器主线程。

步骤6、状态树state更新。

本步骤通过前面的事件触发后的任务管理并执行的结果进行对应的更新前端模块状态树state，再通过虚拟化dom完成该模块的页面渲染。

在store.state.count变化的时候，都会重新求取计算属性，并且触发更新相关联的DOM。在模块化的构建系统中，在每个需要使用state的组件中需要频繁地导入，并且在测试组件时需要模拟状态。

在本申请实施例中，通过vue模块展示任务事件需求与数据源的多线程直连并行处理，前端所有vue展示模块(即组件)的事件任务，全部通过web worker技术来新建线程进行异步并行加载处理，并统一面向state数据仓库进行数据变更，并以Dinic资源扫描算法和效用调度分析算法对并行处理任务进行计算流量的控制与管理。包括：

设计了一种并发事件任务多线程直连的处理方式，替换了原有基础通用的脱耦事件与任务处理，通过webworker多线程进行异步并行加载处理，提升事件至任务处理的一体化综合管理把控，而非多对多的事件与任务间的映射匹配处理，并统一面向state数据仓库进行数据变更，高效满足了在复杂大屏可视化中海量信息模块展示的动态更新与数据计算应用场景。

创新式的将网络流Dinic算法融合应用到web可视化中对前端模块化并行处理信息任务进行计算流量的扫描检查与控制管理，将前端web worker线程池中所有Worker线程的其状态、其资源占用、其处理数据体积进行遍历扫描并快速总结出最小占用的Worker线程worker，然后进行事件任务资源状态管理。

通过设计一种基于效用函数的效用最优调度算法来实现对事件任务多线程的最优调度管理。该算法在考虑对各worker任务完成时间和运行成本综合考虑，在进行任务分配时，将任务分配给效用最大的资源。

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

1、更低占用的高效处理。在不影响主页面结构展示效率的情况下，以多线程的方式对事件型模块数据更新任务进行统一的并行管理处理，并在进行多任务同时处理时，可以减少对跨模块数据源的重复请求与协同，降低web前端有限的内存资源占用。

2、更灵活应对前端复杂场景。可适应大屏或PC端海量图表等信息内容在模块化敏捷框架中的计算与处理的高效机制支撑。

基于上述实施例提供的页面显示方法，相应地，本申请还提供了页面显示装置的具体实现方式。请参见以下实施例。

参见图7，本申请实施例提供的页面显示装置可以包括：

获取模块701，用于获取目标事件任务，其中，所述目标事件任务由页面的目标组件的状态信息发生变化触发；所述目标事件任务包括N个计算任务，N为大于1的整数；

确定模块702，用于通过Dinic算法确定worker线程池中最小资源占用的M个worker线程，其中，M为大于1，小于或等于N的整数；

执行模块703，用于利用所述M个worker线程执行所述N个计算任务，得到所述目标事件任务的执行结果；

显示模块，用于利用所述执行结果，更新显示所述页面中的所述目标组件。

在一些实施例中，所述确定模块，包括：

扫描子模块，用于通过Dinic算法扫描worker线程池中各worker线程的流量信息，其中，所述流量信息包括以下至少一项：状态信息、内存占用信息和数据处理性能信息；

第一确定子模块，用于利用所述流量信息确定所述worker线程池中最小资源占用的M个worker线程。

在一些实施例中，所述第一执行模块，包括：

第二确定子模块，用于基于效用函数确定所述M个worker线程中，用于计算所述N个计算任务中第i计算任务的效用最大的目标worker线程，其中，i为小于或等于N的正整数；

执行子模块，用于利用所述目标worker线程执行所述第i计算任务。

在一些实施例中，所述第二确定子模块，包括：

第一确定单元，用于根据时间效用函数，确定所述第i计算任务在各worker线程上执行的时间效用值；

第二确定单元，用于根据成本效用函数，确定所述第i计算任务在各worker线程上执行的成本效用值；

第三确定单元，用于根据所述第i计算任务在各worker线程上执行的所述时间效用值和所述成本效用值，确定所述第i计算任务在各worker线程上执行的目标效用值，得到与所述M个worker线程一一对应的M个目标效用值；

第四确定单元，用于将所述M个目标效用值中的最大值对应的worker线程，确定为用于计算所述第i计算任务的效用最大的目标worker线程。

在一些实施例中，所述时间效用函数如公式(1)所示：

其中，U

所述成本效用函数如公式(2)所示：

其中，U

在一些实施例中，所述第三确定单元，具体用于：

获取时间效用权重值和成本效用权重值；

将各worker线程的第一值与第二值的和，确定为所述第i计算任务在各worker线程上执行的目标效用值，得到与所述M个worker线程一一对应的M个目标效用值；

其中，各worker线程的所述第一值为各worker线程的所述时间效用值与所述时间效用权重值的乘积，各worker线程的所述第二值为各worker线程的所述成本效用值与所述成本效用权重值的乘积；

所述时间效用权重值W

其中，

T

在一些实施例中，所述获取模块，包括：

监听子模块，用于监听所述目标组件对应的至少一个状态信息；

生成子模块，用于在监听到所述至少一个状态信息中的目标状态信息发生变化的情况下，根据所述目标状态信息，生成目标事件任务。

本申请实施例提供的页面显示装置能够实现方法实施例中页面显示装置实现的各个过程，为避免重复，这里不再赘述。

图8示出了本申请实施例提供的页面显示的硬件结构示意图。

在页面显示设备可以包括处理器801以及存储有计算机程序指令的存储器802。

具体地，上述处理器801可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器802可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器802可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器802可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器802可在综合网关容灾设备的内部或外部。在特定实施例中，存储器802是非易失性固态存储器。

存储器可包括只读存储器(Read-Only Memory，ROM)，随机存取存储器(RanDOMAccess Memory，RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本公开的一方面的方法所描述的操作。

处理器801通过读取并执行存储器802中存储的计算机程序指令，以实现上述实施例中的任意一种页面显示方法。

在一个示例中，页面显示设备还可包括通信接口808和总线810。其中，如图8所示，处理器801、存储器802、通信接口808通过总线810连接并完成相互间的通信。

通信接口808，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。

总线810包括硬件、软件或两者，将页面显示设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线810可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

另外，结合上述实施例中的页面显示方法，本申请实施例可提供一种计算机存储介质来实现。该计算机存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种页面显示方法。

需要明确的是，本申请并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申请的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

上面参考根据本公开的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

以上所述，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。