Mobile application function exception processing method and device, electronic equipment and storage medium

Abstract

The invention discloses a mobile application function exception processing method and device, electronic equipment and a storage medium, and the method comprises the steps: carrying out the parallel monitoring of a system resource state and business behavior data through a buried point probe, generating a structured log with an exception type identifier, and storing the structured log in a local database; when an exception is responded, triggering an associated diagnostor based on an exception type identifier in the log, and analyzing log data through a predefined rule to judge an exception level; and executing the sub-path response according to the grade. According to the method, the problems of slow response and fuzzy positioning of manual operation and maintenance are solved through probe collaborative collection, dynamic grading of the diagnostor and automatic response closed loop, the key anomaly recognition accuracy is improved, and automatic fault diagnosis and user consultation processing are achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of mobile terminal application, and in particular to a mobile application function exception processing method and device, an electronic device and a storage medium. BACKGROUND

[0002] The general process of current mobile application exception processing is that the user actively feeds back the mobile application exception problem, the customer service records and feeds back to the developer, the developer analyzes the log and returns the solution, the developer analyzes the log and processes the exception, but the traditional APM tool only supports post-event statistics and cannot provide a repair solution in combination with the user's real-time context. Moreover, due to the lack of real-time environment sensing capability, the exception caused by the user's network fluctuation, permission loss and insufficient storage space cannot be actively identified by the mobile application. The whole process of mobile application exception processing takes 1-3 days, the user's waiting cost is high, and the success rate of exception feedback processing is not high. This mobile application exception processing process is highly dependent on manual work. SUMMARY

[0003] The embodiments of the present application provide a mobile application function exception processing method and device, an electronic device and a storage medium, which improve the fault resolution rate and shorten the user operation path.

[0004] In a first aspect, the embodiments of the present application provide a mobile application function exception processing method, which includes:

[0005] A mobile application running state is monitored by deploying a buried point probe, and a structured log is generated according to acquired system resource state and business behavior data and stored in a local database; wherein the system resource state is the environmental state data of a terminal device running the mobile application, and the business behavior data is the mobile application function execution process data;

[0006] An exception type identifier in the structured log is analyzed, and a target diagnostic instrument in an exception diagnostic instrument set associated with the exception type identifier is determined; wherein the exception type identifier is generated when the buried point probe detects system resource state and / or business behavior data exception;

[0007] The structured log data is analyzed by the target diagnostic instrument, and an exception level is judged based on a predefined rule; wherein each diagnostic instrument in the exception diagnostic instrument set is pre-associated with a specific exception type;

[0008] A path response is executed according to the exception level.

[0009] In a second aspect, the embodiments of the present application provide a mobile application function exception processing device, which includes:

[0010] An abnormality perception module is configured to monitor a running state of a mobile application by deploying a buried point probe, and generate a structured log according to obtained system resource state and business behavior data; wherein the system resource state is environmental state data of a terminal device running the mobile application, and the business behavior data is mobile application function execution process data;

[0011] A diagnostic device determination module is configured to analyze an abnormality type identifier in the structured log, and trigger a target diagnostic device in a set of abnormality diagnostic devices associated with the abnormality type identifier; wherein the abnormality type identifier is generated when the buried point probe detects abnormality in system resource state and / or business behavior data;

[0012] An abnormality level judgment module is configured to analyze structured log data by the target diagnostic device, and judge an abnormality level based on a predefined rule; wherein each diagnostic device in the set of abnormality diagnostic devices is pre-associated with a specific abnormality type;

[0013] A split-path response execution module is configured to execute a split-path response according to the abnormality level.

[0014] In a third aspect, an electronic device is provided, which includes a memory storing a plurality of instructions, and a processor loading the instructions from the memory to perform steps of any of the mobile application function abnormality processing methods provided in the embodiments of the present application.

[0015] In a fourth aspect, a computer readable storage medium is provided, which stores a plurality of instructions, and the instructions are adapted to be loaded by a processor to perform steps of any of the mobile application function abnormality processing methods provided in the embodiments of the present application.

[0016] In a fifth aspect, a computer program product is provided, which includes a computer program or instructions, and the computer program or instructions are executed by a processor to implement steps of any of the mobile application function abnormality processing methods provided in the embodiments of the present application.

[0017] By adopting the scheme of the embodiments of the present application, differential data collection of low-frequency resource polling collection and high-frequency resource callback listening can be performed through parallel cooperation mechanism of deployed system resource buried point probe and business resource buried point probe, and abnormal events are dynamically classified and determined according to preset rules of a diagnostic device cluster, thereby solving the problems of slow response speed, fuzzy abnormality positioning and single response strategy caused by manual operation in related technologies, achieving full-automatic mobile application abnormality perception and identification, and improving key abnormality identification accuracy, automatic fault diagnosis and user consultation processing. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort based on these drawings.

[0019] Figure 1 is a flow diagram of a mobile application function exception processing method provided in the embodiments of the present application;

[0020] Figure 2 is a flow diagram of a mobile application function exception monitoring and response process provided in the embodiments of the present application;

[0021] Figure 3 is a flow diagram of a mobile application function exception diagnosis and response processing closed loop provided in the embodiments of the present application;

[0022] Figure 4 is a structural diagram of a mobile application function exception processing apparatus provided in the embodiments of the present application;

[0023] Figure 5 is a structural diagram of an electronic device provided in the embodiments of the present application. DETAILED DESCRIPTION

[0024] The technical solutions in the embodiments of the present application will be described clearly and completely with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort fall within the scope of protection of the present application. Meanwhile, in the description of the embodiments of the present application, the terms "first", "second", etc. are only used for differentiation and description, and cannot be understood as indicating or implying relative importance. Therefore, the features with "first" and "second" can explicitly or implicitly include one or more features. In the description of the embodiments of the present application, the meaning of "multiple" is two or more, unless otherwise specifically limited.

[0025] The embodiments of the present application provide a mobile application function exception processing method, apparatus, electronic device and storage medium.

[0026] Specifically, the embodiment will be described from the perspective of a mobile application function exception handling apparatus, which can be integrated in an electronic device, i.e., the mobile application function exception handling method of the embodiment can be executed by an electronic device. Optionally, the electronic device can include a terminal device. The terminal device can be a mobile phone, a tablet computer, a smart Bluetooth device, a notebook computer, a game console, or a personal computer (PC) and the like.

[0027] The mobile application function exception handling method provided by the embodiment can be applied to a mobile application function exception handling system. The mobile application function exception handling system can include a terminal device and a server. The terminal device can be a device including receiving and transmitting hardware, i.e., a device having receiving and transmitting hardware capable of performing bidirectional communication on a bidirectional communication link. The terminal device and the server can perform bidirectional communication through a network.

[0028] Optionally, the server can be a stand-alone server, or a server network or server cluster composed of servers, including but not limited to a computer, a network host, a single network server, a plurality of network server sets, or a cloud server composed of a plurality of servers. The cloud server is composed of a large number of computers or network servers based on cloud computing.

[0029] The following will be described in detail with reference to the accompanying drawings. In the embodiment, the execution subject is taken as an example of a terminal device. It should be noted that the order of the following embodiments is not limited as the preferred order of the embodiments. Although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown in the accompanying drawings.

[0030] The mobile application function exception handling method of the embodiment can use polling and callback dual-mode cooperative collection through the differentiated monitoring strategy of the buried point probe. The business behavior is triggered at the key node event. The trend is positioned in combination with the whole cycle basic log. The fault point is accurately marked by the exception identification log. The event and the log identification are synchronously driven when the exception occurs. The diagnostic cluster quickly associates and analyzes the historical log data according to the identification. Finally, the dynamic response is triggered by the regularized hierarchical rules of the numerical threshold and the frequency statistics. The accuracy of the exception identification is ensured, and the closed-loop control effect of monitoring-diagnosis-response is formed.

[0031] Please refer to Figure 1 The specific process of the mobile application function exception handling method can include the following steps 101 to 104, wherein:

[0032] Step 101, monitor the running state of the mobile application by deploying a buried probe, and generate structured logs according to the obtained system resource state and business behavior data.

[0033] The system resource state is the environment state data of the mobile application terminal device, and the business behavior data is the mobile application function execution process data.

[0034] Optionally, the environment state data includes at least one of network signal strength, storage space, hardware resource usage, battery state, network connection state, and Bluetooth connection state of the terminal device.

[0035] Optionally, the function execution process data includes audio / video playback state, file download state, and page loading state.

[0036] The audio / video playback state records abnormal states of audio / video playback, such as playback failure, resource acquisition failure leading to failure to play, etc.

[0037] The file download state records abnormal states of file download, such as file resource loss, insufficient storage space leading to failure to download, no storage permission leading to failure to download, etc.

[0038] The page loading state records abnormal states of page opening, such as no network leading to page opening failure, page resource error leading to page white screen, etc.

[0039] During the use of the mobile application by the user, if an exception is encountered, the exception information in the use process of the mobile application will be captured through step 101, and the corresponding exception log output value will be saved in the database. The exception information includes common system exception information and business-specific exception information.

[0040] In some embodiments of the present application, the running state of the mobile application is monitored in real time by deploying a buried probe, structured logs are generated according to the obtained system resource state and business behavior data, and are stored in a local database, including:

[0041] The system resource buried probe collects the system running environment state data of the terminal device in real time;

[0042] The business resource buried probe passively listens to key nodes in the business function execution process, and collects abnormal related business function execution data when an exception is detected;

[0043] The system running environment state data and the abnormal related business function execution data are encapsulated as structured logs and stored in the local database.

[0044] It should be noted that the system resource burying point probe and the business resource burying point probe are both pre-buried in the mobile application code. When the mobile application is started, the system resource burying point probe immediately starts to work and monitors the system resource state. The business resource burying point probe is deployed at the key node of the business function, but does not continuously monitor the entire execution process, and is triggered to monitor and collect data on the business resource only when an exception occurs in the business function.

[0045] The exception detection mechanism of the business resource burying point probe is based on the active monitoring of the pre-buried code on the business execution node, and the process is completely event-driven. The developer pre-buries the probe at the core code position of the mobile application business function, including the audio and video playing logic (such as checking the video decoding state), the file download process (such as monitoring the transmission interruption), the page loading module (such as detecting the rendering time), and other key nodes. The probe is embedded in these business functions, but by default, it is in a "sleep state" and does not actively consume resources. During the execution process of the business function, the probe monitors the return value, error code, execution time or other predetermined conditions in real time. When the probe detects a state that violates the preset rules, it immediately triggers the monitoring. For example, in audio and video playing, the probe checks the playing state code: if an error code (such as 404 playing failure) or the buffering time exceeds the set threshold (such as continuous stuttering for more than 5 seconds), it is determined as an abnormal event and the probe is triggered. Each probe is bound to a unique exception rule library of the business, such as the audio and video playing error code mapping (such as 404 = "video resource does not exist"). The probe compares the execution state with these rules in real time, and confirms the exception when a match fails.

[0046] In some embodiments of the present application, the system resource burying point probe is used to collect the system running environment state data of the terminal device in real time, including:

[0047] The system resource burying point probe is used to synchronously execute the timing polling of the polling type system resource and the real-time response to the callback type system resource change, so as to obtain the system running environment state data of the terminal device.

[0048] Specifically, the system resource burying point probe is used to execute the timing polling of the polling type system resource, so as to obtain the system running environment state data of the terminal device, including:

[0049] The system resource burying point probe is used to set a timing polling task for the polling type system resource, and collect the state of the polling type system resource at a predetermined time interval;

[0050] In the case where the polling task detects that the polling type system resource exceeds the system threshold, the data burying is triggered.

[0051] For example, when the polling task detects that the storage is ≤100 MB or the CPU is ≥80%, the data burying is triggered; otherwise, the data is discarded.

[0052] The polling-type system resources include resource types that need to be actively detected. Optionally, the polling-type system resources include at least one of network detection, storage monitoring, permission verification, and CPU / memory changes.

[0053] Network detection, recording parameters such as signal strength (dBm), delay (ms), and jitter;

[0054] Storage monitoring: real-time tracking of available storage space, triggering an alert when the remaining capacity falls below a preset threshold (e.g., 100MB);

[0055] Permission verification, dynamically detecting the enabled status of sensitive permissions such as camera, microphone, and location;

[0056] CPU / memory changes, regularly obtain overall usage, and trigger an alert when the overall usage exceeds the threshold percentage.

[0057] Specifically, the system resource tracking probe performs real-time response callback-type system resource changes to obtain the system operating environment status data of the terminal device, including:

[0058] Register system callback events through system resource tracking probes to respond to status changes of callback-type system resources in real time;

[0059] When the system callback notifies the callback-type system resource of a status change, the data tracking point is triggered.

[0060] The callback-type system resource includes a resource type that supports system event notification. Optionally, the callback-type system resource includes at least one of a network connection status, a Bluetooth connection status, and a battery status.

[0061] Network connection status, recording 5G / WiFi mode, VPN opening status, and proxy status;

[0062] Bluetooth connection status, record Bluetooth connection status, single device / multi-device connection;

[0063] Battery status, recording charging status, battery health status (good / overheated / damaged).

[0064] Please also see Figure 2 , Figure 2 : is a flow chart of abnormal monitoring and response of mobile application functions provided in the embodiment of the present application, such as Figure 2As shown, two parallel monitoring paths are initialized simultaneously when the mobile application starts: the system resource path executes: after injecting system resource probe, it operates in two ways: (1) start a timed polling collection on storage space size, network signal strength, CPU memory usage; (2) inject system callback monitoring on network connection state, Bluetooth connection state, battery state; after frequency control filtering (such as CPU ≥ 80% then pass), trigger system resource data probe. The business resource path executes: inject business probe in audio and video playback, file download, page opening module, real-time monitor function execution state, after frequency control filtering (such as 10 seconds of playback failure ≥ 3 times), trigger corresponding business processing. The data stream generated by the two paths is uniformly processed in the standardized data packaging link, and finally the log cache is performed. This process improves the technical effect of key exception capture through system polling and callback / business node monitoring.

[0065] In some embodiments of the present application, the collected system running environment state data and exception related business function execution data are packaged as structured logs and stored in a local database, including:

[0066] The collected system running environment state data and exception related business function execution data are packaged as structured data in a unified format;

[0067] The structured data is stored in the local database with the exception type identifier as the main classification basis.

[0068] The exception type identifier is a predefined exception label associated with the mobile application business function module.

[0069] Optionally, the business function module includes at least one of network communication, multimedia playback, and file storage. The exception type identifier includes at least one of network exception, song cutting, storage space, and playback exception.

[0070] Specifically, the packaged structured data is stored in an SQLite database with the type field as the main index field.

[0071] System resource events and business exception events share the same data table, and are distinguished by the type field.

[0072] The structured data format is JSON format data.

[0073] Specifically, the JSON structure includes fixed fields:

[0074] type: mark the exception category (such as "play pause");

[0075] content: event description (such as "play exception caused by resource file loss");

[0076] logTime: timestamp (format: yyyy-MM-dd HH:mm:ss);

[0077] extInfo: extended information (e.g., "play type");

[0078] uniqueId: unique identifier (device ID + random number);

[0079] After the deployment of the point-in-time probe, when the corresponding behavior event occurs, the point-in-time probe prepares to output data, and these data are unified and standardized parameter encapsulation is provided.

[0080] Step 102, analyzing the abnormal type identifier in the structured log to determine a target diagnostic in the abnormal diagnostic set associated with the abnormal type identifier;

[0081] The abnormal type identifier is generated when the point-in-time probe detects system resource state and / or business behavior data abnormality.

[0082] In some embodiments of the present application, each diagnostic in the abnormal diagnostic set is pre-associated with a specific abnormal type.

[0083] In some embodiments of the present application, the step of generating an abnormal type identifier includes:

[0084] In the case where the system resource point-in-time probe detects that the resource state data exceeds the preset system abnormal trigger threshold, the identifier is set as a predefined system resource abnormal type;

[0085] In the case where the business resource point-in-time probe detects that the number of execution failures per unit time at a business critical node reaches the preset business abnormal trigger frequency threshold, the identifier is set as a predefined business function abnormal type.

[0086] Step 103, analyzing the structured log data through the target diagnostic and determining the abnormal level based on a predefined rule.

[0087] In some embodiments of the present application, analyzing the abnormal type identifier in the structured log to determine a target diagnostic in the abnormal diagnostic set associated with the abnormal type identifier includes:

[0088] In the case where the structured log contains multiple abnormal type identifiers, multiple corresponding target diagnostics are triggered in parallel according to the corresponding multiple abnormal type identifiers;

[0089] Analyzing the structured log data through the target diagnostic and determining the abnormal level based on a predefined rule includes:

[0090] Each target diagnostic analyzes the structured log data independently, and determines the abnormal level of the abnormal event based on predefined rules.

[0091] Optionally, the set of abnormality diagnosers includes at least one of a network diagnostic, a song switching diagnostic, a storage diagnostic, and a playing diagnostic.

[0092] The network diagnostic is configured to handle signal delay abnormality.

[0093] The song switching diagnostic is configured to handle song switching timeout.

[0094] The storage diagnostic is configured to monitor storage space.

[0095] The playing diagnostic is configured to analyze video buffer abnormality.

[0096] For example, when the storage space is detected to be less than or equal to 50 MB, the abnormal type identifier is “storage space”, and the storage diagnostic is triggered. When the buffer rate is detected to be less than or equal to 100 KB / s (playing abnormality) and the signal strength is detected to be less than or equal to -90 dBm (network abnormality), the abnormal type identifier is [“playing abnormality”, “network abnormality”], and the playing diagnostic and the network diagnostic are triggered in parallel.

[0097] In some embodiments of the present application, the step of analyzing the structured log data by the target diagnostic includes:

[0098] querying the structured log matching the current abnormal type identifier from the local database by executing the query instruction by the target diagnostic;

[0099] parsing the abnormal type identifier in the obtained structured log.

[0100] In some embodiments of the present application, when the abnormal type identifier is a system resource abnormality, determining the abnormal level based on predefined rules includes:

[0101] comparing the numerical field extracted from the structured log with a preset first system threshold and a second system threshold;

[0102] when the numerical value is not greater than the first system threshold, determining the abnormal level as a high level;

[0103] when the numerical value is greater than the first system threshold and not greater than the preset second system threshold, determining the abnormal level as a low level;

[0104] wherein the first system threshold is higher than the second system threshold.

[0105] Specifically, in the system resource abnormality level determination, the numerical field of the structured log is compared with the preset first and second system threshold values, and the numerical characteristics of different resource types are processed differently. For positive indicators (such as CPU usage, memory occupancy, and the like, the greater the numerical value, the higher the abnormality degree), the first system threshold value (high-level trigger line) is set to be higher than the second system threshold value (low-level trigger line). When the numerical value in the log is not less than the first system threshold value, it is determined to be a high-level abnormality (for example, CPU ≥ 80%). When the numerical value is greater than the second system threshold value but less than the first system threshold value, it is determined to be a low-level abnormality (for example, 60% < CPU < 80%). For negative indicators (such as storage remaining space, network signal strength, and the like, the smaller the numerical value, the higher the abnormality degree), the first system threshold value (high-level trigger line) is set to be lower than the second system threshold value (low-level trigger line). When the numerical value in the log is not greater than the first system threshold value, it is determined to be a high-level abnormality (for example, storage space ≤ 50 MB). When the numerical value is greater than the first system threshold value but not more than the second system threshold value, it is determined to be a low-level abnormality (for example, 50 MB < storage ≤ 200 MB). This double-threshold dynamic matching mechanism not only guarantees the real-time response of key abnormalities (through the strict first threshold value), but also realizes the record coverage of potential risks (through the relatively loose second threshold value). At the same time, through the automatic adaptation of the threshold value direction and the resource characteristics (≥ relationship for positive indicators and ≤ relationship for negative indicators), the misjudgment problem in system resource monitoring is solved.

[0106] In some embodiments of the present application, in the case of a service function abnormality, the abnormality level is determined based on a predefined rule, including:

[0107] The execution failure frequency in a unit time is counted based on the timestamp field of the structured log, and compared with a preset first service frequency threshold value and a second service frequency threshold value;

[0108] In the case where the failure frequency is not less than the first service frequency threshold value, the abnormality level is determined to be high;

[0109] In the case where the failure frequency is less than the first service frequency threshold value and not less than the second service frequency threshold value, the abnormality level is determined to be low;

[0110] Wherein, the first service frequency threshold value is greater than the second service frequency threshold value.

[0111] In the business function exception level determination, the level division is realized through the comparison mechanism of the execution failure frequency in unit time and the first and second frequency threshold values. The first business frequency threshold value (high level trigger line) is greater than the second business frequency threshold value (low level trigger line), forming a cascade response strategy. Specifically, the system will accurately calculate the number of abnormal event occurrences in a unit time window (such as the number of audio loading failures in 5 minutes) based on the timestamp field in the structured log. When the statistical value is not less than the first business frequency threshold value (such as 8 times / 5 minutes), it is determined as a high-level exception (which needs to pop up an alarm immediately). When the frequency is less than the first threshold value but not less than the second business frequency threshold value (such as 5 times / 5 minutes), it is determined as a low-level exception (only silent recording). Based on the continuity feature of business failure, the higher the frequency, the stronger the fault persistence, and the response priority needs to be improved accordingly. The second business frequency threshold value (low level line) needs to be higher than the upper limit of the normal failure rate of the business scenario. For example, in the audio and video playing scenario, the average 2 times / minute of playing failure under normal network fluctuation belongs to the acceptable range. At this time, the second threshold value is set to 3 times / minute (i.e. > normal fluctuation upper limit) to avoid excessive warning. The first business frequency threshold value (high level line) corresponds to the critical state of business function unavailability. For example, in the live scenario, if there are 3 consecutive playing failures within 10 seconds, it will lead to user loss, so the first threshold value is set to 18 times / minute (equivalent to 3 times every 10 seconds). The time unit (5 minutes / 1 minute, etc.) needs to be bound with the business characteristics. High-frequency business (such as Bluetooth song cutting) adopts a short window (10 seconds unit) to avoid the dilution of instantaneous failure by long period; low-frequency business (such as file download) adopts a long window (5 minutes unit) to prevent accidental exception from triggering. Through the comparison mechanism of the execution failure frequency in unit time and the first and second frequency threshold values, the level division is realized, which overcomes the randomness defect of single failure determination (such as user manual pause misjudged as playing failure), and captures system-level failure (such as continuous decoding failure) through time window frequency statistics.

[0112] It should be noted that each diagnostic performs a dedicated database query instruction, and through the database query instruction, logs matching the current exception type identifier within a predetermined time period are filtered from the database (such as the playing diagnostic only querying playing related records), and whether the query result reaches the preset threshold value (such as the video buffering rate ≤ 100 KB / s) is analyzed.

[0113] Specifically, the diagnostic executes a database query instruction (such as SQL SELECT) to extract related logs from the SQLite database, including:

[0114] Time range: a predetermined time period (such as 1 hour before the failure occurs);

[0115] Log type: the type field matches the diagnostic type (such as the playing diagnostic only queries "VIDEO_BUFFERING" type logs)

[0116] Additional condition: Filter by business ID / device ID (e.g., videoId = "xYz123").

[0117] Exemplarily, when the system resource burying probe reads that the network connection state changes from a WiFi signal strength of -80 dBm to -100 dBm, the system resource data burying is triggered, and an abnormal log is generated through data encapsulation. Then, the abnormal log is analyzed to obtain the abnormal behavior of the business as the network connection state, and the network diagnostic activator is triggered to activate. The network diagnostic activator queries similar logs in the past 1 hour, and the WiFi signal strength recorded in the log value is continuously -100 dBm, which is less than the system threshold -90 dBm. Therefore, the network diagnostic activator determines that the network connection state abnormal event is a high-level abnormal event.

[0118] Exemplarily, the predetermined time period is 1 hour, and the predetermined time period can be dynamically adjusted. The number of abnormal occurrences in 1 hour is counted, for example, the number of switching timeouts of the song switching diagnostic activator in 1 hour is greater than 5 times, and it is determined that the abnormal behavior of the song switching diagnostic activator is a high-level abnormal event.

[0119] Step 104, performing a path response according to the abnormal level.

[0120] In some embodiments of the present application, the path response according to the abnormal level includes:

[0121] generating a real-time pop-up solution prompt information for a high-level abnormal event; wherein the real-time pop-up solution prompt information contains an abnormal reason explanation;

[0122] generating a silent diagnosis record for a low-level abnormal event and storing it in a local database; wherein the silent diagnosis record is a keyword indexed log.

[0123] In some embodiments of the present application, the real-time pop-up solution prompt information contains an abnormal reason explanation and an interactive component.

[0124] Exemplarily, the real-time pop-up solution contains an abnormal reason explanation, and the content specification is: containing an abnormal reason explanation, an operable suggestion (generated based on the diagnosis result), and an interactive component embedded function button (such as "switch network" and "retry playing").

[0125] Exemplarily, the field format of the silent diagnosis record is: [abnormal type] [timestamp] [key parameter], for example, [network abnormality] [2025-03-20 10:23:45] [type: WiFi, strength: -85 dBm].

[0126] It should be noted that each diagnostic activator sets a corresponding preset threshold for differential response, exemplarily:

[0127] Differentiated response threshold rules for network diagnostic:

[0128] Signal strength trigger pop-up strong reminder condition: When WiFi signal strength ≤ -90 dBm or cellular signal strength ≤ -105 dBm is detected, a pop-up window will prompt "Network is severely unstable, functions may be interrupted!" and provide "Switch network" and "Close agent" operation buttons.

[0129] Signal strength silent recording condition: When WiFi signal strength ≤ -80 dBm or cellular signal strength ≤ -95 dBm is detected, a silent record is made in the format of [network exception] [timestamp] [network type] [signal strength value] log, with the index keyword "network exception".

[0130] Network delay trigger pop-up strong reminder condition: When the PING delay is ≥ 300 ms for 5 consecutive times, a pop-up window will prompt "Network is severely unstable, functions may be interrupted!" and provide "Switch network" and "Close agent" buttons.

[0131] Network delay silent recording condition: When the PING delay is ≥ 200 ms for 5 consecutive times, a silent record is made in the format of [timestamp] [network type] [delay value] log, with the index keyword "network exception".

[0132] Differentiated response threshold rules for song switching diagnostic:

[0133] Switch response slow pop-up condition: When the song switching response time is ≥ 1500 ms, a pop-up window will prompt "Unable to access song resources, please check the network", and provide "Retry / Skip" buttons.

[0134] Switch response slow silent condition: When the song switching response time is ≥ 800 ms, a silent record is made in the format of [timestamp] [song name] [problem description] log, with the index keyword "song switching".

[0135] Resource loading failure pop-up condition: When audio file loading failure is ≥ 5 times per minute, a pop-up window will prompt "Unable to access song resources, please check the network", and provide "Retry / Skip" buttons.

[0136] Resource loading failure silent condition: When audio file loading failure is ≥ 1 time per minute, a silent record is made in the format of [timestamp] [song name] [problem description] log, with the index keyword "song switching".

[0137] Bluetooth song switching exception pop-up condition: When the same Bluetooth song switching instruction is received for ≥ 5 times in the same time interval, a pop-up window will prompt "Bluetooth peripheral exception, please check the Bluetooth device", and provide "Go to settings / Cancel" buttons.

[0138] Bluetooth song switching abnormal silence condition: when the same instruction is received continuously for more than 3 times in the same time interval, record the silence log [timestamp] [song name] [abnormal Bluetooth device name] [problem description] with the index word "song switching".

[0139] Differentiated response threshold rule of storage space diagnostic tool:

[0140] Storage alert pop-up condition: when the system storage space is less than or equal to 50 MB, pop up a window to prompt "The storage space is about to run out!" and provide a "Go to clean up / cancel" button.

[0141] Storage alert silence condition: when the system storage space is less than or equal to 200 MB, generate a storage space usage report with the index keyword "storage space".

[0142] Differentiated response threshold rule of play diagnostic tool:

[0143] Buffer rate pop-up condition: when the average video buffer rate is less than or equal to 100 KB / s, pop up a window to prompt "Video is severely lagging, suggest reducing quality" and provide an "Immediately switch" button.

[0144] Buffer rate silence condition: when the average video buffer rate is less than or equal to 200 KB / s, record the [timestamp] [video name] [playback rate] [problem description] log with the index word "playback abnormality".

[0145] Audio-visual offset pop-up condition: when the audio-visual timestamp offset is greater than or equal to 500 ms, pop up a window to prompt "Audio-visual synchronization is severely out of sync, suggest adjusting settings" and provide an "Immediately repair" button.

[0146] Audio-visual offset silence condition: when the timestamp offset is greater than or equal to 200 ms, record the [timestamp] [video name] [offset] [problem description] log with the index word "playback abnormality".

[0147] In some embodiments of the present application, after performing a path-specific response according to the abnormality level, the method further comprises:

[0148] Generating an abnormality handling log according to the business abnormality analysis and business abnormality handling data and saving it to a local database.

[0149] The abnormality handling log is used for database matching when the user consults.

[0150] Exemplarily, the data format of the abnormality handling log is as follows:

[0151] "keywords":"Playback exception (save different matching keywords according to the visual business)", "content":"Due to poor network signal and network delay of more than 100ms, you may encounter slow playback / stuck playback problems. You can try switching networks to solve this problem", "logTime":"xxxx", "extInfo":"Playback Type", "uniqueId":"xxxx"}

[0152] In some embodiments of the present application, the method further comprises:

[0153] In response to a user's consultation request, the system matches pre-stored silent diagnosis records based on the consultation request text and outputs a corresponding solution.

[0154] In some embodiments of the present application, outputting a corresponding solution based on matching the consultation request text with a pre-stored silent diagnosis record includes:

[0155] In response to a user consultation request, extracting consultation request text keywords;

[0156] Through semantic mapping, records matching keywords are filtered from pre-stored silent diagnosis records, and corresponding solutions are output.

[0157] Specifically, the system parses user inquiry request text (e.g., "The video is always stuck") and extracts keywords ("video," "stuck"). Through semantic mapping, it accurately matches keywords from pre-existing silent diagnostic records. Keywords are directly connected to silent log index fields (e.g., "stuck" maps to "playback exception" logs). It can also expand synonyms (e.g., "slow loading" is associated with "low buffering rate" logs) for fuzzy matching. Matching records are filtered from the exception handling log, and the solution text for the corresponding content field is returned (e.g., "Excessive network latency detected, recommending switching networks or reducing image quality").

[0158] Please also see Figure 3 , Figure 3 1 is a flow chart of a closed loop of mobile application function abnormality diagnosis and response processing provided in the embodiment of the present application. Figure 3As shown, the user triggers two parallel data streams during the use of the mobile application, that is, the normal runtime key system log is continuously stored in the local database (corresponding to the periodic collection of the system resource probe), and when an exception is encountered during use, the exception awareness module is triggered to generate an exception log for synchronous storage (fault capture of the business resource probe); At this time, the diagnostic cluster module responds immediately: a specific diagnostic tool performs type identification based on the exception type identifier (such as PLAY_FAILURE) in the log, and generates a treatment strategy according to the preset rules (treatment strategy differentiation path: for high-level exceptions, generate an instant pop-up reminder, if the user confirms to repair, perform protocol jump (such as switching network / cleaning storage); For low-level exceptions, generate a silent record and store it in the database). When the user subsequently enters the customer service page, the dynamic matching engine response module starts: based on the user consultation text, extract the keywords (such as "play lag"), match the historical exception log (such as the buffer rate insufficient record) in the silent record database, and through the data mapping engine, convert the technical parameters into natural language solutions (such as "detecting that your current network delay > 100ms, suggest switching to 5G network"), and finally display the exclusive diagnostic results on the interface to complete the problem solving closed loop. The process improves the fault solving rate and shortens the user operation path through the double coupling of the diagnostic decision tree (pop-up instant intervention / silent data sedimentation) and the natural language processing engine (keyword→technical parameter→solution).

[0159] In the embodiments of the present application, by deploying the parallel cooperation mechanism of system resource and business resource buried point probes, differential data collection is performed through low-frequency resource polling collection and high-frequency resource callback monitoring, and the preset rules of the diagnostic cluster are combined to dynamically grade and determine abnormal events, thereby solving the problems of slow response speed, ambiguous abnormal positioning, and single response strategy caused by manual operation in related technologies, realizing full-automatic mobile application exception awareness and identification, and improving the accuracy of key exception identification and automatic fault diagnosis and user consultation processing.

[0160] The embodiments also provide a mobile application function exception processing apparatus, which can be integrated in a terminal device. For example, as shown in the figure, the mobile application function exception processing apparatus 400 can include: Figure 4

[0161] The exception awareness module 401 is configured to monitor the running state of the mobile application by deploying the buried point probe, and generate structured logs according to the obtained system resource state and business behavior data; wherein the system resource state is the environmental state data of the terminal device running the mobile application, and the business behavior data is the mobile application function execution process data.

[0162] ​The diagnostic apparatus determination module 402 is configured to analyze an exception type identifier in the structured log, and determine a target diagnostic apparatus in a set of diagnostic apparatuses associated with the exception type identifier; wherein the exception type identifier is generated by a buried point probe when detecting an abnormality in system resource state and / or business behavior data;

[0163] The exception level judgment module 403 is configured to analyze the structured log data by the target diagnostic apparatus, and judge an exception level based on a predefined rule; wherein each diagnostic apparatus in the set of diagnostic apparatuses is pre-associated with a specific exception type.

[0164] The path response execution module 404 is configured to execute a path response according to the exception level.

[0165] In some embodiments of the present application, the exception awareness module 401 is further configured to:

[0166] Collecting system running environment state data of a terminal device in real time through a system resource buried point probe;

[0167] Passively monitoring a key node in a business function execution process through a business resource buried point probe, and collecting exception-related business function execution data when detecting an exception;

[0168] Encapsulating the collected system running environment state data and exception-related business function execution data as structured logs, and storing the structured logs to a local database.

[0169] In some embodiments of the present application, the exception awareness module 401 is further configured to:

[0170] Encapsulating the collected system running environment state data and exception-related business function execution data as structured data in the same format;

[0171] Storing the structured data to the local database as a main classification basis.

[0172] In some embodiments of the present application, the exception awareness module 401 is further configured to:

[0173] Setting an identifier as a predefined system resource exception type when the system resource buried point probe detects that the resource state data exceeds a preset system exception triggering threshold;

[0174] Setting an identifier as a predefined business function exception type when the business resource buried point probe detects that the number of execution failures in a unit of time at a business key node reaches a preset business exception triggering frequency threshold.

[0175] In some embodiments of the present application, the diagnostic apparatus determination module 402 is further configured to:

[0176] In a case where the structured log comprises a plurality of abnormal type identifiers, a plurality of corresponding target diagnosers are triggered in parallel according to the plurality of corresponding abnormal type identifiers;

[0177] The abnormal level judging module 403 is further configured to independently analyze the structured log data by each target diagnoser, and judge the abnormal level of the abnormal event based on a predefined rule.

[0178] In some embodiments of the present application, the diagnoser determining module 402 is further configured to:

[0179] execute the query instruction by the target diagnoser to query the structured log matching the current abnormal type identifier from the local database;

[0180] parse the abnormal type identifier in the obtained structured log.

[0181] In some embodiments of the present application, in a case where the abnormal type identifier is a system resource abnormality, the abnormal level judging module 403 is further configured to:

[0182] compare the numerical field extracted from the structured log with a preset first system threshold and a second system threshold;

[0183] determine the abnormal level as a high level in a case where the numerical value is not greater than the first system threshold;

[0184] determine the abnormal level as a low level in a case where the numerical value is greater than the first system threshold and not greater than a preset second system threshold;

[0185] wherein the first system threshold is higher than the second system threshold.

[0186] In some embodiments of the present application, in a case where the abnormal event is a business function abnormality, the abnormal level judging module 403 is further configured to:

[0187] compare the failure frequency in a unit time based on the timestamp field of the structured log with a preset first business frequency threshold and a second business frequency threshold;

[0188] determine the abnormal level as a high level in a case where the failure frequency is not less than the first business frequency threshold;

[0189] determine the abnormal level as a low level in a case where the failure frequency is less than the first business frequency threshold and not less than the second business frequency threshold;

[0190] wherein the first business frequency threshold is greater than the second business frequency threshold.

[0191] In some embodiments of the present application, the path-specific response executing module 404 is further configured to:

[0192] generating a real-time pop-up solution prompt information for a high-level exception; wherein the prompt information contains an exception cause explanation;

[0193] generating a silent diagnosis record for a low-level exception and storing the record in a local database; wherein the silent diagnosis record is a keyword-indexed log.

[0194] In some embodiments of the present application, the sub-path response execution module 404 is further configured to:

[0195] In response to a user consultation request, matching the silent diagnosis record based on the consultation request text, and outputting the corresponding solution.

[0196] In some embodiments of the present application, the sub-path response execution module 404 is further configured to:

[0197] In response to a user consultation request, extracting the consultation request text keywords;

[0198] Through semantic mapping, filtering the records matching the keywords from the pre-stored silent diagnosis records, and outputting the corresponding solution.

[0199] In some embodiments of the present application, the exception awareness module 401 is further configured to:

[0200] Through the system resource burying probe, synchronously performing the timed polling of the polling-type system resources and the real-time response to the callback-type system resource changes, obtaining the system running environment state data of the terminal device.

[0201] In some embodiments of the present application, the exception awareness module 401 is further configured to:

[0202] Through the system resource burying probe, setting a timed polling task for the polling-type system resources, and collecting the polling-type system resource states at predetermined time intervals;

[0203] In the case where the polling task detects that the polling-type system resources exceed the system threshold, triggering data burying;

[0204] The polling-type system resources include resource types that need to be actively probed.

[0205] In some embodiments of the present application, the exception awareness module 401 is further configured to:

[0206] Through the system resource burying probe, registering a system callback event, and responding to the state changes of the callback-type system resources in real time;

[0207] When the system callback notifies that the callback-type system resources have state changes, triggering data burying;

[0208] The callback-type system resources include resource types that support system event notifications.

[0209] Accordingly, an embodiment of the present application further provides an electronic device, which may be a terminal, such as a smartphone, a tablet computer, a laptop computer, a touch screen, a game console, a personal computer (PC), a personal digital assistant (PDA), or the like. Alternatively, the electronic device may be a server.

[0210] like Figure 5 As shown, Figure 5 Schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device 500 includes a processor 501 having one or more processing cores, a memory 502 having one or more computer-readable storage media, and a computer program stored in the memory 502 and executable on the processor. The processor 501 is electrically connected to the memory 502. It will be understood by those skilled in the art that the electronic device structure shown in the figure does not constitute a limitation of the electronic device, and may include more or fewer components than shown, or combine certain components, or arrange the components differently.

[0211] The processor 501 is the control center of the electronic device 500. It connects the various parts of the entire electronic device 500 using various interfaces and lines. By running or loading software programs and / or units stored in the memory 502 and calling data stored in the memory 502, it executes various functions of the electronic device 500 and processes data, thereby monitoring the entire electronic device 500. The processor 501 can be a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), etc., and can implement or execute the various methods, steps, and logic blocks disclosed in the embodiments of this application.

[0212] In the embodiment of the present application, the processor 501 in the electronic device 500 loads instructions corresponding to one or more application processes into the memory 502 according to the following steps, and the processor 501 runs the application stored in the memory 502 to implement various functions, such as:

[0213] Monitor the running status of mobile applications by deploying tracking probes, and generate structured logs based on the acquired system resource status and business behavior data; wherein the system resource status is the environmental status data of the terminal device running the mobile application, and the business behavior data is the mobile application function execution process data;

[0214] Analyze the exception type identifier in the structured log, determine a target diagnostic in a set of exception diagnostics associated with the exception type identifier; wherein the exception type identifier is generated by a buried point probe when detecting system resource state and / or business behavior data exception;

[0215] Analyze the structured log data through the target diagnostic, and determine an exception level based on a predefined rule; wherein each diagnostic in the set of exception diagnostics is pre-associated with a specific exception type;

[0216] Perform a path response according to the exception level.

[0217] In the embodiments of the present application, through the differential monitoring strategy of the buried point probe, the polling and callback dual-mode are cooperatively collected, the business behavior is triggered at the key node event, the trend is positioned in combination with the whole cycle basic log, the fault point is accurately marked in combination with the exception identification log, and the event and the log identification are synchronously driven when the exception occurs, the diagnostic cluster is quickly associated with the historical log data according to the identification, and finally the dynamic response is triggered through the rule-based grading of the numerical threshold and the frequency statistics, so as to guarantee the accuracy of the exception identification and form the closed-loop control effect of monitoring-diagnosis-response.

[0218] The specific implementation of each operation can be referred to the foregoing embodiments, which will not be described here.

[0219] Optionally, as shown in Figure 5 The electronic device 500 further includes a touch display screen 503, a radio frequency circuit 504, an audio circuit 505, an input unit 506, and a power supply 507. The processor 501 is electrically connected with the touch display screen 503, the radio frequency circuit 504, the audio circuit 505, the input unit 506, and the power supply 507, respectively. Those skilled in the art can understand that the electronic device structure shown in the Figure 5 The electronic device structure shown in the

[0220] The touch display screen 503 can be used to display a graphical user interface and receive operation instructions generated by user acting on the graphical user interface. The touch display screen 503 can include a display panel and a touch panel. The display panel can be used to display information input by the user or provided to the user and various graphical user interfaces of the electronic device, which can be composed of graphics, text, icons, videos and any combination thereof. Optionally, the display panel can be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. The touch panel can be used to collect touch operations (such as operations of the user using a finger, a stylus or any suitable object or accessory on or near the touch panel) of the user on or near it and generate corresponding operation instructions, and the operation instructions execute corresponding programs. Optionally, the touch panel can include two parts of a touch detection device and a touch controller. The touch detection device detects the touch position of the user and detects the signals brought by the touch operation and transmits the signals to the touch controller; the touch controller receives the touch information from the touch detection device and converts it into touch coordinates and sends it to the processor 501, and can also receive commands from the processor 501 and execute them. The touch panel can cover the display panel, and when the touch panel detects a touch operation on or near it, it transmits to the processor 501 to determine the type of the touch event, and then the processor 501 provides corresponding visual output on the display panel according to the type of the touch event. In the embodiments of the present application, the touch panel and the display panel can be integrated into the touch display screen 503 to realize the input and output functions. However, in some embodiments, the touch panel and the touch panel can realize the input and output functions as two independent components. That is, the touch display screen 503 can also realize the input function as part of the input unit 506.

[0221] The radio frequency circuit 504 can be used to transceive radio frequency signals to establish wireless communication with network devices or other electronic devices.

[0222] The audio circuit 505 can be used to provide an audio interface between the user and the electronic device through the speaker and the microphone. The audio circuit 505 can convert the received audio data into an electrical signal and transmit it to the speaker, which converts it into a sound signal output; on the other hand, the microphone collects the sound signal and converts it into an electrical signal, which is received by the audio circuit 505 and converted into audio data, and then the audio data is output to the processor 501 for processing, and then transmitted to another electronic device through the radio frequency circuit 504, or output to the memory 502 for further processing. The audio circuit 505 can also include an earphone jack to provide communication between the external earphone and the electronic device.

[0223] The input unit 506 can be configured to receive input of numbers, character information or user feature information (e.g., fingerprint, iris, face information, etc.), and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function controls.

[0224] The power supply 507 is configured to supply power to various components of the electronic device 500. Optionally, the power supply 507 can be logically connected to the processor 501 through a power management system, so as to realize functions such as management of charging, discharging and power consumption management through the power management system. The power supply 507 can also include one or more direct current or alternating current power supplies, recharging systems, power failure detection circuits, power converters or inverters, power status indicators and any other components.

[0225] Although Figure 5 The electronic device 500 can also include a camera, a sensor, a wireless fidelity module, a Bluetooth module, etc., which are not described herein.

[0226] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0227] Those skilled in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructions, or by related hardware controlled by the instructions, which can be stored in a computer readable storage medium and loaded and executed by a processor.

[0228] To this end, an embodiment of the present application provides a computer readable storage medium, which stores a plurality of computer programs. The computer programs can be loaded by a processor to execute any one of the mobile application function exception handling methods provided by the embodiments of the present application. The computer programs can execute the steps of the following mobile application function exception handling method:

[0229] A mobile application running state is monitored by deploying a buried point probe, and a structured log is generated according to acquired system resource state and business behavior data; wherein the system resource state is environmental state data of a terminal device running the mobile application, and the business behavior data is mobile application function execution process data;

[0230] An exception type identifier in the structured log is analyzed, and a target diagnostic instrument in a set of exception diagnostic instruments associated with the exception type identifier is determined; wherein the exception type identifier is generated when the buried point probe detects system resource state and / or business behavior data exception;

[0231] The structured log data is analyzed by the target diagnostic analyzer, and an exception level is determined based on a predefined rule; wherein each diagnostic analyzer in the exception diagnostic analyzer set is pre-associated with a specific exception type;

[0232] A path-specific response is performed according to the exception level.

[0233] In the embodiments of the present application, through the differential monitoring strategy of the buried point probe, the polling and callback dual-mode cooperative collection are adopted, the business behavior is triggered at the key node event, the trend is positioned by the full-cycle basic log, the fault point is accurately marked by the exception identification log, and the event and the log identification are synchronously driven when the exception occurs, the diagnostic analyzer cluster is quickly associated with the historical log data according to the identification, and finally the dynamic response is triggered by the rule-based grading of the numerical threshold and the frequency statistics, so as to ensure the accuracy of the exception identification and form the closed-loop control effect of monitoring-diagnosis-response.

[0234] The specific implementation of each operation can refer to the foregoing embodiments, and will not be described here.

[0235] The computer readable storage medium can include a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0236] Since the computer program stored in the computer readable storage medium can execute any one of the mobile application function exception processing methods provided by the embodiments of the present application, the beneficial effects of any one of the mobile application function exception processing methods provided by the embodiments of the present application can be achieved, which will be described in detail in the foregoing embodiments and will not be described here.

[0237] According to an aspect of the present application, a computer program product or computer program is also provided, which includes computer instructions stored in a computer readable storage medium. The processor of the electronic device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the method provided in various optional implementation manners in the foregoing embodiments.

[0238] In the mobile application function exception processing apparatus, the computer readable storage medium, the electronic device, and the computer program product described above, the description of each embodiment has its own focus. The parts not described in detail in a certain embodiment can be referred to the relevant description of other embodiments. The skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the mobile application function exception processing apparatus, the computer readable storage medium, the computer program product, the electronic device, and the corresponding units thereof described above and the beneficial effects brought by them can be referred to the description of the mobile application function exception processing method in the above embodiments. The specific working process and the beneficial effects will not be described here again.

[0239] The mobile application function exception processing method, the apparatus, the electronic device, the computer readable storage medium, and the computer program product provided by the embodiments of the present application are described in detail above. The principle and implementation manner of the present application are described by applying specific examples. The above description of the embodiments is only used to help understand the method of the present application and its core idea. Meanwhile, for the skilled in the art, according to the idea of the present application, the specific implementation manner and application range will be changed. In summary, the content of the specification should not be understood as a limitation of the present application.

Claims

1. A method for handling abnormal mobile application functions, characterized in that: Comprise: Monitor the running state of the mobile application by deploying a buried probe, and generate structured logs according to the obtained system resource state and business behavior data; wherein the system resource state is the environmental state data of the terminal device running the mobile application, and the business behavior data is the mobile application function execution process data; Analyze the abnormal type identifier in the structured log to determine the target diagnostic instrument in the abnormal diagnostic instrument set associated with the abnormal type identifier; wherein the abnormal type identifier is generated when the system resource state and / or business behavior data is detected by the buried probe; Analyze the structured log data through the target diagnostic instrument, and judge the abnormal level based on the predefined rules; wherein each diagnostic instrument in the abnormal diagnostic instrument set is pre-associated with a specific abnormal type; Perform path response according to the abnormal level.

2. The method according to claim 1, characterized in that Real-time monitoring of the running state of the mobile application by deploying a buried probe, and generating structured logs according to the obtained system resource state and business behavior data, comprising: Real-time collection of system running environment state data of terminal device by system resource buried probe; Passive listening to key nodes in business function execution process by business resource buried probe, and collecting abnormal related business function execution data when detecting abnormality; Encapsulate the collected system running environment state data and abnormal related business function execution data into structured logs, and store them into local database.

3. The method of claim 2, wherein, Encapsulate the collected system running environment state data and abnormal related business function execution data into structured data of the same format; Store the structured data into the local database as the main classification basis. The step of generating abnormal type identifier, comprising:

4. The method of claim 2, wherein, In the case that the system resource buried probe detects that the resource state data exceeds the preset system abnormal trigger threshold, set the identifier as the pre-defined system resource abnormal type; In the case that the business resource buried probe detects that the number of execution failures per unit time at the business key node reaches the preset business abnormal trigger frequency threshold, set the identifier as the pre-defined business function abnormal type. Analyze the abnormal type identifier in the structured log to determine the target diagnostic instrument in the abnormal diagnostic instrument set associated with the abnormal type identifier, comprising:

5. The method of claim 1, wherein, In the case that the structured log contains multiple abnormal type identifiers, trigger multiple corresponding target diagnostic instruments in parallel according to the corresponding multiple abnormal type identifiers; Analyze the structured log data through the target diagnostic instrument, and judge the abnormal level based on the predefined rules, comprising: Each target diagnostic instrument independently analyzes the structured log data, and judges the abnormal level of the abnormal event based on the predefined rules. The step of analyzing the structured log data through the target diagnostic instrument, comprising:

6. The method of claim 1, wherein, Execute the query instruction through the target diagnostic instrument, query the structured log matching the current abnormal type identifier from the local database; Parse the abnormal type identifier in the obtained structured log. ​ 7. The method of claim 6, wherein, In the case of identifying the exception type as a system resource exception, judging the exception level based on a predefined rule, including: Comparing a numerical field extracted from the structured log with a preset first system threshold and a second system threshold; In the case of the numerical value being not greater than the first system threshold, determining the exception level as a high level; In the case of the numerical value being greater than the first system threshold and not greater than the preset second system threshold, determining the exception level as a low level; Wherein, the first system threshold is higher than the second system threshold.

8. The method of claim 6, wherein, In the case of the exception event being a business function exception, judging the exception level based on a predefined rule, including: Comparing the execution failure frequency within a unit time based on the timestamp field of the structured log with a preset first business frequency threshold and a second business frequency threshold; In the case of the failure frequency being not less than the first business frequency threshold, determining the exception level as a high level; In the case of the failure frequency being less than the first business frequency threshold and not less than the second business frequency threshold, determining the exception level as a low level; Wherein, the first business frequency threshold is greater than the second business frequency threshold.

9. The method of claim 1, wherein, Executing a path response according to the exception level, including: Generating a real-time pop-up solution prompt information for a high-level exception; wherein the prompt information contains an exception reason explanation; Generating a silent diagnosis record for a low-level exception and storing it in a local database; wherein the silent diagnosis record is a keyword indexed log.

10. The method of claim 9, wherein, Further including: In response to a user consultation request, matching the silent diagnosis record based on the consultation request text, and outputting the corresponding solution.

11. The method of claim 10, wherein, In response to a user consultation request, matching the silent diagnosis record based on the consultation request text, and outputting the corresponding solution, including: In response to a user consultation request, extracting the consultation request text keyword; Filtering the records matched with the keyword from the pre-stored silent diagnosis record through semantic mapping, and outputting the corresponding solution.

12. The method of claim 2, wherein, Real-time collection of system running environment state data of terminal equipment through system resource buried probe, including: Synchronous execution of a timing polling polling type system resource and real-time response to callback type system resource changes through a system resource buried probe to obtain system running environment state data of terminal equipment.

13. The method of claim 12, wherein, Execution of a timing polling polling type system resource through a system resource buried probe to obtain system running environment state data of terminal equipment, including: Setting a timing polling task for a polling type system resource through a system resource buried probe, and collecting the state of the polling type system resource at a predetermined time interval; In the case of detecting that the polling type system resource exceeds the system threshold through the polling task, triggering data burying; Wherein, the polling type system resource includes a resource type that needs to be actively probed.

14. The method of claim 12, wherein, Execution of real-time response to callback type system resource changes through a system resource buried probe to obtain system running environment state data of terminal equipment, including: Registering a system callback event through a system resource buried probe to respond to state changes of a callback type system resource in real time; When the system callback notifies that the callback type system resource has a state change, triggering data burying; Wherein, the callback type system resource includes a resource type that supports system event notification.

15. A mobile application function exception handling apparatus, characterized by comprising: The device includes: The anomaly perception module is used to monitor the running status of mobile applications by deploying embedded probes and generate structured logs based on the acquired system resource status and business behavior data; wherein the system resource status is the environmental status data of the terminal device running the mobile application, and the business behavior data is the mobile application function execution process data; A diagnostic device determination module is used to analyze the abnormality type identifier in the structured log and determine the target diagnostic device in the abnormality diagnostic device set associated with the abnormality type identifier; wherein the abnormality type identifier is generated when the embedded probe detects an abnormality in the system resource status and / or business behavior data; an abnormality level determination module, configured to analyze the structured log data through the target diagnostic device and determine the abnormality level based on predefined rules; wherein each diagnostic device in the set of abnormality diagnostic devices is pre-associated with a specific abnormality type; The sub-path response execution module is configured to execute a sub-path response according to the abnormality level.

16. An electronic device, comprising: It includes a processor and a memory, wherein the memory stores multiple instructions; the processor loads instructions from the memory to execute the steps of the mobile application function abnormality processing method as described in any one of claims 1 to 14.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions, which are suitable for loading by a processor to execute the steps of the mobile application function abnormality handling method according to any one of claims 1 to 14.

18. A computer program product comprising computer programs or instructions, characterized in that, When the computer program or instructions are executed by a processor, the steps of the mobile application function abnormality handling method as described in any one of claims 1 to 14 are implemented.

Images