CN113672458A

CN113672458A - Application program monitoring method, electronic equipment and storage medium

Info

Publication number: CN113672458A
Application number: CN202110950278.5A
Authority: CN
Inventors: 成梦阳
Original assignee: Beijing Keynote Network Inc
Current assignee: Beijing Keynote Network Inc
Priority date: 2021-08-18
Filing date: 2021-08-18
Publication date: 2021-11-19
Anticipated expiration: 2041-08-18
Also published as: CN113672458B

Abstract

The present disclosure relates to a monitoring method of an application program, an electronic device, and a storage medium, including: when a preset process starts, creating a node and associating the node with the process, taking the node as a root node of a tree structure, creating a stack corresponding to a current thread and stacking the node; monitoring a function called in the process, generating a starting time stamp when the function calling starts, creating a new node, and associating the new node with the function; reading a stack top element of a corresponding stack to be used as a father node of the node; when the function is synchronously called, the node is stacked to a stack corresponding to a thread for calling the function; when the function call is finished, generating an end timestamp, and popping the corresponding stack top element; when the function is asynchronous, when the function execution starts, the node is stacked to a stack corresponding to a thread for executing the function; when the function execution is finished, generating a finishing timestamp, and popping the corresponding stack top element out of the stack; at the end of the process, an end timestamp of the process is generated. Monitoring of the application program is achieved.

Description

Application program monitoring method, electronic equipment and storage medium

Technical Field

The present disclosure relates to the field of computers, and in particular, to a method for monitoring an application program, an electronic device, and a storage medium.

Background

With the continuous and deep development of the mobile internet, mobile terminal users gradually tend to be in a saturated state, the scale of mobile internet users is increased, the traffic pool is continuously decreased, the traffic pool is basically saturated, and the competition among mobile applications is gradually changed from the original 'attention to refresh' to 'attention to retention'. In such an increasingly competitive environment, it becomes important how to give the user a better experience and to preempt more users for a longer period of time. However, the quality of the user application experience directly determines whether the user wishes to continue using the mobile application, and serious problems such as startup flash back, page jam or incapability of opening, application flash back and the like become the main cause of user loss at present. How to monitor applications to provide effective improvement information has not been an effective solution.

Disclosure of Invention

In order to solve the technical problem or at least partially solve the technical problem, the present disclosure provides a monitoring method of an application program, an electronic device, and a storage medium.

In a first aspect, the present disclosure provides a monitoring method applied to an electronic device, including: when the starting of a preset process of an application program is monitored, creating a node, associating the node with the preset process, setting the node as a root node of a tree structure, creating a stack corresponding to a current thread and stacking the node; monitoring a function called in a preset process, and for the monitored function: when the function calling is monitored to start, generating a function starting time stamp, creating a new node, and associating the new node with the function identifier; reading a stack top element of a stack corresponding to a thread of a calling function as a parent node of a new node; under the condition that the function is synchronously called, a new node is stacked to a stack corresponding to a thread for calling the function; when the function calling is monitored to be ended, generating an ending timestamp of the function, and popping stack top elements of a stack corresponding to a thread calling the function; and/or when the function is asynchronously called, when the function execution starts, a new node is stacked to a stack corresponding to a thread executing the function; when the function execution is monitored to be finished, generating a function finishing time stamp, and popping stack top elements of a stack corresponding to a thread for executing the function; and when the preset process is monitored to be ended, generating an ending timestamp of the preset process.

In some embodiments, pushing the new node to the stack corresponding to the thread executing the function further includes: judging whether a stack corresponding to a thread executing a function exists or not; and if the stack corresponding to the thread executing the function does not exist, creating the stack corresponding to the thread executing the function.

In some embodiments, the monitoring method further comprises: and under the condition that the function is asynchronously called, monitoring whether the calling of the function is overtime, and if the calling of the function is overtime, not counting the execution time consumption of the function into the time consumption of a preset process.

In some embodiments, the functions include page-loaded functions, wherein a node is created for a page-loaded function and a function of all views included in the page-load is associated therewith, wherein a start timestamp and an end timestamp of each view-load are recorded.

In some embodiments, the function comprises a network request, wherein the network request is treated as an asynchronous call if the network request is issued through an api with Completion Handler; if the network request is sent out through the delete api, a node is created for the function of the network request, the node is associated with the task of the network request, when the delete method is called, the node is obtained through the task and is stacked, and when the delete method calling is finished, the node is popped up to associate each stage of the network request.

In some embodiments, a method for monitoring calls made during a predetermined procedure includes: the functions called during the preset process are monitored in a hook manner.

In some embodiments, the identification of the function includes a class name and a method name.

In some embodiments, the preset process includes a start-up process, a page loading process, or a user operation process of the application.

In a second aspect, the present disclosure provides an electronic device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor; the computer program, when executed by a processor, implements the steps of the method of any of the embodiments of the present disclosure.

In a second aspect, the present disclosure provides a computer-readable storage medium having a monitoring program stored thereon, where the monitoring program is executed by a processor to implement the steps of the monitoring method of any of the embodiments of the present disclosure.

Compared with the prior art, the technical scheme provided by the embodiment of the disclosure has the following advantages: the method provided by the embodiment of the disclosure realizes monitoring of the process of the application program in the electronic device, and obtains the time consumption of the process, the function call relation of the process and the time consumption of the function.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure.

In order to more clearly illustrate the embodiments or technical solutions in the prior art of the present disclosure, the drawings used in the description of the embodiments or prior art will be briefly described below, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without inventive exercise.

Fig. 1 is a schematic hardware structure diagram of an implementation manner of an electronic device according to an embodiment of the present disclosure;

FIG. 2 is a flow chart of one embodiment of a monitoring method provided by the embodiments of the present disclosure;

fig. 3 is a block diagram of a monitoring device according to an embodiment of the present disclosure.

Detailed Description

It should be understood that the specific embodiments described herein are merely illustrative of the disclosure and are not intended to limit the disclosure.

In the following description, suffixes such as "module", "component", or "unit" used to denote elements are used only for the convenience of explanation of the present disclosure, and have no specific meaning in themselves. Thus, "module", "component" or "unit" may be used mixedly.

The electronic equipment provided in the embodiment of the disclosure comprises a mobile terminal such as a smart phone, a smart watch, a tablet computer and the like. The electronic device provided in the embodiments of the present disclosure may include: a Radio Frequency (RF) unit, a WiFi module, an audio output unit, an a/V (audio/video) input unit, a sensor, a display unit, a user input unit, an interface unit, a memory, a processor, and a power supply.

The electronic device 10 provided by the embodiment of the present disclosure at least includes but is not limited to: a memory 11, a processor 12, which may be communicatively coupled to each other via a system bus, as shown in FIG. 1. It is noted that fig. 1 only shows the electronic device 10 with components 11-12, but it is to be understood that not all of the shown components are required to be implemented, and that more or fewer components may be implemented instead.

In some embodiments, the storage 11 may be an internal storage unit of the electronic device 10, such as a hard disk or a memory of the electronic device 10. In other embodiments, the memory 11 may also be an external storage device of the electronic device 10, such as a flash memory card equipped on the electronic device 10. Of course, the memory 11 may also include both internal and external memory units of the electronic device 10. In this embodiment, the memory 11 is generally used for storing an operating system 111 and various application programs 111 installed in the electronic device 10. Further, the memory 11 may also be used to temporarily store various types of data that have been output or are to be output.

Processor 12 may be a Central Processing Unit (CPU), controller, microcontroller, microprocessor, or other data Processing chip in some embodiments. The processor 12 is generally operative to control overall operation of the electronic device 10. In this embodiment, the processor 12 is configured to run program codes stored in the memory 11 or process data.

Based on the hardware structure of the electronic device, various embodiments of the method are provided.

The embodiment of the present disclosure provides a monitoring method, which is applied to an electronic device, and is used for monitoring a process of an application program in the electronic device to obtain time consumed by the process, a function call relationship of the process, and time consumed by a function, as shown in fig. 2, the monitoring method includes steps S202 to S212.

Step S202, when the beginning of the preset process of the application program is monitored, a node is created and is associated with the preset process, the node is set to be a root node of a tree structure, a stack corresponding to the current thread is created, and the node is stacked.

In some examples, the corresponding relationship between the thread and the stack is established by taking the identification of the thread as the identification of the stack corresponding to the thread.

In some examples, the corresponding function is called at the main thread at the beginning of the pre-set process, the current thread being the main thread. In other examples, the function corresponding to the preset process is called at the child thread at the beginning of the preset process, and the current thread is the child thread calling the function.

Step S204, monitoring the function called in the preset process.

In the disclosed embodiment, for a monitored function, a call chain of the function and a time consumption of the function are determined. Specifically, the method includes steps S206 to S210. In some examples, but not limited to, a portion of the function is monitored during the predetermined procedure.

Step S206, when the function calling is monitored to start, generating a function starting time stamp, creating a new node, and associating the new node with the function identifier; and reading a stack top element of a stack corresponding to the thread of the calling function as a parent node of the new node.

In some examples, the identification of the function includes a class name and a method name.

In embodiments of the present disclosure, the invocation of the function includes a synchronous call and/or an asynchronous call. Generally, in the synchronous call, when a function call is issued, the call is not returned until a result is not obtained, and the program is not executed next; in asynchronous calls, when an asynchronous call is issued, the caller cannot get the result immediately, and the component actually handling the call notifies the caller via state, notification, and callback (Handler mechanism) after completion.

In some examples, the preset procedure includes a synchronization call. In other examples, the preset procedure includes a synchronous call and an asynchronous call.

In the embodiment of the present disclosure, in the case that the function is a synchronous call, the process proceeds to step S208. In the case where the function is an asynchronous call, the process proceeds to step S210.

Step S208, a new node is stacked to a stack corresponding to the thread of the calling function; and when the function call is monitored to be ended, generating an ending timestamp of the function, and popping the stack top element of the stack corresponding to the thread calling the function.

In the embodiment of the present disclosure, in the case of synchronous call, the call and execution of the function are performed in the same thread. Illustratively, method a executed by the main thread synchronously calls method B, which is to be executed by the main thread, and the node of method B is stacked on the stack corresponding to the main thread.

Step S210, when the function execution starts, a new node is stacked to a stack corresponding to the thread executing the function; and when the function execution is monitored to be finished, generating a function finishing time stamp, and popping the stack top element of the stack corresponding to the thread for executing the function.

In the embodiment of the present disclosure, in the case of asynchronous calling, the calling and execution of the function are executed in the same thread or different threads. When the function is executed, the node corresponding to the function is put into a stack corresponding to the thread of the stack path execution function. And if the thread for executing the function is the same as the thread for calling the function, the node is pushed to the stack corresponding to the thread, and the node becomes the top element of the stack. If the thread (for example, sub-thread 1) for executing the function is different from the thread (for example, main thread) for calling the function, judging whether a stack corresponding to the thread (namely, sub-thread 1) for executing the function exists, if so, stacking the node to the stack corresponding to the sub-thread 1, if not, creating the stack corresponding to the sub-thread 1, and stacking the node to the created stack, wherein the node becomes the top element of the stack.

Illustratively, a function a executed by the main thread creates a node for the function a, and stacks the node a associated with the function a to the stack corresponding to the main thread, where the node a associated with the function a is used as the top-of-stack element of the stack. The function A calls the function B in an asynchronous mode, when the function B is called, a stack top element (namely a node a) is read from a stack corresponding to a main thread, a node B corresponding to the function B is created and is used as a child node of the read stack top element, and a node a corresponding to the stack top element is a parent node of the node B corresponding to the function B, so that the calling relation between the function B and the function A is established. And the asynchronously called function B is executed by the sub-thread 1, a stack corresponding to the sub-thread 1 is created when the function B is executed, and the node B corresponding to the function B is stacked to the stack corresponding to the sub-thread 1. At the end of the function B execution, the top element of the stack corresponding to child thread 1 (i.e., node B) is popped.

In some examples, asynchronously called functions may call one or more functions in a synchronous manner. In the embodiment of the present disclosure, the function called synchronously among the asynchronously called functions is processed according to step S206 and step S208. For example, when function a called asynchronously calls function B in a synchronous manner during execution, the node associated with function B is a child node of the node associated with function a. When the function B call starts, the node associated with the function B is stacked to the stack corresponding to the thread executing the function A.

In some examples, a synchronously called function may call one or more functions in an asynchronous manner. In the embodiment of the present disclosure, the asynchronously called function among the synchronously called functions is processed according to step S206 and step S210. Illustratively, function a, which is called synchronously, calls function B asynchronously when called, and the node associated with function B is a child node of the node associated with function a. When the function B is executed, the node associated with the function B is stacked to the stack corresponding to the thread executing the function B.

Step S212, when it is monitored that the preset process is ended, an end timestamp of the preset process is generated.

In the disclosed embodiment, a start point and an end point of a preset process are set. In some examples, the starting point of the preset process is a predetermined function, the execution process of the predetermined function calls one or more other functions, and finally returns to the predetermined function, and the ending point of the preset process is the end of the execution of the predetermined function. In other examples, the preset process may begin with a first function and end with a second function, and one or more other functions may be called between the first function and the second function. In some cases, a process of an application may involve a large number of functions, and in some examples, portions of the functions may be monitored as needed.

In the disclosed embodiment, the preset process includes, but is not limited to: the method comprises the steps of starting an application program, loading a page and operating a user. A preset process may include one or more other preset processes (as sub-processes). For example, the startup process of an application includes a page loading process (typically the loading process of the application's home/home page), and the user operation process (if the operation results in a page switch, e.g., clicking on the "login" application will switch from the login page to the home page) may include the page loading process.

In the embodiment of the present disclosure, the time consumption of the preset process from the start point to the end point is monitored, and meanwhile, the call chain in the preset process, that is, the call relationship of the function in the preset process, and the time consumption of each function are monitored. In the embodiment of the disclosure, according to the monitored time consumption of the preset process, the function call relationship, and the function time consumption, a plurality of performance indicators may be defined, and the performance indicators may be related to the time consumption of one or more functions.

In some examples, the corresponding function may call one or more functions synchronously or asynchronously at the beginning of the pre-set procedure, and each of the one or more functions may call one or more functions synchronously or asynchronously. In the embodiment of the present disclosure, the caller is used as a parent node of the callee, and the callee is used as a child node of the caller. For example, the function a calls the function B and the function C in sequence, the node related to the function a is a parent node of the nodes related to the function B and the function C, and the node related to the function B and the node related to the function C are child nodes of the nodes related to the function a and are in the same level. Further, the function B calls the function D, and the function D calls the function E, where the node associated with the function D is used as a child node of the node associated with the function B, and the node associated with the function E is used as a child node of the node associated with the function D.

In the embodiment of the present disclosure, the network request is an important process in the application, for example, the network request may be involved in the process of page loading, application starting and the like. In some examples, the function of the network request is monitored to derive a course and time consuming of the network request. For example, in the starting process of the application program, user information is acquired through a network request, and a page is displayed according to the user information.

In the embodiment of the present disclosure, page loading is an important process in an application, and for example, page loading may be involved in user operation, application startup, and the like. In some examples, the function of page loading is monitored to derive the process and time consumption of page loading.

Illustratively, page loading is staged, i.e., views of a page are loaded according to the relationship between the views that the page contains. And creating nodes, wherein the life cycles of all views in the page loading process are contained. The starting point of page loading is the function causing page loading, and the ending point of page loading is ViewDidAppear of a parameter ViewController in a page loading method.

Illustratively, a tree structure (i.e., a call chain tree) of a preset process is traversed in a breadth-first manner, and if the node is a lifecycle node of the view, the node is taken out, and traversal of child nodes of the node is stopped. The traversed nodes are then combined into a new page-loaded tree. And then traversing the tree from the page loaded tree by adopting a preorder traversal mode again, taking out the nodes of the life cycle of the node ViewController, and organizing the call chain tree of a single ViewController according to the address of the ViewController recorded in the nodes.

Illustratively, if a network request from the delegat api is used. The network requests that the user code be notified in stages after the data is received. In this case, a virtual node is created at the beginning of the network request, and then the nodes of the network request are associated by the virtual node. The virtual node is transferred in each stage in an associated object mode of OC runtime. The node will push and pop with each delete method to ensure that each delete method can be correctly associated.

In some embodiments, the functions called during the provisioning process are monitored in a hook fashion. Exemplary, some methods of interest utilize the OC runtime feature and the fisherhook et al technology hook. The method specifically comprises the following steps: the method comprises the steps of a proxy method called in the starting process of an application program, a method responding to user operation, a partial life cycle method of UIViewController and subclasses thereof, a page switching method, a method for realizing synchronous and asynchronous calling, a method for requesting a library through a network, an I/O method provided by a system, a Json serialization and deserialization method and the like.

Example (c): call chain tracing

Some interesting methods are based on the OC runtime characteristics and the technical hook of fisherhook et al. The method specifically comprises the following steps: the method comprises the steps of invoking an agent method in the App starting process, responding to a user operation method, a UIViewController and a partial life cycle method of the subclass thereof, a page switching method, a method for realizing synchronous and asynchronous invoking, a method for requesting a library through a network, an I/O method provided by a system, and Json serialization and deserialization methods.

When starting or operating by a user, an Action can be abstracted, and the SDK creates an object with a tree data structure. The root node is a class name and a method name which are started or respond to user operation, records the node name, a starting timestamp and adds one to the count of the uncompleted node. And meanwhile, creating a data structure of a stack by taking the thread as the key, and pushing the node into the stack.

When the method is started or the method responding to the user operation is called, the method concerned by the user is called. If it is synchronous, we create a node, record the name, start timestamp, etc., and add one to the incomplete node count, take its parent node from the stack and mount it under the parent node, then push the node onto the stack, if there are more method calls we are interested in the method, repeat the previous logic.

If the method is asynchronous calling, when the asynchronous method calling starts, a node is created, the name and the asynchronous calling timestamp are recorded, and the count of the unfinished node is increased by one. Then, the father node is taken out from the stack and mounted below the father node. Unlike synchronous calls, this asynchronous node is not pushed onto the stack at this point. And when the asynchronously called task really starts to execute, acquiring a data structure of a stack by taking a thread for executing the task as a key, if the node can be pushed to the stack, and if the node cannot be pushed, establishing a data structure of the stack by taking the thread as the key and pushing the node. How does the asynchronous task execution get the nodes created when the asynchronous call is made here? GCD is a method for capturing external variables through block, and the asynchronous mode of NSOperation and performSelector is transmitted through the mode of runtime correlation objects. If the method we are interested in is called in the asynchronous task execution, the previous logic is repeated. And after the asynchronous task is executed, recording the completion timestamp, and reducing the count of the uncompleted nodes by one.

When the incomplete node count is 0, the call chain of this Action is completed. A tree-structured call relation chain is formed.

Example (c): network association

If a user makes a network request using an api with a committionhandler, the network request may be associated in an asynchronous call. If the user uses a network request from delegage's api. The network requests that the user code be notified in stages after the data is received. In this case, the SDK is created by creating a node at the beginning of issuing the network request, and then associating the nodes of the network request with each other through the node. The node is transferred in each stage by an associated object mode of OC runtime. The node will push and pop with each delete method to ensure that each delete method can be correctly associated.

Page loading:

the switching of pages is caused by an Action. The method for page switching can be in the process of Action calling, namely the page switching node can be mounted in the tree structure of the Action calling chain. Page switching is phased similar to the request issuing using delete. The same way as network request processing using delete takes place. And creating a node, wherein the difference is that the node does not call push and pop along with the life cycle method. Push and pop are only performed once, and all the lifecycle of the ViewController is included in the process of switching pages. The page switching end point is ViewDidAppear of a parameter ViewController in the page switching method.

And traversing the call chain tree of the Action in a breadth-first mode, if the node is the lifecycle node of the ViewController, taking out the node, and stopping traversing the child nodes of the node. The traversed nodes are then combined into a new page-loaded tree. And then traversing the tree from the page loaded tree by adopting a preorder traversal mode again, taking out the nodes of the life cycle of the node ViewController, and organizing the call chain tree of a single ViewController according to the address of the ViewController recorded in the nodes.

It should be understood that the embodiments of the present disclosure also include monitoring and recording other performance data in the preset process, or in the function of the preset process. In the embodiment of the present disclosure, details of the real user equipment (for example, a device model, an operating system version, an operator, a network status, and the like) may also be recorded, which is not limited by the embodiment of the present disclosure.

The following describes a monitoring method according to an embodiment of the present disclosure, by taking a starting process of an application program, a page loading process, or a user operation process as an example.

Example one: page loading process

The method of using an automated test program or system tool to be able to analyze only a single view (Activity or Viewcontroller) is time consuming, but the user's visual page is composed of "views" one after the other. In this example, views of the development perspective are combined into a page in a user-perceived perspective. A page may include multiple views. In the case of the present example,

in this example, the focus metrics for the page loading process include:

(1) interactive time: defined as the time the page is open until the user can interact normally. Android starts from onCreat/onStart of the first view to the end of onResume of the last view. The iOS starts with viewDidLoad/viewWillAppear and ends with the last viewDidApper.

(2) The first screen time: defined as the time from the page being opened to the content being presented (including the network elapsed time). The process is page loading, starting with the first lifecycle method and ending with the last asynchronous call method back to the main thread.

In this example, factors that affect the user experience include: slow interactability (e.g., start-up takes more than 3 s); slow first screen: the page whose first screen takes longer than a given threshold (e.g., threshold 3000 ms). The dimensions of interest include: region, operator, access mode, equipment, operating system.

For example, it can be known from the interaction time of the "commodity page", that the user needs to wait for two seconds to interact, and by using the chain "exploded view", it can be determined that the reason why the "commodity page" cannot interact is that the execution time of "table view controller.

For example, looking at the first screen time of the "commodity details" page may find that the first screen loading time is close to 5s, and in the call chain exploded view, it can be seen that the "view controllernew # view willapplearer" method requests a service API interface, and the service API interface calls the "request commodity" interface after the response (response time 1076ms) is finished, whereas the interface refreshes the interface to display the commodity after the response (response time 3144ms) is finished. After analysis, it can be known that the main reason for the slow initial screen time of the "merchandise page" is that the response time of the "merchandise request" interface is too long, which is mainly consumed in the "initial package time", so that the back-end logic can be optimized.

In the example, the user retention rate and the brand comfort can be improved by optimizing the availability of the key operation, and the service conversion rate can be directly improved to achieve the purpose of increasing the service amount.

Example two: user operating process

In this example, the user operates a process, i.e., user interaction. The analysis interaction time consumption can provide operation availability and performance trend data display in the operation process of a real user, provide abnormal data analysis and tracking in the operation process, change the standard and method for measuring user experience, and upgrade the monitoring of the application program from research and development of an operation and maintenance performance analysis tool to a user experience management platform for guiding the service success value. Meanwhile, the value also helps to research, develop, operate and maintain the prevention risk, find, position and solve the performance problem, promote internal cooperation, increase the active guarantee of the help service and optimize the user experience so as to improve the brand goodness, user retention, service conversion rate, service achievement number and service amount.

In this example, the user operational process attention indicators include: the operation is time-consuming: the total time of operation (including the time of execution of the asynchronous method); the blocking takes time: the execution of the entry function during the operation is time-consuming (the user cannot perform any operation during the blocking process); and (3) smooth operation: and (4) performing operation which consumes less time and does not reach the set threshold value. Factors that affect the user experience include: and (3) crashing operation: the operation of crash/flash quit occurs in the application in the operation process; and (4) failure operation: an operation with a request error rate of 100% in the operation process (for example, three requests are sent out in the operation process, and if errors occur in all the three requests, the operation is an error operation); slow operation: the operation time exceeds the operation of the set threshold (default threshold 3S, configurable); and (3) clamping operation: and (4) blocking the operation which takes longer than the set threshold (default threshold 3S, configurable). The dimensions of interest include: region, operator, access mode, equipment, operating system.

In this example, the operation types include: 1) android: click events: onClick, onItemClick, ItemSelected, PageSelected; 2) and iOS: other operational events besides the system: uitagesturerecognizers (one click), uipinhgesturerecognizers (two-finger pinch), uiswippegesturgeurerecognizers (light sweep), uipaygesturgerecheckers (drag), uiscenededgepangesturgerecheckers (slide left from right edge of screen), uilongpressgesturgerecheckers (long press); and (4) control: UITableView-didSelectRow AtIndexPath, UICollectionView-didSelectItemAtIndexPath, UIPickerView-didSelectRow.

Illustratively, clicking on "login" when using the App on an iPad will always wait a long time. By monitoring the availability and the operation time consumption of the login operation, the availability directly reflects the condition whether the operation is unavailable due to breakdown or request error in the login operation process of the user, and the operation time consumption directly reflects the performance condition of the user in the login operation process.

In this example, the main reason why the user's login' is slow can be located is that an asynchronous method is called in the main thread 'login' method to update the user information, but the 'login page' must wait for the asynchronous method to finish executing before refreshing again, so the interface always turns around (i.e. waits for the page to load), and the user feels to wait for a long time after clicking the 'login' button.

Through the user perception quantification user operation experience index, the time consumption of the optimized key business operation can help operators to improve the conversion rate.

Example three: application startup procedure

In this example, the starting of the application program is divided into three different starting modes, namely first starting, cold starting and hot starting, and the time consumption of the different starting modes is collected respectively, so that research and development staff can be helped to know a combination scene in the use process of a real user. Such as: the first start after installation, the cold start after application quitting, and the hot start after application switching.

In this example, the startup process attention indicators of the application include: application program start time; initialization time, construction time and page loading time. Factors that affect the user experience include: slow start (e.g., start up takes more than 3 s); starting and flashing back: the application is flashed back after being started; starting errors: network data and errors during application startup. The dimensions of interest include: region, operator, access mode, equipment, operating system.

In this example, automatic spotting is performed for applying the respective lifecycle methods using Hook technology, where:

(1) first start or cold start procedure (time):

android: application. attachbasecontext () starts to the end of mainactivity. onresponse ();

and iOS: main function start time (SDK start time) to the end of first vc.

(2) Hot start process (time):

android: home key: activity.onrestart () starts to activity.onresture () ends; back key: activity.oncreate () starts to activity.onresponse () ends;

and iOS: application WillEntereForeground () starts to application DidBegome active ().

(3) Initialization procedure (time):

android: application init, Application.

And iOS: main function start time (SDK start time) to application delete.

(4) Construction time:

android: MainActivity init, application.attachbasecontext () ends to application.oncreate ();

and iOS: application delete, di finishlaninching within operations () starts to first vc.

(5) Page loading time:

android: vitality onCreate to onresource, application

And iOS: first vc

In this example, the first start or cold start procedure contains a critical time:

(1)Android：

application preparation time: application. attachbasecontext () starts to ends;

main page initialization time: application.attachbasecontext () ends to application.oncreate () ends;

view filling time: application.oncreate () ends to maintenance.oncreate () ends;

interaction preparation time: mainactivity.oncreate () ends to mainactivity.onresponse () ends;

(2)iOS：

initialization time: main function start time (SDK start time) to application delete.

Construction time: application delete, di finishlaninching within options () starts to first vc.

Page loading time: first vc.

In this example, the warm start process contains a critical time:

(1)Android：

view filling time: home key: application.oncreate () ends to maintenance.onrequest () ends; back key: application.oncreate () ends to maintenance.oncreate () ends;

interaction preparation time: home key: onerestart () ends to mainactivity oneresume (); back key: create () ends to create () ends

(2)iOS：

Page loading time: application WillEntereForeground () starts to application DidBegome active ().

Illustratively, the problem that App frequently has slow startup occurs, and the slow startup times of the 2.0 version of the application upgrade on the OPPO android6.0.1 can be determined to be most significant through dimension analysis.

For example, by looking at single sample data, the reason that the current start-up is slow for the first time is that a hot update framework of Bugly is used in the "application preparation phase", and the problem of overlong start-up time is caused by long time for loading multiple dex due to system reasons.

Through the starting experience analysis, business personnel can be helped to find slow starting, starting crash and frequently-occurring request errors (Http errors and network errors) in the starting process, research and development personnel can be prompted to pertinently optimize the user experience condition of the key business nodes, and the key point for helping the business personnel to improve the business conversion rate is actually achieved.

The embodiment of the present disclosure further provides a monitoring apparatus, which is applied to an electronic device, and is configured to monitor a process of an application program in the electronic device, and obtain time consumed by the process, a function call relationship of the process, and time consumed by a function, as shown in fig. 3, where the detecting apparatus includes:

a first module 310, configured to, when it is monitored that a preset process of an application program starts, create a node and associate the node with the preset process, set the node as a root node of a tree structure, create a stack corresponding to a current thread, and stack the node.

A second module 320, connected to the first module 310, configured to monitor a function called in a preset process, where for the monitored function: when the function calling is monitored to start, generating a function starting time stamp, creating a new node, and associating the new node with the function identifier; reading a stack top element of a stack corresponding to a thread of a calling function as a parent node of a new node; under the condition that the function is synchronously called, a new node is stacked to a stack corresponding to a thread for calling the function; when the function calling is monitored to be ended, generating an ending timestamp of the function, and popping stack top elements of a stack corresponding to a thread calling the function; and/or, when the function is asynchronously called, when the function is started to execute, pushing a new node to a stack corresponding to a thread executing the function; and when the function execution is monitored to be finished, generating a function finishing time stamp, and popping the stack top element of the stack corresponding to the thread for executing the function.

And a third module 330, connected to the second module 320, configured to generate an end timestamp of the preset process when it is monitored that the preset process is ended.

In some embodiments, the second module 320 is further configured to determine whether a stack corresponding to a thread executing a function exists before a new node is stacked onto a stack corresponding to a thread executing a function; and if the stack corresponding to the thread executing the function does not exist, creating the stack corresponding to the thread executing the function.

In some embodiments, the second module 320 is further configured to monitor whether the function is called overtime in the case that the function is called asynchronously, and if the function is called overtime, not count the execution time of the function as the time of the preset process.

The present embodiment also provides a computer-readable storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, a server, an App application mall, etc., on which a computer program is stored, which when executed by a processor implements corresponding functions. The computer readable storage medium of the present embodiments stores program code of any one or more of the disclosed embodiments, which when executed by a processor implements the method of any one or more of the disclosed embodiments.

In the related art, the starting time, the page time and the like of the application are counted by an Xcode/self-contained analysis tool or a code dotting mode. The time-consuming start-up and process is achieved by automated tools. Basic application performance tests can be performed only in a laboratory environment in a manual test mode, the starting time, view loading time and the like of applications can be obtained only through tools carried by some platforms, and the use condition of an online real user cannot be known. The embodiment of the disclosure realizes online monitoring of the use condition of a real user.

Due to the limitation of a self-contained tool of a development platform, research and development are needed to be matched for dotting key nodes, and testers can often test only one function or one page and cannot give consideration to the whole application. The embodiment of the disclosure realizes monitoring of any predefined process of the application program.

There are many factors affecting the user application experience, and a local test or test tool cannot correlate the network data of the application and cannot analyze the reason why the page picture cannot be loaded.

The embodiment of the disclosure realizes: the method comprises the steps of automatically collecting starting time consumption, page time consumption and user interaction time consumption of App application, respectively obtaining equipment information and code calling relation of each process, simultaneously providing details (equipment model, operating system version, operator and network state) of real user equipment, helping mobile developers to improve code quality, shorten edition sending period and optimize user experience.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The above-mentioned serial numbers of the embodiments of the present disclosure are merely for description and do not represent the merits of the embodiments.

Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solutions of the present disclosure may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal (e.g., a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present disclosure.

While the embodiments of the present disclosure have been described in connection with the drawings, the present disclosure is not limited to the specific embodiments described above, which are intended to be illustrative rather than limiting, and it will be apparent to those of ordinary skill in the art in light of the present disclosure that many more modifications can be made without departing from the spirit of the disclosure and the scope of the appended claims.

Claims

1. A monitoring method applied to electronic equipment is characterized by comprising the following steps:

when the beginning of a preset process of an application program is monitored, a node is created and is associated with the preset process, the node is set as a root node of a tree structure, a stack corresponding to a current thread is created, and the node is stacked;

monitoring a function called in the preset process, and for the monitored function:

when the function call is monitored to start, generating a starting timestamp of the function, creating a new node, and associating the new node with the identifier of the function; reading a stack top element of a stack corresponding to a thread calling the function as a father node of the new node;

under the condition that the function is synchronously called, the new node is pushed to a stack corresponding to a thread calling the function; when the function calling is monitored to be ended, generating an ending timestamp of the function, and popping stack top elements of a stack corresponding to a thread calling the function out of the stack; and/or

Under the condition that the function is called asynchronously, when the function is started to be executed, the new node is pushed to a stack corresponding to a thread for executing the function; when the function execution is monitored to be finished, generating a finishing time stamp of the function, and popping stack top elements of a stack corresponding to a thread for executing the function;

and when the preset process is monitored to be ended, generating an ending timestamp of the preset process.

2. The method according to claim 1, wherein before stacking the new node onto a stack corresponding to a thread executing the function, further comprising:

judging whether a stack corresponding to the thread executing the function exists or not;

and if the stack corresponding to the thread executing the function does not exist, creating the stack corresponding to the thread executing the function.

3. The monitoring method of claim 1, further comprising: and under the condition that the function is asynchronously called, monitoring whether the calling of the function is overtime, and if the calling of the function is overtime, not counting the execution time consumption of the function into the time consumption of the preset process.

4. The monitoring method according to claim 1, wherein the functions comprise functions of page loading, wherein a node is created for a function of page loading and a function of all views comprised by the page loading is associated therewith, wherein a start timestamp and an end timestamp of each view loading are recorded.

5. The monitoring method of claim 1, wherein the function comprises a network request, wherein,

if the network request is issued through an api with Completion Handler, treating the network request as an asynchronous call;

if the network request is sent out through the delete api, a node is created for the function of the network request, the node is associated with the task of the network request, when the delete method is called, the node is obtained through the task and is stacked, and when the delete method calling is finished, the node is popped up to associate each stage of the network request.

6. The method for monitoring as claimed in claim 1, wherein the method for monitoring the call in the preset process comprises: and monitoring the functions called in the preset process in a hook mode.

7. The monitoring method of claim 1, wherein the identification of the function includes a class name and a method name.

8. The monitoring method according to any one of claims 1 to 7, wherein the preset process includes: a start-up process of an application, a page loading process, or a user operation process.

9. An electronic device, characterized in that the electronic device comprises:

a memory, a processor, and a computer program stored on the memory and executable on the processor;

the computer program, when executed by the processor, implementing the steps of the method of any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that the computer-readable storage medium has stored thereon a monitoring program which, when executed by a processor, implements the steps of the monitoring method according to any one of claims 1 to 8.