H5 application page white screen detection method and device, equipment and medium

Abstract

The invention relates to the technical field of data processing, can be applied to business system platforms of medical health, financial science and technology and the like, and discloses an H5 application page white screen detection method which comprises the following steps: acquiring a to-be-detected page of an H5 application, analyzing the to-be-detected page, and determining a target detection area; analyzing the target detection area, extracting key elements, and judging whether a white screen condition occurs or not according to the key elements; monitoring element changes of the DOM of the to-be-detected page in real time, obtaining element change information, and judging whether a white screen condition occurs or not according to the element change information; obtaining timeline data after loading of the to-be-detected page is completed, and judging whether a white screen condition occurs or not according to the timeline data and the time threshold value; detecting a JS error and / or a resource loading state of the to-be-detected page in real time, and judging whether a white screen condition occurs or not according to the JS error and / or the resource loading state; and obtaining all white screen data in which the white screen occurs, transmitting the white screen data to a server, and sending out a white screen alarm.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method, apparatus, device, and storage medium for detecting blank screens on H5 application pages. Background Technology

[0002] Traditional H5 white screen monitoring solutions have core limitations and urgently need systematic reconstruction. Existing solutions rely excessively on page loading events such as `window.onload`, which can only determine the loading completion status and cannot distinguish whether the white screen is caused by a JS error, resource loading failure, or DOM operation abnormality. While DOM element detection can capture some scenarios, it is highly dependent on selector accuracy and prone to false positives in dynamic content or asynchronous rendering scenarios, making root cause localization difficult. Current monitoring systems can only capture JS exceptions and resource loading failures, completely failing to address white screens caused by non-JS exceptions such as framework crashes (e.g., React / Vue runtime errors), network interruptions, and CSS rendering blockages. This "seeing the trees but not the forest" approach leaves many critical exception scenarios in monitoring blind spots. Traditional solutions are mostly post-event analysis (e.g., error log reporting), lacking real-time response capabilities; monitoring granularity remains at the coarse-grained event level, unable to pinpoint the specific root cause of the exception (e.g., a failed API request or a specific DOM operation error). Performance tools (such as Lighthouse) can only analyze loading performance and cannot directly correlate with white screen phenomena, leading to fragmented root cause analysis. Existing monitoring functions are fixed and difficult to extend to complex scenarios such as WebAssembly crashes and Service Worker exceptions; manual insertion of monitoring code increases development and maintenance costs and may interfere with business logic. This intrusive design limits the boundaries of monitoring capabilities and increases the risk of system coupling. There is an urgent need to build a next-generation white-screen monitoring system that covers all exception types and has real-time diagnostic capabilities by combining new technologies such as runtime exception capture, resource loading tracing, and rendering state snapshots.

[0003] In the healthcare field, traditional solutions cannot capture React / Vue framework crashes or WebAssembly anomalies in real time, causing critical services such as online consultations and electronic medical records to suddenly display blank screens, affecting the continuity of doctors' diagnoses and potentially delaying crucial treatment time in emergency situations. Lack of monitoring for resource loading failures (such as interrupted loading of medical image DICOM files) can prevent the generation of examination reports, while false positives in DOM detection may mask true anomalies, causing a break in the patient's medical data chain. Post-event log analysis cannot trace offline data synchronization failures caused by Service Worker anomalies, making it difficult to meet the data integrity auditing requirements of regulations such as HIPAA.

[0004] In the fintech sector, blank screens caused by network outages or CSS blocking may conceal payment process anomalies. Traditional monitoring methods cannot distinguish between front-end rendering failures and back-end API timeouts, increasing the risk of fund settlement issues. The lack of real-time capture capabilities for asynchronous rendering anomalies means that high-frequency trading interface freezes cannot be alerted immediately, potentially leading to market manipulation or liquidity risks. When WebAssembly crashes go unmonitored, quantitative trading model anomalies cannot be traced, violating MiFID II and other regulations' requirements for trading transparency. Static performance tools cannot correlate blank screens with underlying API failures, resulting in distorted data in regulatory reports.

[0005] In summary, both domains require high-precision root cause localization (e.g., distinguishing between API failures and DOM manipulation errors), real-time response capabilities (e.g., circuit breaker triggering), and non-JS exception coverage (e.g., WebAssembly crashes). Existing solutions lack runtime snapshots and tracing capabilities, leading to systemic risks to business continuity, data integrity, and compliance. Summary of the Invention

[0006] The main objective of this invention is to provide a method, apparatus, device, and storage medium for detecting white screen on H5 application pages, aiming to solve the limitation of existing white screen monitoring solutions that cannot accurately determine the cause of white screen.

[0007] To achieve the above objectives, the present invention provides a method for detecting blank screens in H5 application pages, comprising: Obtain the page to be detected from the H5 application, analyze the page to be detected, and determine the target detection area; The target detection area is parsed to extract key elements, and the presence of a white screen is determined based on the key elements. Real-time monitoring of DOM element changes on the page to be detected, obtaining element change information, and determining whether a white screen occurs based on the element change information; Obtain the timeline data of the page to be detected after loading, and determine whether a white screen occurs based on the timeline data and the time threshold. Real-time detection of JS errors and / or resource loading status of the page to be detected, and determination of whether a white screen occurs based on the JS errors and / or resource loading status; Acquire all white screen data where a white screen occurs, transmit the white screen data to the server, and issue a white screen warning.

[0008] Furthermore, to achieve the above objectives, the present invention provides an H5 application page white screen detection device, comprising: The target acquisition module is used to acquire the page to be detected in the H5 application, analyze the page to be detected, and determine the target detection area. The key element judgment module is used to parse the target detection area, extract the key elements of the target detection area, and determine whether a white screen occurs based on the key elements. The element change judgment module is used to monitor the element changes of the DOM of the page to be detected in real time, obtain element change information, and determine whether a white screen occurs based on the element change information. The loading time judgment module is used to obtain the timeline data of the page to be detected after loading, and to determine whether a white screen occurs based on the timeline data and the time threshold. The performance monitoring module is used to detect JS errors and / or resource loading status of the page to be detected in real time, and determine whether a white screen occurs based on the JS errors and / or resource loading status. The error reporting module is used to obtain all white screen data when a white screen occurs, transmit the white screen data to the server, and issue a white screen warning.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and an H5 application page white screen detection program stored in the memory and executable on the processor, wherein when the H5 application page white screen detection program is executed by the processor, it implements the steps of the H5 application page white screen detection method as described above.

[0010] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing an H5 application page white screen detection program, wherein when the H5 application page white screen detection program is executed by a processor, it implements the steps of the H5 application page white screen detection method as described above.

[0011] Beneficial Effects: This invention relates to the field of data processing technology and can be applied to business system platforms in communications, healthcare, and fintech. It discloses a method for detecting white screen on H5 application pages, comprising: acquiring the page to be detected in the H5 application and analyzing it to determine a target detection area; parsing the target detection area to extract key elements and determining whether a white screen occurs based on the key elements; monitoring changes in the DOM elements of the page to be detected in real time, acquiring element change information, and determining whether a white screen occurs based on the element change information; acquiring timeline data of the page to be detected after loading, and determining whether a white screen occurs based on the timeline data and a time threshold; detecting JS errors and / or resource loading status of the page to be detected in real time, and determining whether a white screen occurs based on the JS errors and / or resource loading status; acquiring all white screen data where white screen occurs, transmitting the white screen data to a server, and issuing a white screen warning. This invention constructs a lightweight, non-intrusive, and modular software development kit (SDK) and embeds it into an H5 application. The SSD inserts tracking code during critical page loading stages to monitor the rendering status of key elements, DOM changes, page loading timeline, JS errors, and resource loading in real time, comprehensively determining whether a blank screen (white screen) occurs. When a blank screen is detected, relevant data is reported to the server and a warning is issued, effectively improving front-end anomaly monitoring capabilities and ensuring a better user experience. Attached Figure Description

[0012] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for an H5 application page white screen detection method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the H5 application page white screen detection method of the present invention; Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the H5 application page white screen detection device of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0013] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0014] The H5 application page white screen detection method provided in this embodiment of the invention can be applied to applications such as... Figure 1In this application environment, the user client communicates with the server via a network. The server can obtain the H5 application's page to be tested from the user client, analyze the page to be tested, determine the target detection area, parse the target detection area, extract key elements, and determine whether a white screen occurs based on the key elements; monitor the DOM element changes of the page to be tested in real time, obtain element change information, and determine whether a white screen occurs based on the element change information; obtain the timeline data of the page to be tested's loading completion, and determine whether a white screen occurs based on the timeline data and time thresholds; detect JS errors and / or resource loading status of the page to be tested in real time, and determine whether a white screen occurs based on the JS errors and / or resource loading status; obtain all white screen data where white screens occur, transmit the white screen data to the server, and issue a white screen warning. This invention constructs a lightweight, non-intrusive, and modular software development kit (SDK) and embeds it into an H5 application. The SSD inserts tracking code during critical page loading stages to monitor the rendering status of key elements, DOM changes, page loading timeline, JS errors, and resource loading in real time, comprehensively determining whether a blank screen occurs. Upon detecting a blank screen, relevant data is reported to the server and a warning is issued, effectively improving front-end anomaly monitoring capabilities and ensuring user experience. The user end can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server end can be implemented using a dedicated server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0015] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the H5 application page white screen detection method provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0016] like Figure 2 As shown, the H5 application page white screen detection method proposed in this invention includes the following steps: S100: Obtain the page to be detected from the H5 application, analyze the page to be detected, and determine the target detection area; S200: The target detection area is parsed and processed to extract key elements of the target detection area, and the white screen situation is determined based on the key elements. S300. Monitor the changes of DOM elements on the page to be detected in real time, obtain element change information, and determine whether a white screen occurs based on the element change information. S400: Obtain the timeline data of the page to be detected after loading, and determine whether a white screen occurs based on the timeline data and the time threshold. S500. Real-time detection of JS errors and / or resource loading status of the page to be detected, and determination of whether a white screen occurs based on the JS errors and / or resource loading status. S600: Obtain all white screen data where a white screen occurs, transmit the white screen data to the server, and issue a white screen warning.

[0017] In this embodiment, a series of systematic steps are used to comprehensively monitor the white screen situation of H5 applications, thereby helping developers to discover and solve problems in a timely manner, and improve user experience and system stability.

[0018] The page to be monitored refers to the H5 page that needs to be monitored for white screen issues, loaded through a browser. During the initialization of the Software Development Kit (SDK), the specific pages to be monitored can be specified through configuration. The target detection area refers to the area on the page that needs focused monitoring for white screen phenomena, typically the core content areas that users are interested in, such as the page header, main content area, and footer. To determine the target detection area, the page can be analyzed in the following ways: first, using CSS selectors (such as ID and class name) to directly locate the target detection area; second, based on page layout analysis, determining the key areas by analyzing the page's DOM structure. The target detection area is then parsed to extract key elements, which are crucial to user experience, such as buttons, text boxes, and images. The presence of a white screen is determined by checking whether these key elements are rendered correctly. If the key elements are not rendered, a white screen is considered to have occurred.

[0019] To monitor DOM element changes on a webpage in real time, you can use the Mutation Observer (a Web API provided by the browser for listening to changes in the DOM tree). The Mutation Observer allows you to obtain real-time information about DOM changes, including element additions, deletions, and attribute changes. Based on this information, you can further determine if a blank screen (white screen) has occurred. Additionally, you can use the Performance API (a set of JavaScript interfaces provided by the browser for measuring and monitoring webpage performance) to obtain timeline data on the page's loading completion, including navigation start time, DNS lookup time, and TCP connection time. Based on the page load time and a preset time threshold, if the page load time exceeds the threshold, a blank screen is considered to have occurred.

[0020] Meanwhile, real-time detection of JavaScript errors and resource loading status on the page under test is also an important monitoring method. Synchronous and asynchronous errors can be captured through global error capture mechanisms (such as `window.onerror` and `window.addEventListener(error)`). Resource loading status can be detected by listening to the `load` and `error` events of resources. If a JavaScript error or resource loading failure is captured, it may mean that the page displays a blank screen.

[0021] Upon detecting a blank screen, it's necessary to obtain relevant blank screen data, including timeline data, JavaScript error messages, and resource loading status. This data is then transmitted to the server via an HTTP request, along with a blank screen warning, to notify developers or operations personnel to address the issue promptly.

[0022] Through the above steps, from determining the target detection area to real-time monitoring of DOM changes, page load time, JS errors and resource loading status, and then transmitting the white screen data to the server and issuing warnings, the entire process can comprehensively monitor the white screen situation of H5 applications, effectively helping developers to discover and solve white screen problems in a timely manner, thereby improving user experience and system stability.

[0023] For example, in the financial technology field, the above content can be applied to scenarios such as online trading platforms, mobile banking apps, and financial information display pages of financial institutions. These pages have extremely high requirements for stability and user experience; any blank screen phenomenon may prevent users from completing transactions or obtaining important information in a timely manner, thereby leading to customer complaints and economic losses. By embedding a lightweight software development kit (SDK), financial institutions can monitor key stages of the page loading process in real time, such as DOM loading, resource loading, and JS execution, accurately identifying the causes of blank screens, such as JavaScript errors, resource loading failures, or DOM operation anomalies. The non-intrusive design of the SSD allows financial institutions to quickly integrate monitoring functions without significantly modifying existing code, improving development efficiency. At the same time, the modular design of the SSD allows financial institutions to flexibly configure monitoring strategies according to business needs, such as focusing on monitoring key elements such as transaction buttons and account balance display areas to ensure the normal rendering of these elements. Once a blank screen is detected, the system will immediately report abnormal data, including time, page, and user device information, helping financial institutions quickly locate the problem and take measures to ensure the stable operation of the trading system and improve customer satisfaction and trust.

[0024] In the field of healthcare technology, this technology can be applied to scenarios such as online consultation systems, electronic medical record display pages, and remote medical monitoring interfaces on healthcare platforms. The stability of pages in the healthcare field is directly related to patients' health and the continuity of medical services. By using a Software Development Kit (SDK), healthcare platforms can monitor page loading and rendering status in real time, ensuring that critical information such as patient vital signs, diagnostic results, and medication information is displayed to doctors and patients promptly and accurately. The real-time data acquisition function of the SDK comprehensively records various states during the page loading process, including the rendering time of key elements, JS errors, and resource loading status, helping the healthcare platform accurately pinpoint the cause of white screen errors, such as network problems, server response delays, or front-end code errors. Furthermore, the SDK has good compatibility, adapting to various medical devices and browser environments, ensuring the wide applicability of the monitoring function. When a white screen occurs, the system quickly reports abnormal data and issues a warning, notifying the healthcare platform's operations and maintenance personnel to handle the situation promptly, avoiding disruption to normal medical services and ensuring patients' medical experience and safety. Through this real-time monitoring and rapid response mechanism, the medical and health technology field can effectively improve the stability and reliability of the system, and provide patients with higher quality and more efficient medical services.

[0025] In one embodiment, prior to step S100, the method further includes: Pre-built software development kits; The software development kit can be embedded into the H5 application using either manual or automatic embedding mode. The initialization method of the software development kit is called in the entry file of the H5 application; Configure the parameters of the software development kit using the initialization method described above.

[0026] In this embodiment, the Software Development Kit (SDK) is a lightweight, non-intrusive, and modular tool specifically designed for monitoring white screen issues in H5 applications. Its lightweight design ensures a small SDK size, minimizing impact on page performance and avoiding excessive network bandwidth consumption or prolonged page load times. Its non-intrusive nature is reflected in the fact that the SDK can dynamically inject scripts or automatically inject code using build tools, eliminating the need for extensive modifications to business logic and reducing disruption to the development process, thus improving efficiency. The modular design provides the SDK with greater flexibility, supporting on-demand loading; for example, it can monitor white screen issues, performance problems, or errors separately, and can be customized to meet different business needs.

[0027] The process of building a software development kit (SDK) mainly includes the following steps: core function development, implementing the core functions of the SSD, such as data acquisition, white screen judgment logic, and data reporting; performance optimization, ensuring that the code execution efficiency of the SSD is high and will not negatively affect page performance; compatibility testing, verifying the compatibility of the SSD on different browsers and devices to ensure that it can work normally; and modular encapsulation, encapsulating the different functions of the SSD into modules for easy loading and expansion on demand.

[0028] Embedding a software development kit (SDK) into an HTML5 application can be achieved through either manual or automatic embedding. Manual embedding includes directly embedding it into the HTML file. <script>标签引入软件开发工具包脚本文件，这种方式简单直接，但需要开发者手动管理软件开发工具包的引入路径；或者通过构建工具（如Webpack、Rollup等）配置，在构建过程中自动嵌入软件开发工具包代码，这种方式更加自动化，但需要开发者熟悉构建工具的配置。自动嵌入模式则通过工具或脚本实现，例如开发构建工具插件（如Webpack插件），在构建过程中自动注入软件开发工具包代码，插件可以在HTML文件的指定位置插入<script>标签或直接将软件开发工具包代码注入到JavaScript文件中；或者编写代码注入脚本，扫描H5应用的代码文件，并在指定位置插入软件开发工具包的初始化代码，这种方式适用于已经存在的项目，无需修改构建工具的配置。无论采用哪种嵌入模式，目标都是将软件开发工具包成功嵌入到H5应用中，使其在页面加载过程中发挥作用。

[0029] H5应用的入口文件通常是页面加载的起点，例如在单页面应用（SPA）中可能是index.js或main.js，在多页面应用中可能是每个页面的主JavaScript文件。在入口文件中调用软件开发工具包的初始化方法，是为了确保软件开发工具包在页面加载的早期阶段就开始工作，从而能够实时采集数据并监控白屏现象。初始化方法的作用包括配置软件开发工具包参数，通过它可以设置软件开发工具包的各种参数，如数据上报的地址、监控的白屏阈值、需要监控的关键元素等，这些参数决定了软件开发工具包的行为和功能；启动数据采集，初始化方法会启动软件开发工具包的数据采集功能，包括页面加载阶段的监控、关键元素的可见性状态监控、异常信息监控等；设置白屏判定逻辑，初始化方法会根据配置的参数，设置白屏判定逻辑，例如时间线判定、DOM状态判定、资源加载判定等，从而根据配置的参数开始监控H5应用的白屏现象。

[0030] 软件开发工具包支持按需加载和自定义监控策略，这意味着可以通过初始化方法配置软件开发工具包的参数，以满足不同的业务需求。配置参数的作用包括定制监控范围，可以根据需要监控的内容（如白屏、性能、错误等）配置软件开发工具包的功能模块，例如仅加载白屏监控模块；优化性能，通过合理配置参数，减少软件开发工具包的资源消耗，提高页面性能，例如设置白屏判定的时间阈值；适配业务逻辑，根据H5应用的业务逻辑，配置关键元素的选择器、数据上报的格式等参数，例如指定需要监控的关键元素的ID或类名，以便更准确地判断白屏。

[0031] 初始化方法的参数配置可能包括数据上报配置，如上报地址、上报频率、上报数据格式等；白屏判定配置，如时间阈值、关键元素选择器、资源加载判定规则等；监控功能配置，如是否监控白屏、性能、错误等，以及对应的监控策略；以及其他配置项，如日志级别、用户标识等。通过在初始化方法中配置这些参数，可以确保软件开发工具包能够根据具体的业务需求，高效地监控H5应用的白屏现象，并提供有价值的数据支持。

[0032] 示例性的，在金融技术领域，预先构建的软件开发工具包可通过手动或自动嵌入模式集成到金融机构的H5应用中，如在线交易平台、移动银行APP等。手动嵌入模式允许开发者在特定页面精准植入软件开发工具包代码，而自动嵌入模式则通过构建工具在编译阶段自动注入，确保所有关键页面均被覆盖。在H5应用的入口文件中调用软件开发工具包的初始化方法，并配置参数，如数据上报地址、白屏判定阈值、关键元素选择器等，使软件开发工具包能够实时监控页面加载过程中的关键阶段，如DOM加载、资源加载、JS执行等。软件开发工具包的无侵入性设计确保金融业务代码的稳定性，而模块化配置允许金融机构根据业务需求灵活调整监控策略，如重点监控交易按钮、账户余额显示区域等关键元素。一旦检测到白屏情况，软件开发工具包会立即上报异常数据，包括时间、页面、用户设备信息等，帮助金融机构快速定位问题并采取措施，保障交易系统的稳定运行，提升客户满意度和信任度。

[0033] 在医疗健康技术领域，软件开发工具包的嵌入模式同样适用于医疗健康平台的H5应用，如在线问诊系统、电子病历展示页面等。通过手动或自动嵌入模式，软件开发工具包能够无缝集成到医疗平台的各个页面中。在入口文件中初始化软件开发工具包并配置参数，如设置关键元素为生命体征数据展示区域、诊断结果区域等，确保这些关键信息的正常渲染。软件开发工具包的实时数据采集功能能够全面记录页面加载过程中的各种状态，包括关键元素的渲染时间、JS错误、资源加载状态等，帮助医疗平台精准定位白屏原因，如网络问题、服务器响应延迟或前端代码错误。此外，软件开发工具包的兼容性好，能够适应各种医疗设备和浏览器环境，确保监控功能的广泛适用性。当白屏情况发生时，系统会迅速上报异常数据，并发出警告，通知医疗平台的运维人员及时处理，避免影响医疗服务的正常进行，保障患者的就医体验和医疗安全。通过这种实时监控和快速响应机制，医疗健康技术领域能够有效提升系统的稳定性和可靠性，为患者提供更加优质、高效的医疗服务。

[0034] 在一个实施例中，所述步骤S100，包括：S101、获取所述H5应用的待检测页面，并对所述待检测页面进行分析，获得页面结构；S102、根据所述页面结构确定待检测页面的目标检测区域；S103、对所述目标检测区域进行标识处理。

[0035] 本实施例中，监控H5应用中的白屏现象需要对页面的加载、结构分析、目标检测区域的确定以及标识处理进行系统化操作，以实现精准高效的白屏检测。

[0036] 首先，页面的加载和渲染是一个动态过程，因此获取待检测页面通常需要在页面加载完成后进行。可以通过监听window.onload或DOMContent Loaded事件来确定页面是否加载完成。此外，利用Performance API可以获取页面加载的详细时间线，从而更准确地判断页面加载状态。这些方法能够确保在页面完全加载后再进行后续的白屏检测操作。

[0037] 页面结构是指页面的DOM树结构，包括HTML标签、元素的层级关系以及属性等。分析页面结构的目的是为了确定页面的关键元素和布局，为后续的白屏检测提供依据。可以通过以下几种方式分析页面结构：一是从document.documentElement开始递归遍历DOM树，获取页面的所有元素及其属性；二是使用document.querySelectorAll通过选择器获取页面中特定的元素集合，例如获取所有元素或带有特定类名的元素；三是分析元素的CSS样式（如display、visibility、position等），确定页面的布局结构。通过这些方法，可以获取待检测页面的完整结构信息，为确定目标检测区域奠定基础。

[0038] 目标检测区域是指页面中需要重点监控白屏现象的区域，通常是页面的关键部分，如头部、主体内容区、底部等。确定目标检测区域的目的是为了提高白屏检测的效率和准确性，避免对整个页面进行不必要的检测。可以通过以下几种方式确定目标检测区域：一是基于页面布局，选择关键区域作为目标检测区域，例如页面的<header>、<main>、<footer>等，可以通过选择器直接获取这些区域；二是基于关键元素，选择具有重要意义的元素作为目标检测区域，例如登录按钮、搜索框、广告位等，同样可以通过选择器获取；三是基于用户交互区域，选择用户经常交互的区域作为目标检测区域，例如点击区域、滚动区域等，可以通过监听用户交互事件来确定这些区域。根据页面结构和业务需求，可以灵活确定待检测页面的目标检测区域。

[0039] 目标检测区域进行标识处理的目的是为了在后续的白屏检测过程中能够快速定位这些区域并进行监控。标识处理可以通过以下几种方式实现：一是为每个目标检测区域添加自定义属性（如data-detection-area），以便在后续检测中快速识别；二是使用Mutation Observer监听DOM变化，动态更新目标检测区域的标识；三是记录目标检测区域的DOM元素引用，将其存储在一个数组或对象中，方便后续的检测操作。通过这些方法，目标检测区域可以在白屏检测过程中被快速识别和监控。

[0040] 通过获取待检测页面的结构、确定目标检测区域并对目标检测区域进行标识处理，可以实现对H5应用中白屏现象的精准监控。这一过程不仅提高了白屏检测的效率，还能够根据具体的业务需求灵活调整监控策略，为H5应用的性能优化和用户体验提升提供有力支持。

[0041] 示例性的，在金融技术领域，获取H5应用的待检测页面并进行分析以获得页面结构，是确保金融应用稳定性的关键步骤。通过分析页面结构，金融机构能够识别出关键的用户交互区域，如登录表单、交易按钮、账户信息展示区等，这些区域对用户体验和业务连续性至关重要。例如，在在线交易平台中，交易按钮和实时行情展示区域是用户进行交易操作的核心，任何白屏现象都可能导致用户无法及时完成交易，造成经济损失。确定目标检测区域后，对这些区域进行标识处理，如添加特定的数据属性或类名，使得软件开发工具包能够精准地监控这些区域。这种标识处理不仅有助于实时监控页面状态，还能在白屏发生时快速定位问题区域，提高故障排查效率。通过这种方式，金融机构能够确保关键业务区域的稳定运行，提升用户信任度和满意度，同时降低因页面故障导致的业务风险。

[0042] 在医疗健康技术领域，获取和分析H5应用的待检测页面同样具有重要意义。医疗健康应用通常涉及患者信息展示、在线问诊、电子病历查看等功能，这些功能的页面稳定性直接关系到患者的就医体验和医疗服务的质量。通过分析页面结构，医疗平台能够确定关键的目标检测区域，如患者生命体征数据展示区、医生诊断结果区、预约挂号按钮等。对这些区域进行标识处理后，软件开发工具包能够实时监控这些关键区域的渲染状态，确保患者和医生能够及时获取准确的医疗信息。例如，在远程医疗监控界面中，生命体征数据的实时展示是医生判断患者病情的重要依据，任何白屏现象都可能延误诊断和治疗。通过精准监控这些关键区域，医疗平台能够及时发现并解决页面渲染问题，保障医疗服务的连续性和可靠性，提升患者满意度和医疗安全水平。

[0043] 在一个实施例中，所述步骤S200，包括：S201、基于所述软件开发工具包在所述待检测页面的关键阶段插入打点代码；S202、对所述目标检测区域进行解析处理，提取所述目标检测区域的关键元素；S203、通过所述打点代码检测所述关键元素是否被渲染在所述目标检测区域；S204、若所述关键元素被渲染在所述目标检测区域，则判定所述目标检测区域没有出现白屏情况；S205、若所述关键元素没有被渲染在所述目标检测区域，则判定所述目标检测区域出现白屏情况。

[0044] 在本实施例中，H5应用的页面加载和渲染是一个多阶段的过程，涉及多个关键阶段，通过在这些阶段插入打点代码，可以实现对页面加载和渲染状态的实时监控，进而精准判定白屏现象。

[0045] 页面加载的关键阶段包括以下几个方面：DOMContent Loaded事件表示DOM完全加载并解析完成，但此时不包括样式表、图片和子框架的加载；load事件标志着页面的全部内容（包括图片、样式表、脚本等）加载完成；beforeunload事件则在页面即将卸载时触发，通常用于提示用户是否保存数据。此外，页面渲染完成可以通过Mutation Observer或Performance API来判断。打点代码是用于监控页面加载和渲染状态的小段脚本，通过在这些关键阶段插入打点代码，可以实时采集页面的状态信息，为后续的白屏检测提供数据支持。

[0046] 目标检测区域是页面中需要重点监控白屏现象的区域，这些区域在上一步中已经通过标识处理确定。解析目标检测区域的目的是提取其中的关键元素，这些元素是判断白屏的重要依据。通过在关键阶段插入的打点代码，可以实时检测关键元素是否被正确渲染在目标检测区域内。具体检测方法包括：一是检查元素的可见性，通过window.getComputedStyle检查元素的display、visibility等属性，判断元素是否可见；二是检查元素是否在DOM中，通过document.contains方法确认元素是否被正确加载到页面中；三是检查元素的渲染时间，利用Performance API检查元素的渲染时间是否超出预期。通过这些检测手段，可以根据关键元素的渲染状态判定目标检测区域是否出现白屏情况。如果关键元素被正确渲染在目标检测区域内，则没有白屏；反之，如果关键元素未被渲染或渲染失败，则判定为白屏。

[0047] 通过在关键阶段插入打点代码、解析目标检测区域的关键元素，并检测这些关键元素的渲染状态，可以精准地判定目标检测区域是否出现白屏情况。这种方法不仅能够实时监控白屏现象，还能通过日志记录和数据上报，帮助开发者快速定位问题原因，从而提升用户体验和系统的稳定性。

[0048] 示例性的，在金融技术领域，基于软件开发工具包在待检测页面的关键阶段插入打点代码，能够实时监控金融H5应用的页面加载和渲染状态。例如，在在线交易平台中，关键阶段包括用户登录、交易提交、资金划转等操作页面。软件开发工具包在这些阶段插入打点代码，可以实时采集页面的DOM加载、资源加载、JS执行等关键信息。对目标检测区域进行解析处理，提取关键元素，如交易按钮、账户余额显示区域、实时行情图表等，这些元素对用户的交易操作至关重要。通过打点代码检测这些关键元素是否被正确渲染在目标检测区域，若关键元素被渲染，则判定该区域没有出现白屏情况，用户可以正常进行交易操作；若关键元素没有被渲染，则判定该区域出现白屏情况，可能导致用户无法及时完成交易，造成经济损失。例如，当交易按钮因JavaScript错误或资源加载失败而未能渲染时，软件开发工具包会立即检测到白屏情况，并将相关数据上报给服务器，触发白屏警告，通知金融机构的技术团队及时处理，保障交易系统的稳定运行，提升用户体验和信任度。

[0049] 在医疗健康技术领域，基于软件开发工具包在待检测页面的关键阶段插入打点代码，能够实时监控医疗健康H5应用的页面状态。例如，在在线问诊系统中，关键阶段包括患者信息录入、症状描述提交、医生诊断结果展示等页面。软件开发工具包在这些阶段插入打点代码，实时采集页面的DOM变化、资源加载、JS执行等信息。对目标检测区域进行解析处理，提取关键元素，如患者生命体征数据展示区、医生诊断意见区、电子病历链接等，这些元素对医生的诊断和患者的就医体验至关重要。通过打点代码检测这些关键元素是否被正确渲染在目标检测区域，若关键元素被渲染，则判定该区域没有出现白屏情况，医生可以正常查看患者信息并进行诊断；若关键元素没有被渲染，则判定该区域出现白屏情况，可能导致医生无法及时获取患者信息，延误诊断。例如，当患者的心电图因资源加载失败而未能渲染时，软件开发工具包会立即检测到白屏情况，并将相关数据上报给服务器，触发白屏警告，通知医疗平台的技术团队及时处理，保障医疗服务的连续性和可靠性，提升患者满意度和医疗安全水平。

[0050] 在一个实施例中，所述步骤S300，包括：S301、预设待检测页面的监听选项；S302、实时监测所述待检测页面的DOM的关键元素变化；S303、当检测到所述DOM的关键元素发生变化时，获取元素变化信息；S304、根据所述元素变化信息和所述监听选项判断是否出现异常渲染情况；S305、若所述元素变化信息符合监听选项，则认为待检测页面发生异常渲染情况，判定所述待检测页面出现白屏情况。

[0051] 在本实施例中，为了精准监控H5应用中的白屏现象，通过配置监听选项并实时监测页面的关键元素变化，可以有效判断页面是否出现异常渲染情况。

[0052] 监听选项是指在监控过程中需要关注的特定事件或条件，这些选项可以根据具体的业务需求和页面特性进行灵活配置。常见的监听选项包括：关键元素的可见性变化（例如，某个重要元素从可见变为不可见）、关键元素的样式变化（例如，display、visibility、opacity等属性的变化）、关键元素的内容变化（例如，文本内容或图片资源的变化）、关键元素的加载状态（例如，图片或脚本加载失败），以及页面加载时间（例如，页面加载时间超过预设阈值）。这些监听选项可以通过软件开发工具包的初始化方法进行配置，从而满足不同的监控需求。

[0053] 为了实现实时监测，可以使用Mutation Observer，这是一个强大的浏览器API，专门用于监听DOM的变化。通过Mutation Observer，可以实时监测关键元素的变化，包括属性变化、内容变化和子节点变化。当Mutation Observer检测到DOM的关键元素发生变化时，会触发回调函数。在回调函数中，可以通过Mutation Record对象获取详细的变化信息，例如变化类型（attributes表示属性变化、childList表示子节点变化、characterData表示文本内容变化）、变化的目标元素（mutation.target）、变化的属性名称（mutation.attributeName，仅适用于属性变化），以及变化前后的值（mutation.oldValue和mutation.newValue）。

[0054] 根据预设的监听选项和获取的元素变化信息，可以判断是否出现异常渲染情况。例如，如果监听选项中启用了"元素可见性变化”，并且某个关键元素的display或visibility属性变为none或hidden，则认为出现异常；如果监听选项中启用了"元素加载状态”，并且某个关键资源（如图片、脚本）加载失败，则认为出现异常；如果页面加载时间超过预设阈值，也认为出现异常。如果判断出待检测页面发生异常渲染情况，则可以认为页面出现白屏情况。此时，需要将异常信息上报到后端服务器，并进行进一步的分析和处理。

[0055] 通过预设监听选项、实时监测DOM的关键元素变化、获取元素变化信息，并根据监听选项判断是否出现异常渲染情况，可以精准地判定待检测页面是否出现白屏情况。这种方法能够实时监控页面的渲染状态，及时发现并上报异常，帮助开发者快速定位和解决问题，从而提升用户体验和系统的稳定性。

[0056] 示例性的，在金融技术领域，预设待检测页面的监听选项可以针对关键业务区域进行精准监控。例如，在网上银行的转账页面，可以预设监听转账按钮、金额输入框、交易状态提示等关键元素的变化。通过实时监测这些元素的DOM变化，系统能够获取详细的元素变化信息，如属性更改、子节点变动等。当检测到关键元素发生变化时，系统根据预设的监听选项判断是否出现异常渲染情况。若元素变化信息符合监听选项，例如转账按钮突然不可见或金额输入框显示异常，系统会判定页面出现白屏情况。这种实时监控机制能够及时发现并上报异常，确保用户在进行转账等关键操作时不会因页面异常而遭受损失。

[0057] 在医疗健康技术领域，预设监听选项同样至关重要。以在线问诊平台为例，可以预设监听患者的症状输入框、医生回复区域、诊断结果展示区等关键元素的变化。实时监测这些元素的DOM变化，获取元素变化信息，系统能够快速判断是否出现异常渲染情况。当检测到关键元素发生变化时，系统根据预设的监听选项判断异常。若元素变化信息符合监听选项，例如患者症状输入框突然不可编辑或医生回复区域显示为空白，系统会判定页面出现白屏情况。这种实时监控机制能够确保患者在填写症状、接收医生诊断等关键环节时页面的稳定性，避免因页面异常导致信息传递中断，保障医疗服务的连续性和可靠性。通过这种精准的监控和快速响应机制，金融和医疗健康领域的H5应用能够有效提升用户体验和系统稳定性，减少因白屏现象引发的风险和不便。

[0058] 在一个实施例中，所述步骤S400，包括：S401、根据业务场景设置时间阈值；S402、当所述待检测页面加载完成时，获取待检测页面加载的时间线数据；S403、根据所述时间线数据和所述时间阈值判断是否出现白屏情况；S404、当所述时间线数据大于所述时间阈值时，则判定待检测页面出现白屏情况。

[0059] 本实施例中，在本实施例中，通过设置时间阈值并结合页面加载时间线数据来监控页面加载过程中的异常情况，从而有效判定白屏现象。

[0060] 时间阈值是指页面加载完成的最大允许时间。如果页面加载时间超过这个阈值，可能意味着页面加载过程中出现了问题，如资源加载失败、脚本执行卡顿等，从而导致白屏现象。时间阈值的设置需要根据具体的业务场景和用户体验需求来确定。例如，对于电商页面，用户对加载速度要求较高，时间阈值可以设置为3秒；而对于一些复杂的金融页面，时间阈值可以适当放宽到5秒或更长。时间阈值可以通过软件开发工具包的初始化方法进行灵活配置，以满足不同业务需求。

[0061] 页面加载时间线数据是指页面从开始加载到加载完成的各个阶段的时间信息。这些数据可以通过浏览器的Performance API获取，具体包括：导航开始时间（navigationStart）、DNS查询时间（domainLookupStart和domainLookupEnd）、TCP连接时间（connectStart和connectEnd）、请求开始时间（requestStart）、响应开始时间（responseStart）、DOM加载完成时间（DOMContent LoadedEventEnd）以及页面加载完成时间（loadEventEnd）。通过这些详细的时间线数据，可以全面了解页面加载的各个阶段。

[0062] 根据获取的页面加载时间线数据和预设的时间阈值，可以判断页面加载时间是否超过阈值。如果页面加载时间超过阈值，可能意味着页面加载过程中出现了问题，从而导致白屏现象。在这种情况下，判定页面出现白屏情况，并将白屏信息上报到后端服务器，以便进行进一步的分析和处理。

[0063] 通过设置时间阈值、获取页面加载时间线数据，并根据时间线数据和阈值判断是否出现白屏情况，可以有效地监控页面加载过程中的异常情况。这种方法能够实时发现页面加载时间过长导致的白屏问题，并通过上报机制帮助开发者快速定位和解决问题，从而提升用户体验和系统的稳定性。

[0064] 示例性的，在金融技术领域，页面加载速度直接影响用户体验和业务效率。通过设置合理的时间阈值，可以有效监控金融H5应用的加载性能。例如，对于在线银行转账页面，可以将时间阈值设定为3秒。当页面加载完成时，获取加载时间线数据，包括DOM加载时间、资源加载时间等关键指标。如果加载时间超过设定的阈值，系统将判定页面出现白屏或加载过慢的情况。这种机制能够帮助金融机构及时发现性能瓶颈，例如资源加载失败、服务器响应延迟等问题。一旦检测到加载时间过长，系统会立即触发警报，通知开发和运维团队进行排查和优化。这不仅提升了用户在进行金融交易时的满意度，还增强了系统的稳定性和可靠性，减少了因页面加载问题导致的交易中断和用户流失。

[0065] 在医疗健康技术领域，页面加载速度同样至关重要。例如，在在线问诊系统中，患者可能需要快速获取医生的诊断建议。可以将时间阈值设定为2秒，以确保页面能够快速加载并显示关键信息。当页面加载完成时，获取时间线数据并进行分析。如果加载时间超过阈值，系统将判定页面出现白屏或加载过慢的情况。这种实时监控机制能够帮助医疗平台及时发现并解决加载问题，例如网络延迟、服务器故障等。一旦检测到加载时间过长，系统会立即发出警报，通知技术团队进行干预。这不仅提升了患者的就医体验，确保他们能够及时获取医疗建议，还增强了医疗平台的稳定性和可靠性，保障了医疗服务的连续性和高效性。通过这种精准的监控和快速响应机制，金融和医疗健康领域的H5应用能够有效提升用户体验和系统稳定性，减少因页面加载问题引发的风险和不便。

[0066] 在一个实施例中，所述步骤S500，包括：S501、实时捕获所述待检测页面的同步和异步错误；S502、实时检测所述待检测页面的资源加载状态；S503、当所述待检测页面出现所述同步和异步错误和 / 或资源加载失败，则判定所述待检测页面出现白屏情况。

[0067] 本实施例中，在本实施例中，通过实时监控页面的同步和异步错误以及资源加载状态，可以有效识别可能导致白屏的异常情况，并及时上报以便进行分析和处理。

[0068] 首先，同步错误是指在页面加载和脚本执行过程中直接抛出的错误，例如语法错误或运行时错误。这些错误可以通过全局错误捕获机制来捕获。window.onerror是一个全局事件处理器，能够在错误发生时触发，并提供错误信息、文件名、行号等详细信息。此外，异步错误是指在异步操作（如Promise、fetch、XMLHttpRequest等）中发生的错误。这些错误需要通过特定的机制来捕获，例如使用window.addEventListener(error)可以捕获全局范围内的同步和异步错误，包括Promise的未捕获错误。

[0069] 其次，资源加载状态检测是指监控页面中各种资源（如图片、脚本、样式表等）的加载情况。如果某些资源加载失败，可能会导致页面渲染异常或白屏。可以通过监听图片的load和error事件来检测图片是否加载成功；监听脚本的load和error事件来检测脚本是否加载成功；以及监听样式表的load和error事件来检测样式表是否加载成功。

[0070] 如果捕获到同步或异步错误，或者检测到资源加载失败，则可以认为页面可能出现白屏情况。此时，需要将相关信息上报到后端服务器，并进行进一步的分析和处理。通过这种方式，可以判定页面出现白屏情况，并采取相应的处理措施。

[0071] 通过实时捕获页面的同步和异步错误以及资源加载状态，可以有效地监控页面运行过程中可能出现的异常情况。如果捕获到错误或资源加载失败，则可以判定页面出现白屏情况，并通过上报机制帮助开发者快速定位和解决问题，从而提升用户体验和系统的稳定性。

[0072] 示例性的，在金融技术领域，实时捕获待检测页面的同步和异步错误以及检测资源加载状态，对于保障金融交易的安全性和稳定性至关重要。例如，在在线交易平台中，同步错误可能包括JavaScript代码在解析或执行过程中出现的错误，如语法错误、类型错误等，这些错误可能导致交易按钮无法正常显示或点击，影响用户进行交易。异步错误则可能涉及Promise对象的未捕获拒绝、fetch请求的失败等，例如，当用户尝试获取实时行情数据时，异步请求失败可能导致行情数据无法及时更新，影响用户的交易决策。通过实时捕获这些错误，系统能够立即感知页面的异常状态，并将错误信息上报给服务器，触发白屏警告。同时，实时检测资源加载状态，如图片、样式表、脚本等资源的加载情况，能够确保页面的关键资源完整加载。例如，如果交易页面的CSS样式表加载失败，可能导致页面布局错乱，影响用户操作。一旦检测到资源加载失败，系统会立即判定页面出现白屏情况，并采取相应措施，如尝试重新加载资源或提示用户刷新页面。

[0073] 在医疗健康技术领域，实时捕获同步和异步错误以及检测资源加载状态，对于保障医疗服务的连续性和可靠性同样具有重要意义。例如，在在线问诊系统中，同步错误可能导致患者信息录入界面无法正常显示，影响患者填写症状。异步错误可能涉及医生回复数据的获取失败，导致患者无法及时看到医生的诊断建议。通过实时捕获这些错误，系统能够及时发现页面的异常状态，并将错误信息上报给服务器，触发白屏警告。同时，实时检测资源加载状态，如医疗图片、样式表、脚本等资源的加载情况，能够确保页面的关键资源完整加载。例如，如果电子病历页面的图片资源加载失败，可能导致医生无法查看患者的重要检查结果，影响诊断的准确性。一旦检测到资源加载失败，系统会立即判定页面出现白屏情况，并采取相应措施，如尝试重新加载资源或提示用户检查网络连接。

[0074] 综上所述，在金融技术和医疗健康技术领域，通过实时捕获同步和异步错误以及检测资源加载状态，能够有效监控页面的异常状态，及时发现并处理白屏情况，保障系统的稳定性和用户体验。

[0075] 在一实施例中，提供一种H5应用页面白屏检测装置，该H5应用页面白屏检测装置与上述实施例中H5应用页面白屏检测方法一一对应。参照图3，图3为本发明H5应用页面白屏检测装置一较佳实施例的功能模块示意图。获取检测目标模块10、关键元素判断模块20、元素变化判断模块30、加载时间判断模块40、性能监控模块50和错误上报模块60。各功能模块详细说明如下：获取检测目标模块10，用于获取H5应用的待检测页面，并对所述待检测页面进行分析，确定目标检测区域；关键元素判断模块20，用于对所述目标检测区域进行解析处理，提取所述目标检测区域的关键元素，并根据所述关键元素判断是否出现白屏情况；元素变化判断模块30，用于实时监测所述待检测页面的DOM的元素变化，获取元素变化信息，并根据所述元素变化信息判断是否出现白屏情况；加载时间判断模块40，用于获取所述待检测页面加载完成的时间线数据，根据所述时间线数据和时间阈值判断是否出现白屏情况；性能监控模块50，用于实时检测所述待检测页面的JS错误和 / 或资源加载状态，根据所述JS错误和 / 或资源加载状态判断是否出现白屏情况；错误上报模块60，用于获取所有出现白屏情况的白屏数据，将所述白屏数据传输给服务器，并发出白屏警告。

[0076] 在一个实施例中，所述软件开发工具包构建模块，包括：构建单元，用于预先构建软件开发工具包；嵌入单元，用于通过手动嵌入模式或自动嵌入模式将所述软件开发工具包嵌入H5应用；初始化调用单元，用于在所述H5应用的入口文件中调用软件开发工具包的初始化方法；初始化配置单元，用于通过所述初始化方法配置软件开发工具包的参数。

[0077] 在一个实施例中，所述获取检测目标模块10，包括：页面结构单元，用于获取所述H5应用的待检测页面，并对所述待检测页面进行分析，获得页面结构；目标区域单元，用于根据所述页面结构确定待检测页面的目标检测区域；标识处理单元，用于对所述目标检测区域进行标识处理。

[0078] 在一个实施例中，所述关键元素判断模块20，包括：打点代码单元，用于基于所述软件开发工具包在所述待检测页面的关键阶段插入打点代码；关键元素单元，用于对所述目标检测区域进行解析处理，提取所述目标检测区域的关键元素；渲染判断单元，用于通过所述打点代码检测所述关键元素是否被渲染在所述目标检测区域；正确渲染单元，用于若所述关键元素被渲染在所述目标检测区域，则判定所述目标检测区域没有出现白屏情况；错误渲染单元，用于若所述关键元素没有被渲染在所述目标检测区域，则判定所述目标检测区域出现白屏情况。

[0079] 在一个实施例中，所述元素变化判断模块30，包括：监听选项单元，用于预设待检测页面的监听选项；元素变化单元，用于实时监测所述待检测页面的DOM的关键元素变化；变化信息单元，用于当检测到所述DOM的关键元素发生变化时，获取元素变化信息；异常判断单元，用于根据所述元素变化信息和所述监听选项判断是否出现异常渲染情况；异常渲染单元，用于若所述元素变化信息符合监听选项，则认为待检测页面发生异常渲染情况，判定所述待检测页面出现白屏情况。

[0080] 在一个实施例中，所述加载时间判断模块40，包括：时间阈值单元，用于根据业务场景设置时间阈值；加载时间单元，用于当所述待检测页面加载完成时，获取待检测页面加载的时间线数据；时间异常单元，用于根据所述时间线数据和所述时间阈值判断是否出现白屏情况；时间白屏单元，用于当所述时间线数据大于所述时间阈值时，则判定待检测页面出现白屏情况。

[0081] 在一个实施例中，所述性能监控模块50，包括：错误捕获单元，用于实时捕获所述待检测页面的同步和异步错误；状态监控单元，用于实时检测所述待检测页面的资源加载状态；白屏判断单元，用于当所述待检测页面出现所述同步和异步错误和 / 或资源加载失败，则判定所述待检测页面出现白屏情况。

[0082] 在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务端，其内部结构图可以如图4所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性和 / 或易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的用户端通过网络连接通信。该计算机程序被处理器执行时以实现一种H5应用页面白屏检测方法服务端侧的功能或步骤。

[0083] 在一个实施例中，提供了一种计算机设备，该计算机设备可以是用户端，其内部结构图可以如图5所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部服务器通过网络连接通信。该计算机程序被处理器执行时以实现一种H5应用页面白屏检测方法用户端侧的功能或步骤在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储至存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：获取H5应用的待检测页面，并对所述待检测页面进行分析，确定目标检测区域；对所述目标检测区域进行解析处理，提取所述目标检测区域的关键元素，根据所述关键元素判断是否出现白屏情况；实时监测所述待检测页面的DOM的元素变化，获取元素变化信息，根据所述元素变化信息判断是否出现白屏情况；获取所述待检测页面加载完成的时间线数据，根据所述时间线数据和时间阈值判断是否出现白屏情况；实时检测所述待检测页面的JS错误和 / 或资源加载状态，根据所述JS错误和 / 或资源加载状态判断是否出现白屏情况；获取所有出现白屏情况的白屏数据，将所述白屏数据传输给服务器，并发出白屏警告。

[0084] 在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：获取H5应用的待检测页面，并对所述待检测页面进行分析，确定目标检测区域；对所述目标检测区域进行解析处理，提取所述目标检测区域的关键元素，根据所述关键元素判断是否出现白屏情况；实时监测所述待检测页面的DOM的元素变化，获取元素变化信息，根据所述元素变化信息判断是否出现白屏情况；获取所述待检测页面加载完成的时间线数据，根据所述时间线数据和时间阈值判断是否出现白屏情况；实时检测所述待检测页面的JS错误和 / 或资源加载状态，根据所述JS错误和 / 或资源加载状态判断是否出现白屏情况；获取所有出现白屏情况的白屏数据，将所述白屏数据传输给服务器，并发出白屏警告。

[0085] 需要说明的是，上述关于计算机可读存储介质或计算机设备所能实现的功能或步骤，可对应参阅前述方法实施例中，服务端侧以及用户端侧的相关描述，为避免重复，这里不再一一描述。

[0086] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和 / 或易失性存储器。非易失性存储器可包括只读存储器（ROM）、可编程ROM（PROM）、电可编程ROM（EPROM）、电可擦除可编程ROM（EEPROM）或闪存。易失性存储器可包括随机存取存储器（RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM（SRAM）、动态RAM（DRAM）、同步DRAM（SDRAM）、双数据率SDRAM（DDRSDRAM）、增强型SDRAM（ESD RAM）、同步链路（Synchlink）DRAM（SLDRAM）、存储器总线（Rambus）直接RAM（RDRAM）、直接存储器总线动态RAM（DRDRAM）、以及存储器总线动态RAM（RDRAM）等。

[0087] 所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

[0088] 应当说明的是，本申请实施例中若出现了非本公司的软件工具或组件，仅仅是用于举例介绍，并不代表实际使用。以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。< / script>

Claims

1. A method for detecting blank screen on an H5 application page, characterized in that, Includes the following steps: Obtain the page to be detected from the H5 application, analyze the page to be detected, and determine the target detection area; The target detection area is parsed to extract key elements, and the presence of a white screen is determined based on the key elements. Real-time monitoring of DOM element changes on the page to be detected, obtaining element change information, and determining whether a white screen occurs based on the element change information; Obtain the timeline data of the page to be detected after loading, and determine whether a white screen occurs based on the timeline data and the time threshold. Real-time detection of JS errors and / or resource loading status of the page to be detected, and determination of whether a white screen occurs based on the JS errors and / or resource loading status; Acquire all white screen data where a white screen occurs, transmit the white screen data to the server, and issue a white screen warning.

2. The H5 application page white screen detection method as described in claim 1, characterized in that, Before obtaining the page to be detected from the H5 application, analyzing the page to be detected, and determining the target detection area, the method further includes: Pre-built software development kits; Embed the software development kit into an H5 application; The initialization method of the software development kit is called in the entry file of the H5 application; Configure the parameters of the software development kit using the initialization method described above.

3. The H5 application page white screen detection method as described in claim 1, characterized in that, The process of obtaining the page to be detected from the H5 application and analyzing the page to be detected to determine the target detection area includes: Obtain the page to be tested from the H5 application, and analyze the page to obtain the page structure; The target detection area of ​​the page to be detected is determined based on the page structure. The target detection area is marked.

4. The H5 application page white screen detection method as described in claim 2, characterized in that, The step of parsing and processing the target detection region, extracting key elements of the target detection region, and determining whether a white screen occurs based on the key elements includes: Based on the software development kit, dot code is inserted at key stages of the page to be detected; The target detection region is parsed to extract key elements of the target detection region; The key element is detected in the target detection area by the dot code; If the key element is rendered in the target detection area, it is determined that there is no white screen in the target detection area; If the key element is not rendered in the target detection area, it is determined that the target detection area is in a white screen state.

5. The H5 application page white screen detection method as described in claim 1, characterized in that, The real-time monitoring of DOM element changes on the page to be detected, obtaining element change information, and determining whether a white screen occurs based on the element change information includes: Preset the listening options for the page to be detected; Real-time monitoring of changes in key DOM elements of the page to be detected; When a change is detected in a key element of the DOM, the element change information is obtained; Determine whether an abnormal rendering situation has occurred based on the element change information and the monitoring options; If the element change information matches the listening options, it is considered that the page to be detected has an abnormal rendering situation, and it is determined that the page to be detected has a white screen.

6. The H5 application page white screen detection method as described in claim 1, characterized in that, The step of obtaining the timeline data of the page to be detected completing loading, and determining whether a white screen occurs based on the timeline data and the time threshold, includes: Set time thresholds based on business scenarios; When the page to be detected is fully loaded, obtain the timeline data of the page loading. Determine whether a white screen occurs based on the timeline data and the time threshold. When the timeline data is greater than the time threshold, it is determined that the page to be detected is in a white screen state.

7. The H5 application page white screen detection method as described in claim 1, characterized in that, The real-time detection of JS errors and / or resource loading status of the page to be detected, and the determination of whether a white screen occurs based on the JS errors and / or resource loading status, includes: Real-time capture of synchronous and asynchronous errors on the page to be detected; Real-time monitoring of the resource loading status of the page to be monitored; If the page to be tested encounters synchronous and asynchronous errors and / or resource loading failures, it is determined that the page to be tested is in a blank screen state.

8. A device for detecting blank screens on H5 application pages, characterized in that, The H5 application page white screen detection device includes: The target acquisition module is used to acquire the page to be detected in the H5 application, analyze the page to be detected, and determine the target detection area. The key element judgment module is used to parse the target detection area, extract the key elements of the target detection area, and determine whether a white screen occurs based on the key elements. The element change judgment module is used to monitor the element changes of the DOM of the page to be detected in real time, obtain element change information, and determine whether a white screen occurs based on the element change information. The loading time judgment module is used to obtain the timeline data of the page to be detected after loading, and to determine whether a white screen occurs based on the timeline data and the time threshold. The performance monitoring module is used to detect JS errors and / or resource loading status of the page to be detected in real time, and determine whether a white screen occurs based on the JS errors and / or resource loading status. The error reporting module is used to obtain all white screen data when a white screen occurs, transmit the white screen data to the server, and issue a white screen warning.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and an H5 application page white screen detection program stored in the memory and executable on the processor. When the H5 application page white screen detection program is executed by the processor, it implements the steps of the H5 application page white screen detection method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores an H5 application page white screen detection program, which, when executed by the processor, implements the steps of the H5 application page white screen detection method as described in any one of claims 1-7.

Images