A continuous anr monitoring and handling method and system

Abstract

The present application relates to the field of mobile terminal monitoring, and discloses a continuous ANR monitoring and processing method and system, which specifically comprises the following steps: acquiring process non-response information in real time; accumulating and counting the process non-response information within a preset time window; judging whether the accumulated and counted information reaches a preset threshold within the preset time window, so as to execute a system processing operation or a monitoring operation. The present application can effectively identify and process high-frequency ANR abnormalities within a short time through a time window monitoring mechanism, avoid redundant problem reporting, and improve system stability and problem positioning efficiency.

Description

Technical Field

[0001] This invention relates to the field of mobile terminal monitoring, and in particular to a method and system for continuous ANR monitoring and handling. Background Technology

[0002] In the R&D and quality assurance system of Android smart terminals, the R&D team typically uses an automated testing framework combined with the MTBF (Mean Time Between Failures) reliability verification model to conduct comprehensive stress testing and robustness assessment of the system. By simulating high concurrency, multi-threaded concurrent operations, and injecting abnormal scenarios, potential defects can be systematically exposed. This testing process drives a closed loop of problem localization and repair through anomaly log analysis, crash rate statistics, and quantitative evaluation of performance degradation curves, ultimately achieving continuous iterative optimization of system stability, application compatibility, and overall device reliability indicators.

[0003] In Android system stability testing, when using the Monkey testing framework to perform stress tests on low-end devices, hardware performance bottlenecks, such as insufficient CPU computing power, limited storage I / O throughput, excessively high number of background concurrent threads, or resource-intensive operations, can easily lead to continuous ANR (Application Not Responding) exceptions. These exceptions are mainly caused by main thread blocking or system resource contention.

[0004] In existing technologies, the Android system's ANR event handling mechanism has the following shortcomings: The native Android system does not enforce control over consecutive ANR events occurring within a short period; each ANR triggers an independent exception reporting process. Under stress testing scenarios, continuous ANR reporting generates a large number of redundant unresponsive issue records and may also cause cascading failures such as black screens and screen freezes, significantly reducing the efficiency of problem localization. Testers need to sift through massive amounts of repetitive logs to extract valid information, increasing analysis costs. Furthermore, for user scenarios, consecutive ANRs severely impact user experience, but the system lacks an effective self-recovery mechanism to interrupt the exception chain.

[0005] The root cause of the above problems lies in the lack of a time window monitoring mechanism and dynamic handling strategy for continuous ANR events. It is impossible to identify and intercept high-frequency ANR anomalies in a short period of time at the system level, and it is also impossible to take differentiated recovery measures according to the characteristics of the scenario. Summary of the Invention

[0006] The purpose of this invention is to propose a continuous ANR monitoring and handling method and system, which can effectively identify and handle high-frequency ANR anomalies in a short period of time through a time window monitoring mechanism, avoid redundant problem reporting, and improve system stability and problem location efficiency.

[0007] To address the aforementioned technical problems, this invention provides a method for continuous ANR monitoring and handling, specifically including the following: Real-time acquisition of information about processes that are not responding; The number of unresponsive processes within a preset time window is cumulatively counted. Determine whether the cumulative statistics have reached a preset threshold within the preset time window, in order to perform system processing or monitoring operations.

[0008] Furthermore, the step of determining whether the cumulative statistics have reached a preset threshold within the preset time window to execute system handling or monitoring operations specifically includes: if the cumulative statistics have reached the preset threshold within the preset time window, then triggering a system handling operation; if the cumulative statistics have not reached the preset threshold within the preset time window, then resetting the cumulative statistics and returning to the statistics step to continue monitoring.

[0009] Furthermore, if the cumulative number of statistics is greater than or equal to a preset threshold, and the statistical duration from the start of the current time window to the current time is less than or equal to the preset time window duration, then the triggering condition is determined to be met, and the system takes action; if the cumulative number of statistics is less than the preset threshold, and / or the statistical duration is greater than the preset time window duration, then the triggering condition is determined to be unmet, the cumulative number of statistics is cleared to zero, and the system returns to the statistical step to continue the next round of monitoring.

[0010] Furthermore, the real-time acquisition of process unresponsive information specifically includes: monitoring application unresponsive events in real time through the application unresponsive interface, and acquiring the process unresponsive information corresponding to the application unresponsive event.

[0011] Furthermore, the step of accumulating statistics on the process unresponsive information within a preset time window specifically includes: incrementing and updating the count value within the preset time window whenever an application unresponsive event is detected; and using the count value as the measurement basis for the cumulative statistics.

[0012] Furthermore, before performing cumulative statistics, it also includes: determining whether the application corresponding to the currently obtained process unresponsive information belongs to the preset monitoring whitelist, so as to choose whether to perform cumulative statistics operation.

[0013] Furthermore, if the application corresponding to the currently obtained process non-response information does not belong to the monitoring whitelist, the current cumulative statistics will not be executed, and the process will return to the acquisition step to continue monitoring; if the application corresponding to the currently obtained process non-response information belongs to the monitoring whitelist, the cumulative statistics will continue to be executed.

[0014] Furthermore, the system's processing operations specifically include: identifying the current running scenario type; if it is identified as an automated testing scenario, then directly executing a system restart operation; if it is identified as a non-automated testing scenario, then presenting a restart confirmation prompt to the user, and deciding whether to execute the system restart operation based on the user's selection.

[0015] Furthermore, the identification of the current operating scenario type is achieved through at least one of the following methods: identifying random event injection test scenarios by detecting random user event injection characteristics in the process; and identifying mean time between failures (MTBF) test scenarios by analyzing the statistical characteristics of the system's continuous runtime and fault intervals.

[0016] In addition, the present invention also proposes a continuous ANR monitoring and handling system for implementing the continuous ANR monitoring and handling method as described above, including an acquisition module, a statistics module and a handling module. The acquisition module is used to acquire process non-response information in real time; The statistics module is used to accumulate statistics on the non-response information of the process within a preset time window; The processing module is used to determine whether the cumulative statistics have reached a preset threshold within the preset time window, and to perform corresponding operations.

[0017] Through the above technical solution, the present invention has the following beneficial effects: By establishing a time-window-based cumulative statistical mechanism, high-frequency ANR anomalies within a short period can be identified at the system level. Preset thresholds are used to dynamically determine whether to implement system-level handling or continue monitoring, avoiding the need for each ANR to trigger an independent anomaly reporting process. This effectively reduces redundant problem records and improves the effectiveness of test logs and the efficiency of problem localization. Furthermore, by accumulating and judging process unresponsiveness information within a preset time window, timely measures can be taken when consecutive ANRs reach preset conditions, interrupting the anomaly chain, preventing cascading failures, and enhancing the system's emergency response capabilities and overall stability. Attached Figure Description

[0018] Figure 1 This is an overall flowchart of a continuous ANR monitoring and handling method in one embodiment of the present invention; Figure 2 This is a flowchart of a continuous ANR monitoring and handling method in one embodiment of the present invention; Figure 3 This is a flowchart of the continuous ANR assessment and processing mechanism in a continuous ANR monitoring and handling method according to an embodiment of the present invention. Figure 4 This is a block diagram of a continuous ANR monitoring and handling system according to an embodiment of the present invention. Detailed Implementation

[0019] Based on the teachings of this specification, those skilled in the art can form new technical solutions through cross-combination of different implementation methods without creating technical contradictions. Such variations should all be considered to fall within the protection scope of this invention.

[0020] The following description, in conjunction with the accompanying drawings, provides a more detailed account of a continuous ANR monitoring and handling method and system according to the present invention, which illustrates preferred embodiments of the invention. It should be understood that those skilled in the art can modify the invention described herein while still achieving its advantageous effects. Therefore, the following description should be understood as being of general knowledge to those skilled in the art and is not intended to limit the invention.

[0021] The invention is described more specifically by way of example in the following paragraphs with reference to the accompanying drawings. The advantages and features of the invention will become clearer from the following description. It should be noted that the drawings are in a very simplified form and use non-precise proportions, and are only used to facilitate and clarify the illustration of the embodiments of the invention.

[0022] like Figures 1-3 As shown in the figure, this embodiment of the invention proposes a method for continuous ANR monitoring and handling, which specifically includes the following steps: S1. Real-time acquisition of process unresponsiveness information; S2. Accumulate and statistically analyze the non-response information of the process within a preset time window; S3. Determine whether the cumulative statistics have reached a preset threshold within the preset time window, so as to perform system processing or monitoring operations.

[0023] In step S1, the real-time acquisition of process unresponsive information specifically includes: monitoring application unresponsive events in real time through the application unresponsive interface, and acquiring the process unresponsive information corresponding to the application unresponsive event.

[0024] In a specific example, this embodiment utilizes the Application NotResponding interface provided by the Android system for ANR event listening. At the system's underlying implementation, when the application's main thread fails to complete its task within a specified time (e.g., 5 seconds for input event response timeout, 10 seconds for broadcast processing timeout, 20 seconds for service startup timeout), the system triggers the ANR detection mechanism through the `appNotResponding()` method of `ActivityManagerService` (AMS). This method calls `handleApplicationANR` for initial ANR processing, recording key diagnostic data such as process ID, process name, package name, no-response timestamp, thread stack, and CPU usage. Subsequently, the `anrApplicationInner` method in `AppError.java` responds to the no-response event, executing error report generation and user notification processes. Simultaneously, the `onPackageFailure` method in `PackageWatchdog.java` is called, registering the ANR event with the system's fault monitoring mechanism. Through the collaborative work of these system-level interfaces, this embodiment can obtain complete ANR event information in real time, providing a reliable data source for subsequent cumulative statistics and threshold judgment.

[0025] Those skilled in the art will understand that the specific implementation of the application unresponsive interface can be adapted to the characteristics of different operating system platforms, and also includes other interface implementation methods besides this embodiment, such as through system service monitoring, process status polling, etc. This embodiment obtains ANR information in real time through a standardized interface, which can improve the timeliness and accuracy of monitoring. Then, a system-level continuous ANR detection mechanism is constructed to obtain the process unresponsive information corresponding to the application unresponsive event.

[0026] In step S2, the step of accumulating statistics on the process unresponsive information within a preset time window specifically includes: incrementing and updating the count value within the preset time window whenever an application unresponsive event is detected; and using the count value as the measurement basis for the cumulative statistics.

[0027] In a preferred embodiment, the cumulative statistics are implemented through a system rescue mechanism (RescueParty). Specifically, the RescuePartyObserver in RescueParty.java observes the fault situation. When an ANR event is detected, the current Level is obtained according to the getRescueLevel method. Level represents the rescue level corresponding to the cumulative number of ANR events within a preset time window. Each time a new ANR event is detected, the system determines whether the event occurred within the current time window. If so, the count value is updated by increasing the Level; if it exceeds the time window, the Level is reset and a new time window is opened. The window time and Level threshold can be dynamically adjusted according to the stability requirements of different projects. For example, it can be set to "5 ANR events within 1 minute trigger Level 5 rescue operation" or "10 ANR events within 2 minutes trigger Level 10 rescue operation".

[0028] In a specific example, this embodiment maintains a time window counter, initially set to 0. When an ANR event is detected for the first time, the current timestamp is recorded as the start time of the time window, and the counter is incremented by 1. Subsequently, each time a new ANR event is detected, it is determined whether the current time is still within the time window. If it is, the counter continues to increment; if it exceeds the window, the counter is reset and the start time of the time window is updated. Those skilled in the art will know that the duration of the preset time window can be set according to actual needs, for example, it can be set to 30 seconds, 60 seconds, or 120 seconds, and other time window configuration schemes besides this embodiment are also included. This embodiment, through a cumulative statistical mechanism within the time window, can accurately quantify the frequency of consecutive ANRs, providing a reliable basis for subsequent threshold determination.

[0029] In this embodiment, before performing cumulative statistics, it further includes: determining whether the application corresponding to the currently obtained process non-response information belongs to the preset monitoring whitelist, so as to select whether to perform cumulative statistics operation.

[0030] In a specific example, the preset monitoring whitelist can include critical system applications, such as core system service processes like the System UI, Phone, and Messaging processes. This embodiment can also set different levels based on the importance of the application, where Level refers to the importance classification of the application; for example, Level 1 represents the highest priority core system processes, Level 2 represents secondary system processes, and Level 3 represents ordinary application processes, etc. When an ANR event is detected, the package name or process name in the process non-response information is first extracted and matched against the whitelist. If a match is successful, the subsequent cumulative statistics process continues; if a match fails, the ANR event is ignored and not counted. Those skilled in the art will understand that the monitoring whitelist configuration can be customized according to actual monitoring needs. For example, it can monitor only applications of specific business modules, or exclude certain applications known to frequently trigger ANR but not affecting system stability, and also includes other whitelist configuration schemes besides this embodiment. This embodiment, through a whitelist filtering mechanism, can focus on the abnormal monitoring of critical applications, improving the targeting and effectiveness of monitoring and avoiding misjudgments.

[0031] Preferably, if the application corresponding to the currently obtained process non-response information does not belong to the monitoring whitelist, the current cumulative statistics will not be executed, and the acquisition step will be returned to continue monitoring; if the application corresponding to the currently obtained process non-response information belongs to the monitoring whitelist, the cumulative statistics will continue to be executed.

[0032] In a specific example, suppose the monitoring whitelist contains two critical system processes, "com.android.systemui" and "com.android.phone". When an ANR event is detected, the process package name "com.android.systemui" is extracted. If it matches the whitelist, the cumulative statistics continue. If the extracted process package name is "com.thirdparty.app", which is not in the whitelist, the current statistics are skipped, and the system returns to monitor the next ANR event. This embodiment, through explicit whitelist judgment logic, can achieve accurate application filtering and reduce invalid statistics and false alarms.

[0033] In step S3, determining whether the cumulative statistics have reached a preset threshold within the preset time window to execute system handling or monitoring operations specifically includes: if the cumulative statistics have reached the preset threshold within the preset time window, then triggering a system handling operation; if the cumulative statistics have not reached the preset threshold within the preset time window, then resetting the cumulative statistics and returning to the statistics step to continue monitoring.

[0034] In a specific example, the preset threshold can be set to 3 times. That is, when 3 or more ANR events are detected within a preset time window, it is determined to be a continuous high-frequency anomaly, triggering system handling operations. If the cumulative number of occurrences does not reach 3 by the end of the time window, the ANR event is considered an occasional occurrence, the counter is reset, and a new round of monitoring begins. Those skilled in the art will understand that the preset threshold can be flexibly configured according to system stability requirements and business scenarios. For example, it can be set to 2 times for scenarios with high stability requirements, and 4 or 5 times for scenarios with high fault tolerance requirements. Other threshold configuration schemes besides those in this embodiment are also included. This embodiment, through a threshold judgment mechanism, can effectively distinguish between occasional ANRs and continuous anomalies, avoiding misjudgments of normal operation.

[0035] Preferably, if the cumulative number of statistics is greater than or equal to a preset threshold, and the statistical duration from the start of the current time window to the current time is less than or equal to the preset time window duration, then the triggering condition is determined to be met, and the system takes action; if the cumulative number of statistics is less than the preset threshold, and / or the statistical duration is greater than the preset time window duration, then the triggering condition is determined to be unmet, the cumulative number of statistics is cleared to zero, and the system returns to the statistical step to continue the next round of monitoring.

[0036] In a specific example, assuming a preset threshold of 3 occurrences and a preset time window duration of 60 seconds, when the first ANR occurs, the recording starts at time T0, and the counter is set to 1. When the second ANR occurs at T0+20 seconds, the counter increments to 2. When the third ANR occurs at T0+45 seconds, the counter increments to 3. At this point, the condition of "cumulative count ≥ 3 and statistical duration ≤ 60 seconds" is met, triggering system processing. If the third ANR occurs at T0+65 seconds, although the cumulative count reaches 3, the statistical duration exceeds the 60-second window, the triggering condition is deemed invalid, the counter is reset to zero, and monitoring restarts. This embodiment, through the dual judgment conditions of count and duration, can accurately identify high-frequency anomalies within a short period of time, improving the accuracy of anomaly detection.

[0037] In this embodiment, the system handling operation specifically includes: identifying the current operating scenario type; if it is identified as an automated testing scenario, a system restart operation is directly executed; if it is identified as a non-automated testing scenario, a restart confirmation prompt is presented to the user, and the system restart operation is executed based on the user's choice. In a specific example, when continuous ANR reaches the threshold and triggers system handling, the scenario identification module first determines the current operating scenario of the device. If it is determined to be an automated testing scenario (e.g., monkey testing, stability testing, etc.), to avoid test interruption and improve test efficiency, the system directly calls the restart interface to execute the system restart operation without manual intervention; if it is determined to be a normal user usage scenario, a dialog box pops up prompting the user "System anomaly detected, it is recommended to restart the device to restore stability," and provides two options: "Restart now" and "Process later," and the system decides whether to execute the restart based on the user's choice. This embodiment, through scenario identification and differentiated handling strategies, can improve testing efficiency and problem reproducibility in automated testing scenarios, and enhance user experience and device controllability in user usage scenarios.

[0038] In a preferred embodiment, the system handling operation is implemented through the `executeRescueAnrLevel` method. This method performs corresponding rescue operations based on the current Level and the type of operating scenario. Specifically, when the Level reaches a preset threshold (e.g., Level 5) and is within a preset time window (e.g., 1 minute), the system calls the `executeRescueAnrLevel` method to determine the scenario: if a Monkey test process or other automated test identifier is detected, a system restart operation is directly performed to ensure that the test environment can be quickly restored; if it is a normal user usage scenario, a user interaction interface is popped up, and the user chooses whether to perform a restart operation.

[0039] Preferably, the identification of the current operating scenario type is achieved through at least one of the following methods: identifying random event injection test scenarios by detecting random user event injection characteristics in the process; and identifying mean time between failures (MTBF) test scenarios by analyzing the statistical characteristics of the system's continuous runtime and fault interval.

[0040] In a specific example, for identifying random event injection test scenarios, the system can be monitored for the presence of monkey processes or specific test framework processes, or for high-frequency random touch, swipe, or key presses in the input event stream. If these characteristics are detected, the system is identified as a monkey test or random stress test scenario. For identifying Mean Time Between Failures (MTBF) test scenarios, the system's runtime since startup and the intervals between historical ANR events or system anomalies can be statistically analyzed. If the runtime exceeds a specific threshold (e.g., 24 hours) and the intervals between anomalies exhibit regularity, the system is identified as an MTBF stability test scenario. Those skilled in the art will understand that the specific methods for scenario identification can be extended according to different test types and business needs. For example, scenario determination can be performed by identifying characteristic processes of testing tools, detecting system attribute configurations, and analyzing log characteristics. Other scenario identification schemes besides those in this embodiment are also included. This embodiment, through a multi-dimensional scenario identification mechanism, can accurately distinguish between test scenarios and user scenarios, providing a reliable basis for differentiated handling.

[0041] In addition, such as Figure 4 As shown, this embodiment also proposes a continuous ANR monitoring and handling system to implement the continuous ANR monitoring and handling method described above, including an acquisition module, a statistics module, and a handling module. Specifically, the acquisition module is used to acquire process unresponsive information in real time; the statistics module is used to accumulate statistics on the process unresponsive information within a preset time window; the handling module is used to determine whether the accumulated statistics have reached a preset threshold within the preset time window and to perform corresponding operations.

[0042] In one embodiment, the acquisition module communicates with the underlying system service through an application non-response interface to monitor the generation of ANR events in real time. When an ANR event callback is received, key information such as process ID, process name, package name, and non-response timestamp is extracted and passed to the statistics module for processing. The statistics module maintains a time window counter and timestamp record, dynamically updates the counter value based on the received process non-response information, and calculates the current statistical duration in real time. The handling module executes threshold judgment logic based on the cumulative statistical data and time window information provided by the statistics module. If the triggering condition is met, the scenario recognition submodule is called to determine the current running scenario, and a direct restart or user interaction confirmation process is executed according to the scenario type. If the triggering condition is not met, a reset command is sent to the statistics module to clear the counter and start a new round of monitoring. This embodiment, through a modular system architecture design, can achieve clear functional separation and flexible expansion capabilities, facilitating subsequent maintenance and functional upgrades.

[0043] In this implementation, after system startup, the acquisition module begins real-time monitoring of application unresponsive events. When the first ANR event is captured, the current timestamp is recorded as the start time of the time window, and the counter is initialized to 1. Subsequently, the statistics module continuously monitors ANR events within the time window. Each time a new ANR event is detected, the counter is incremented by 1, and the time difference between the current time and the start time is calculated. The handling module compares the counter value with a preset number of occurrences threshold and the time difference with a preset time window duration in real time. When the condition of "counter ≥ number of occurrences threshold and time difference ≤ time window duration" is met, it is determined to be a continuous high-frequency anomaly, and the system handling process is immediately triggered. In the system handling process, the scene recognition module first determines whether the current situation is an automated testing scenario. If so, the system restart interface is directly called to achieve rapid recovery; otherwise, a user confirmation dialog box pops up, and the user decides whether to restart based on their selection. If the threshold condition is not met before the end of the time window, the counter is cleared to zero, the start time of the next time window is recorded again, and a new round of monitoring and statistics is executed. This embodiment achieves intelligent identification and automated handling of continuous ANR events through the coordinated work of multiple links such as time window sliding, cumulative statistics, threshold judgment, scene recognition, and differentiated handling, effectively interrupting the abnormal chain and preventing the occurrence of cascading system failures.

[0044] In summary, the continuous ANR monitoring and handling method and system proposed in this invention have the following advantages: By establishing a time-window-based cumulative statistical mechanism, high-frequency ANR anomalies within a short period can be identified at the system level. Preset thresholds are used to dynamically determine whether to implement system-level handling or continue monitoring, avoiding the need for each ANR to trigger an independent anomaly reporting process. This effectively reduces redundant problem records and improves the effectiveness of test logs and the efficiency of problem localization. Furthermore, by accumulating and judging process unresponsiveness information within a preset time window, timely measures can be taken when consecutive ANRs reach preset conditions, interrupting the anomaly chain, preventing cascading failures, and enhancing the system's emergency response capabilities and overall stability.

[0045] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for continuous ANR monitoring and handling, characterized in that, Specifically, it includes the following: Real-time acquisition of information about processes that are not responding; The number of unresponsive processes within a preset time window is cumulatively counted. Determine whether the cumulative statistics have reached a preset threshold within the preset time window, in order to perform system processing or monitoring operations.

2. The continuous ANR monitoring and handling method as described in claim 1, characterized in that, The step of determining whether the cumulative statistics have reached a preset threshold within the preset time window to execute system handling or monitoring operations specifically includes: if the cumulative statistics have reached the preset threshold within the preset time window, then triggering a system handling operation; if the cumulative statistics have not reached the preset threshold within the preset time window, then resetting the cumulative statistics and returning to the statistics step to continue monitoring.

3. The continuous ANR monitoring and handling method as described in claim 2, characterized in that, If the cumulative number of statistics is greater than or equal to the preset number threshold, and the statistical duration from the start time of the current time window to the current time is less than or equal to the preset time window duration, then the triggering condition is determined to be met, and the system processing operation is triggered. If the cumulative number of statistics is less than the preset threshold, and / or the statistical duration is greater than the preset time window duration, the triggering condition is determined to be invalid, the cumulative number of statistics is cleared to zero, and the statistical step is returned to continue the next round of monitoring.

4. The continuous ANR monitoring and handling method as described in claim 1, characterized in that, The real-time acquisition of process unresponsive information specifically includes: monitoring application unresponsive events in real time through the application unresponsive interface, and acquiring the process unresponsive information corresponding to the application unresponsive event.

5. The continuous ANR monitoring and handling method as described in claim 4, characterized in that, The step of accumulating statistics on the process unresponsiveness information within a preset time window specifically includes: incrementing and updating the count value within the preset time window whenever an application unresponsiveness event is detected; and using the count value as the measurement basis for the cumulative statistics.

6. The continuous ANR monitoring and handling method as described in claim 1, characterized in that, Before performing cumulative statistics, it also includes: determining whether the application corresponding to the currently obtained process unresponsive information belongs to the preset monitoring whitelist, so as to choose whether to perform cumulative statistics operation.

7. The continuous ANR monitoring and handling method as described in claim 6, characterized in that, If the application corresponding to the currently obtained process non-response information is not in the monitoring whitelist, the current cumulative statistics will not be executed, and the process will return to the acquisition step to continue monitoring; if the application corresponding to the currently obtained process non-response information is in the monitoring whitelist, the cumulative statistics will continue to be executed.

8. The continuous ANR monitoring and handling method as described in claim 1, characterized in that, The system's processing operations specifically include: identifying the current running scenario type; if it is identified as an automated testing scenario, directly executing a system restart operation; if it is identified as a non-automated testing scenario, presenting a restart confirmation prompt to the user, and deciding whether to execute the system restart operation based on the user's selection.

9. The continuous ANR monitoring and handling method as described in claim 8, characterized in that, The identification of the current operating scenario type is achieved through at least one of the following methods: identifying random event injection test scenarios by detecting random user event injection characteristics in the process; and identifying mean time between failures (MTBF) test scenarios by analyzing the statistical characteristics of the system's continuous runtime and fault intervals.

10. A continuous ANR monitoring and handling system, used to implement the continuous ANR monitoring and handling method as described in any one of claims 1-9, characterized in that, It includes an acquisition module, a statistics module, and a processing module; The acquisition module is used to acquire process non-response information in real time; The statistics module is used to accumulate statistics on the non-response information of the process within a preset time window; The processing module is used to determine whether the cumulative statistics have reached a preset threshold within the preset time window, and to perform corresponding operations.

Images