Method for preventing browser page crash in large-screen display application and related device

Abstract

This invention discloses a method and related device for preventing browser page crashes in large-screen display applications, belonging to the field of browser technology. The method includes: obtaining the current performance parameters of the target browser; determining the level of the current performance parameters based on a comparison with preset multi-level warning thresholds, wherein the multi-level warning thresholds include at least a first threshold and a second threshold, and the level includes at least a first level corresponding to the first threshold and a second level corresponding to the second threshold; when the current performance parameters are at the second level, performing a forced refresh operation to prevent the target browser from crashing. This invention proactively obtains browser performance parameters and performs risk classification based on multi-level thresholds, automatically performing a forced refresh when the page is on the verge of crashing, thus realizing a shift from passive warning to proactive self-rescue and effectively ensuring the stable operation of large-screen applications.

Description

Technical Field

[0001] This invention relates to the field of browser technology, and more specifically to a method and related equipment for preventing browser pages from crashing in large-screen display applications. Background Technology

[0002] With the development of data visualization technology, large-screen display pages have been widely used in critical scenarios such as command centers and monitoring centers that require stable operation over extended periods. These large-screen pages typically feature long runtimes, complex DOM structures, and real-time data updates, and their stability directly impacts business continuity. In practical applications, large-screen pages are prone to issues such as accumulated memory leaks and explosive growth of DOM nodes after prolonged operation. Both of these problems share a gradual nature, meaning there is a window of opportunity for intervention before a crash occurs. If risks can be identified and proactively addressed within this window, crashes can be effectively avoided.

[0003] In existing technologies, such as patent application CN119201590A, a method for full-link large-screen global monitoring dashboards is disclosed. This method collects operational data from business systems to detect indicators such as processing time and response rate of business nodes and generate early warnings. However, this solution has the following shortcomings: First, its monitoring object is the business system nodes rather than the browser itself, and it cannot perceive the real-time status of page performance indicators such as browser memory usage and total number of DOM nodes, thus making it difficult to identify risks before a crash occurs; Second, this solution only uses a single early warning threshold and lacks the ability to monitor performance indicators in a tiered manner, making it impossible to distinguish the severity of risks; Third, this solution only provides passive early warnings, and manual intervention is still required after the warning is issued. However, in large-screen scenarios, manual response often lags behind the crash process, making it impossible to proactively perform self-rescue operations such as forced refresh before a crash. These defects prevent existing technologies from effectively utilizing the intervention window before a crash, and large-screen applications still face the risk of business interruption due to browser crashes. Summary of the Invention

[0004] The purpose of this invention is to provide a method and related equipment for preventing browser page crashes in large-screen display applications, so as to overcome the technical problem that the existing technology cannot obtain browser performance parameters, making it difficult to intervene in a timely manner when the browser page is on the verge of crashing.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a method for preventing browser page crashes in large-screen display applications, comprising: Get the current performance parameters of the target browser; Based on the comparison result between the current performance parameter and the preset multi-level warning threshold, the level of the current performance parameter is determined; the multi-level warning threshold includes at least a first threshold and a second threshold, and the level includes at least a first level corresponding to the first threshold and a second level corresponding to the second threshold; When the current performance parameter is at the second level, a forced refresh operation is performed to prevent the target browser from crashing.

[0006] In one embodiment of the present invention, the current performance parameters include memory usage, total number of DOM nodes, and DOM node increment rate.

[0007] In one embodiment of the present invention, the multi-level warning threshold further includes a third threshold, and the grading further includes a third level corresponding to the third threshold; the first threshold is less than the third threshold, and the third threshold is less than the second threshold.

[0008] In one embodiment of the present invention, when the current performance parameter is at the first level, the current performance parameter is recorded and an alarm message is output.

[0009] In one embodiment of the present invention, when the current performance parameter is at the third level, a mild cleanup operation is performed; the mild cleanup operation includes at least one of cleaning up DOM nodes in invisible areas, pausing non-core timed refresh tasks, and reducing the refresh frequency of high-frequency components.

[0010] In one embodiment of the present invention, before performing the forced refresh operation, the method further includes: delaying the acquisition of the current performance parameters of the target browser again; if the acquired performance parameters are still at the second level, then performing the forced refresh operation.

[0011] In one embodiment of the present invention, the method further includes: recording performance parameters into a locally stored circular log queue; and reading the performance parameters in the circular log queue and reporting them to the server after the page is reloaded.

[0012] Secondly, the present invention provides a system for preventing browser page crashes in large-screen display applications, comprising: The performance parameter acquisition module is used to obtain the current performance parameters of the target browser; The classification determination module is used to determine the classification of the current performance parameter based on the comparison result between the current performance parameter and the preset multi-level warning threshold; the multi-level warning threshold includes at least a first threshold and a second threshold, and the classification includes at least a first level corresponding to the first threshold and a second level corresponding to the second threshold; The forced refresh execution module is used to perform a forced refresh operation when the current performance parameter is at level two, in order to prevent the target browser from crashing.

[0013] Thirdly, the present invention provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method for preventing browser page crashes as described above in a large-screen display application.

[0014] Fourthly, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method for preventing browser page crashes as described above in a large-screen display application.

[0015] Compared with the prior art, the present invention has the following beneficial technical effects: Firstly, this invention provides a method for preventing browser page crashes in large-screen display applications. By proactively acquiring the current performance parameters of the target browser, the monitoring focus shifts from business system nodes to the browser itself, fundamentally solving the problem of not being able to perceive the browser's operating status. Based on this, the acquired performance parameters are compared with preset multi-level warning thresholds to determine the level of the parameter, quantifying the browser's current health status into an identifiable risk level. When the performance parameter reaches the second level, representing severe risk, a forced refresh operation is automatically executed, introducing a proactive intervention mechanism within the critical time window before a crash occurs. This method, through a closed-loop logic of "acquisition—grading—handling," transforms the existing monitoring method, which can only provide passive warnings, into a defense mechanism with proactive self-rescue capabilities. This allows for timely intervention to prevent the continuation of the failure when the browser page is on the verge of crashing, effectively ensuring the stable operation of large-screen applications.

[0016] Secondly, this invention provides a system for preventing browser page crashes in large-screen display applications. Through the coordinated operation of a performance parameter acquisition module and a risk assessment module, the browser's operational status is transformed into structured data for judgment. The performance parameter acquisition module handles browser-level data collection, while the risk assessment module stratifies the collected data based on preset multi-level warning thresholds, enabling the system to distinguish between normal fluctuations and critical states on the verge of collapse. A forced refresh execution module is automatically triggered when the risk assessment results indicate severe risk, forming a complete chain from data collection and risk assessment to action execution. This architecture reconstructs the passive monitoring mode of receiving alarms from business systems into an adaptive system that proactively perceives browser operational risks and autonomously executes recovery actions. Preventative measures before crashes can be completed without manual intervention, improving the ability to ensure business continuity in large-screen scenarios.

[0017] Thirdly, the present invention provides a computer device that, through a processor executing a specific computer program, can efficiently implement the steps of the method of the present invention. When performing data processing tasks, the computer device can accurately perform numerical calculations and logical judgments, avoiding errors caused by human factors. At the same time, since the computer program has high stability and reliability, it can ensure the accuracy and consistency of the data processing results.

[0018] Fourthly, the present invention provides a computer-readable storage medium. By programming the steps of the method of the present invention into a computer program and storing it on the computer-readable storage medium, users can easily load these programs onto any compatible computer device and execute them without rewriting or converting the code, which greatly improves the convenience and flexibility of program execution. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating a method for preventing browser page crashes in a large-screen display application, as described in an embodiment of the present invention.

[0020] Figure 2 This is a flowchart of the multi-dimensional performance monitoring and graded response method in an embodiment of the present invention.

[0021] Figure 3 This is a schematic diagram of the structure of the circular log storage queue in an embodiment of the present invention.

[0022] Figure 4 This is a flowchart illustrating the workflow of the graded response and handling module in an embodiment of the present invention.

[0023] Figure 5 This is a timing diagram of the secondary confirmation mechanism in an embodiment of the present invention.

[0024] Figure 6 This is a schematic diagram of a system for preventing browser page crashes in a large-screen display application, as described in an embodiment of the present invention. Detailed Implementation

[0025] In large-screen display applications, pages typically need to run continuously for extended periods, and their stability directly impacts business continuity. Existing technologies mostly focus on monitoring at the business system level, only able to detect and issue alerts for metrics such as response time and success rate of business nodes. However, they cannot detect performance metrics such as browser memory usage and total number of DOM nodes, and lack the ability to proactively intervene when a page is on the verge of crashing. As a result, large-screen applications still face the risk of business interruption due to browser crashes.

[0026] Based on the above background, this invention proposes a method and related device for preventing browser page crashes in large-screen display applications. By actively acquiring the current performance parameters of the target browser and comparing them with preset multi-level warning thresholds to determine its risk level, a forced refresh operation is automatically executed when the performance parameters reach the second level, which represents a serious risk. This transforms passive warning into proactive self-rescue, thereby timely blocking the continuation of the fault before a crash occurs and effectively ensuring the stable operation of large-screen applications.

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] Example 1 like Figure 1 As shown in the figure, this embodiment of the invention provides a method for preventing browser pages from crashing in large-screen display applications.

[0029] During the operation of the application on the large screen, the processor executing the method actively acquires the current performance parameters of the target browser. This acquisition action is continuously performed at a preset sampling period, ensuring that the processor can grasp the changing trend of the browser's operating status in real time, rather than passively receiving alarm information from the business system level only after an anomaly occurs. By shifting the monitoring target from the business system node to the browser itself, the processor can perceive potential risks in the early stages of page performance degradation.

[0030] The processor is pre-configured with multiple warning thresholds, including at least a first threshold and a second threshold. The first threshold corresponds to a lower risk level (Level 1), while the second threshold corresponds to a higher risk level (Level 2). Upon acquiring the current performance parameter, the processor compares it to each of the aforementioned warning thresholds, determining the parameter's level based on the comparison results. This leveling process discretizes continuously changing performance data into quantifiable risk levels, enabling the processor to respond differently based on the severity of the risk, rather than relying solely on a single threshold for a simple normal / abnormal judgment.

[0031] When the current performance parameters are determined to be at level two, the processor automatically performs a forced refresh operation. This forced refresh operation, achieved by reloading the current page, can promptly release occupied system resources and prevent further failure in critical states such as excessive browser memory usage or abnormal accumulation of DOM nodes that could lead to a crash. Compared to existing technologies that only issue warning notifications and wait for manual intervention, this solution proactively performs recovery actions when serious risks are identified, shifting the intervention time to the critical time window before the crash occurs. This effectively prevents the target browser from crashing due to resource exhaustion or performance degradation, ensuring the business continuity of large-screen display applications.

[0032] Example 2 Based on Example 1, this embodiment further elaborates on the specific composition of performance parameters, the configuration of multi-level early warning thresholds, the handling methods corresponding to different risk levels, and the crash site tracing mechanism.

[0033] To comprehensively assess browser health from multiple dimensions, the target browser's current performance parameters include memory usage, total number of DOM nodes, and DOM node growth rate. Memory usage is obtained through the `performance.memory` API, which calculates the ratio of used JavaScript heap memory to total memory. This API is a standard browser interface that reflects the current page's memory usage in real time, providing a basis for determining if memory leaks are accumulating. The total number of DOM nodes is calculated using the DOM Traversal API, which counts all nodes on the current page. This metric directly reflects the complexity of the page structure and can identify explosive node growth caused by uncontrolled dynamic rendering. The DOM node growth rate is monitored through the `MutationObserver` API, which tracks changes in the DOM tree and counts the number of new nodes within a preset time window (e.g., 1 second), calculating the growth rate per unit time. This metric can capture abnormal growth trends such as infinite rendering loops caused by code defects. These three parameters collaboratively assess browser health from three dimensions: memory consumption, page complexity, and dynamic change trends. Compared to monitoring a single metric, this approach more accurately identifies performance degradation trends, overcoming the limitation of existing technologies that cannot perceive browser performance metrics because the monitored objects are business system nodes.

[0034] Based on the performance parameters obtained from the aforementioned multi-dimensional monitoring, the preset multi-level early warning thresholds also include a third threshold, and the classification also includes a third level corresponding to the third threshold. The values ​​of the first threshold, third threshold, and second threshold increase sequentially, corresponding to the alert level, high-risk level, and collapse level of risk, respectively. Taking the large screen application of the urban traffic command center as an example, the first threshold can be set to a memory utilization rate of 80%, a total number of DOM nodes of 3000, and a DOM node increase rate of 300 / second; the third threshold can be set to a memory utilization rate of 90%, a total number of DOM nodes of 5000, and a DOM node increase rate of 500 / second; the second threshold can be set to a memory utilization rate of 95%, a total number of DOM nodes of 8000, and a DOM node increase rate of 800 / second. The above thresholds can be adjusted according to the actual application scenario. By setting multi-level thresholds, the system can distinguish the severity of risks, providing a basis for subsequent differentiated handling. Unlike the existing technology that only uses a single early warning threshold, this solution divides risks into multiple levels through multi-level thresholds, enabling differentiated responses to risks of different severity levels and avoiding the drawbacks of a "one-size-fits-all" approach under a single threshold.

[0035] When the current performance parameters are determined to be at Level 1, it indicates a minor performance risk on the page that has not yet reached the point requiring active intervention. In this case, the current performance data is recorded in a circular log queue, and performance alerts are output to the console. Monitoring continues without active intervention. This approach records only alerts when the risk is relatively low, avoiding excessive response that could negatively impact user experience, while simultaneously accumulating data for subsequent problem analysis. Compared to existing technologies that only issue warnings and wait for manual intervention, this solution saves performance data to a circular log queue simultaneously with the warning, providing a foundation for subsequent root cause analysis.

[0036] When the current performance parameters are determined to be at level three, it indicates that page performance has significantly deteriorated but has not yet reached the crash threshold. At this point, a gentle cleanup operation is performed. The DOM tree is traversed to identify invisible areas outside the current viewport, and their content is cleared or set to invisible to reduce memory usage. Non-core data refresh timers are identified and paused, such as data update tasks for secondary charts, to prevent non-critical tasks from consuming system resources. The refresh rate of high-frequency components such as heatmaps and real-time monitoring is reduced, for example, from 30 frames per second to 10 frames per second, to reduce rendering pressure. These three operations work together to alleviate system pressure from three directions: memory release, task simplification, and rendering frequency reduction. After cleanup, performance parameters are collected again after a preset observation period (e.g., 30 seconds) for evaluation. If the indicators drop, normal monitoring is resumed; if the indicators remain high, preparations are made to enter crash-level handling. Through these gentle cleanup methods, flexible handling is prioritized when the problem is severe but has not yet reached the crash threshold, avoiding direct forced refreshes that could impact user experience. In response to the limitation of existing technologies that cannot proactively intervene before a collapse, this solution initiates proactive and gentle cleanup at high-risk levels, moving the intervention window forward and effectively preventing the problem from worsening.

[0037] When the current performance parameters are determined to be at level two, it indicates that the page is in a critical state of collapse and a forced refresh is required to prevent a crash. To avoid accidental operations due to occasional performance fluctuations, a secondary confirmation mechanism is triggered before executing a forced refresh: after a delay (e.g., 3 seconds), the current performance parameters of the target browser are retrieved again. If the retrieved performance parameters are still at level two, a forced refresh is executed, reloading the current page using `window.location.reload(true)` to release occupied memory. Before a forced refresh, the highest-level alarm information and all current performance data are written to local storage as a final log. This secondary confirmation mechanism, by setting a delayed confirmation window before a forced refresh, effectively avoids accidental operations caused by occasional fluctuations and improves the robustness of the system. In addition, the page frame rate is monitored as an auxiliary criterion for judging crash risk. When the page frame rate is continuously lower than a preset frame rate threshold (e.g., 15 frames / second) for a preset time, the above-mentioned forced refresh operation is also triggered, providing an additional dimension for identifying crash risks. Unlike existing technologies that can only output early warning notifications, this solution proactively performs a forced refresh operation in the critical state of a crash, moving the intervention time forward to before the crash occurs, thus realizing the transformation from passive early warning to proactive self-rescue.

[0038] Building upon the aforementioned tiered response and handling, to facilitate tracing the scene after a page crash, a fixed-capacity circular log queue is maintained in the browser's local storage to record performance metrics data. Each log entry includes a timestamp, page URL, various performance metrics, and trigger level. When the number of logs exceeds the queue capacity, the oldest historical logs are automatically overwritten, ensuring that the most recently generated logs are always retained. To implement tiered log storage, multiple independent storage queues can be maintained: a warning log queue with a capacity of 30 entries, used to record warning messages for the first time exceeding the threshold; a high-risk log queue with a capacity of 20 entries, used to record performance data reaching a high-risk level; a crash log queue with a capacity of 10 entries, used to record key metrics before an impending crash; and a final log, stored separately, retaining only the latest forced refresh record. When the page reloads, the circular log queue in local storage is automatically read, and the performance data before the crash is reported to the server via the fetch API or sendBeacon API. After reporting, the reported logs are cleaned up. This mechanism allows developers to obtain complete performance data before the crash, facilitating rapid problem localization and system optimization, and solving the problem of missing crash scene information in existing technologies.

[0039] Example 3 The technical solution of the present invention will be described in detail below with reference to a specific application scenario. This embodiment takes the application of a large screen in an urban traffic command center as an example. This large screen application includes multiple visualization components such as real-time traffic maps, traffic flow charts, and accident warning lists, and needs to run continuously 24 / 7.

[0040] like Figure 2 As shown, the technical solution of this embodiment includes the following steps.

[0041] Step S1: Construct a multi-dimensional performance monitoring model. During system initialization, multi-level warning thresholds are configured. The first threshold (alert level) is set to 80% memory usage, 3000 total DOM nodes, and a DOM node increase rate of 300 nodes / second. The second threshold (crash level) is set to 95% memory usage, 8000 total DOM nodes, and a DOM node increase rate of 800 nodes / second. The third threshold (high-risk level) is set to 90% memory usage, 5000 total DOM nodes, and a DOM node increase rate of 500 nodes / second. Simultaneously, a circular log storage queue is constructed, maintaining a fixed-capacity circular queue of 50 entries in the browser's local storage to record performance metric data. After system startup, the monitoring module continuously acquires the target browser's performance metrics, including memory usage, total DOM nodes, and DOM node increase rate, at a sampling period of once per second. Under normal operating conditions, all metrics remain within the threshold range. As runtime increases, memory usage gradually rises due to JavaScript objects not being promptly garbage collected.

[0042] Step S2: Configure a hierarchical early warning threshold system. For example... Figure 4 As shown, when memory usage first exceeds the first threshold (80%) and reaches 85%, a warning-level response is triggered. At this point, current performance data is recorded to a circular log queue, and a "high memory usage" alert is output to the console. Monitoring continues without active intervention. If memory usage continues to rise to the third threshold (90%) and reaches 92%, a high-risk response is triggered. The system performs a mild cleanup operation: traversing the DOM tree to identify invisible areas outside the current viewport, clearing the content of off-screen chart containers to release memory; identifying and pausing non-core data refresh timers, such as secondary data update tasks for the incident warning list; reducing the refresh rate of high-frequency components such as heatmaps from 30 frames per second to 10 frames per second to reduce rendering pressure. After cleanup, wait 30 seconds and collect performance parameters again for judgment. If memory usage drops back to 83%, normal monitoring resumes; if the indicator remains high (e.g., still above 93%), prepare for a crash-level response.

[0043] Step S3: Construct a circular log storage queue. For example... Figure 3 As shown, the final log recorded before a forced refresh is stored in a circular log queue along with other logs at various levels. The circular log queue is implemented using a fixed-capacity array; new logs are appended to the end of the array as they are added, and the oldest record is automatically removed when the number of logs exceeds the queue's capacity. Each log record includes a timestamp, page URL, memory usage, total number of DOM nodes, DOM node growth rate, and trigger level. To achieve hierarchical log storage, multiple independent storage queues can be maintained: a warning log queue with a capacity of 30 entries, used to record warning messages for the first time exceeding the threshold; a high-risk log queue with a capacity of 20 entries, used to record performance data reaching a high-risk level; a crash log queue with a capacity of 10 entries, used to record key indicators before an impending crash; and a final log stored separately, retaining only the latest forced refresh record.

[0044] Step S4: Implement tiered response measures. For example... Figure 5 As shown, if memory usage remains at 93% after a gentle cleanup and does not improve for 30 seconds, a crash-level response is triggered. The system executes a secondary confirmation mechanism: after a 3-second delay, it retrieves the target browser's memory usage and other performance parameters again. If the retrieved parameters are still at the second level (i.e., memory usage still exceeds the second threshold of 95% or continues to deteriorate), a forced refresh is performed. Before the forced refresh, the system writes the highest-level alarm information and all current performance data to local storage as a final log, and then reloads the current page using `window.location.reload(true)` to release the occupied memory.

[0045] Step S5: Crash Scene Tracing. After the page reloads, the system automatically reads the circular log queue in local storage, aggregates the performance data before the crash, and generates a complete crash report. The crash report includes a unique report identifier, timestamp, current page URL, log content at all levels, and basic browser information (including user agent, language, device memory, etc.). The system attempts to upload the report to the server via the fetch API, setting the keepalive flag to ensure the request can be completed; if fetch upload fails, it uses the sendBeacon API as a fallback; after the upload is complete, all uploaded logs in local storage are cleaned up, and the timestamp of the last recovery completion is recorded.

[0046] Through the above process, this embodiment realizes a complete closed loop from real-time monitoring of performance indicators, multi-level threshold classification judgment, differentiated handling (alert-level recording, high-risk-level gentle cleanup, and crash-level secondary confirmation followed by forced refresh) to crash scene tracing. It proactively intervenes when the browser page is on the verge of crashing, effectively ensuring the business continuity of large-screen applications.

[0047] Example 4 like Figure 6 As shown, this embodiment of the invention provides a system for preventing browser page crashes in large-screen display applications. The system includes a performance parameter acquisition module, a hierarchical determination module, and a forced refresh execution module. The system architecture of this embodiment corresponds to the methods described in Embodiments 1 to 3. The functions of each module in the system will be described in detail below.

[0048] The performance parameter acquisition module is configured to acquire the current performance parameters of the target browser. This module continuously performs acquisition actions at a preset sampling period to ensure the system can monitor the browser's running status changes in real time. The acquired performance parameters include memory usage, total number of DOM nodes, and DOM node growth rate. Memory usage is obtained through the `performance.memory` API, which calculates the ratio of used JavaScript heap memory to total memory. The total number of DOM nodes is calculated using the DOM traversal API to count all nodes on the current page. The DOM node growth rate is calculated by using the `MutationObserver` API to monitor changes in the DOM tree and counting the number of newly added nodes within a preset time window. By shifting the monitoring focus from business system nodes to the browser itself, the performance parameter acquisition module enables the system to detect potential risks at an early stage of page performance degradation, overcoming the problem of existing technologies that cannot detect browser performance metrics because the monitoring object is a business system node.

[0049] The classification determination module communicates with the performance parameter acquisition module and is configured to determine the classification of the current performance parameter based on a comparison between the current performance parameter acquired by the performance parameter acquisition module and a preset multi-level warning threshold. The preset multi-level warning thresholds include at least a first threshold and a second threshold, and the classification includes at least a first level corresponding to the first threshold and a second level corresponding to the second threshold. The classification determination module discretizes continuously changing performance data into quantifiable risk levels, enabling the system to make differentiated responses based on the severity of the risk. Unlike existing technologies that use only a single warning threshold, the classification determination module divides risks into multiple levels using multi-level thresholds, avoiding the drawbacks of a "one-size-fits-all" approach under a single threshold.

[0050] The forced refresh execution module communicates with the grading determination module and is configured to perform a forced refresh operation when the grading determination module determines that the current performance parameters are at the second grading level, in order to prevent the target browser from crashing. The forced refresh execution module reloads the current page using `window.location.reload(true)`, which can promptly release occupied system resources and prevent further failures in critical states such as high browser memory usage or abnormal accumulation of DOM nodes that could lead to a crash. Unlike existing technologies that only output warning notifications and wait for manual intervention, the forced refresh execution module proactively performs recovery actions when serious risks are identified, shifting the intervention time to the critical time window before the crash occurs, thus realizing a shift from passive warning to proactive self-rescue.

[0051] The three modules work together to form a complete chain from data collection and risk assessment to response execution: the performance parameter acquisition module is responsible for collecting browser-level data, the risk classification module classifies the collected data into risk levels based on preset multi-level warning thresholds, and the forced refresh execution module automatically triggers recovery actions when the classification results indicate severe risk. This architecture reconstructs the monitoring mode of passively receiving alarms from business systems into an adaptive system that proactively senses browser operational risks and autonomously executes recovery actions. It can complete preventative handling before a crash without manual intervention, effectively ensuring the stable operation of business continuity in large-screen scenarios.

[0052] Example 5 This invention also provides a computer device in specific embodiments. Specifically, the computer device includes a processor and a memory. The memory stores a computer program, which includes program instructions. The processor executes the program instructions stored in the computer storage medium. The processor may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It is the computing and control core of the terminal, suitable for implementing one or more instructions, specifically suitable for loading and executing one or more instructions to achieve corresponding method flows or corresponding functions. The processor described in this embodiment can be used to obtain the current performance parameters of the target browser. Based on the comparison result between the current performance parameter and the preset multi-level warning threshold, the level of the current performance parameter is determined; the multi-level warning threshold includes at least a first threshold and a second threshold, and the level includes at least a first level corresponding to the first threshold and a second level corresponding to the second threshold; When the current performance parameter is at the second level, a forced refresh operation is performed to prevent the target browser from crashing.

[0053] Example 6 This invention also provides a storage medium, specifically a computer-readable storage medium, which is a memory device in a terminal device used to store programs and data. It is understood that the computer-readable storage medium here can include both the built-in storage medium in the terminal device and extended storage media supported by the terminal device. The computer-readable storage medium provides storage space containing the terminal's operating system. Furthermore, the storage space also contains one or more instructions suitable for loading and execution by a processor. These instructions can be one or more computer programs (including program code). It should be noted that the computer-readable storage medium here can be high-speed RAM or nonvolatile memory, such as at least one disk storage device. The processor can load and execute one or more instructions stored in the computer-readable storage medium to implement the corresponding steps of the methods in the above embodiments; the one or more instructions in the computer-readable storage medium are loaded and executed by the processor to perform the following steps: obtaining the current performance parameters of the target browser; Based on the comparison result between the current performance parameter and the preset multi-level warning threshold, the level of the current performance parameter is determined; the multi-level warning threshold includes at least a first threshold and a second threshold, and the level includes at least a first level corresponding to the first threshold and a second level corresponding to the second threshold; When the current performance parameter is at the second level, a forced refresh operation is performed to prevent the target browser from crashing.

[0054] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0055] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0056] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0057] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0058] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. It will be apparent to those skilled in the art that the invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of the invention is not limited by the foregoing description. Thus, all changes falling within the meaning and scope of equivalents are intended to be included within the scope of the invention. No reference numerals in the drawings should be considered limiting.

[0059] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can be appropriately combined to form other embodiments that can be understood by those skilled in the art. The above content is only for illustrating the technical concept of the present invention and should not be used to limit the scope of protection of the present invention. Any modifications made to the technical solutions based on the technical concept proposed in this invention fall within the scope of protection of this invention.

Claims

1. A method for preventing browser page crashes in large-screen display applications, characterized in that, include: Get the current performance parameters of the target browser; Based on the comparison results between the current performance parameter and the preset multi-level early warning threshold, the level of the current performance parameter is determined; The multi-level early warning threshold includes at least a first threshold and a second threshold, and the classification includes at least a first level corresponding to the first threshold and a second level corresponding to the second threshold; When the current performance parameter is at the second level, a forced refresh operation is performed to prevent the target browser from crashing.

2. The method for preventing browser page crashes in large-screen display applications according to claim 1, characterized in that, The current performance parameters include memory usage, total number of DOM nodes, and DOM node growth rate.

3. The method for preventing browser page crashes in large-screen display applications according to claim 1, characterized in that, The multi-level warning threshold also includes a third threshold, and the classification also includes a third level corresponding to the third threshold; the first threshold is less than the third threshold, and the third threshold is less than the second threshold.

4. The method for preventing browser page crashes in large-screen display applications according to claim 3, characterized in that, When the current performance parameter is at the first level, the current performance parameter is recorded and an alarm message is output.

5. The method for preventing browser page crashes in large-screen display applications according to claim 3, characterized in that, When the current performance parameter is at the third level, a mild cleanup operation is performed; the mild cleanup operation includes at least one of cleaning up DOM nodes in invisible areas, pausing non-core timed refresh tasks, and reducing the refresh frequency of high-frequency components.

6. The method for preventing browser page crashes in large-screen display applications according to claim 1, characterized in that, Before performing the forced refresh operation, the method further includes: delaying the acquisition of the current performance parameters of the target browser again; if the acquired performance parameters are still at the second level, then performing the forced refresh operation.

7. The method for preventing browser page crashes in large-screen display applications according to claim 1, characterized in that, Also includes: Record performance parameters to a local circular log queue; Once the page is reloaded, the performance parameters in the circular log queue are read and reported to the server.

8. A system for preventing browser page crashes in large-screen display applications, characterized in that, include: The performance parameter acquisition module is used to obtain the current performance parameters of the target browser; The grading determination module is used to determine the grading of the current performance parameter based on the comparison result between the current performance parameter and the preset multi-level early warning threshold. The multi-level early warning threshold includes at least a first threshold and a second threshold, and the classification includes at least a first level corresponding to the first threshold and a second level corresponding to the second threshold; The forced refresh execution module is used to perform a forced refresh operation when the current performance parameter is at level two, in order to prevent the target browser from crashing.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method for preventing browser page crashes in a large-screen display application as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for preventing browser page crashes in a large-screen display application as described in any one of claims 1 to 7.

Images