[0001] 本公开涉及软件处理技术领域，尤其涉及一种微前端性能监测方法、装置、设备及存储介质。

[0002] 前端的网络性能是用户留存率的重要影响因素。目前，微前端应用是互联网行业的一个大趋势。但是，现有技术中性能监测技术针对多页应用，依托导航计时标准，记录多页应用页面初次加载或者深度刷新过程中的性能数据。而微前端内的应用切换时不会触发页面重新加载，无法在应用切换时及时获得性能数据，进而无法及时发现微前端网络性能存在的问题，导致微前端的使用体验差。

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

[0021] 网络性能影响用户留存率，例如，万维网(World wide web，web)页面的加载性能。研究表明：如果一个移动端页面加载时长超过3秒，用户就会放弃而离开；并且网页加载时长每增加1秒，用户就会流失10％。我们希望通过监控来知道web应用性能的现状和趋势。而针对微前端应用的特殊性，本公开提供一种微前端性能监测方法，来实现对微前端应用的性能监测。本方法可以通过软件算法实现，该软件算法实现于服务器、计算机、处理器等处理设备中，且该处理设备能够获取微前端的相关数据。下面结合图1‑图2描述本公开实施例提供的微前端性能监测方法。

[0022] 一个实施例中，如图1所示，微前端性能监测方法实现的流程步骤如下：

[0023] 步骤101，获取微前端内切换至目标应用的应用切换信息。

[0024] 本实施例中，由独立交付的多个前端应用组成整体架构，形成微前端。微前端包括主应用和至少一个子应用，通过主应用将各个子应用集成起来，各个应用之间独立部署。当微前端内的应用切换时，不会触发页面的重新加载，但是应用切换会导致一些与应用相关信息变化，例如，统一资源定位地址的变化等，从这些变化中可以提取到应用切换信息。

[0025] 步骤102，当应用切换信息触发历史代理函数时，获取目标应用请求的资源，其中，历史代理函数由第一钩子函数代理历史记录接口形成，历史记录接口用于记录微前端内应用切换时的路由变化。

[0026] 本实施例中，预先通过第一钩子函数和历史记录接口构建历史代理函数。历史记录接口是一个用于记录微前端内应用切换时路由变化的应用程序编程接口(Application Programming Interface，API)，具体的，Windows操作系统下的历史记录接口为window.history接口。Window.history接口用于保存用户在一个会话期间的网站访问记录，用户每次访问一个新的统一资源定位(uniform resource locator，URL)地址(即路由变化一次)则创建一个新的历史记录。微前端内应用切换导致路由变化，也就是说，切换前的应用和切换后的应用所对应的URL地址是不一样的。通过第一钩子函数代理window.history接口形成资源获取代理函数，表示为proxyHistory。

[0027] 钩子函数是Windows消息处理机制的一部分，通过设置钩子函数，应用程序可以在系统级对所有消息、事件进行过滤，访问在正常情况下无法访问的消息。钩子函数的本质是一段用以处理系统消息的程序，通过系统调用，把钩子函数挂入系统。

[0028] 由第一钩子函数代理历史记录接口形成历史代理函数。当微前端内应用切换时，URL地址的变化造成历史记录接口动作，进而触发历史代理函数。也就是说，当历史代理函数被触发时，表明此时微前端内存在应用切换的动作。当历史代理函数被触发时，表明微前端内的应用切换至目标应用，则获取目标应用请求的资源，来对目标应用进行性能监测。

[0029] 步骤103，对资源进行性能分析，获得目标应用的性能监测数据。

[0030] 本实施例中，获取目标应用请求的资源后，对该资源进行性能分析，即可获得目标应用的性能监测数据。

[0031] 一个实施例中，获取目标应用的资源时，采用资源获取代理函数。具体的，当应用切换信息触发历史代理函数时，获取目标应用请求的资源，实现过程如下：当应用切换信息触发历史代理函数时，调用资源获取代理函数，其中，资源获取代理函数由第二钩子函数代理资源获取接口形成，资源获取接口用于微前端内的目标应用向后端获取资源；通过资源获取代理函数，获取目标应用请求的资源。

[0032] 本实施例中，微前端内的目标应用在获取资源时，需要通过资源获取接口。基于微前端实现的具体方式，微前端所支持的资源获取接口实现形式也有所不同，例如，Windows操作系统下的资源获取接口的具体实现形式根据需要可以为window.XMLHttpRequest或window.fetch。通过第二钩子函数代理window.XMLHttpRequest形成资源获取代理函数，表示为proxyXMLHttpRequest；或者，第二钩子函数代理window.fetch形成资源获取代理函数，表示为proxyFetch。

[0033] 当历史代理函数被触发时，表示微前端内发生了应用切换，则调用预先设置的资源获取代理函数，来获取目标应用请求的资源。

[0034] 一个实施例中，当通过资源获取代理函数获取目标应用请求的资源后，通过性能监听代理函数得到目标应用的性能监测数据。具体的，对资源进行性能分析，获得目标应用的性能监测数据，实现过程如下：当资源获取代理函数生成资源加载结束信息时，调用性能监听代理函数，其中，性能监听代理函数由第三钩子函数代理性能监听接口形成，性能监听接口用于监听文档对象模型结构变化；通过性能监听代理函数，分析资源中文档对象模型的结构变化，获得目标应用的性能监测数据。其中，资源加载结束信息表示资源加载操作已经执行完毕。

[0035] 本实施例中，预先通过第三钩子函数和性能监听接口形成性能监听代理函数。性能监听接口用于监听文档对象模型(Document Object Model，DOM)结构变化，具体的，Windows操作系统下的性能监听接口为MutationObserver接口。MutationObserve的所有监听操作以及相应处理都是在其他脚本执行完成之后异步执行的，并且是所有变动触发之后，将变得记录在数组中，统一进行回调，也就是说，当使用MutationObserver监听至少一个DOM变化时，并且每个DOM均发生了变化，那么MutationObserve会将变化记录到变化数组中，等待一起都结束了，然后一次性的从变化数组中执行其对应的回调函数。通过第三钩子函数代理MutationObserver接口形成性能监听代理函数，表示为proxyMutationObserver。

[0036] 本实施例中，当目标应用请求的资源全部加载完毕时，资源获取代理函数会生成资源加载结束信息。该资源加载结束信息生成时，则会触发性能监听代理函数，对目标应用请求的资源进行分析，即分析该资源中DOM的结构变化，进而获得目标应用的性能监测数据。

[0037] 一个实施例中，对于微前端的性能监测，主要针对的是微前端请求资源的情况，所以为了简化处理流程，避免处理资源浪费，性能监测过程中通过兴趣标签来调用资源获取代理函数。具体的，当应用切换信息触发历史代理函数时，调用资源获取代理函数，具体实现过程为：当应用切换信息触发历史代理函数时，获取目标应用的统一资源定位地址；确定统一资源定位地址包含预设的兴趣标签后，调用资源获取代理函数，其中，兴趣标签为指示资源加载操作的标签。

[0038] 本实施例中，当应用切换导致历史代理函数被触发时，获取切换后目标应用的统一资源定位地址(即URL地址)。若目标应用向后端请求资源，则URL地址中会有指示资源加载操作的标签，例如，img、iframe、image、link(stylesheet)、src、href等。

[0039] 其中，img指的是图像文件的一种格式，目标应用的URL地址中带有img标签，表示目标应用请求了图像资源；iframe指的是页面嵌套，iframe标签用于规定一个内联框架，一个内联框架被用来在当前超文本标记语言(Hyper Text Markup Language，HTML)文档中嵌入另一个文档，目标应用的URL地址中带有iframe标签，表示目标应用请求了文档资源；link标签用于定义文档与外部资源的关系，即用于链接样式表(stylesheet)，目标应用的URL地址中带有link标签，表示目标应用通过文档向外部请求了资源；src指的是source的缩写，指向外部资源的位置，指向的内容将会应用到文档中当前标签所在位置，src用于规定要播放的音频资源的URL；href(Hypertext Reference)指定网络资源的位置，从而在当前元素或者当前文档和由当前属性定义的需要的锚点或资源之间定义一个链接或者关系，href用于指定超链接目标资源的URL。

[0040] 当然，还可以根据实际情况和/或具体需求，来确定兴趣标签的具体类型，本申请的保护范围不以兴趣标签的具体类型为限制。

[0041] 本实施例中，通过确定URL地址中是否包含兴趣标签，来确定切换后的目标应用是否会触发资源加载的操作，若URL地址中包含预设的兴趣标签，则调用资源获取代理函数，对目标应用请求的资源进行分析以获得性能监测数据；若URL地址中不包含预设的兴趣标签，表示切换后的目标应用并没有加载资源，则不调用资源获取代理函数。上述过程避免了目标应用并未请求资源，但是仍旧调用资源获取代理函数，导致处理资源浪费的情况，节省了处理资源，提高微前端性能监测过程的效率。

[0042] 一个实施例中，为进一步提高微前端性能监测的效率，通过定时器监控资源加载操作的进程，具体的，在调用资源获取代理函数的同时，启动定时器统计资源加载操作的执行时长；当资源获取代理函数生成资源加载结束信息时，调用性能监听代理函数，实现过程如下：当执行时长达到第一预设时长时，将定时器清零，判断资源加载操作是否结束，若是，根据资源获取代理函数生成的资源加载结束信息，调用性能监听代理函数；若否，再次启动定时器统计执行时长。

[0043] 本实施例中，目标应用请求资源的过程中，可能存在数据延迟等情况。在调用资源获取代理函数后，性能监听代理函数需要在全部资源请求完毕后进行性能分析。通过定时器周期性计时第一预设时长，实现周期性通过资源获取代理函数获取目标应用请求的资源。通过以第一预设时长为周期来判断资源加载操作是否结束，当目标应用资源加载操作结束时，则立即调用性能监听代理函数进行性能分析，明确函数调用时机，避免处理资源浪费。

[0044] 一个实施例中，预先设定第二预设时长，实现资源加载操作的延时缓冲，优选的，第二预设时长可以设定为50毫秒至100毫秒中的任意一个时长。具体的，启动定时器统计资源加载操作的执行时长，实现过程如下：启动定时器累计观察时长；通过资源获取代理函数，判断资源加载操作是否执行，若是，将定时器清零，再次启动定时器统计资源加载操作的执行时长；若否，确定观察时长达到第二预设时长时，将定时器清零，结束本次性能监测进程。

[0045] 本实施例中，设置第二预设时长，相当于为确定资源加载操作是否结束的过程设置了一个缓冲时间，避免操作存在延迟等情况造成监测数据不完整。

[0046] 一个具体的例子中，第一预设时长设定为1秒，第二预设时长设定为50毫秒。当开始调用资源获取代理函数时，首先观察在50ms内资源加载操作是否执行，若在50毫秒内，若未执行资源加载操作，直接结束本次性能监测进程，同时可以生成无资源加载的性能监测数据；若在50毫秒内，执行资源加载操作，则以1秒为周期，监测资源加载操作是否结束，确定操作结束后，结束资源获取代理函数的调用，进行下一步调用性能监听代理函数进行性能分析。

[0047] 一个实施例中，当获得目标应用的性能监测数据后，需要保存该性能监测数据。此时，需要根据目标应用的类型，分类存储性能监测数据。具体的，对资源进行性能分析，获得目标应用的性能监测数据之后，根据目标应用统一资源定位地址的路由规则，确定目标应用的应用类型，其中，应用类型包括主应用和子应用；将目标应用的性能监测数据，与应用类型对应保存。

[0048] 本实施例中，微前端内进行应用切换时，伴随着URL地址的变化。切换后的应用，URL地址符合预定的路由规则。预先设定应用类型和路由规则的键值对，以应用类型为键，路由规则为值，具体的，应用类型包括主应用和子应用。基于上述实施例中获得的目标应用URL地址，或者，通过单独获取目标应用的URL地址，来判断目标应用的应用类型。当切换后的目标应用URL地址的路由规则属于主应用时，则将目标应用的性能监测数据保存与主应用对应保存。当切换后的目标应用URL地址的路由规则属于子应用时，则将目标应用的性能监测数据保存与子应用对应保存。具体的，预先设置主应用和子应用的存储区域，当目标应用URL地址的路由规则属于主应用时，则将目标应用的性能监测数据存储至主应用对应的存储区域；当目标应用URL地址的路由规则属于子应用时，则将目标应用的性能监测数据存储至子应用对应的存储区域。

[0049] 一个实施例中，分类存储性能监测数据时，还可以根据资源域名来实现。具体的，对资源进行性能分析，获得目标应用的性能监测数据之后，根据目标应用的统一资源定位地址，获取目标应用的资源域名；根据资源域名，确定目标应用的应用类型，其中，应用类型包括主应用和子应用；将目标应用的性能监测数据，与应用类型对应保存。

[0050] 本实施例中，主应用和子应用均是独立部署的微服务，各个应用获取资源时对应的资源域名和资源传输路径是不同的，该资源域名可以从目标应用的URL地址中提取出来。预先设置应用类型和资源域名的键值对，以应用类型为键，以资源域名为值，具体的，基于上述实施例中获得的目标应用URL地址，或者，通过单独获取目标应用的URL地址，提取目标应用对应的资源域名。当目标应用请求资源数据时，对应的资源域名属于主应用时，将目标应用的性能监测数据与主应用对应保存。当目标应用请求资源数据时，对应的资源域名属于子应用时，将目标应用的性能监测数据与子应用对应保存。具体的，预先设置主应用和子应用的存储区域，当目标应用对应的资源域名属于主应用时，则将目标应用的性能监测数据存储至主应用对应的存储区域；当目标应用对应的资源域名属于子应用时，则将目标应用的性能监测数据存储至子应用对应的存储区域。

[0051] 上述实施例中，将主应用和子应用的性能监测数据分类存储，便于后续对数据的进一步处理。

[0052] 一个具体的实施例中，如图2所示，微前端性能监测方法实现的具体流程如下：

[0053] 当微前端内切换至目标应用时，应用切换会导致路由变化，即当前URL地址切换至目标应用的URL地址。本方法所处运行环境的探针，抓取由于路由变化生成的应用切换信息，进而触发历史代理函数。本实施例对兴趣标签标示的兴趣节点进行监听，即确定目标应用的URL地址中包含兴趣标签后，调用资源获取代理函数。当历史代理函数被触发后，且在兴趣标签下，目标应用请求资源时，触发资源获取代理函数(proxyXMLHttpRequest或proxyFetch)，图2中，XHR或Fetch表示资源获取的过程。在资源加载操作执行过程中，将50ms～100ms中任意一个时长作为第二预设时长，例如第二预设时长为50ms，实现性能监听代理函数的调用延时，避免遗漏加载数据导致性能监听结果不完善的后果。若50ms内若未执行资源加载操作直接结束本次性能监测进程，同时可以生成无资源加载的性能监测数据；若在50毫秒内，执行资源加载操作，则以第一预设时长为周期，例如，第一预设时长为
1s，周期性观测资源加载操作是否结束，直至确定全部资源已经加载结束，则调用性能监听代理函数进行性能分析，获得性能监测数据。资源获取代理函数与性能分析代理函数结合，通过性能监听代理函数，对资源获取代理函数获得的资源进行分析，最终得到目标应用的性能监测数据。

[0054] 获得性能监测数据后，将该性能监测数据上报给存储装置，按照目标应用的应用类型将性能监测数据保存。本次对微前端内目标应用的性能监测过程结束。

[0055] 本公开提供的微前端性能监测方法，通过第一钩子函数代理历史记录接口形成历史代理函数，其中微前端内应用切换导致的路由变化由历史记录接口记录。当获取微前端内切换至目标应用的应用切换信息时，应用切换信息则会触发历史代理函数，该历史代理函数被触发时，获取目标应用请求的资源，通过分析该资源，得到目标应用的性能监测数据。也就是说，通过历史代理函数，能够在微前端内的应用切换时，启动性能监测的流程，实现微前端内应用切换时的性能监测。

[0056] 下面对本公开实施例提供的微前端性能监测装置进行描述，下文描述的微前端性能监测装置与上文描述的微前端性能监测方法可相互对应参照，重复之处不再赘述。如图3所示，微前端性能监测装置包括：

[0057] 第一获取模块301，用于获取微前端内切换至目标应用的应用切换信息；

[0058] 第二获取模块302，用于当应用切换信息触发历史代理函数时，获取目标应用请求的资源，其中，历史代理函数由第一钩子函数代理历史记录接口形成，历史记录接口用于记录微前端内应用切换时的路由变化；

[0059] 分析模块303，用于对资源进行性能分析，获得目标应用的性能监测数据。

[0060] 一个实施例中，第二获取模块302，具体用于当应用切换信息触发历史代理函数时，调用资源获取代理函数，其中，资源获取代理函数由第二钩子函数代理资源获取接口形成，资源获取接口用于微前端内的目标应用向后端获取资源；通过资源获取代理函数，获取目标应用请求的资源。

[0061] 一个实施例中，分析模块303，具体用于当资源获取代理函数生成资源加载结束信息时，调用性能监听代理函数，其中，性能监听代理函数由第三钩子函数代理性能监听接口形成，性能监听接口用于监听文档对象模型结构变化；通过性能监听代理函数，分析资源中文档对象模型的结构变化，获得目标应用的性能监测数据。

[0062] 一个实施例中，第二获取模块302，具体用于当应用切换信息触发历史代理函数时，获取目标应用的统一资源定位地址；确定统一资源定位地址包含预设的兴趣标签后，调用资源获取代理函数，其中，兴趣标签为指示资源加载操作的标签。

[0063] 一个实施例中，分析模块303，具体用于调用资源获取代理函数的同时，启动定时器统计资源加载操作的执行时长；以及具体用于当执行时长达到第一预设时长时，将定时器清零，判断资源加载操作是否结束，若是，根据资源获取代理函数生成的资源加载结束信息，调用性能监听代理函数；若否，再次启动定时器统计执行时长。

[0064] 一个实施例中，微前端性能监测装置还包括存储模块304，用于对资源进行性能分析，获得目标应用的性能监测数据之后，根据目标应用统一资源定位地址的路由规则，确定目标应用的应用类型，其中，应用类型包括主应用和子应用；将目标应用的性能监测数据，与应用类型对应保存。

[0065] 一个实施例中，存储模块304，用于对资源进行性能分析，获得目标应用的性能监测数据之后，根据目标应用的统一资源定位地址，获取目标应用的资源域名；根据资源域名，确定目标应用的应用类型，其中，应用类型包括主应用和子应用；将目标应用的性能监测数据，与应用类型对应保存。

[0066] 图4示例了一种电子设备的实体结构示意图，如图4所示，该电子设备可以包括：处理器(processor)401、通信接口(Communications Interface)402、存储器(memory)403和通信总线404，其中，处理器401，通信接口402，存储器403通过通信总线404完成相互间的通信。处理器401可以调用存储器403中的逻辑指令，以执行微前端性能监测方法，该方法包括：获取微前端内切换至目标应用的应用切换信息；当应用切换信息触发历史代理函数时，获取目标应用请求的资源，其中，历史代理函数由第一钩子函数代理历史记录接口形成，历史记录接口用于记录微前端内应用切换时的路由变化；对资源进行性能分析，获得目标应用的性能监测数据。

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

[0068] 另一方面，本公开还提供一种计算机程序产品，计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，计算机程序包括程序指令，当程序指令被计算机执行时，计算机能够执行上述各方法所提供的微前端性能监测方法，该方法包括：获取微前端内切换至目标应用的应用切换信息；当应用切换信息触发历史代理函数时，获取目标应用请求的资源，其中，历史代理函数由第一钩子函数代理历史记录接口形成，历史记录接口用于记录微前端内应用切换时的路由变化；对资源进行性能分析，获得目标应用的性能监测数据。

[0069] 又一方面，本公开还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各提供的微前端性能监测方法，该方法包括：获取微前端内切换至目标应用的应用切换信息；当应用切换信息触发历史代理函数时，获取目标应用请求的资源，其中，历史代理函数由第一钩子函数代理历史记录接口形成，历史记录接口用于记录微前端内应用切换时的路由变化；对资源进行性能分析，获得目标应用的性能监测数据。

[0070] 以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

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

[0072] 最后应说明的是：以上实施例仅用以说明本公开的技术方案，而非对其限制；尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本公开各实施例技术方案的精神和范围。