CN117518916A

CN117518916A - Flow monitoring method, device, electronic equipment and storage medium

Info

Publication number: CN117518916A
Application number: CN202311500115.2A
Authority: CN
Inventors: 刘源
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2023-11-10
Filing date: 2023-11-10
Publication date: 2024-02-06

Abstract

The application discloses a flow monitoring method, a flow monitoring device, electronic equipment and a storage medium, and relates to the technical field of electronic equipment. The method comprises the following steps: and responding to the triggering callback, traversing a callback linked list, wherein a plurality of nodes are arranged in the callback linked list according to the order from high priority to low priority, each node comprises a callback function, determining an execution result corresponding to the callback function included in the traversed node, wherein the execution result comprises execution success, execution failure or non-execution, and storing the execution result corresponding to the callback function included in each node when the plurality of nodes are traversed. According to the method and the device, by traversing all the nodes in the callback chain table and recording the execution results corresponding to the callback functions respectively included in all the nodes according to successful execution, failure execution or non-execution, reliability monitoring of callback flow can be guaranteed, and reliability of products is improved.

Description

Flow monitoring method, device, electronic equipment and storage medium

Technical Field

The present disclosure relates to the field of electronic devices, and in particular, to a method and apparatus for monitoring a flow, an electronic device, and a storage medium.

Background

With the development of science and technology, electronic devices are increasingly widely used, and have more and more functions, and become one of the necessities in daily life. At present, certain operations can be executed by controlling the electronic equipment through the callback function, however, the electronic equipment lacks tracking of an execution result of the callback function, reliability monitoring of a callback flow cannot be guaranteed, and reliability of a product is low.

Disclosure of Invention

In view of the above, the present application proposes a flow monitoring method, a device, an electronic apparatus, and a storage medium, so as to solve the above problem.

In a first aspect, an embodiment of the present application provides a flow monitoring method, where the method includes: responding to a triggering callback, traversing a callback linked list, wherein a plurality of nodes are arranged in the callback linked list according to the order of priority from high to low, and each node comprises a callback function; determining an execution result corresponding to a callback function included in the traversed node, wherein the execution result comprises execution success, execution failure or non-execution; and under the condition that the plurality of nodes are traversed, storing execution results corresponding to callback functions respectively included by the plurality of nodes.

In a second aspect, an embodiment of the present application provides a flow monitoring device, where the device includes: the callback link list traversing module is used for responding to triggering callback and traversing a callback link list, wherein a plurality of nodes are arranged in the callback link list according to the order of priority from high to low, and each node comprises a callback function; the execution result determining module is used for determining an execution result corresponding to a callback function included in the traversed node, wherein the execution result comprises execution success, execution failure or non-execution; and the execution result storage module is used for storing the execution results corresponding to the callback functions respectively included by the plurality of nodes under the condition that the plurality of nodes are traversed.

In a third aspect, embodiments of the present application provide an electronic device comprising a memory coupled to a processor and a processor, the memory storing instructions that when executed by the processor perform the above-described method.

In a fourth aspect, embodiments of the present application provide a computer readable storage medium having program code stored therein, the program code being callable by a processor to perform the above method.

According to the flow monitoring method, the flow monitoring device, the electronic equipment and the storage medium, the callback list is traversed in response to triggering of the callback, the plurality of nodes are arranged in the callback list in the order from high priority to low priority, each of the plurality of nodes comprises callback functions, the execution results corresponding to the callback functions included in the traversed node are determined, wherein the execution results comprise execution success, execution failure or non-execution, and when the plurality of nodes are traversed, the execution results corresponding to the callback functions included in the plurality of nodes are stored, so that through traversing all the nodes in the callback list and recording the execution results corresponding to the callback functions included in all the nodes according to the execution success, the execution failure or non-execution, reliability monitoring of the flow can be guaranteed, and reliability of products is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly introduced below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 illustrates a flow diagram of a current registration reset callback;

FIG. 2 illustrates another flow diagram of a current registration reset callback;

FIG. 3 illustrates a flow diagram of a current trigger reset callback;

FIG. 4 illustrates another flow diagram of a current trigger reset callback;

FIG. 5 illustrates yet another flow diagram of a current trigger reset callback;

FIG. 6 is a flow chart of a flow monitoring method according to an embodiment of the present disclosure;

FIG. 7 is a flow chart of a flow monitoring method according to an embodiment of the present disclosure;

FIG. 8 is a flow chart of a flow monitoring method according to an embodiment of the present disclosure;

FIG. 9 is a flow chart of a flow monitoring method according to an embodiment of the present disclosure;

FIG. 10 is a flow chart of a flow monitoring method according to an embodiment of the present disclosure;

FIG. 11 is a flow chart illustrating a flow monitoring method according to an embodiment of the present disclosure;

FIG. 12 is a schematic flow chart of a device reset callback provided in an embodiment of the present application;

FIG. 13 is a schematic flow diagram of another device reset callback provided in an embodiment of the present application;

FIG. 14 is a schematic flow chart of a device registration callback provided in an embodiment of the present application;

FIG. 15 is a schematic flow diagram of another device registration callback provided by an embodiment of the present application;

FIG. 16 shows a block diagram of a flow monitoring device according to an embodiment of the present application;

FIG. 17 shows a block diagram of an electronic device for performing a flow monitoring method according to an embodiment of the present application;

fig. 18 shows a storage unit for storing or carrying program codes for implementing the flow monitoring method according to the embodiment of the present application.

Detailed Description

In order to enable those skilled in the art to better understand the present application, the following description will make clear and complete descriptions of the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application.

As shown in fig. 1, the current registration reset callback (when the device is started) includes the following steps:

1. in the starting process of the electronic device, a key link is kernel starting, wherein a plurality of driving modules are loaded successively (for example, modprobe in an Android system).

2. Some driving modules call a system interface (example: int register_reboot_identifier (struct notifier block) nb) in the Android system) for registering a reset callback to transmit callback functions and priorities as parameters to a reset callback module for realizing the timely execution of service processing corresponding to the callback functions in a device reset scene.

3. In the system interface registering the reset callback, the reset callback module creates a new node. And storing the registered callback functions, priority and other information in the node.

4. The new node is inserted into the proper position in the reset callback chain table, so that all nodes in the reset callback chain table are always arranged in the order of the priority in the nodes from large to small.

5. The reset callback module feeds back registration results (examples: success, failure) to the driving module.

6. The driving module knows that the registration result is failed, and can perform some abnormal processing (examples: printing log, error statistics, failed retry, data return, resetting equipment and the like) according to the service requirement.

As a more specific example, as shown in fig. 2, the following steps may be included:

1. at some stage of the device start-up, the drive modules 1 to N are loaded in sequence.

2. The driving module 1 registers a reset callback (parameters: callback function 1, priority) and creates a head node in a reset callback linked list.

3. The driving module 2 registers a reset callback (parameters: callback function 2, priority) and adds a node at the appropriate position of the reset callback linked list (the node where the callback function 1 is located is arranged behind the node where the callback function 1 is located because the priority is lower than the node where the callback function 1 is located).

4. The driving module 3 registers reset callback (parameters: callback function 3, priority) and adds a node at a proper position of the reset callback linked list (the priority is lower than the node where the callback function 1 is located, but higher than the node where the callback function 2 is located, so that the node is arranged between the node where the callback function 1 is located and the node where the callback function 2 is located).

5. The presence driver module does not register a reset callback. Until the loading of the driving module N is completed.

6. All nodes in the callback chain list are reset, and the nodes are always arranged in the order from big to small according to the priority in the nodes.

As shown in fig. 3, the current triggered reset callback (when the device resets) includes the following steps:

1. in the reset process of the electronic device, there is a key link that triggers a reset callback (for example, blocking_non_call_chain (unboot_non_list, sys_restart, cmd)) in Android.

2. And the reset callback module starts traversing the reset callback linked list and judges that no node which is not traversed exists.

3. If there are more nodes that are not traversed, executing the callback function in the node.

4. After the callback function is executed, an execution result is fed back to the reset callback module.

5. The reset callback module checks the feedback execution result (examples: valid values in the Android system include notify_done, notify_ok, notify_stop_mask, notify_bad).

6. If the check execution result is successful (example: notify_done or notify_ok in Android system), go to step 2 (continue traversing nodes).

7. If the checking execution result is failure (examples: NOTIFY_STOP_MASK and NOTIFY_BAD in the Android system), the trigger reset callback flow is directly ended.

As a more specific example, as shown in fig. 4, the following steps may be included:

1. in a certain stage of device reset, a reset callback flow is triggered to start.

2. Traversing to the first node in the reset callback chain table, and executing the callback function 1 successfully.

3. The reset callback module checks that the feedback execution result is successful, and the next step is continued.

4. Traversing to the next node in the reset callback chain table, and executing the callback function 3 successfully.

5. The reset callback module checks that the feedback execution result is successful, and the next step is continued.

6. Traversing to the next node in the reset callback chain table, and executing the callback function 2 successfully.

7. The reset callback module checks that the feedback execution result is successful, and the next step is continued.

8. In general, all callback functions can be successfully executed until the execution of the callback function N is completed.

As shown in fig. 5, the triggering of the reset callback may also include the following steps:

4. Traversing to the next node in the reset callback chain table, and failing to execute the callback function 3.

5. The reset callback module checks that the feedback execution result is failure, and then directly suspends traversal.

6. The next node callback function 2 in the callback chain list and a plurality of callback functions at the back are reset and are not executed.

As an example, at device start-up, camera. Ko (note: a driver module associated with the camera) dynamically adds a piece of processing through registration reset callback, causing the device to execute a "flash off callback function at reset. When the device is reset, because the flash lamp is turned off to process the exception, the feedback execution result fails, and then the reset callback is triggered to be directly stopped, and the rest callback functions (registered priority is lower than camera. Ko) of the reset callback linked list are not executed.

The inventors have found through research that the current technology has the following disadvantages:

first, a driving module which executes successfully for reset callback:

(a) A service that is generally executed successfully does not intentionally set log printing so as not to affect performance, so no log printing can confirm execution success.

(b) The driving module only knows that the execution is successful on the spot, and can not distinguish whether the execution is successful or not after that.

Second, a driver module that fails execution of the reset callback:

(a) The driver module only knows that the execution fails on site, and does not know that callback functions of other low-priority driver modules are not executed.

(b) Typically, businesses that fail to execute print exception information into log files. In order to avoid influencing the resetting performance, the log file stored before resetting can be found in the loading link of the driving module started by the next time (or after the equipment is completely started), and then the content of the file is matched according to the printed abnormal information keywords, so that the failure of the execution can be confirmed. The driving module is required to be independently realized by the business party.

Third, a driver module that does not execute for a reset callback:

(a) When the user does not know that the user does not execute the method, whether the user successfully executes or does not execute the method is not distinguished afterwards.

(b) The callback function of which driving module fails to execute, and the method is also unprofitable.

In order to solve the problems, the inventor discovers through long-term research and puts forward the flow monitoring method, the device, the electronic equipment and the storage medium provided by the embodiment of the application, and by traversing all nodes in the callback chain table and recording execution results corresponding to callback functions respectively included in all the nodes according to successful execution, failure execution or non-execution, the reliability monitoring of the callback flow can be ensured, so that the reliability of products is improved. The specific flow monitoring method is described in detail in the following embodiments.

The terms that may be used in the embodiments of the present application will be described below.

Electronic equipment: such as mobile phones, tablets, etc

Resetting: restarting and shutting down

And (3) a kernel: the Android system is operated on the basis of a Linux kernel

And a driving module: basic unit of expansion function of Linux kernel can be dynamically loaded and unloaded as required

Function: a relatively independent piece of software code, defined as a function

Registering a callback: transferring a function as a parameter to another module, and when a certain condition is met, the other module actively calls the function

Resetting callback: according to actual needs, a section of specific processing is dynamically added when the equipment is reset in a callback registration mode, and the specific processing is different from a fixed equipment reset flow link, and the method comprises the following steps: data safety storage, hardware safety power-down, reset overtime detection and the like

Priority level: the Android system is represented by multiple numbers, wherein some scenes are higher in priority as the numbers are larger, such as reset callback, and some scenes are lower in priority as the numbers are smaller, such as memory management

And (3) node: the node is a basic element forming a linked list and can be provided with a plurality of attributes including the pointed next node

Linked list: a linked list is an ordered set of a group of nodes, from the first node of the linked list, all the remaining nodes can be found one by one

Traversing the linked list: traversing is to start from the first node of the linked list, find the next node pointed to, then find the next node pointed to by the next node, stop until a certain condition is reached, or find the last node of the linked list all the time

Inserting a node: according to the existing ordering logic of a certain attribute value in the nodes, the linked list is split into 2 sections and then spliced by using new nodes, or the linked list is directly attached to a certain end at the beginning and the end

Persistence: storing the data in nonvolatile memory device such as Flash and hard disk, and keeping the data after power-down

Block device: abstract representation of Linux system for Flash hard disk storage device

The read-write mode of the block device: compared with the file read-write mode, the method is a mode for directly reading and writing data according to the specified offset address of the storage device

Magic word: for checking in general, it is agreed in advance that there is a section of specified content in a specified storage location, and if there is no match, it means that the checking is not passed

Json format: in "key-value" form, the data format is { key: value }. The key-value can be nested again in the value

Referring to fig. 6, fig. 6 is a flow chart illustrating a flow monitoring method according to an embodiment of the present application. The method is used for traversing all nodes in the callback chain list, recording the execution results corresponding to the callback functions respectively included in all the nodes according to successful execution, failure execution or non-execution, and guaranteeing reliability monitoring of callback flow so as to improve reliability of products. In a specific embodiment, the flow monitoring method is applied to the flow monitoring apparatus 200 shown in fig. 16 and the electronic device 100 (fig. 17) configured with the flow monitoring apparatus 200. The specific flow of the present embodiment will be described below by taking an electronic device as an example, and it will be understood that the electronic device applied in the present embodiment may include a smart phone, a tablet computer, a wearable electronic device, and the like, which is not limited herein. The following details about the process shown in fig. 6, where the process monitoring method specifically includes the following steps:

Step S110: and responding to the triggering callback, traversing a callback linked list, wherein a plurality of nodes are arranged in the callback linked list according to the order of priority from high to low, and each node comprises a callback function.

Triggering a callback refers to calling a predefined function or method when an event occurs, wherein the callback function is usually registered or bound between event occurrences, and when an event occurs, the system automatically calls the callback function to execute corresponding operations or processes. In programming, triggering a callback is a very common mechanism that can help handle asynchronous events, corresponding operations, or process results. The callback function may be any callable object, such as a function, method, closure, etc.

When a trigger callback is used, a callback function is usually provided as a parameter and is transferred to a related function or method of the trigger event, and when the event occurs, the related function or method calls the transferred callback function so as to execute corresponding operation or processing. For example, in JavaScript, the addeventlist method may be used to register a callback function for a click event, which the system will automatically call when the user clicks a button, in order to perform the corresponding operation or process.

In this embodiment, the trigger callback may be detected, and if the trigger callback is detected, the callback linked list may be traversed in response to the trigger callback, where multiple nodes are arranged in the callback linked list in order of priority from high to low, where the multiple nodes each include a callback function. It can be appreciated that traversing the callback linked list begins with a first node of the plurality of nodes, finds a next node of the first node, and then finds a next node of the next node until a last node of the callback linked list is found.

Optionally, the trigger callback may include a device reset callback.

Step S120: and determining an execution result corresponding to the callback function included in the traversed node, wherein the execution result comprises execution success, execution failure or non-execution.

It may be understood that, by traversing the callback linked list, all nodes (multiple nodes) in the callback linked list may be traversed, in this embodiment, in the process of traversing the callback linked list, an execution result corresponding to a callback function included in each node in all traversed nodes may be determined, and optionally, the execution result may include execution success, execution failure or non-execution.

If the execution result corresponding to the callback function is that the execution is successful, the callback function can be determined to be executed, and the operation indicated by the callback function can be completed; if the execution result corresponding to the callback function is that the execution fails, the callback function can be determined to be executed, and the operation indicated by the callback function cannot be completed; if the execution result corresponding to the callback function is unexecuted, it can be determined that the callback function is unexecuted.

In some embodiments, for each node in all traversed nodes, it may be determined whether to execute a callback function included in the node, and if it is determined that the callback function included in the node is not executed, it may be determined that an execution result corresponding to the callback function included in the node is not executed; if the callback function included in the node is determined to be executed, the callback function included in the node can be executed, whether the callback function is executed successfully or not is determined, if the callback function is determined to be executed successfully, the execution result corresponding to the callback function included in the node can be determined to be executed successfully, and if the callback function is determined to be executed unsuccessfully, the execution result corresponding to the callback function included in the node can be determined to be executed unsuccessfully.

As an implementation manner, in the process of traversing the callback linked list, for all nodes in the callback linked list, each time one node is traversed, the execution result corresponding to the callback function included in the traversed node can be determined, and until all nodes in the callback linked list are traversed, the execution result corresponding to the callback function included in each node in the callback linked list can be determined.

Step S130: and under the condition that the plurality of nodes are traversed, storing execution results corresponding to callback functions respectively included by the plurality of nodes.

In this embodiment, when it is determined that the plurality of nodes have been traversed, execution results corresponding to callback functions included in each of the plurality of nodes may be saved. Based on the method, the execution details of the trigger callback completion can be tracked, the current disadvantages of 'only calling and incapability of tracking' are changed, a section of monitoring blind area of the execution details of the trigger callback scene is made up, and the reliability of products is improved.

In some embodiments, in the process of traversing the callback linked list, whether there are non-traversed nodes can be judged, if it is determined that there are no non-traversed nodes, it can be determined that all nodes (i.e. a plurality of nodes) in the callback linked list are traversed, at this time, execution results corresponding to callback functions included in the plurality of nodes have been obtained, and accordingly, the execution results corresponding to callback functions included in the plurality of nodes can be saved.

In some embodiments, storing the execution results corresponding to the callback functions included in each of the plurality of nodes may include: and persistence of the execution results corresponding to the callback functions respectively included by the plurality of nodes.

As an implementation manner, persisting the execution results corresponding to the callback functions included in each of the plurality of nodes may include: storing the execution results corresponding to the callback functions respectively included in the plurality of nodes in a file read-write mode, for example, storing the execution results corresponding to the callback functions respectively included in the plurality of nodes in a file system in a file read-write mode (example: json format file).

As yet another implementation manner, persisting the execution results corresponding to the callback functions included in each of the plurality of nodes may include: storing the execution results corresponding to the callback functions of the nodes in a read-write mode of the block device, for example, storing the execution results corresponding to the callback functions of the nodes to a certain offset position of a memory in a read-write mode of the block device, and adding a certain magic word for checking the validity of the data at the forefront or other positions of the data.

According to the flow monitoring method provided by the embodiment of the invention, a callback list is traversed in response to triggering a callback, a plurality of nodes are arranged in the callback list from high priority to low priority, each of the plurality of nodes comprises callback functions, execution results corresponding to the callback functions included in the traversed node are determined, wherein the execution results comprise execution success, execution failure or non-execution, and when the plurality of nodes are traversed, the execution results corresponding to the callback functions included in the plurality of nodes are stored, so that reliability monitoring of the callback flow can be ensured by traversing all the nodes in the callback list and recording the execution results corresponding to the callback functions included in all the nodes according to the execution success, the execution failure or the non-execution, and reliability of products is improved.

Referring to fig. 7, fig. 7 is a flow chart illustrating a flow monitoring method according to an embodiment of the present application. The following details about the process shown in fig. 7, the process monitoring method specifically may include the following steps:

step S210: and responding to the triggering callback, traversing a callback linked list, wherein a plurality of nodes are arranged in the callback linked list according to the order of priority from high to low, and each node comprises a callback function.

The specific description of step S210 is referred to step S110, and will not be repeated here.

Step S220: and if traversing to a target node in the plurality of nodes, determining a state value of a callback flag, wherein the callback flag is created when a callback is triggered, and the state value of the callback flag is set to be a first state value when the callback is created.

In this embodiment, when a callback is triggered, the electronic device may create a callback flag, and the state value of the callback flag is set to the first state value at the time of creation, that is, when the callback is triggered, the electronic device may create a callback flag corresponding to the first state value (initial value). Optionally, when the callback flag corresponds to the first state value, the current corresponding node may be represented as a normal node, and then the callback function included in the corresponding node may be executed, where, in the case of executing the callback function included in the corresponding node, an execution result of the callback function may be obtained, and a processing manner of the state value of the callback flag may be determined according to the execution result, for example, if the execution result is that the execution is successful, the state value of the callback flag may be kept as the first state value, or if the execution result is that the execution is failed, the state value of the callback flag may be updated from the first state value to the second state value; when the callback flag corresponds to the second state value (different from the first state value), the current corresponding node may be characterized as an abnormal node, and the callback function included in the corresponding node may not be executed.

In some embodiments, the number of callback marks may be one or more, and when the number of callback marks is one, multiple nodes in the callback linked list may correspond to the same callback mark; when the number of callback marks is multiple, multiple nodes in the callback chain table can respectively correspond to one callback mark, and the callback mark is not limited herein.

The target node may be any node of the plurality of nodes, for example, the target node may be a first node of the plurality of nodes, may be an intermediate node of the plurality of nodes, may be a last node of the plurality of nodes, and the like, which is not limited herein. In this embodiment, if traversing to a target node of the plurality of nodes, the state value of the callback tag may be determined. Alternatively, the state value of the callback flag may be the first state value or the second state value.

In some embodiments, if multiple nodes correspond to the same callback tag, the state value of the callback tag may be determined when traversing to a target node in the multiple nodes; if the plurality of nodes respectively correspond to one callback mark, when traversing to a target node in the plurality of nodes, determining the state value of the callback mark corresponding to the target node.

Step S230: and if the state value of the callback flag is the first state value, determining that the target node is the first node of the plurality of nodes or the execution result corresponding to the callback function included in the last node of the target node is successful execution.

In some embodiments, where a status value of a callback tag is obtained, it may be determined whether the status value of the callback tag is a first status value or a second status value. As an implementation manner, assuming that the first state value is "normal", and the second state value is "abnormal", if the state value of the callback flag is obtained, it may be determined that the state value of the callback flag is "normal" or "abnormal", and if it is determined that the state value of the callback flag is "normal", it may be determined that the state value of the callback flag is the first state value; if the state value of the callback flag is determined to be "abnormal", the state value of the callback flag may be determined to be a second state value.

It can be understood that, since the initial value corresponding to the callback flag is the first state value when the callback flag is created, and the state value corresponding to the callback flag is the initial value when the callback flag traverses to the first node of the plurality of nodes, if the state value of the callback flag is determined to be the first state value, it can be determined that the target node is likely to be the first node of the plurality of nodes.

In addition, it may be understood that, since the initial value corresponding to the callback flag at the time of creation is the first state value, and when the callback flag corresponds to the first state value, the callback function included in the corresponding node may be executed, and when the execution result corresponding to the callback function is that the execution is successful, the state value of the callback flag corresponding to the next node is maintained as the first state value, and accordingly, if it is determined that the state value of the callback flag is the first state value, it may be determined that the execution result corresponding to the callback function included in the previous node possibly being the target node is that the execution is successful.

In this embodiment, if it is determined that the state value of the callback flag is the first state value, it may be determined that the target node is a first node of the multiple nodes, or an execution result corresponding to the callback function included in a previous node of the target node is successful execution.

Step S240: and if traversing to a target node in the plurality of nodes, wherein the target node is a head node in the plurality of nodes or an execution result corresponding to a callback function included in a previous node of the target node is successful execution, executing the callback function included in the target node.

In this embodiment, if the target node in the plurality of nodes is traversed, and the target node is a first node in the plurality of nodes or an execution result corresponding to a callback function included in a previous node of the target node is execution success, the callback function included in the target node may be executed.

In some implementations, if traversing to a target node of the plurality of nodes, it can be determined whether the state value of the callback flag is a first state value or a second state value. If the state value of the callback flag is determined to be the first state value, a callback function included by the target node may be executed.

Step S250: and determining a target execution result corresponding to the callback function included by the target node.

In this embodiment, under the condition that the callback function included in the target node is executed, a target execution result corresponding to the callback function included in the target node may be determined. Alternatively, the target execution result may include execution success or execution failure.

In some embodiments, when the callback function included in the target node is executed, a corresponding operation or state may be detected, and a target execution result corresponding to the callback function included in the target node is determined according to the detected operation or state.

Step S260: if the target execution result is the execution failure, traversing all nodes arranged behind the target node in the plurality of nodes, and determining the execution results corresponding to callback functions included in all nodes arranged behind the target node as unexecuted.

In this embodiment, if it is determined that the target execution result is the execution failure, it may continue to traverse all nodes arranged after the target node in the plurality of nodes, and determine that the execution result corresponding to the callback function included in all the nodes arranged after the target node is not executed.

As an implementation manner, if it is determined that the target execution result is the execution failure, all nodes arranged behind the target node may be determined from the callback linked list, and the execution results corresponding to the callback functions included in all nodes arranged behind the target node are directly determined to be unexecuted.

As still another implementation manner, if it is determined that the target execution result is the execution failure, it may be further traversed all the nodes arranged after the target node, for each traversed node, the state value of the callback flag may be determined, and since the state value of the callback flag after the execution failure of the callback function included in the target node may always maintain the second state value, and when the state value of the callback flag is the second state value, the callback function included in the corresponding node is not executed, and therefore, the execution result corresponding to the callback function included in the corresponding node is not executed, and then, it may be sequentially determined that the execution result corresponding to the callback function included in all the nodes arranged after the target node is not executed.

As an example, assuming that the callback list sequentially includes, from high to low, a node 1, a node 2, a node 3, a node 4, and a node 5, where the node 1 includes a callback function 1, the node 2 includes a callback function 2, the node 3 includes a callback function 3, the node 4 includes a callback function 4, and the node 5 includes a callback function 5, if the target node is the node 2 and the execution result of the callback function 2 is an execution failure, it may be determined that the execution result of the callback function 1 is an execution success, the execution result of the callback function 2 is an execution failure, the execution result of the callback function 3 is non-execution, the execution result of the callback function 4 is non-execution, and the execution result of the callback function 5 is non-execution.

In some embodiments, if it is determined that the target execution result is an execution failure, the state value of the callback flag may be updated from the first state value to the second state value. If it is determined that the execution failure is the target execution result, it is characterized that callback functions included in all nodes arranged behind the target node in the callback chain table are not executed any more, and then the state value of the callback flag can be updated from the first state value to the second state value, so that it is convenient to determine that callback functions included in subsequent nodes are not executed any more according to the callback flag in the second state value.

In some embodiments, if the target execution result is determined to be successful execution, the state value of the callback flag may be kept as the first state value. If the target execution result is determined to be that the execution is successful, the next node arranged in the target node in the callback chain table is characterized to continue to execute, the state value of the callback mark can be kept to be a first state value, so that a callback function included in the next node of the target node can be determined to continue to execute according to the callback mark in the first state value.

Step S270: and if the state value of the callback flag is the second state value, determining that the execution result corresponding to the callback function included in the previous node of the target node is execution failure or non-execution.

It can be understood that, because the initial value corresponding to the callback flag is the first state value when the callback flag is created, and when the callback flag corresponds to the first state value, the callback function included in the corresponding node can be executed, and when the execution result corresponding to the callback function is the execution failure, the state value of the callback flag is updated from the first state value to the second state value, and accordingly, the state value of the callback flag corresponding to the next node is the second state value when traversing to the next node, if it is determined that the state value of the callback flag is the second state value, it can be determined that the execution result corresponding to the callback function possibly included in the previous node of the target node is the execution failure.

In addition, it may be understood that, since the initial value corresponding to the callback tag is the first state value when the callback tag is created, and when the callback tag corresponds to the first state value, the callback function included in the corresponding node may be executed, and when the execution result corresponding to the callback function is the execution failure, the state value of the callback tag is updated from the first state value to the second state value, and accordingly, the state value of the callback tag corresponding to the next node when traversing to the next node is the second state value, for the node arranged after the next node in the callback chain table, since the state value of the callback tag is the second state value, and the callback function included in the node is not executed in the case that the state value of the callback tag corresponding to the node is the second state value, in the subsequent node traversing process, the state value of the callback tag will keep the second state value unchanged, and the execution result of the callback function included in the node is not executed, and then it may be determined that the execution result corresponding to the callback function included in the previous node of the target node is not executed.

In this embodiment, if it is determined that the state value of the callback flag is the second state value, it may be determined that the execution result corresponding to the callback function included in the previous node of the target node is an execution failure, or it may be determined that the execution result corresponding to the callback function included in the previous node of the target node is not executed.

Step S280: if the target node in the plurality of nodes is traversed, and the execution result corresponding to the callback function included in the previous node of the target node is the execution failure or is not executed, the callback function included in the target node is not executed, and the execution result corresponding to the callback function included in the target node is determined to be not executed.

In this embodiment, if the target node in the plurality of nodes is traversed, and the execution result corresponding to the callback function included in the previous node of the target node is execution failure or non-execution, the callback function included in the target node may not be executed, and the execution result corresponding to the callback function included in the target node is determined to be non-execution.

In some implementations, if traversing to a target node of the plurality of nodes, it can be determined whether the state value of the callback flag is a first state value or a second state value. If the state value of the callback flag is determined to be the second state value, the callback function included in the target node may not be executed, and the execution result corresponding to the callback function included in the target node is determined to be unexecuted.

The execution sequence between step S230 to step S260 and step S270 to step S280 is not limited herein.

Step S290: and under the condition that the plurality of nodes are traversed, storing execution results corresponding to callback functions respectively included by the plurality of nodes.

The specific description of step S290 is referred to step S130, and is not repeated here.

In the flow monitoring method provided in an embodiment of the present application, compared with the flow monitoring method shown in fig. 6, in this embodiment, a callback flag is further created when a callback is triggered, so as to determine whether to execute a callback function corresponding to a traversed node according to a state value where the callback flag is located, and determine an execution result corresponding to a previous node of the traversed node according to the state value where the callback flag is located, so that relevance of each node in a callback linked list and accuracy of execution judgment of the callback function can be improved. In addition, the embodiment also updates the state value of the callback mark or keeps the state value of the callback mark according to the execution result of the callback function, so that the correspondence between the state value of the callback mark and the execution result is realized, and the accurate judgment of whether the callback function is executed or not is improved. In addition, according to the embodiment, callback functions of other nodes arranged behind the node corresponding to the callback function with the execution result of failure are determined to be unexecuted, so that complete records of the execution results of the callback functions of all the nodes can be realized, and reliability of product testing can be ensured.

Referring to fig. 8, fig. 8 is a flow chart illustrating a flow monitoring method according to an embodiment of the present application. The following details about the process shown in fig. 8, the process monitoring method specifically may include the following steps:

step S310: and responding to the triggering callback, traversing a callback linked list, wherein a plurality of nodes are arranged in the callback linked list according to the order of priority from high to low, and each node comprises a callback function.

Step S320: and determining an execution result corresponding to the callback function included in the traversed node, wherein the execution result comprises execution success, execution failure or non-execution.

The specific description of step S310 to step S320 refer to step S110 to step S120, and are not described herein.

Step S330: recording an execution result corresponding to a callback function included in the traversed node in an execution result record table, wherein the execution result record table is created when the callback is triggered.

In this embodiment, when a callback is triggered, the electronic device may create an execution result record table, that is, when a callback is triggered, the electronic device may create an empty execution result record table, so as to record the execution results of all callback functions in the process of traversing the callback linked list. It can be appreciated that by creating an execution result record table to record the execution results of executing all callback functions, the complete record of triggering the callback flow can be realized.

In some embodiments, for each node in the plurality of nodes, when traversing to the node, determining whether to execute the callback function included in the node, if it is determined that the callback function included in the node is not executed, determining an execution result corresponding to the callback function included in the node as non-executed, and recording in an execution result record table that the callback function included in the node is not executed; if the callback function included in the node is determined to be executed, whether the execution result of the callback function included in the node is successful or not can be determined, and if the execution result of the callback function included in the node is determined to be successful, the execution success of the callback function included in the node can be recorded in an execution result record table; if the callback function included in the node is determined to be failed to be executed, the callback function included in the node can be recorded in an execution result record table.

Step S340: and under the condition that the plurality of nodes are traversed, storing execution results corresponding to callback functions respectively included by the plurality of nodes.

The specific description of step S340 is referred to step S130, and will not be repeated here.

Compared with the flow monitoring method shown in fig. 6, the flow monitoring method provided by the embodiment of the invention also creates the execution result record table when the callback is triggered, and records the execution result corresponding to the callback function included in the traversed node in the execution result record table, thereby realizing complete record of the execution result of all callback functions in the callback triggering process, cleaning the monitoring blind area in the callback triggering flow, and improving the reliability of the product.

Referring to fig. 9, fig. 9 is a flow chart illustrating a flow monitoring method according to an embodiment of the present application. The following details about the flow shown in fig. 9, the flow monitoring method specifically may include the following steps:

step S410: and responding to the triggering callback, traversing a callback linked list, wherein a plurality of nodes are arranged in the callback linked list according to the order of priority from high to low, and each node comprises a callback function.

Step S420: and determining an execution result corresponding to the callback function included in the traversed node, wherein the execution result comprises execution success, execution failure or non-execution.

The specific description of step S410 to step S420 refer to step S110 to step S120, and are not described herein.

Step S430: and under the condition that the plurality of nodes are traversed, acquiring the associated information corresponding to the callback functions respectively included by the plurality of nodes.

In addition to determining the execution result corresponding to the callback function included in the traversed node, the association information corresponding to the callback function included in the traversed node can be determined. Optionally, the association information corresponding to the callback function may include: the execution time stamp corresponding to the callback function, the error code corresponding to the callback function, the variable value corresponding to the callback function, and the like are not limited herein.

In this embodiment, when it is determined that the plurality of nodes have been traversed, association information corresponding to callback functions included in each of the plurality of nodes may be obtained, for example, one or a combination of several of an execution timestamp corresponding to a callback function included in each of the plurality of nodes, an error code corresponding to a callback function included in each of the plurality of nodes, and a variable value corresponding to a callback function included in each of the plurality of nodes may be obtained.

Step S440: and storing an execution result corresponding to the callback function respectively included by the plurality of nodes and associated information corresponding to the callback function respectively included by the plurality of nodes.

In this embodiment, when the execution result corresponding to the callback function included in each of the plurality of nodes and the association information corresponding to the callback function included in each of the plurality of nodes are obtained, the execution result corresponding to the callback function included in each of the plurality of nodes and the association information corresponding to the callback function included in each of the plurality of nodes may be stored.

In some embodiments, under the condition that the execution results corresponding to the callback functions included in each of the plurality of nodes and the associated information corresponding to the callback functions included in each of the plurality of nodes are obtained, the execution results corresponding to the callback functions included in each of the plurality of nodes and the associated information corresponding to the callback functions included in each of the plurality of nodes may be recorded in an execution result record table, and the execution result record table is stored, so that the storage of the execution results corresponding to the callback functions included in each of the plurality of nodes and the associated information corresponding to the callback functions included in each of the plurality of nodes is realized.

Compared with the flow monitoring method shown in fig. 6, the flow monitoring method provided in an embodiment of the present invention further obtains association information corresponding to callback functions included in each of the plurality of nodes, and stores execution results corresponding to the callback functions included in each of the plurality of nodes and association information corresponding to the callback functions included in each of the plurality of nodes, so that more flow information can be obtained, and reliability of products is further improved.

Referring to fig. 10, fig. 10 is a flow chart illustrating a flow monitoring method according to an embodiment of the present application. The following details about the flow shown in fig. 10, the flow monitoring method specifically may include the following steps:

Step S510: and responding to the triggering callback, traversing a callback linked list, wherein a plurality of nodes are arranged in the callback linked list according to the order of priority from high to low, and each node comprises a callback function.

Step S520: and determining an execution result corresponding to the callback function included in the traversed node, wherein the execution result comprises execution success, execution failure or non-execution.

Step S530: and under the condition that the plurality of nodes are traversed, storing execution results corresponding to callback functions respectively included by the plurality of nodes.

The specific description of step S510 to step S530 refers to step S110 to step S130, and will not be repeated here.

Step S540: in response to registering the callback, a registered target callback function is determined.

Where registering a callback refers to registering device information or performing a specific operation through a callback function, such callback mechanisms may be used in a variety of different application scenarios, such as device monitoring, application running, etc. Alternatively, the registration callback may be used in the device start-up phase, and then in implementation of the device start-up registration callback, it is generally necessary to define a callback function first, where the callback function includes relevant information of the device or specific operations to be performed, and then, at the time of device start-up, register device information or perform specific operations by calling the callback function.

In this embodiment, the registration callback may be detected, and if the registration callback is detected, the registered target callback function may be determined in response to the registration callback.

Step S550: and if the callback functions included in the nodes respectively comprise the target callback functions, acquiring the execution results corresponding to the target callback functions from the stored execution results corresponding to the callback functions included in the nodes respectively.

In some embodiments, in the case of determining the registered target callback function, the target callback function may be compared with the callback functions included in each of the plurality of stored nodes, so as to determine whether the target callback function is included in the callback functions included in each of the plurality of nodes. If it is determined that the callback functions included in the plurality of nodes include the target callback function, the execution result corresponding to the target callback function may be obtained from the stored execution results corresponding to the callback functions included in the plurality of nodes.

As an implementation manner, callback functions included by each of the plurality of nodes and execution results corresponding to the callback functions included by each of the plurality of nodes are recorded in an execution result record table, and then, in the case of determining the registered target callback function, whether the target callback function exists or not can be searched in the execution result record table. If the target callback function is found in the execution result record table, the execution result corresponding to the target callback function can be obtained from the execution result record table.

Step S560: and processing based on the execution result corresponding to the target callback function.

In this embodiment, in the case of obtaining an execution result corresponding to the target callback function, processing may be performed based on the execution result corresponding to the target callback function.

As an implementation manner, if the execution result corresponding to the target callback function is execution failure or non-execution, exception handling may be performed, for example, exception handling such as log printing, error statistics, failure retry, data feedback, and resetting of devices may be performed according to service requirements; if the execution result corresponding to the target callback function is that the execution is successful, the exception handling is not required.

In some embodiments, processing based on the execution result corresponding to the target callback function may include: determining a registration result corresponding to the target callback function, wherein the registration result can comprise successful registration or failure registration, and processing based on an execution result corresponding to the target callback function and the registration result corresponding to the target callback function.

As an implementation manner, if the execution result corresponding to the target callback function is execution failure or non-execution, and/or the registration result corresponding to the target callback function is registration failure, exception handling may be performed, for example, exception handling such as printing logs, error statistics, failure retry, data return, reset device and the like may be performed according to service requirements. If the execution result corresponding to the target callback function is successful execution and the registration result corresponding to the target callback function is successful registration, exception handling is not required.

As a way, if the execution result corresponding to the target callback function is execution failure or non-execution, and/or the registration result corresponding to the target callback function is registration failure, the first exception information may be generated, and exception processing may be performed based on the first exception information. Optionally, the electronic device may create an event recording module, and in the case of generating the first abnormal information, may record the first abnormal information to the event recording module, and transmit the first abnormal information back to the product server through the event recording module, so as to process the abnormal information.

In the flow monitoring method provided in this embodiment, compared with the flow monitoring method shown in fig. 6, the present embodiment further determines the registered target callback function in response to the registration callback, if the callback function included in each of the plurality of nodes includes the target callback function, the execution result corresponding to the callback function is obtained from the stored execution result corresponding to the callback function included in each of the plurality of nodes, and processing is performed based on the execution result corresponding to the target callback function, so that the execution result of the last trigger callback is conveyed when the callback is registered, and a self-flexible decision to process countermeasures can be implemented, and by placing all possible time-consuming operations in the next registration callback, user experience can be improved.

Referring to fig. 11, fig. 11 is a flow chart illustrating a flow monitoring method according to an embodiment of the present application. In this embodiment, the triggering callback includes a device reset callback, which will be described in detail below with respect to the flowchart shown in fig. 11, and the method for monitoring the flowchart specifically may include the following steps:

step S610: and responding to the triggering callback, traversing a callback linked list, wherein a plurality of nodes are arranged in the callback linked list according to the order of priority from high to low, and each node comprises a callback function.

Step S620: and determining an execution result corresponding to the callback function included in the traversed node, wherein the execution result comprises execution success, execution failure or non-execution.

Step S630: and under the condition that the plurality of nodes are traversed, storing execution results corresponding to callback functions respectively included by the plurality of nodes.

The specific description of step S610 to step S630 refer to step S110 to step S130, and are not repeated here.

Step S640: and in the process of starting the equipment, determining whether the equipment stores the execution results corresponding to the callback functions respectively included by the plurality of nodes.

Optionally, the triggering callback may include a device reset callback and the registering callback may include a device initiated registering callback.

In this embodiment, in the process of starting the device, it may be determined whether the device stores execution results corresponding to callback functions included in each of the plurality of nodes.

In some embodiments, if callback functions included in each of the plurality of nodes are recorded in the execution result record table, it may be determined whether the execution result record table exists during the device start-up process. If the execution result record table is determined to exist, the equipment can be determined to store the execution results corresponding to the callback functions respectively included by the plurality of nodes; if the execution result record table is determined not to exist, the fact that the equipment does not store the execution results corresponding to the callback functions included by the nodes can be determined.

As an implementation manner, if the execution result record table is stored in a persistent manner by means of file reading and writing, whether the execution result record table exists can be determined by judging whether the result exists; if the execution result record table is stored in a lasting manner by means of reading and writing of the block device, whether the data content of the specified offset of the memory is the expected magic word or not can be judged, and whether the execution result record table exists or not can be determined.

Step S650: and if the equipment is determined to store the execution results corresponding to the callback functions respectively included in the plurality of nodes, reading the stored execution results corresponding to the callback functions respectively included in the plurality of nodes.

In this embodiment, if it is determined that the device stores the execution results corresponding to the callback functions included in each of the plurality of nodes, the stored execution results corresponding to the callback functions included in each of the plurality of nodes may be read, so that the execution results corresponding to the callback functions included in each of the plurality of nodes are used as references in the registration, a processing countermeasure may be flexibly determined, and some possible time-consuming operations may be placed after the device is started, so that an influence on user experience may be reduced.

In some embodiments, the electronic device may create an event recording module, and in case that the stored execution results corresponding to the callback functions included in each of the plurality of nodes are successfully read, the execution results corresponding to the callback functions included in each of the plurality of nodes may be converted into an event, such as a callback function+an execution result, and the event is recorded by the event recording module.

In some embodiments, if it is determined that the device does not store the execution results corresponding to the callback functions included in each of the plurality of nodes, or the stored execution results corresponding to the callback functions included in each of the plurality of nodes are not successfully read, second exception information may be generated, and exception processing is performed based on the second exception information. Optionally, the electronic device may create an event recording module, and in the case of generating the second abnormal information, may record the second abnormal information to the event recording module, and transmit the second abnormal information back to the product server through the event recording module, so as to process the abnormal information.

In the flow monitoring method provided in an embodiment of the present application, compared with the flow monitoring method shown in fig. 1, in the process of starting the device, it is further determined whether the device stores execution results corresponding to callback functions included in each of the plurality of nodes, if so, the execution results corresponding to the callback functions included in each of the plurality of nodes are read, and if not, abnormal information is reported, so that the self-diagnosis capability of the product and the big data capability of the product can be improved.

As shown in fig. 12, when the flow monitoring method provided in the embodiment of the present application is applied in a device reset scenario, the method may include the following steps:

1. in the device reset process, one key element is to trigger a reset callback.

2. An empty execution result record table is newly created. And the method is used for recording the execution result data of all callback functions.

3. A callback flag whose initial value is [ normal ] is newly created. For deciding whether to execute the callback function.

4. And the reset callback module starts traversing the reset callback linked list and judges that no node which is not traversed exists.

5. If there are more nodes that are not traversed, it is determined what the callback flag is.

6. If the callback flag value is normal, executing the callback function in the node.

a) After the callback function is executed, an execution result is fed back to the reset callback module.

b) The reset callback module records { callback function:. Timestamp + execution result } information to the execution result record table. And (3) injection: in addition to basic information such as "callback function", "timestamp", "execution result", more expansion information such as "error code", "variable value" and the like can be added as required.

c) The reset callback module checks the feedback execution result.

d) If the result of the check execution is failure, the callback flag value is set to [ exception ].

7. Jump to step 5 (determine callback flag value). If the callback flag value is abnormal, the callback function is not executed any more, and the { callback function } timestamp+non-execution } information is directly recorded in the execution result record table.

8. Jump to step 4 (continue traversing the node). If no nodes are not traversed, the result record table data is executed durably. And the reset callback flow normally ends.

a) Persistent implementation 1: and storing the file in a file system in a file read-write mode (an example is a json format file).

b) Persistent implementation 2: and storing the data to a certain offset position of the memory in a read-write mode of the block equipment. A certain magic word may be added at the forefront of the data or elsewhere for checking the validity of the data.

As a more specific example, as shown in fig. 13, the following steps may be included:

3. The reset callback module records the content { callback function 1: timestamp + execution success } in the execution result record table.

4. The reset callback module checks that the feedback execution result is successful, and the next step is continued.

5. Traversing to the next node in the reset callback chain table, and failing to execute the callback function 3.

6. The reset callback module records the content { callback function 3: timestamp + execution failure } in the execution result record table.

7. The next node in the reset callback chain list is traversed, but the callback function 2 is not executed any more, and the content { callback function 2: timestamp+not executed }) is directly recorded in the execution result record table.

8. The process is traversed in this manner all the time. And until the last node in the callback chain table is reset, the callback function N is not executed any more, and the content { callback function N: time stamp + non-execution } is directly recorded in the execution result record table.

9. And the persistent execution result record table stores data in a direct reading and writing mode of a file or a memory.

As shown in fig. 14, when the flow monitoring method provided in the embodiment of the present application is applied to a device start-up scenario after a device reset scenario, the method may include the following steps:

1. in the device start-up flow, the reset callback module is started.

2. It is checked whether the execution result record table exists.

a) If the file read-write mode for persistence is adopted, judging whether the file exists or not.

b) If the read-write mode of the block device for persistence is adopted, whether the data content of the specified offset of the memory is the expected magic word is judged.

3. If the execution result record table does not exist, the event record module records a < timestamp+execution result record table does not exist > event. And (3) injection: the general event points include: what time + what object + what happens.

4. If the execution result record table exists, an attempt is made to read the execution result record table.

5. If the reading fails, the event recording module records the event of < time stamp + the execution result record list reading exception >.

6. If the reading is successful, all contents in the execution result record table are converted into events such as < timestamp+callback function+execution result > which are all recorded by the event recording module.

7. Until the initialization of the reset callback module is completed, a plurality of driving modules are loaded successively.

8. If one driving module has the action of registering the reset callback, the driving module can transmit the functions and the priorities which need to be executed when the device is reset to the reset callback module as parameters.

9. In the system interface registering the reset callback, the reset callback module creates a new node. And storing the registered callback function and priority information in the node.

10. The new node is inserted into the proper position in the reset callback chain table, so that all nodes in the reset callback chain table are always arranged in the order of the priority in the nodes from large to small.

11. Then, the reset callback module searches whether the callback function exists in the execution result record list.

12. If the callback function is found, the reset callback module feeds back the current registration result and the last execution result to the driving module.

13. If the registration result is failure or the last execution result is execution failure or non-execution, the system can automatically perform exception handling according to the service requirement (examples: printing logs, error statistics, failed retries, data feedback, resetting equipment and the like).

14. The device start-up flow continues to execute downwards until the formal start-up is completed.

15. When the conditions such as the network are met, the event recording module can transmit all the event data back to the product server.

As shown in fig. 15, as a more specific example, the following steps may be included:

1. and initializing a reset callback module, and firstly attempting to import an execution result record table. If it fails, there will be a corresponding event record.

2. The driving modules 1 to N are loaded in sequence.

3. The driving module 1 registers a reset callback (parameters: callback function 1, priority) and adds a node in the reset callback linked list.

4. The reset callback module feeds back the current registration result and the last execution result to the driving module 1.

5. Aiming at the abnormal situations that the registration result is failed or the execution result is failed or not executed last time, the driving module can flexibly process (examples: log printing, error statistics, failed retry, data feedback and the like) according to the requirement.

6. The presence driver module does not register a reset callback. Until the loading of the driving module N is completed.

7. The event recording module records key events in the process (for example, < time stamp+execution result record table does not exist >, < time stamp+drive module 1+execution success >), and the following conditions can be transmitted back to the product server side when the following conditions are met.

Therefore, the embodiment of the application at least comprises the following effects:

the first embodiment of the application aims at the equipment reset scene, can enable the complete execution details of the triggering reset callback to be tracked, overcomes the current disadvantages of 'only calling and incapability of tracking', and makes up a section of monitoring blind area of the execution details of the reset scene;

second, embodiments of the present application may identify causal links from "execution failed" to "unexecuted". Malicious modules and inconsequential modules are avoided, execution is performed preferentially and failure is performed, and other low-priority modules are affected. The execution reliability of the service realized by the reset callback is effectively ensured, and the problems of user data loss, device damage or user experience caused by execution failure and non-execution are avoided, wherein the problems comprise resource safety release, hardware safety power-down and maintainability and measurability (slow reset and dead reset).

Third, the embodiments of the present application are directed to unified enhancement of the platform mechanism itself, and no adaptation needs to be added to each driving module. The monitoring target range can be automatically included no matter how many driving modules register reset callbacks. Compared with the mode that each driving module realizes self monitoring through log recording and the like, the embodiment of the application has smaller influence on reset performance.

Fourth, in the embodiment of the present application, when the driver module registers a reset callback, the driver module conveys the execution result of the last reset, and the driver module may flexibly determine the processing countermeasure (e.g. print log, error statistics, failure retry, data feedback, reset device, etc.).

Fifth, the embodiments of the present application place all possible time-consuming operations after the next device startup is completed, so that the user experience impact on reset+startup is controllable.

Sixth, the event recording module in the embodiment of the present application is responsible for "event recording" and "transmitting back to the product server", so as to improve the self-diagnostic capability of the device and the big data capability of the product.

Seventh, the embodiment of the application provides an effective verification means for product research and development and testers, solves the defects that the reset scene log is unreliable, has no clear phenomenon, is difficult to debug in a single step, is difficult to test and the like, quickly discovers problems, and improves the product quality. The test case in the product research and development stage can only cover the currently focused driving module, and the indirect influence on other driving modules is not considered.

Referring to fig. 16, fig. 16 is a block diagram illustrating a flow monitoring apparatus according to an embodiment of the present application. The flow monitor 200 will be described with respect to the block diagram shown in fig. 16, and includes: a callback linked list traversing module 210, an execution result determining module 220, and an execution result saving module 230, wherein:

And the callback link list traversing module 210 is configured to traverse the callback link list in response to triggering a callback, wherein a plurality of nodes are arranged in the callback link list in order from high priority to low priority, and each of the plurality of nodes includes a callback function.

The execution result determining module 220 is configured to determine an execution result corresponding to a callback function included in the traversed node, where the execution result includes execution success, execution failure or non-execution.

Further, the execution result determining module 220 includes: the callback function execution sub-module, the target execution result determination sub-module and the first unexecuted determination sub-module, wherein:

and the callback function execution sub-module is used for executing the callback function included in the target node if the callback function is traversed to the target node in the plurality of nodes and the execution result corresponding to the callback function included in the first node in the plurality of nodes or the last node of the target node is successful execution.

And the target execution result determining submodule is used for determining a target execution result corresponding to the callback function included by the target node.

And the first unexecuted determination submodule is used for traversing all nodes arranged behind the target node in the plurality of nodes if the target execution result is the execution failure, and determining the execution result corresponding to the callback function included in all the nodes arranged behind the target node as unexecuted.

Further, the execution result determining module 220 further includes: a second unexecuted determination submodule in which:

and the second unexecuted determination submodule is used for not executing the callback function included in the target node if the target node in the plurality of nodes is traversed, and the execution result corresponding to the callback function included in the previous node of the target node is the execution failure or unexecuted, and determining the execution result corresponding to the callback function included in the target node as unexecuted.

Further, the execution result determining module 220 further includes: the system comprises a state value determining sub-module, a first execution result determining sub-module and a second execution result determining sub-module, wherein:

and the state value determining submodule is used for determining the state value of the callback mark if traversing to the target node in the plurality of nodes, wherein the callback mark is created when the callback is triggered, and the state value of the callback mark is set to be a first state value when the callback mark is created.

And the first execution result determining submodule is used for determining that the target node is the first node in the plurality of nodes or the execution result corresponding to the callback function included in the last node of the target node is successful execution if the state value of the callback mark is the first state value.

And the second execution result determining submodule is used for determining that the execution result corresponding to the callback function included in the previous node of the target node is execution failure or non-execution if the state value of the callback mark is the second state value.

Further, the execution result determining module 220 further includes: a state value update sub-module and a state value holding sub-module, wherein:

and the state value updating sub-module is used for updating the state value of the callback mark from the first state value to the second state value if the target execution result is the execution failure.

And the state value maintaining sub-module is used for maintaining the state value of the callback mark as the first state value if the target execution result is that the execution is successful.

And the execution result saving module 230 is configured to save, when the plurality of nodes have been traversed, execution results corresponding to callback functions included in the plurality of nodes.

Further, the execution result saving module 230 includes: the system comprises a correlation information acquisition sub-module and an execution result storage sub-module, wherein:

and the associated information acquisition sub-module is used for acquiring associated information corresponding to callback functions respectively included by the plurality of nodes.

And the execution result storage submodule is used for storing the execution results corresponding to the callback functions respectively included by the plurality of nodes and the associated information corresponding to the callback functions respectively included by the plurality of nodes.

Further, the execution result saving module 230 includes: the device comprises a first execution result storage sub-module and a second execution result storage sub-module, wherein:

and the first execution result storage submodule is used for storing the execution results corresponding to the callback functions respectively included by the plurality of nodes in a file read-write mode.

And the second execution result storage sub-module is used for storing the execution results corresponding to the callback functions respectively included by the plurality of nodes in a read-write mode of the block equipment.

Further, the flow monitoring device 200 further includes: and an execution result recording module, wherein:

and the execution result recording module is used for recording the execution result corresponding to the callback function included in the traversed node in an execution result recording table, wherein the execution result recording table is created when the callback is triggered.

Further, the flow monitoring device 200 further includes: the device comprises a callback function determining module, an execution result obtaining module and a processing module, wherein:

A callback function determination module for determining a registered target callback function in response to registering a callback,

an execution result obtaining module, configured to obtain an execution result corresponding to the target callback function from the saved execution results corresponding to the callback functions included in the plurality of nodes if the callback functions included in the plurality of nodes include the target callback function,

and the processing module is used for processing based on the execution result corresponding to the target callback function.

Further, the processing module includes: a registration result determination sub-module and a processing sub-module, wherein:

and the registration result determining submodule is used for determining a registration result corresponding to the target callback function, wherein the registration result comprises registration success or registration failure.

And the processing sub-module is used for processing based on the execution result corresponding to the target callback function and the registration result corresponding to the target callback function.

Further, the processing submodule includes: a first abnormality information generation unit and a processing unit, wherein:

and the first abnormal information generating unit is used for generating first abnormal information if the execution result corresponding to the target callback function is execution failure or non-execution and/or the registration result corresponding to the target callback function is registration failure.

And the processing unit is used for carrying out exception processing based on the first exception information.

Further, the triggering callback includes a device reset callback, and the flow monitoring apparatus 200 further includes: the device comprises an execution result judging module, an execution result reading module and an abnormal information processing module, wherein:

and the execution result judging module is used for determining whether the equipment stores the execution results corresponding to the callback functions respectively included by the plurality of nodes in the equipment starting process.

And the execution result reading module is used for reading the stored execution results corresponding to the callback functions respectively included by the plurality of nodes if the equipment is determined to store the execution results corresponding to the callback functions respectively included by the plurality of nodes.

And the exception information processing module is used for generating second exception information and performing exception processing based on the second exception information if the equipment is determined to not store the execution results corresponding to the callback functions respectively included by the plurality of nodes or not successfully read the stored execution results corresponding to the callback functions respectively included by the plurality of nodes.

It will be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working process of the apparatus and modules described above may refer to the corresponding process in the foregoing method embodiment, which is not repeated herein.

In several embodiments provided herein, the coupling of the modules to each other may be electrical, mechanical, or other.

In addition, each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist alone physically, or two or more modules may be integrated into one module. The integrated modules may be implemented in hardware or in software functional modules.

Referring to fig. 17, a block diagram of an electronic device 100 according to an embodiment of the present application is shown. The electronic device 100 may be a smart phone, a tablet computer, an electronic book, or the like capable of running an application program. The electronic device 100 in this application may include one or more of the following components: a processor 110, a memory 120, and one or more application programs, wherein the one or more application programs may be stored in the memory 120 and configured to be executed by the one or more processors 110, the one or more program(s) configured to perform the method as described in the foregoing method embodiments.

Wherein the processor 110 may include one or more processing cores. The processor 110 utilizes various interfaces and lines to connect various portions of the overall electronic device 100, perform various functions of the electronic device 100, and process data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 120, and invoking data stored in the memory 120. Alternatively, the processor 110 may be implemented in hardware in at least one of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field-Programmable Gate Array, FPGA), programmable logic array (Programmable Logic Array, PLA). The processor 110 may integrate one or a combination of several of a central processing unit (Central Processing Unit, CPU), a graphics processor (Graphics Processing Unit, GPU), and a modem, etc. The CPU mainly processes an operating system, a user interface, an application program and the like; the GPU is used for being responsible for rendering and drawing the content to be displayed; the modem is used to handle wireless communications. It will be appreciated that the modem may not be integrated into the processor 110 and may be implemented solely by a single communication chip.

The Memory 120 may include a random access Memory (Random Access Memory, RAM) or a Read-Only Memory (Read-Only Memory). Memory 120 may be used to store instructions, programs, code, sets of codes, or sets of instructions. The memory 120 may include a stored program area and a stored data area, wherein the stored program area may store instructions for implementing an operating system, instructions for implementing functions (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the various method embodiments described below, and the like. The storage data area may also store data created by the electronic device 100 in use (e.g., phonebook, audiovisual data, chat log data), and the like.

Referring to fig. 18, a block diagram of a computer readable storage medium according to an embodiment of the present application is shown. The computer readable medium 300 has stored therein program code which can be invoked by a processor to perform the methods described in the method embodiments described above.

The computer readable storage medium 300 may be an electronic memory such as a flash memory, an EEPROM (electrically erasable programmable read only memory), an EPROM, a hard disk, or a ROM. Optionally, the computer readable storage medium 300 comprises a non-volatile computer readable medium (non-transitory computer-readable storage medium). The computer readable storage medium 300 has storage space for program code 310 that performs any of the method steps described above. The program code can be read from or written to one or more computer program products. Program code 310 may be compressed, for example, in a suitable form.

In summary, in the process monitoring, the device, the electronic equipment and the storage medium provided in the embodiments of the present application, a callback list is traversed in response to a trigger callback, where a plurality of nodes are arranged in the callback list in a priority order from high to low, each of the plurality of nodes includes a callback function, and an execution result corresponding to the callback function included in the traversed node is determined, where the execution result includes execution success, execution failure or non-execution, and when the plurality of nodes are traversed, the execution result corresponding to the callback function included in each of the plurality of nodes is saved, so that by traversing all the nodes in the callback list, and recording the execution result corresponding to the callback function included in each of all the nodes according to execution success, execution failure or non-execution, reliability monitoring of the callback process can be ensured, so as to improve reliability of the product.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and are not limiting thereof; although the present application has been described in detail with reference to the foregoing embodiments, one of ordinary skill in the art will appreciate that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not drive the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A process monitoring method, the method comprising:

responding to a triggering callback, traversing a callback linked list, wherein a plurality of nodes are arranged in the callback linked list according to the order of priority from high to low, and each node comprises a callback function;

determining an execution result corresponding to a callback function included in the traversed node, wherein the execution result comprises execution success, execution failure or non-execution;

and under the condition that the plurality of nodes are traversed, storing execution results corresponding to callback functions respectively included by the plurality of nodes.

2. The method according to claim 1, wherein determining the execution result corresponding to the callback function included in the traversed node includes:

if traversing to a target node in the plurality of nodes and the target node is a head node in the plurality of nodes or an execution result corresponding to a callback function included in a previous node of the target node is successful execution, executing the callback function included in the target node;

determining a target execution result corresponding to a callback function included by the target node;

if the target execution result is the execution failure, traversing all nodes arranged behind the target node in the plurality of nodes, and determining the execution results corresponding to callback functions included in all nodes arranged behind the target node as unexecuted.

3. The method according to claim 2, wherein the method further comprises:

if the target node in the plurality of nodes is traversed, and the execution result corresponding to the callback function included in the previous node of the target node is the execution failure or is not executed, the callback function included in the target node is not executed, and the execution result corresponding to the callback function included in the target node is determined to be not executed.

4. The method according to claim 2, wherein the method further comprises:

if traversing to a target node in the plurality of nodes, determining a state value of a callback flag, wherein the callback flag is created when a callback is triggered, and the state value of the callback flag is set to be a first state value when the callback is created;

if the state value of the callback flag is the first state value, determining that the target node is the first node of the plurality of nodes or the execution result corresponding to the callback function included in the previous node of the target node is successful execution; or alternatively

And if the state value of the callback flag is the second state value, determining that the execution result corresponding to the callback function included in the previous node of the target node is execution failure or non-execution.

5. The method according to claim 4, wherein the method further comprises:

if the target execution result is that the execution fails, updating the state value of the callback flag from the first state value to the second state value; or alternatively

And if the target execution result is that the execution is successful, maintaining the state value of the callback flag as the first state value.

6. The method according to claim 1, further comprising, after determining the execution result corresponding to the callback function included in the traversed node:

recording an execution result corresponding to a callback function included in the traversed node in an execution result record table, wherein the execution result record table is created when the callback is triggered.

7. The method of claim 1, wherein the saving the execution results corresponding to the callback functions included in each of the plurality of nodes comprises:

acquiring associated information corresponding to callback functions respectively included by the plurality of nodes;

and storing an execution result corresponding to the callback function respectively included by the plurality of nodes and associated information corresponding to the callback function respectively included by the plurality of nodes.

8. The method of claim 1, wherein the saving the execution results corresponding to the callback functions included in each of the plurality of nodes comprises:

storing execution results corresponding to callback functions respectively included by the plurality of nodes in a file reading and writing mode; or alternatively

And storing the execution results corresponding to the callback functions respectively included by the plurality of nodes in a read-write mode of the block equipment.

9. The method according to any one of claims 1 to 8, further comprising, after storing execution results corresponding to callback functions included in each of the plurality of nodes in the case where the plurality of nodes have been traversed,:

responsive to registering the callback, determining a registered target callback function;

if the callback functions included by the nodes respectively comprise the target callback functions, acquiring the execution results corresponding to the target callback functions from the stored execution results corresponding to the callback functions included by the nodes respectively;

and processing based on the execution result corresponding to the target callback function.

10. The method of claim 9, wherein the processing based on the execution result corresponding to the target callback function comprises:

Determining a registration result corresponding to the target callback function, wherein the registration result comprises registration success or registration failure;

and processing based on the execution result corresponding to the target callback function and the registration result corresponding to the target callback function.

11. The method of claim 10, wherein the processing based on the execution result corresponding to the target callback function and the registration result corresponding to the target callback function comprises:

if the execution result corresponding to the target callback function is execution failure or non-execution, and/or the registration result corresponding to the target callback function is registration failure, generating first abnormal information;

and performing exception processing based on the first exception information.

12. The method according to any one of claims 1-8, wherein the triggering callback includes a device reset callback, and further comprising, after storing execution results corresponding to callback functions included by each of the plurality of nodes in the case where the plurality of nodes are traversed:

in the process of starting equipment, determining whether the equipment stores execution results corresponding to callback functions respectively included by the plurality of nodes;

If the equipment is determined to store the execution results corresponding to the callback functions respectively included in the plurality of nodes, reading the stored execution results corresponding to the callback functions respectively included in the plurality of nodes; or alternatively

And if the equipment is determined to not store the execution results corresponding to the callback functions respectively included in the plurality of nodes, or the stored execution results corresponding to the callback functions respectively included in the plurality of nodes are not successfully read, generating second exception information, and performing exception processing based on the second exception information.

13. A process monitoring device, the device comprising:

the callback link list traversing module is used for responding to triggering callback and traversing a callback link list, wherein a plurality of nodes are arranged in the callback link list according to the order of priority from high to low, and each node comprises a callback function;

the execution result determining module is used for determining an execution result corresponding to a callback function included in the traversed node, wherein the execution result comprises execution success, execution failure or non-execution;

and the execution result storage module is used for storing the execution results corresponding to the callback functions respectively included by the plurality of nodes under the condition that the plurality of nodes are traversed.

14. An electronic device comprising a memory and a processor, the memory coupled to the processor, the memory storing instructions that when executed by the processor perform the method of any of claims 1-12.

15. A computer readable storage medium having stored therein program code which is callable by a processor to perform the method according to any one of claims 1-12.