CN113900910A

CN113900910A - Application program monitoring method and device, storage medium and electronic equipment

Info

Publication number: CN113900910A
Application number: CN202111489942.7A
Authority: CN
Inventors: 李钰; 盖作甲
Original assignee: Beijing Xintang Sichuang Educational Technology Co Ltd
Current assignee: Beijing Xintang Sichuang Educational Technology Co Ltd
Priority date: 2021-12-08
Filing date: 2021-12-08
Publication date: 2022-01-07

Abstract

The embodiment of the disclosure provides an application program monitoring method, an application program monitoring device, a storage medium and electronic equipment, wherein the method comprises the following steps: acquiring CPU use parameters of current threads of an application program; determining the current risk level based on the CPU use parameters of each thread; when the current risk level is higher than a preset risk level, stack information of a target thread is obtained; wherein the target thread is one or more of the threads; and performing symbolization processing on the stack information to obtain code information corresponding to the target thread.

Description

Application program monitoring method and device, storage medium and electronic equipment

Technical Field

The present invention relates to the field of computer technologies, and in particular, to an application monitoring method, an application monitoring apparatus, and a computer-readable storage medium and an electronic device for implementing the application monitoring method.

Background

With the popularization of smart terminal devices such as smart phones, the number of applications installed and run in the smart terminal devices is increased. In the running process of the application program, problems such as blocking or breakdown may occur, and the reason information of the problems occurring in the application program is collected so as to analyze the problems, analyze the performance of the application program and improve the application program, which is a key technology in application of the application program.

Currently, for monitoring problems such as application program jamming or crashing, when the problems such as jamming or crashing of the application program have occurred, analysis is usually performed based on a jamming log record when jamming occurs, or based on a crash file when crashing occurs. However, no solution for performing predictive analysis on the problem that the application program is about to be stuck or crashed exists at present.

Disclosure of Invention

According to an aspect of the present disclosure, there is provided an application monitoring method, including:

acquiring CPU use parameters of current threads of an application program;

determining the current risk level based on the CPU use parameters of each thread;

when the current risk level is higher than a preset risk level, stack information of a target thread is obtained; wherein the target thread is one or more of the threads;

and performing symbolization processing on the stack information to obtain code information corresponding to the target thread.

According to another aspect of the present disclosure, there is provided an application monitoring apparatus including:

the parameter acquisition module is used for acquiring CPU use parameters of each current thread of the application program;

the risk determination module is used for determining the current risk level based on the CPU use parameters of all threads;

the information acquisition module is used for acquiring stack information of the target thread when the current risk level is higher than a preset risk level; wherein the target thread is one or more of the threads;

and the information processing module is used for performing symbolization processing on the stack information to obtain source code information corresponding to the target thread.

According to another aspect of the present disclosure, there is provided an electronic device including:

a processor; and

a memory storing a program;

wherein the program comprises instructions which, when executed by the processor, cause the processor to perform the application monitoring method described above.

According to still another aspect of the present disclosure, there is provided a computer-readable storage medium storing computer instructions for causing a computer to execute the above application monitoring method.

According to one or more technical schemes provided in the embodiment of the application, CPU use parameters of each current thread of an application program are obtained; determining the current risk level based on the CPU use parameters of each thread; when the current risk level is higher than a preset risk level, stack information of a target thread is obtained; wherein the target thread is one or more of the threads; and performing symbolization processing on the stack information to obtain code information corresponding to the target thread. In this way, in this embodiment, when it is determined that the risk level exceeds the preset risk level according to the CPU usage parameter of each current thread of the application program, that is, when the application program is about to have a problem such as a stuck or a crash with a high probability, the stack information of the target thread may be obtained, symbolized, and recorded, so as to perform predictive analysis on the problem that may occur.

Drawings

Further details, features and advantages of the disclosure are disclosed in the following description of exemplary embodiments, taken in conjunction with the accompanying drawings, in which:

FIG. 1 shows a flow chart of an application monitoring method according to an exemplary embodiment of the present disclosure;

FIG. 2 shows a flow diagram of an application monitoring method according to another exemplary embodiment of the present disclosure;

FIG. 3 shows a flow chart of an application monitoring method according to yet another exemplary embodiment of the present disclosure;

FIG. 4 shows a flow chart of an application monitoring method according to yet another exemplary embodiment of the present disclosure;

FIG. 5 shows a flow diagram of an application monitoring method according to an embodiment of the present disclosure;

FIG. 6 shows a flow diagram of an application monitoring method according to another embodiment of the present disclosure;

FIG. 7 shows a schematic block diagram of an application monitoring apparatus according to an example embodiment of the present disclosure;

FIG. 8 illustrates a block diagram of an exemplary electronic device that can be used to implement embodiments of the present disclosure.

Detailed Description

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure are shown in the drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but rather are provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the disclosure are for illustration purposes only and are not intended to limit the scope of the disclosure.

It should be understood that the various steps recited in the method embodiments of the present disclosure may be performed in a different order, and/or performed in parallel. Moreover, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present disclosure is not limited in this respect.

The term "include" and variations thereof as used herein are open-ended, i.e., "including but not limited to". The term "based on" is "based, at least in part, on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Relevant definitions for other terms will be given in the following description. It should be noted that the terms "first", "second", and the like in the present disclosure are only used for distinguishing different devices, modules or units, and are not used for limiting the order or interdependence relationship of the functions performed by the devices, modules or units.

It is noted that references to "a", "an", and "the" modifications in this disclosure are intended to be illustrative rather than limiting, and that those skilled in the art will recognize that "one or more" may be used unless the context clearly dictates otherwise.

The names of messages or information exchanged between devices in the embodiments of the present disclosure are for illustrative purposes only, and are not intended to limit the scope of the messages or information.

In the following, a scheme of the present disclosure is described with reference to the accompanying drawings, and fig. 1 shows a flowchart of an application monitoring method according to an exemplary embodiment of the present disclosure, where the application monitoring method may be executed by an electronic device such as a smart phone, a tablet computer, and the like, and specifically may include the following steps:

step S101: and acquiring CPU use parameters of each current thread of the application program.

Illustratively, the CPU usage parameter may include, but is not limited to, CPU occupancy. When the application program starts to run, the CPU usage parameters, such as CPU occupancy, of each current thread of the application program can be acquired.

Step S102: the current risk level is determined based on the CPU usage parameters of each thread.

For example, the CPU usage parameter may have a positive correlation with the current risk level, e.g., if the CPU occupancy of each thread is greater, the determined current risk level is higher. The mapping relationship between different current risk levels and different CPU usage parameters, such as CPU occupancy, may be configured in advance as desired by user, without limitation.

Step S103: when the current risk level is higher than a preset risk level, stack information of a target thread is obtained; wherein the target thread is one or more of the threads.

For example, the preset risk level may be set in advance according to needs, and is not limited in this respect. When the determined current risk level is higher than the preset risk level, namely the determined current risk level indicates that the application program has a high probability of generating a problem such as jamming or breakdown and the like, the stack information of the target thread is acquired from each thread. The target thread may be a thread in which the CPU usage parameter in each thread is greater than a preset CPU usage parameter threshold, that is, the target thread indicates that the target thread is a thread that causes a high probability that an application program will have a problem, such as a stuck state or a crash. The preset CPU usage parameter threshold may be set according to specific needs, which is not limited to this.

Step S104: and performing symbolization processing on the stack information to obtain code information corresponding to the target thread.

Illustratively, the symbolization processing of the stack information of the target thread, for example, the symbolization processing is performed based on a pdb (program database) symbol table, so as to facilitate subsequent analysis by an analyst, and the symbolization processing obtains corresponding code information, such as recognizable code information, so as to facilitate the analyst to view. The symbolization process can be understood by referring to the prior art, and is not described in detail herein.

In this embodiment, when it is determined that the current risk level exceeds the preset risk level according to the CPU usage parameters of each current thread of the application program, that is, when a problem, such as stuck or crash, will occur with a high probability, such as more than 90%, of the application program, stack information of the target thread may be obtained, symbolized, and recorded, so as to perform predictive analysis on the problem that may occur.

In order to reduce the probability of the application program getting a problem, such as a stuck or a crash, and further improve the running reliability and stability of the application program, optionally, in an embodiment of the present disclosure, with reference to fig. 2, the method may further include the following steps:

step S201: and analyzing the code information to obtain a first analysis result.

For example, after step S104, the previously recorded code information, such as recognizable code information, may be analyzed to obtain a first analysis result, which may include, but is not limited to, the location of the code line and the source code information that may cause a potential problem, such as a crash or a stuck.

Step S202: and generating application intervention information based on the first analysis result.

After the first analysis result is obtained, application intervention information may be generated based on the first analysis result, and the application intervention information may include, but is not limited to, an instruction for adjusting a CPU usage parameter of the target thread, for example, an instruction for reducing the CPU usage parameter of the target thread, such as CPU occupancy.

Step S203: and performing intervention processing on the application program based on the application intervention information so that the current risk level is not higher than the preset risk level.

For example, after obtaining the application intervention information, such as an instruction for adjusting the CPU usage parameter of the target thread, the application program may be subjected to intervention processing based on the instruction for adjusting the CPU usage parameter of the target thread, for example, the CPU usage parameter of the target thread, such as the CPU occupancy rate, is reduced, so as to control the risk level determined based on the CPU usage parameter of each thread to be lower than or equal to the preset risk level. Therefore, the probability of the application program generating problems such as seizure or breakdown can be reduced, even the probability is zero, and the running reliability and the running stability of the application program are improved.

Optionally, in an embodiment of the present disclosure, as shown in fig. 3, the method may further include the steps of:

step S301: and when the application program is crashed, acquiring the crash file.

Illustratively, when the application program actually crashes, a download crash file is obtained. The crash file may be a Dump file, and the Dump file is a memory image of the process, and may maintain the execution state of the application program in the Dump file through the debugger.

Step S302: and analyzing the crash file to obtain a second analysis result.

Illustratively, the crash file is analyzed by an analysis tool such as WinDbg, and a second analysis result such as a location of the crash point and source code information corresponding to the crash point is obtained.

Step S303: and obtaining a total analysis result based on the first analysis result and the second analysis result.

For example, in this embodiment, when the application program actually crashes, a final total analysis result is obtained by comprehensive determination based on the second analysis result after the crash occurs and the first analysis result before the crash occurs. Due to the fact that the first analysis result when the crash is about to occur before the crash occurs is added, the accuracy of analysis of the crash reason of the application program is improved.

Optionally, in another embodiment of the present disclosure, as shown in fig. 4, the method may further include the steps of:

step S401: and when the application program is blocked, acquiring the blocking log information.

Illustratively, the katton log information is obtained when the application program actually appears katton.

Step S402: and analyzing the morton log information to obtain a third analysis result.

Step S403: and obtaining a total analysis result based on the first analysis result and the third analysis result.

It can be understood that the specific process based on the morton log analysis can be understood by referring to the prior art, and is not described herein again. In this embodiment, when the application program actually appears in a stuck state, a final total analysis result is obtained by comprehensive determination based on the third analysis result after the stuck state occurs and the first analysis result before the stuck state occurs. Due to the fact that the first analysis result when the jamming is about to occur before the jamming occurs is added, the accuracy of the analysis of the jamming reason of the application program is improved.

Optionally, in an embodiment of the present disclosure, the CPU usage parameter may include, but is not limited to, CPU occupancy and/or CPU wake-up times, where the CPU wake-up times represent wake-up times of all threads to the CPU, and the current risk level is positively correlated with the CPU usage parameter, such as the CPU occupancy and/or the CPU wake-up times. Accordingly, in an embodiment of the present disclosure, in order to improve the accuracy of the prediction judgment on the impending problem of the application program, such as a stuck or a crash, as shown in fig. 5, the determining the current risk level based on the CPU usage parameter of each thread in step S102 may specifically include the following steps:

step S501: and determining a corresponding first risk level based on the CPU occupancy rate of each thread.

Illustratively, the higher the CPU occupancy of each thread, the higher the corresponding first risk level.

Step S502: and determining a corresponding second risk level based on the CPU awakening times.

Illustratively, the greater the number of CPU wakeups, the higher the corresponding second risk level.

Step S503: determining a current risk level based on the first risk level and the second risk level; wherein the current risk level is a low risk level of the first risk level and the second risk level.

In this embodiment, two risk levels in total are respectively determined based on the CPU wake-up times and the CPU occupancy rates of the threads, then a low risk level of the two risk levels is selected as the current risk level, and when the two risk levels are the same, one of the two risk levels is selected as the current risk level.

In the embodiment, when the low risk level of the two selected risk levels is higher than the preset risk level, which indicates that there is a very high probability, for example, 95% or more, that the application program will have a problem, such as a stuck or a crash, the stack information of the target thread is obtained, and step S104 is performed to facilitate subsequent analysis. Therefore, the above-mentioned scheme of this embodiment can improve the accuracy of the predictive analysis and judgment of the impending problem of the application program, such as stuck or breakdown, and reduce the misjudgment.

Optionally, in an embodiment of the present disclosure, with reference to fig. 6, in step S501, determining a corresponding first risk level based on the CPU occupancy of each thread may specifically include the following steps:

step S601: and when the CPU occupancy rate of each thread is not less than the first value and the sum of the CPU occupancy rates of each thread is not less than the second value, determining a first risk sub-grade.

Illustratively, the first value is, for example, 10%, and the second value is, for example, 60%, but is not limited thereto. In one example, the CPU occupancy of each thread is no less than 10%, and the sum of the CPU occupancy of each thread is greater than 60%, then the first risk sub-level is determined.

Step S602: when the CPU occupancy rate of each thread is not less than the third numerical value and the sum of the CPU occupancy rates of each thread is not less than the fourth numerical value, determining a second risk sub-grade; the third value is greater than the first value and less than the second value, and the second value is less than the fourth value.

Illustratively, the third value is, for example, 20%, and the fourth value is, for example, 80%, but is not limited thereto. In one example, the CPU occupancy of each thread is no less than 20%, and the sum of the CPU occupancy of each thread is greater than 80%, then the second risk sub-level is determined.

Step S603: the second risk sub-level or the first risk sub-level is taken as the first risk level.

For example, when the second risk sub-level is determined, it indicates that the application program will have a problem, such as stuck or crash, with a maximum probability of, for example, 97% or more, and then the subsequent steps are performed for subsequent analysis and judgment, so that the accuracy of the prediction analysis and judgment on the problem, such as stuck or crash, of the application program can be improved.

It can be understood that the execution sequence of steps S601 to S602 does not distinguish the order, and can be executed in parallel. The first risk sub-level and the second risk sub-level belong to a subdivision of the first risk level.

Optionally, in an embodiment of the present disclosure, the method may further include the steps of: determining a third risk sub-grade when the CPU occupancy rate of each thread is not less than the fifth numerical value and the sum of the CPU occupancy rates of each thread is not less than the sixth numerical value; wherein the fifth value is greater than the third value and less than the fourth value, the fourth value is less than the sixth value, and the third risk sub-level is higher than the second risk sub-level; the third risk sub-level is taken as the first risk level.

Illustratively, the fifth value is, for example, 30%, and the sixth value is, for example, 100%, but is not limited thereto. In one example, the CPU occupancy of each thread is no less than 30%, and the sum of the CPU occupancy of each thread is greater than 100%, then the third risk sub-level is determined.

It is understood that the first risk sub-level, the second risk sub-level and the third risk sub-level belong to a subdivision of the first risk level, which is merely an example, and can be further divided into more, for example, four, risk sub-levels, etc. as required.

When the third risk sub-level is determined, it indicates that the application program will have a problem, such as stuck or crash, with a maximum probability of more than 99%, and at this time, the subsequent steps are executed for subsequent analysis and judgment, so that the accuracy of predictive analysis and judgment on the problem, such as stuck or crash, of the application program can be improved.

Optionally, in an embodiment of the present disclosure, the determining, in step S502, the corresponding second risk level based on the number of times of CPU wakeup may specifically include the following steps:

step i): and when the CPU awakening times are not larger than the seventh value, determining a fourth risk sub-grade.

Illustratively, the seventh value is, for example, but not limited to, 150 times/second, i.e., the number of CPU wakes per second. When the CPU wake-up number is 150 or less, a fourth risk sub-level is determined.

Step ii): and when the CPU awakening times are larger than the seventh numerical value and not larger than the eighth numerical value, determining a fifth risk sub-grade.

Illustratively, the eighth value may be, for example, 200 times/second. And when the CPU awakening times are more than 150 times/second and not more than 200 times/second, determining the CPU awakening times as a fifth risk sub-level. Wherein the fifth risk sub-level is higher than the fourth risk sub-level.

Step iii): and taking the fourth risk sub-level or the fifth risk sub-level as the second risk level.

It is understood that the fourth risk sub-level, the fifth risk sub-level belong to a subdivision of the second risk level. When the fifth risk sub-level is determined, it indicates that the application program will have a problem, such as stuck or crash, with a maximum probability of more than 97%, and at this time, the subsequent steps are executed for subsequent analysis and judgment, so that the accuracy of predictive analysis and judgment on the problem, such as stuck or crash, of the application program can be improved.

Optionally, in an embodiment of the present disclosure, the method may further include the steps of:

step iiii): when the CPU awakening times are larger than the eighth numerical value and not larger than the ninth numerical value, determining a sixth risk sub-grade; wherein the sixth risk sub-level is higher than the fifth risk sub-level.

Illustratively, the ninth value may be, for example, 300 times/second. And when the CPU awakening times are more than 200 times/second and not more than 300 times/second, determining the sixth risk sub-level.

It is understood that the fourth risk sub-level, the fifth risk sub-level and the sixth risk sub-level belong to the subdivision of the second risk level, which is merely illustrative, and can be further divided as needed to include more than four risk sub-levels.

When the sixth risk sub-level is determined, it indicates that the application program will have a problem, such as stuck or crash, with a maximum probability of more than 99%, and at this time, the subsequent steps are executed for subsequent analysis and judgment, so that the accuracy of the prediction analysis and judgment on the problem, such as stuck or crash, of the application program can be improved.

Optionally, in an embodiment of the present disclosure, before acquiring the stack information of the target thread in step S103, the method may include the following steps: the target thread is determined based on the CPU occupancy of each thread. And the CPU occupancy rate of the target thread is greater than a preset threshold value.

For example, the preset threshold may be set as needed, for example, the CPU occupancy of the target thread is greater than 60%. By the method, the target thread which may cause the problem of the application program, such as jamming or breakdown, can be accurately determined, and the subsequent processing and analysis are performed based on the stack information of the target thread instead of analyzing all threads, so that the accuracy and the processing efficiency of the analysis processing can be improved.

The embodiment of the present disclosure further provides an application monitoring apparatus, and as shown in fig. 7, the application monitoring apparatus may include a parameter obtaining module 701, a risk determining module 702, an information obtaining module 703, and an information processing module 704:

the parameter obtaining module 701 is configured to obtain CPU usage parameters of each current thread of the application program.

The risk determination module 702 is configured to determine a current risk level based on the CPU usage parameters of the threads.

The information obtaining module 703 is configured to obtain stack information of the target thread when the current risk level is higher than a preset risk level. Wherein the target thread is one or more of the threads.

The information processing module 704 is configured to perform symbolization processing on the stack information to obtain code information corresponding to the target thread.

In this embodiment, when it is determined that the current risk level exceeds the preset risk level according to the CPU usage parameters of each current thread of the application program, that is, when the application program is about to have a problem such as a stuck or a crash with a high probability, the stack information of the target thread may be obtained, symbolized, and recorded, so as to perform predictive analysis on the problem that may occur.

Optionally, in an embodiment of the present disclosure, the apparatus may further include a first analysis module and an application intervention module, where the first analysis module is configured to analyze the code information to obtain a first analysis result. The application intervention module is used for generating application intervention information based on the first analysis result; and performing intervention processing on the application program based on the application intervention information so as to enable the current risk level not to be higher than the preset risk level.

Optionally, in an embodiment of the present disclosure, the apparatus may further include a second analysis module, configured to obtain a crash file when the application program crashes; analyzing the crash file to obtain a second analysis result; obtaining a total analysis result based on the first analysis result and the second analysis result.

Optionally, in another embodiment of the present disclosure, the second analysis module is configured to obtain katton log information when the application program is katton; analyzing the morton log information to obtain a third analysis result; obtaining a total analysis result based on the first analysis result and the third analysis result.

Optionally, in an embodiment of the present disclosure, the CPU usage parameter may include a CPU occupancy rate and/or a CPU wake-up number, where the CPU wake-up number indicates a wake-up number of the CPU by all the threads. The current risk level is positively correlated with the CPU usage parameter.

Optionally, in an embodiment of the present disclosure, the risk determining module 702 is configured to determine a first risk level based on a CPU occupancy of each thread; determining a second risk level based on the CPU awakening times; determining a current risk level based on the first risk level and the second risk level. Wherein the current risk level is a lower risk level of the first risk level and the second risk level.

Optionally, in an embodiment of the present disclosure, the risk determining module 702 is configured to: when the CPU occupancy rate of each thread is not less than a first value and the sum of the CPU occupancy rates of each thread is not less than a second value, determining a first risk sub-grade; when the CPU occupancy rate of each thread is not less than a third numerical value and the sum of the CPU occupancy rates of each thread is not less than a second risk sub-grade is determined; wherein the third value is greater than the first value and less than the second value, the second value is less than the fourth value, and the second risk sub-level is higher than the first risk sub-level; taking the second risk sub-level or the first risk sub-level as the first risk level.

Optionally, in an embodiment of the present disclosure, the risk determining module 702 is configured to: determining a third risk sub-grade when the CPU occupancy rate of each thread is not less than a fifth numerical value and the sum of the CPU occupancy rates of each thread is not less than a sixth numerical value; wherein the fifth value is greater than the third value and less than the fourth value, the fourth value is less than the sixth value, and the third risk sub-level is higher than the second risk sub-level; taking the third risk sub-level as the first risk level.

Optionally, in an embodiment of the present disclosure, the risk determining module 702 is configured to: when the CPU awakening times are not larger than a seventh numerical value, determining a fourth risk sub-grade; when the CPU awakening times are larger than the seventh numerical value and not larger than an eighth numerical value, determining a fifth risk sub-grade, wherein the fifth risk sub-grade is higher than the fourth risk sub-grade; taking the fourth risk sub-level or the fifth risk sub-level as the second risk level.

Optionally, in an embodiment of the present disclosure, the risk determining module 702 is configured to: when the CPU awakening times are larger than the eighth numerical value and not larger than the ninth numerical value, determining a sixth risk sub-grade; wherein the sixth risk sub-level is higher than the fifth risk sub-level; taking the sixth risk sub-level as the second risk level.

Optionally, in an embodiment of the present disclosure, the apparatus may further include a thread determining module, configured to determine the target thread based on the CPU occupancy rate of each thread before the information obtaining module 703 obtains the stack information of the target thread. And the CPU occupancy rate of the target thread is greater than a preset threshold value.

An exemplary embodiment of the present disclosure also provides an electronic device including: at least one processor; and a memory communicatively coupled to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program, when executed by the at least one processor, is for causing the electronic device to perform an application monitoring method according to an embodiment of the present disclosure.

The disclosed exemplary embodiments also provide a non-transitory computer readable storage medium storing a computer program, wherein the computer program, when executed by a processor of a computer, is for causing the computer to perform an application monitoring method according to an embodiment of the present disclosure.

The exemplary embodiments of the present disclosure also provide a computer program product comprising a computer program, wherein the computer program, when executed by a processor of a computer, is adapted to cause the computer to perform a method according to an embodiment of the present disclosure.

Referring to fig. 8, a block diagram of a structure of an electronic device 800, which may be a server or a client of the present disclosure, which is an example of a hardware device that may be applied to aspects of the present disclosure, will now be described. Electronic device is intended to represent various forms of digital electronic computer devices, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the disclosure described and/or claimed herein.

As shown in fig. 8, the electronic device 800 includes a computing unit 801 that can perform various appropriate actions and processes according to a computer program stored in a Read Only Memory (ROM) 802 or a computer program loaded from a storage unit 808 into a Random Access Memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the device 800 can also be stored. The calculation unit 801, the ROM 802, and the RAM 803 are connected to each other by a bus 804. An input/output (I/O) interface 805 is also connected to bus 804.

A number of components in the electronic device 800 are connected to the I/O interface 805, including: an input unit 806, an output unit 807, a storage unit 808, and a communication unit 809. The input unit 806 may be any type of device capable of inputting information to the electronic device 800, and the input unit 806 may receive input numeric or character information and generate key signal inputs related to user settings and/or function controls of the electronic device. Output unit 807 can be any type of device capable of presenting information and can include, but is not limited to, a display, speakers, a video/audio output terminal, a vibrator, and/or a printer. The storage unit 804 may include, but is not limited to, a magnetic disk, an optical disk. The communication unit 809 allows the electronic device 800 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers and/or chipsets, such as bluetooth (TM) devices, WiFi devices, WiMax devices, cellular communication devices, and/or the like.

Computing unit 801 may be a variety of general and/or special purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various dedicated Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, and the like. The calculation unit 801 executes the respective methods and processes described above. For example, in some embodiments, the application monitoring methods of the various embodiments described above may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and/or installed onto the electronic device 800 via the ROM 802 and/or the communication unit 809. In some embodiments, the computing unit 801 may be configured to perform the application monitoring method in any other suitable manner (e.g., by means of firmware).

Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

As used in this disclosure, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.

The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

Claims

1. An application monitoring method, comprising:

acquiring CPU use parameters of current threads of an application program;

when the current risk level is higher than a preset risk level, stack information of a target thread is obtained, wherein the target thread is one or more of the threads;

2. The method of claim 1, wherein the method further comprises:

analyzing the code information to obtain a first analysis result;

generating application intervention information based on the first analysis result;

and performing intervention processing on the application program based on the application intervention information so as to enable the current risk level not to be higher than the preset risk level.

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

when the application program is crashed, acquiring a crash file;

analyzing the crash file to obtain a second analysis result;

obtaining a total analysis result based on the first analysis result and the second analysis result;

alternatively, the first and second electrodes may be,

when the application program is blocked, acquiring blocking log information;

analyzing the morton log information to obtain a third analysis result;

obtaining a total analysis result based on the first analysis result and the third analysis result.

4. The method according to any one of claims 1 to 3, wherein the CPU usage parameters comprise CPU occupancy and/or CPU wake-up times, the CPU wake-up times represent the wake-up times of all threads to the CPU, and the current risk level is positively correlated with the CPU usage parameters.

5. The method of claim 4, wherein said determining a current risk level based on CPU usage parameters for each thread comprises:

determining a first risk level based on the CPU occupancy rate of each thread;

determining a second risk level based on the CPU awakening times;

determining the current risk level based on the first risk level and the second risk level, wherein the current risk level is a lower risk level of the first risk level and the second risk level.

6. The method of claim 5, wherein said determining a first risk level based on the CPU occupancy of each of the threads comprises:

when the CPU occupancy rate of each thread is not less than a first value and the sum of the CPU occupancy rates of each thread is not less than a second value, determining a first risk sub-grade;

determining a second risk sub-grade when the CPU occupancy rate of each thread is not less than a third value and the sum of the CPU occupancy rates of each thread is not less than a fourth value, wherein the third value is greater than the first value and less than the second value, the second value is less than the fourth value, and the second risk sub-grade is higher than the first risk sub-grade;

taking the second risk sub-level or the first risk sub-level as the first risk level.

7. The method of claim 6, wherein the method further comprises:

determining a third risk sub-level when the CPU occupancy rate of each thread is not less than a fifth value and the sum of the CPU occupancy rates of each thread is not less than a sixth value, wherein the fifth value is greater than the third value and less than the fourth value, the fourth value is less than the sixth value, and the third risk sub-level is higher than the second risk sub-level;

taking the third risk sub-level as the first risk level.

8. The method of claim 5, wherein said determining a second risk level based on said CPU wake-up times comprises:

when the CPU awakening times are not larger than a seventh numerical value, determining a fourth risk sub-grade;

when the CPU awakening times are larger than the seventh numerical value and not larger than an eighth numerical value, determining a fifth risk sub-grade, wherein the fifth risk sub-grade is higher than the fourth risk sub-grade;

taking the fourth risk sub-level or the fifth risk sub-level as the second risk level.

9. The method of claim 8, wherein the method further comprises:

when the CPU awakening times are larger than the eighth numerical value and not larger than a ninth numerical value, determining a sixth risk sub-grade, wherein the sixth risk sub-grade is higher than the fifth risk sub-grade;

taking the sixth risk sub-level as the second risk level.

10. The method of claim 4, wherein prior to said obtaining stack information for the target thread, the method comprises:

and determining the target thread based on the CPU occupancy rate of each thread, wherein the CPU occupancy rate of the target thread is greater than a preset threshold value.

11. An application monitoring apparatus comprising:

the risk determination module is used for determining the current risk level based on the CPU use parameters of all the threads;

and the information processing module is used for performing symbolization processing on the stack information to obtain code information corresponding to the target thread.

12. An electronic device, comprising:

a processor; and

a memory storing a program;

wherein the program comprises instructions which, when executed by the processor, cause the processor to carry out the application monitoring method according to any one of claims 1-10.

13. A computer-readable storage medium storing computer instructions for causing a computer to perform the application monitoring method according to any one of claims 1-10.