Mobile terminal service availability inspection method based on system state matrix driving

Abstract

The embodiment of the invention provides a mobile terminal service availability inspection method based on system state matrix driving, which belongs to the technical field of physics, and specifically comprises the following steps: constructing a system service state matrix; detecting a structure dimension, a behavior dimension, a signal dimension, an abnormal dimension and a user perception dimension by using a multi-modal probe system, mapping detection results into corresponding discrete state values, and filling and updating a system service state matrix according to the discrete state values; dynamically deciding a subsequent inspection path and a detection priority by combining a real-time environment state and a user behavior mode of the mobile terminal on the basis of each dimension state value filled in the system service state matrix and a predefined association rule; and controlling the multi-mode probe system to execute a corresponding detection action according to the inspection path, and generating an availability evaluation result of the target system service based on the final state of the system service state matrix. Through the scheme disclosed by the invention, the inspection efficiency, accuracy and adaptability are improved.

Description

Technical Field

[0001] This disclosure relates to the field of physical technology, and in particular to a method for mobile terminal service availability inspection based on system state matrix driven. Background Technology

[0002] Currently, with the increasing complexity of the mobile terminal ecosystem, the basic services integrated into the system (such as Google Play services, Huawei push services, Xiaomi authentication services, etc.) have become essential dependencies for application operation. However, the component status, dependency integrity, and reachability of basic services may differ in different ROMs (customized system versions), leading to problems such as service unavailability, inability to start, and DeepLink unresponsiveness.

[0003] In existing technologies, service availability is often detected through the following methods: Static package management query: can only confirm whether the APK is installed, but cannot determine whether the service can start or respond normally.

[0004] UI automation script click verification: It is highly dependent on the specific automation framework and has poor portability; moreover, it can only verify shallow functions at the UI level and cannot delve into the internal state of the service.

[0005] DeepLink trigger testing: The lack of capture of signal layer data (such as system broadcasts, critical process lifecycle changes, and binder call results) in the service call chain leads to a high false positive rate.

[0006] The above methods generally suffer from the following drawbacks: 1. Incomplete verification: It is impossible to comprehensively judge the true availability of the service from multiple dimensions such as structural (whether the component is registered), behavioral (whether the call is successful), and signaling (whether the system responds normally).

[0007] 2. Lack of unified standards: Test results are mostly Boolean values ​​(on / off), lacking a quantifiable and unified scoring model, making it impossible to form a systematic usability assessment report.

[0008] 3. Poor robustness: The test logic is fixed, and once the ROM version or UI changes, the script is very easy to fail, resulting in high maintenance costs.

[0009] It is evident that there is an urgent need for a mobile terminal service availability inspection method based on system state matrix driven by high inspection efficiency, accuracy, and adaptability. Summary of the Invention

[0010] In view of this, the present disclosure provides a mobile terminal service availability inspection method based on system state matrix driving, which at least partially solves the problems of poor inspection efficiency, accuracy and adaptability in the prior art.

[0011] This disclosure provides a mobile terminal service availability inspection method based on a system state matrix, including: Step 1: Construct a system service state matrix, wherein the system service state matrix is ​​a multi-dimensional discrete state space used to uniformly represent the state of the target system service in the mobile terminal. The dimensions of the system service state matrix include a structural dimension representing the integrity of service component declarations, a behavioral dimension representing the service call response capability, a signal dimension representing the consistency of system-level signals, an anomaly dimension representing the recoverability of anomalies, and a user perception dimension representing the terminal interaction performance. Step 2: Using a multimodal probe system, detection is performed on the structural dimension, behavioral dimension, signal dimension, anomaly dimension and user perception dimension respectively, and the detection results are mapped to the corresponding discrete state values, thereby filling and updating the system service state matrix. Step 3: Based on the state values ​​of each dimension already filled in the system service state matrix and their predefined association rules, combined with the real-time environmental status of the mobile terminal and user behavior patterns, dynamically decide the subsequent inspection path and detection priority. Step 4: Based on the inspection path generated by dynamic decision-making, control the multimodal probe system to perform corresponding detection actions, and generate availability assessment results for the target system service based on the final state of the system service state matrix.

[0012] According to a specific implementation of this disclosure, the rule for determining the structural dimension includes: Parse the manifest file corresponding to the target system service, extract all declared components and compare them with a preset benchmark component list to calculate the component matching degree; When a critical service component is missing, the system is determined to be in an unregistered state. When a critical service component is complete but the component matching degree is less than the first threshold, it is determined to be in a partial registration state. When the component matching degree is equal to or greater than the first threshold, it is determined to be in a complete registration state.

[0013] According to a specific implementation of this disclosure, the determination rules for the behavior dimension include: Initiate calls to the target system service using a set of test cases that simulate real user behavior; Record the response time and return code of the call process; If the response time does not exceed the first preset duration and the call return code indicates success, it is determined to be reachable and in a response state; If the response time is between the first preset time and the second preset time, or if the call return code indicates failure, it is determined to be an unresponsive state. If the response time exceeds the second preset time, or if the call times out or an exception occurs, it is determined to be in an unreachable state.

[0014] According to a specific implementation of this disclosure, the rule for determining the signal dimension includes: Use the default tool to capture lifecycle events related to the target system service process in the system log; If a preset process startup flag appears in the log, it is determined to be in a consistent state; If a preset process abnormal termination flag appears in the log, it is determined to be a partially inconsistent state. If no relevant lifecycle event is captured, it is determined to be an abnormal state.

[0015] According to a specific implementation of this disclosure, the rules for determining the anomaly dimension include: During the detection process at the signal or behavior level, capture abnormal events related to the target system service; Analyze the types and frequency of abnormal events to determine whether they can be automatically recovered by the system; Based on the judgment results, the state values ​​of the abnormal dimension are mapped to no abnormality, recoverable abnormality, or unrecoverable abnormality.

[0016] According to a specific implementation of this disclosure, the rules for determining the user perception dimension include: Collect supplementary status data corresponding to the target system service, wherein the supplementary status data includes application interface response time, number of interface refresh blocking events, and input event processing delay; Based on the predefined interval of the statistical analysis results of the supplementary status data, the status is judged as excellent, good, average, or poor.

[0017] According to a specific implementation of an embodiment of this disclosure, the predefined association rules include: If the structure dimension is not registered, then skip the detection of the behavior dimension; If the structural dimension is in a partially registered state, then dependency verification of the missing components will be triggered. If the behavior dimension is in an unreachable state and the structure dimension is in a fully registered state, then a secondary verification based on the backup link is triggered.

[0018] According to a specific implementation of this disclosure, the step of dynamically deciding the subsequent inspection path and detection priority by combining the real-time environmental status of the mobile terminal and the user behavior pattern includes: Collect data on the mobile terminal's network type and signal strength, battery level, and current application usage. Based on the collected data, predict service interruption risk points, adjust the inspection path accordingly, and prioritize the detection of corresponding components or dimensions according to the adjusted inspection path.

[0019] According to a specific implementation of an embodiment of this disclosure, the step of generating an availability assessment result for the target system service includes: Dynamic weight coefficients are assigned to the state values ​​of each dimension in the system service state matrix. The dynamic weight coefficients are determined by analyzing the real-time state data of the mobile terminal and user operation behavior through a graph neural network model. A quantitative usability score is obtained by weighting the state values ​​of each dimension and their corresponding dynamic weight coefficients.

[0020] The mobile terminal service availability inspection scheme based on system state matrix driven in this embodiment includes: Step 1, constructing a system service state matrix, wherein the system service state matrix is ​​a multi-dimensional discrete state space used to uniformly represent the state of the target system service in the mobile terminal. The dimensions of the system service state matrix include a structural dimension representing the integrity of service component declarations, a behavioral dimension representing the service call response capability, a signal dimension representing the consistency of system-level signals, an anomaly dimension representing the recoverability of anomalies, and a user perception dimension representing the terminal interaction performance; Step 2, using a multimodal probe system to detect the structural dimension, behavioral dimension, signal dimension, anomaly dimension, and user perception dimension respectively, and mapping the detection results to the corresponding discrete state values, thereby filling and updating the system service state matrix; Step 3, based on the state values ​​of each dimension already filled in the system service state matrix and their predefined association rules, combined with the real-time environmental state of the mobile terminal and user behavior patterns, dynamically deciding the subsequent inspection path and detection priority; Step 4, according to the inspection path generated by the dynamic decision, controlling the multimodal probe system to execute corresponding detection actions, and generating an availability assessment result for the target system service based on the final state of the system service state matrix.

[0021] The beneficial effects of this disclosure are as follows: By introducing a dynamic weight allocation mechanism based on graph neural networks, the weights of each dimension are dynamically calculated according to the real-time system status and user behavior, making the scoring closer to the actual user experience; the detection path is dynamically generated according to the network status, battery status and user behavior patterns of the mobile terminal, significantly improving the efficiency and accuracy of inspection; the user perception dimension is introduced, directly linking system monitoring with user experience, making service availability assessment more comprehensive and practical; it can accurately identify complex states such as "false availability", "partial availability" and "internal anomaly but external reachability", greatly reducing the false judgment rate and improving user satisfaction. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A flowchart illustrating a mobile terminal service availability inspection method based on a system state matrix driven by an embodiment of this disclosure; Figure 2 A multimodal probe system architecture diagram provided in this disclosure embodiment; Figure 3 A decision flow diagram of an adaptive inspection engine provided in an embodiment of this disclosure; Figure 4 A flowchart illustrating the calculation process of a quantitative scoring system provided in this embodiment of the present disclosure. Detailed Implementation

[0024] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0025] The following specific examples illustrate the implementation of this disclosure. Those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0026] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0027] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The illustrations only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0028] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0029] This disclosure provides a mobile terminal service availability inspection method based on system state matrix driven, which can be applied to the service availability detection process of mobile terminals.

[0030] See Figure 1 This is a flowchart illustrating a mobile terminal service availability inspection method based on a system state matrix driven by an embodiment of this disclosure. Figure 1 As shown, the method mainly includes the following steps: Step 1: Construct a system service state matrix, wherein the system service state matrix is ​​a multi-dimensional discrete state space used to uniformly represent the state of the target system service in the mobile terminal. The dimensions of the system service state matrix include a structural dimension representing the integrity of service component declarations, a behavioral dimension representing the service call response capability, a signal dimension representing the consistency of system-level signals, an anomaly dimension representing the recoverability of anomalies, and a user perception dimension representing the terminal interaction performance. In practice, the System Service State Matrix (SSM) is a finite discrete state space, where each dimension of the state is a set of discrete states mapped from the corresponding probe detection results. The SSM comprises the following five dimensions: Structural dimension (S): Represents the completeness of service component declarations, with values ​​ranging from {not registered, partially registered, fully registered}. Behavioral dimension (B): Represents the service's call response capability, with values ​​ranging from {unreachable, reachable but unresponsive, reachable and responsive}. Signal dimension (G): Represents the consistency of system-level signals, with values ​​ranging from {consistent, partially inconsistent, and abnormal}. Anomaly Dimension (E): Represents the recoverability of an anomaly, with values ​​ranging from {no anomaly, recoverable anomaly, unrecoverable anomaly}. User perception dimension (U): Represents the actual user experience, with values ​​ranging from {excellent, good, average, poor}. The service state at any given time is represented as a state vector: SSM_t = (S_i, B_j, G_k, E_m, U_n); 1.1 Structural Dimension (S) Determination Rules Not Registered: S = Not Registered when a critical authentication component (such as AccountManager) is missing; Partial registration: When a common component is missing but a critical component is complete, S = partial registration; Full registration: S = Full registration when all components are fully declared; Judgment method: Extract the AndroidManifest.xml file of the target service; Parse the declared Activity, Service, and ContentProvider components; Compare with a predefined list of benchmark components; Component matching degree = (number of matching components) / (total number of baseline components); If the matching degree is ≥ 95%, it is considered a complete registration; 1.2 Behavioral Dimension (B) Judgment Rules Reachable and responsive: When the API call response time is ≤ 500ms and the return code is 0 (success); Unresponsive: When the response time is >500ms but ≤2000ms and the return code is not 0 (e.g., -1 indicates authentication failure); Unreachable: When the response time > 2000ms or the call times out / throws an exception; Test case construction: For Google Play services, construct a test case set that includes typical authentication processes (including login, authorization, logout, etc.). Test cases are validated using historical service call logs and user behavior data to ensure coverage of over 90% of typical use cases; 1.3 Signal Dimension (G) Determination Rules Consistent: When "Process started" appears in the system log; Partial inconsistency: When "Process killed" appears in the system log; Exception: When no relevant logs are available; Signal acquisition methods: Use Android's logcat tool to capture system logs; Set filtering rules: tag:ActivityManager pid:<target service PID>; Regularly check if the process exists and analyze the process status information in the logs; 1.4 Anomaly Dimension (E) Judgment Rules No abnormality: When there are no abnormal events; Recoverable anomaly: When there is an anomaly but it can be automatically recovered; Unrecoverable anomaly: An anomaly occurs that cannot be automatically recovered; 1.5 Relationships between state dimensions If S = Unregistered, then B is automatically determined to be unreachable, and no behavioral dimension detection is required; If S is partially registered, then the dependencies of the missing components need to be further verified. If B is unreachable and S is fully registered, then a multi-source behavior alternative link is triggered for secondary verification. 1.6 Correlation Analysis of User Perception Dimension (U) User Perception Dimension (U): This represents the statistical results collected by the application process layer and the system window management module, including interface response time, number of interface refresh blocking events, and input event processing delays. It is used to reflect the degree of impact of service anomalies on terminal interaction performance.

[0031] Step 2: Using a multimodal probe system, detection is performed on the structural dimension, behavioral dimension, signal dimension, anomaly dimension and user perception dimension respectively, and the detection results are mapped to the corresponding discrete state values, thereby filling and updating the system service state matrix. In practical implementation, the multimodal probe (MMP) system is as follows: Figure 2 As shown, it specifically includes: 2.1 Structural probe Implementation principle: Verify the integrity of component declarations using XML parsing technology; ROM version compatibility: The list of benchmark components is determined based on the standard configuration of the target service in different ROM versions. The comparison is performed by matching the version number with the corresponding benchmark list (e.g., the component differences between Android 10 and Android 12).

[0032] 2.2 Behavioral Probes Implementation principle: Service call testing is performed through the AIDL interface.

[0033] Test and verification methods: The call simulates a real user behavior sequence. Record the call response time and return code; If the return code is non-zero, further analyze the stack trace to determine the cause of the exception.

[0034] 2.3 Signal Probe Implementation principle: System-level signal acquisition and analysis.

[0035] Interference avoidance methods: Set the priority of system log capture (--priority:verbose); Use process isolation techniques to avoid system interference.

[0036] Step 3: Based on the state values ​​of each dimension already filled in the system service state matrix and their predefined association rules, combined with the real-time environmental status of the mobile terminal and user behavior patterns, dynamically decide the subsequent inspection path and detection priority. In specific implementation, such as Figure 3 As shown in the figure, this disclosure proposes a mobile terminal-specific adaptive inspection path generation method. This method dynamically adjusts the detection path based on the real-time status of the terminal device (such as network type, signal strength, and battery level) and user behavior patterns. Specifically, it includes the following steps: Collect real-time status data of mobile terminals, including network type, signal strength, battery level, and current application usage. Construct a mobile terminal state graph, using network type, signal strength, battery status, etc. as node attributes; Based on historical and real-time data, a path selection model is trained to predict the most likely service interruption points under different conditions. Based on the prediction results, the optimal detection path is dynamically generated, prioritizing the detection of high-risk components; By using a real-time feedback mechanism, the detection path is continuously optimized to improve inspection efficiency.

[0037] Decision-making logic: When the network type is 4G / 5G and the signal strength is below the threshold, network-related components are detected first. When the battery level is below 20%, components related to low power mode are detected first. When user behavior shows frequent app switching, prioritize detecting components related to inter-app interactions; When the user's perception dimension U is "poor", depth detection is performed first.

[0038] State transition rules: If the structure dimension is not registered, then skip the detection of the behavior dimension; If the structural dimension is in a partially registered state, then dependency verification of the missing components will be triggered. If the behavior dimension is in an unreachable state and the structure dimension is in a fully registered state, then a secondary verification based on the backup link is triggered.

[0039] Step 4: Based on the inspection path generated by dynamic decision-making, control the multimodal probe system to perform corresponding detection actions, and generate availability assessment results for the target system service based on the final state of the system service state matrix.

[0040] In specific implementation, such as Figure 4 As shown, the scoring formula for the quantitative scoring system is:

[0041] Among them, the weighting coefficient , , , , The weights are calculated using a dynamic weight allocation algorithm, which is based on a graph neural network model and uses real-time system status and user behavior data to dynamically calculate the weights of each dimension.

[0042] The dynamic weight allocation algorithm includes the following steps: Collect real-time status data of mobile terminals, including network type, signal strength, battery level, and user operation behavior sequence; Construct user behavior graphs and use graph neural network models to analyze the correlation between user behavior and system state; Based on historical and real-time data, the weight coefficients of each dimension are dynamically calculated. The system service status score is recalculated based on the dynamic weighting coefficients.

[0043] The mobile terminal service availability inspection method based on system state matrix provided in this embodiment introduces a dynamic weight allocation mechanism based on graph neural networks. This mechanism dynamically calculates the weights of each dimension based on real-time system status and user behavior, making the scoring more closely reflect actual user experience. It dynamically generates detection paths based on the mobile terminal's network status, battery status, and user behavior patterns, significantly improving inspection efficiency and accuracy. Furthermore, it introduces a user perception dimension, directly linking system monitoring with user experience, making service availability assessment more comprehensive and practical. It can accurately identify complex states such as "false availability," "partial availability," and "internal anomalies but external reachability," greatly reducing the false positive rate and improving user satisfaction.

[0044] The method of this disclosure will be further described below with reference to several specific embodiments: Example 1: Inspection of Google Play services in Android 10 ROM Structural dimension: S = Complete registration (number of matching components 117 / 120, matching degree 97.5%). Behavioral dimension: B = Reachable and responsive (average API call response time 380ms, return code 0); Signal dimension: G = Consistent ("Process started" appears normally in the system log); Anomaly Dimension: E = No anomalies (no abnormal events); Usability score: 0.4×100 + 0.3×100 + 0.2×100 + 0.1×100 = 100; Conclusion: High availability.

[0045] Example 2: Inspection of Google Play services in a custom ROM Structural dimension: S = Partial registration (number of matching components 102 / 120, matching degree 85%). Behavioral dimension: B = Unreachable (Authentication API returns -1, response time 1500ms); Signal dimension: G = Partial inconsistency ("Process killed" appears in the system log); Anomaly Dimension: E = Recoverable Anomaly (Service automatically recovers after an anomaly occurs); Usability score: 0.4×85 + 0.3×60 + 0.2×70 + 0.1×80 = 74; Conclusion: Moderately usable.

[0046] Example 3: Validation of Dynamic Weight Allocation and User Perception Dimension Effects Tests were conducted on 100 mobile terminals of different models, using both the original and improved solutions to perform service availability checks.

[0047] The results are shown in Table 1: Table 1

[0048] GNN model training results: Model training data volume: 10,000 historical inspection logs; Model convergence time: 28 minutes on average (lightweight model on the terminal side). False alarm rate reduction effect: The GNN model reduced the false alarm rate by an average of 57.3%; Conclusion: The improved solution significantly improves the accuracy of service availability inspection and user satisfaction by introducing dynamic weight allocation and user perception dimensions, and shows good adaptability on different system platforms.

[0049] It should be understood that the various parts of this disclosure can be implemented in hardware, software, firmware, or a combination thereof.

[0050] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A mobile terminal service availability inspection method based on system state matrix driven by the system state matrix, characterized in that, include: Step 1: Construct a system service state matrix, wherein the system service state matrix is ​​a multi-dimensional discrete state space used to uniformly represent the state of the target system service in the mobile terminal. The dimensions of the system service state matrix include a structural dimension representing the integrity of service component declarations, a behavioral dimension representing the service call response capability, a signal dimension representing the consistency of system-level signals, an anomaly dimension representing the recoverability of anomalies, and a user perception dimension representing the terminal interaction performance. Step 2: Using a multimodal probe system, detection is performed on the structural dimension, behavioral dimension, signal dimension, anomaly dimension and user perception dimension respectively, and the detection results are mapped to the corresponding discrete state values, thereby filling and updating the system service state matrix. Step 3: Based on the state values ​​of each dimension already filled in the system service state matrix and their predefined association rules, combined with the real-time environmental status of the mobile terminal and user behavior patterns, dynamically decide the subsequent inspection path and detection priority. Step 4: Based on the inspection path generated by dynamic decision-making, control the multimodal probe system to perform corresponding detection actions, and generate availability assessment results for the target system service based on the final state of the system service state matrix.

2. The method according to claim 1, characterized in that, The rules for determining the structural dimension include: Parse the manifest file corresponding to the target system service, extract all declared components and compare them with a preset benchmark component list to calculate the component matching degree; When a critical service component is missing, the system is determined to be in an unregistered state. When a critical service component is complete but the component matching degree is less than the first threshold, it is determined to be in a partial registration state. When the component matching degree is equal to or greater than the first threshold, it is determined to be in a complete registration state.

3. The method according to claim 1, characterized in that, The rules for determining the behavioral dimension include: Initiate calls to the target system service using a set of test cases that simulate real user behavior; Record the response time and return code of the call process; If the response time does not exceed the first preset duration and the call return code indicates success, it is determined to be reachable and in a response state; If the response time is between the first preset time and the second preset time, or if the call return code indicates failure, it is determined to be an unresponsive state. If the response time exceeds the second preset time, or if the call times out or an exception occurs, it is determined to be in an unreachable state.

4. The method according to claim 1, characterized in that, The rules for determining the signal dimension include: Use the default tool to capture lifecycle events related to the target system service process in the system log; If a preset process startup flag appears in the log, it is determined to be in a consistent state; If a preset process abnormal termination flag appears in the log, it is determined to be a partially inconsistent state. If no relevant lifecycle event is captured, it is determined to be an abnormal state.

5. The method according to claim 1, characterized in that, The rules for determining the anomaly dimension include: During the detection process at the signal or behavior level, capture abnormal events related to the target system service; Analyze the types and frequency of abnormal events to determine whether they can be automatically recovered by the system; Based on the judgment results, the state values ​​of the abnormal dimension are mapped to no abnormality, recoverable abnormality, or unrecoverable abnormality.

6. The method according to claim 1, characterized in that, The rules for determining the user perception dimension include: Collect supplementary status data corresponding to the target system service, wherein the supplementary status data includes application interface response time, number of interface refresh blocking events, and input event processing delay; Based on the predefined interval of the statistical analysis results of the supplementary status data, the status is judged as excellent, good, average, or poor.

7. The method according to claim 1, characterized in that, The predefined association rules include: If the structure dimension is not registered, then skip the detection of the behavior dimension; If the structural dimension is in a partially registered state, then dependency verification of the missing components will be triggered. If the behavior dimension is in an unreachable state and the structure dimension is in a fully registered state, then a secondary verification based on the backup link is triggered.

8. The method according to claim 1, characterized in that, The step of dynamically determining subsequent inspection paths and detection priorities by combining the real-time environmental status of the mobile terminal and user behavior patterns includes: Collect data on the mobile terminal's network type and signal strength, battery level, and current application usage. Based on the collected data, predict service interruption risk points, adjust the inspection path accordingly, and prioritize the detection of corresponding components or dimensions according to the adjusted inspection path.

9. The method according to claim 1, characterized in that, The step of generating availability assessment results for the target system service includes: Dynamic weight coefficients are assigned to the state values ​​of each dimension in the system service state matrix. The dynamic weight coefficients are determined by analyzing the real-time state data of the mobile terminal and user operation behavior through a graph neural network model. A quantitative usability score is obtained by weighting the state values ​​of each dimension and their corresponding dynamic weight coefficients.

Images