Application running state monitoring method and device and terminal equipment

Abstract

The invention provides an application running state monitoring method and device and terminal equipment. The method comprises the following steps: monitoring whether a running application service thread in the terminal equipment is in a blocked state or not; monitoring whether the kernel of the terminal equipment has a fence timeout state or not; and if the application service thread is in the blocked state and the kernel is in the fence timeout state, restarting the terminal equipment. According to the scheme, the problem that when the kernel is in the fence timeout state and the application service thread is blocked, the system still cannot be recovered to be normal only by restarting can be solved, so that the user experience of the terminal equipment can be improved.

Description

Technical Field

[0001] The present disclosure relates to the technical field of terminal devices, and in particular to a method and device for monitoring the running status of an application, and a terminal device. Background Art

[0002] The watchdog thread is used to monitor the operation of the application service in the terminal device. If the application service is found to be blocked for a certain period of time, the watchdog thread will restart the system to restore the system to normal. However, sometimes the system cannot be restored to normal after the watchdog thread restarts the system, thus affecting the normal use of the terminal device. Summary of the invention

[0003] In order to overcome the problems existing in the related art, the present disclosure provides a method, an apparatus and a terminal device for monitoring the running status of an application.

[0004] According to a first aspect of an embodiment of the present disclosure, a method for monitoring an application running state is provided, comprising:

[0005] Monitor whether the application service thread running in the terminal device is blocked;

[0006] Monitoring whether a fence timeout state occurs in the kernel of the terminal device;

[0007] If the application service thread is in a blocked state and the kernel is in a fence timeout state, the terminal device is restarted.

[0008] In some embodiments of the present disclosure, the monitoring of whether an application service thread running in a terminal device is in a blocked state includes:

[0009] Based on the first kernel thread, a first state parameter in the monitoring timer thread is obtained, and according to the first state parameter, it is determined whether the application service thread is in a blocked state; wherein the monitoring timer thread is used to monitor whether the application service thread is in a blocked state; and the first state parameter is a parameter used to characterize whether the application service thread is in a blocked state.

[0010] As a possible implementation manner, the monitoring whether a fence timeout state occurs in the kernel of the terminal device includes:

[0011] Based on the first kernel thread, the running state of the running barrier mechanism thread is obtained, and according to the running state of the barrier mechanism thread, it is determined whether the kernel is in a barrier timeout state.

[0012] The barrier mechanism threads include a graphics processor barrier thread and a display barrier thread.

[0013] In some embodiments of the present disclosure, restarting the terminal device includes:

[0014] Based on the first kernel thread, the terminal device is restarted.

[0015] In some other embodiments of the present disclosure, the method further includes:

[0016] Based on the first kernel thread, determining whether the monitoring timer thread is in a blocked state;

[0017] If the monitoring timer thread is in a blocked state, the terminal device is restarted based on the first kernel thread.

[0018] In some other embodiments of the present disclosure, the monitoring of whether a fence timeout state occurs in the kernel of the terminal device includes:

[0019] Based on the first kernel thread, obtain the second state parameter in the second kernel thread, and determine whether the kernel is in a fence timeout state based on the second state parameter; wherein the second kernel thread is used to monitor whether the kernel is in a fence timeout state; the second state parameter is a parameter used to characterize whether the kernel is in a fence timeout state.

[0020] According to a second aspect of an embodiment of the present disclosure, there is provided a device for monitoring an application running state, comprising:

[0021] The first monitoring module is used to monitor whether the application service thread running in the terminal device is blocked;

[0022] A second monitoring module, used for monitoring whether a fence timeout state occurs in the kernel of the terminal device;

[0023] The first restart module is used to restart the terminal device if the application service thread is in a blocked state and the kernel is in a fence timeout state.

[0024] As a possible implementation manner, the first monitoring module is specifically used to:

[0025] Based on the first kernel thread, a first state parameter in the monitoring timer thread is obtained, and according to the first state parameter, it is determined whether the application service thread is in a blocked state; wherein the monitoring timer thread is used to monitor whether the application service thread is in a blocked state; and the first state parameter is a parameter used to characterize whether the application service thread is in a blocked state.

[0026] In some embodiments of the present disclosure, the second monitoring module is specifically used to:

[0027] Based on the first kernel thread, the running state of the running barrier mechanism thread is obtained, and according to the running state of the barrier mechanism thread, it is determined whether the kernel is in a barrier timeout state.

[0028] The barrier mechanism threads include a graphics processor barrier thread and a display barrier thread.

[0029] In some embodiments of the present disclosure, the first restart module is specifically used to:

[0030] Based on the first kernel thread, the terminal device is restarted.

[0031] In some other embodiments of the present disclosure, the device further includes:

[0032] A judging module, configured to judge whether the monitoring timer thread is in a blocked state based on the first kernel thread;

[0033] The second restart module is used to restart the terminal device based on the first kernel thread if the monitoring timer thread is in a blocked state.

[0034] In some further embodiments of the present disclosure, the second monitoring module is specifically used for:

[0035] Based on the first kernel thread, obtain the second state parameter in the second kernel thread, and determine whether the kernel is in a fence timeout state based on the second state parameter; wherein the second kernel thread is used to monitor whether the kernel is in a fence timeout state; the second state parameter is a parameter used to characterize whether the kernel is in a fence timeout state.

[0036] According to a third aspect of an embodiment of the present disclosure, a terminal device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the method for monitoring the application running status described in the first aspect above is implemented.

[0037] According to a fourth aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the method for monitoring the application running status described in the first aspect above is implemented.

[0038] According to a fifth aspect of an embodiment of the present disclosure, a computer program product is provided, including a computer program, wherein when the computer program is executed by a processor, the method for monitoring the application running status described in the first aspect above is implemented.

[0039] The technical solution provided by the embodiments of the present disclosure may include the following beneficial effects: by monitoring whether the application service thread running in the terminal device is in a blocked state, and monitoring whether the kernel of the terminal device is in a fence timeout state, the terminal device is restarted when the application service thread is in a blocked state and the kernel is in a fence timeout state. This solution can solve the problem that when the kernel is in a fence timeout state and the application service thread is blocked, only restarting the system still cannot restore to normal, thereby improving the user experience of the terminal device.

[0040] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0042] Figure 1 is a flow chart of a method for monitoring application running status according to an exemplary embodiment;

[0043] Figure 2 is a flow chart of another method for monitoring the running status of an application according to an exemplary embodiment;

[0044] Figure 3 is a flowchart of a first kernel thread according to an exemplary embodiment;

[0045] Figure 4 is a flow chart of another method for monitoring the running status of an application according to an exemplary embodiment;

[0046] Figure 5 is an example diagram of a process of monitoring a timer thread according to an exemplary embodiment;

[0047] Figure 6 is another example flow chart of a first kernel thread according to an exemplary embodiment;

[0048] Figure 7 is a flow chart of another method for monitoring the running status of an application according to an exemplary embodiment;

[0049] Figure 8 is a flowchart of a first kernel thread and a second kernel thread according to an exemplary embodiment;

[0050] Fig. 9 is a block diagram of a device for monitoring the running status of an application according to an exemplary embodiment;

[0051] Fig.10 The present invention is a block diagram of a terminal device structure according to an exemplary embodiment. DETAILED DESCRIPTION

[0052] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Instead, they are merely examples of devices and methods consistent with some aspects of the present invention as detailed in the appended claims.

[0053] It should be noted that the monitoring timer thread is used to monitor the operation of the application service in the terminal device. If the operation of the application service is found to be blocked for a certain period of time, the monitoring timer thread will restart the system to restore the system to a normal state. However, sometimes the monitoring timer thread still cannot restore the system to normal after restarting the system, thus affecting the normal use of the terminal device.

[0054] In order to solve the above problems, the present disclosure provides a method, apparatus and terminal device for monitoring the running status of an application.

[0055] Figure 1 is a flow chart of a method for monitoring the running status of an application according to an exemplary embodiment. Figure 1 As shown, the method for monitoring the application running status of the embodiment of the present disclosure is used in a terminal device, comprising the following steps:

[0056] Step 101, monitoring whether an application service thread running in a terminal device is blocked.

[0057] In some embodiments of the present disclosure, the terminal device may be a smart phone, a laptop, a tablet computer, a desktop computer, etc., and the application service threads running in the terminal device may include operating system service threads, as well as UI (User Interface), display (display) and other related threads. For example, if the terminal device is installed with an Android system, the corresponding system service threads may include AMS (Activity Manager Service), PKMS (Package Manager Service), WMS (Window Manager Service) and other corresponding threads.

[0058] As a possible implementation manner, the running status of the application service thread running in the terminal device can be obtained at regular intervals, and whether the application service thread is blocked can be determined based on the running status of the application service thread.

[0059] As another possible implementation, a monitoring timer thread may be enabled in the terminal device, and whether an application service thread running in the terminal device is blocked may be monitored based on the monitoring timer thread.

[0060] Step 102, monitoring whether the kernel of the terminal device is in a fence timeout state.

[0061] It should be noted that the fence mechanism is a resource synchronization mechanism, which is mainly used to handle cross-hardware scenarios, such as the synchronization of buffer resources between CPU and GPU. A group of threads can use the fence mechanism to collectively synchronize with each other. In essence, each thread calls the wait method of the fence when it reaches a certain state, blocking and waiting for all other participating threads to call. Once all threads reach the fence, they will collectively unblock and continue to run together.

[0062] In some embodiments of the present disclosure, when the kernel-related threads of the terminal device enable fence, the waiting time can be set. If the actual waiting time exceeds the corresponding set waiting time, it means that the fence timeout state has occurred. As an example, each thread can call the corresponding timeout program when the fence timeout state occurs, so it can be determined whether the fence timeout state occurs based on the call of the timeout program. As an example, the running status of the threads that enable the fence mechanism in the terminal device can be obtained at regular intervals, and based on the running status of each thread, it can be determined whether the kernel has a fence timeout state.

[0063] Step 103: If the application service thread is blocked and the kernel is in fence timeout state, the terminal device is restarted.

[0064] The inventor of the present disclosure has found that when the kernel of a terminal device is in a fence timeout state, each CPU can work normally, but the upper layer application service thread will be blocked. In this case, the monitoring timer thread will restart the application service layer, but the kernel will not restart, so the problem of application service thread blocking cannot be solved, which may cause the terminal device screen to remain black and unable to recover.

[0065] That is to say, the blocking state of the application service thread may not be caused by a problem on the application service side, but by the kernel, so simply restarting the upper system cannot solve the blocking problem. Therefore, when the application service thread is blocked and the kernel is in a fence timeout state, it can be determined that the application service thread is blocked due to the fence timeout state of the kernel. In this case, the terminal device can be restarted to solve the fence timeout problem of the kernel, thereby solving the blocking state problem of the application service thread and restoring the terminal device to normal.

[0066] According to the method for monitoring the application running status of the embodiment of the present disclosure, by monitoring whether the application service thread running in the terminal device is in a blocked state, and monitoring whether the kernel of the terminal device is in a fence timeout state, when the application service thread is in a blocked state and the kernel is in a fence timeout state, the terminal device is restarted. This solution can solve the problem that when the kernel is in a fence timeout state and the application service thread is blocked, only restarting the system still cannot restore to normal, thereby improving the user experience of the terminal device.

[0067] In actual application scenarios, the corresponding kernel thread can be started to monitor the application running status. The implementation method will be introduced in detail below.

[0068] Figure 2 FIG. 1 is a flow chart of another method for monitoring the running status of an application according to an exemplary embodiment. Figure 2 As shown, the method may include:

[0069] Step 201, based on the first kernel thread, obtain the first state parameter in the monitoring timer thread, and determine whether the application service thread is in a blocked state according to the first state parameter; wherein the monitoring timer thread is used to monitor whether the application service thread is in a blocked state; the first state parameter is a parameter used to characterize whether the application service thread is in a blocked state.

[0070] In some embodiments of the present disclosure, the first state parameter is a parameter in the monitoring timer thread used to characterize whether the application service thread is in a blocked state. As an example, the monitoring timer thread can obtain the running state of the application service thread every 30 seconds, and determine whether there is a thread in a locked state based on the running state of the application service thread. If there is a thread in a locked state, it means that the application service thread is in a blocked state. At this time, the first state parameter is set to the first value, and the dump file is saved. After 60 seconds, the running state of the application service thread is obtained again, and the running state of the application service thread is determined based on the running state of the application service thread. If there is still a thread in a locked state, the dump file is saved and the upper system is restarted. The monitoring timer thread sends the first state parameter to the kernel thread after each run.

[0071] In some embodiments of the present disclosure, the first kernel thread may obtain a first state parameter in the monitoring timer thread. If the first state parameter is a first value, it is determined that the application service thread is in a blocked state; otherwise, it is determined that the application service thread is not in a blocked state.

[0072] Step 202: Based on the first kernel thread, the running state of the running barrier mechanism thread is obtained, and according to the running state of the barrier mechanism thread, it is determined whether the kernel is in a barrier timeout state.

[0073] In some embodiments of the present disclosure, after the application service thread is blocked, the running state of the running fence mechanism thread can be obtained based on the first kernel thread, and the kernel can be judged whether the fence timeout state occurs according to the running state of the fence mechanism thread. In addition, during the execution of the first kernel thread, it can also be judged whether the application service thread is blocked each time, and whether the kernel is fenced each time, which is not limited by the present disclosure.

[0074] The fence mechanism thread refers to a thread that introduces the fence mechanism, which may include a graphics processor fence gpufence thread and a display fence display fence thread.

[0075] Step 203: If the application service thread is in a blocked state and the kernel is in a fence timeout state, the terminal device is restarted based on the first kernel thread.

[0076] According to the method for monitoring the application running status of the embodiment of the present disclosure, based on the first kernel thread, the first state parameter in the monitoring timer thread is obtained, and based on the first state parameter, it is determined whether the application service thread is in a blocked state, based on the first kernel thread, the running state of the running fence mechanism thread is obtained, and based on the running state of the fence mechanism thread, it is determined whether the kernel is in a fence timeout state, and if the application service thread is in a blocked state and the kernel is in a fence timeout state, the terminal device is restarted based on the first kernel thread. This solution uses the parameters of the monitoring timer thread to monitor the application running status through the first kernel thread to solve the problem that when the kernel is in a fence timeout state and the application service thread is blocked, only restarting the system still cannot restore to normal, thereby improving the user experience of the terminal device.

[0077] In order to implement the above embodiment, the first kernel thread will be introduced below.

[0078] Figure 3 FIG. 1 is a flowchart of a first kernel thread according to an exemplary embodiment. Figure 3 As shown, the process of the first kernel thread may include:

[0079] Step 301, obtaining a first state parameter in a monitoring timer thread.

[0080] In some embodiments of the present disclosure, the first kernel thread may be executed once at a certain interval, for example, step 301 may be executed every 30 seconds. As an example, after each execution of the monitoring timer thread, the first state parameter is sent to the kernel, and the kernel stores it in the corresponding area. The first kernel thread may directly search for the latest first state parameter in the corresponding area.

[0081] Step 302: Determine whether the application service thread is in a blocked state according to the first parameter state.

[0082] As an example, the first state parameter may be a numerical parameter. For example, if the first state parameter is 0, it is determined that the application service thread is not in a blocked state. If the first state parameter is 1, it is determined that the application service thread is in a blocked state.

[0083] In some embodiments of the present disclosure, if the application service thread is in a blocked state, step 303 is continued to be executed, otherwise the monitoring is completed and monitoring is performed again after waiting for a period of time.

[0084] Step 303: Get the running status of the fence mechanism thread.

[0085] Step 304, determine whether the kernel is in a fence timeout state.

[0086] In some embodiments of the present disclosure, if the kernel does not have a fence timeout state, it means that the blocking state of the application service thread is a problem of the upper layer service, so the monitoring timer thread directly restarts the upper layer service, that is, the first kernel thread ends this monitoring. If the kernel has a fence timeout state, it means that the blocking state of the application service thread may be caused by the kernel fence timeout, so in this case, continue to execute step 305.

[0087] Step 305, save the dump file.

[0088] Step 306, restart the terminal device.

[0089] According to the method for monitoring the application running status of the embodiment of the present disclosure, the first kernel thread obtains the first status parameter in the monitoring timer thread, and determines whether the application service thread is in a blocked state based on the first status parameter. When the application service thread is in a blocked state, the kernel is determined to be in a fence timeout state by obtaining the running status of the running fence mechanism thread, and according to the running status of the fence mechanism thread, restarting the terminal device if the application service thread is in a blocked state and the kernel is in a fence timeout state. This solution uses the first kernel thread to monitor the application running status, so as to solve the problem that when the kernel is in a fence timeout state and the application service thread is blocked, only restarting the system still cannot restore to normal, thereby improving the user experience of the terminal device.

[0090] Figure 4 FIG. 1 is a flow chart of another method for monitoring the running status of an application according to an exemplary embodiment. Figure 4 As shown, the method includes:

[0091] Step 401, based on the first kernel thread, obtain the first state parameter in the monitoring timer thread, and determine whether the application service thread is in a blocked state according to the first state parameter; wherein the monitoring timer thread is used to monitor whether the application service thread is in a blocked state; the first state parameter is a parameter used to characterize whether the application service thread is in a blocked state.

[0092] As a possible implementation, the first state parameter in the monitoring timer thread may be a count parameter count, such as Figure 5As shown, the monitoring timer thread determines whether the application service thread is blocked every 30 seconds. If not, the first state parameter count is set to the first value and the monitoring ends. If the application service thread is blocked, count is set to the second value and the dump file is saved. After 60 seconds, it continues to determine whether the application service is still blocked. If it is still blocked after 60 seconds, count is set to the third value, the dump file is saved, and the application service is restarted. If no blocking state occurs after 60 seconds, the monitoring ends. The first value is smaller than the second value, and the second value is smaller than the third value. Figure 5 In the example, the first value is 10, the second value is 12, and the third value is 20.

[0093] In some embodiments of the present disclosure, the implementation method of determining whether an application service thread is in a blocked state based on a first state parameter may include: determining whether the first state parameter is greater than a first value; if the first state parameter is greater than the first value, determining that the application service thread is in a blocked state; otherwise, determining that the application service thread is not blocked.

[0094] Step 402: Based on the first kernel thread, the running state of the running barrier mechanism thread is obtained, and according to the running state of the barrier mechanism thread, it is determined whether the kernel is in a barrier timeout state.

[0095] Step 403: If the application service thread is in a blocked state and the kernel is in a fence timeout state, the terminal device is restarted based on the first kernel thread.

[0096] Step 404: Based on the first kernel thread, determine whether the monitoring timer thread is in a blocked state.

[0097] It can be understood that the operation of the monitoring timer thread depends on the stability of the underlying layer. If the kernel is abnormal, the monitoring timer thread will also be blocked. Therefore, in order to monitor the running status of the application, it is also necessary to introduce the judgment of the running status of the monitoring timer thread.

[0098] In some embodiments of the present disclosure, based on the first kernel thread, an implementation method for determining whether a monitoring timer thread is in a blocked state may include: based on the first kernel thread, monitoring the update duration of a first state parameter, wherein the update duration of the first state parameter refers to the time interval between the first state parameter sent by the current monitoring timer thread and the first state parameter sent by the last monitoring timer; if the update duration of the first state parameter is greater than a preset duration threshold, it is determined that the monitoring timer thread is in a blocked state; otherwise, it is determined that the monitoring timer thread is not in a blocked state.

[0099] In some other embodiments of the present disclosure, based on the first kernel thread, an implementation method for determining whether a monitoring timer thread is in a blocked state may include: each time a first state parameter is obtained, determining a third state parameter based on the first state parameter, wherein the third state parameter is the same as the first state parameter; based on the first kernel thread, determining the size of the third state parameter at intervals, if the third state parameter is greater than or equal to a state threshold, determining that the monitoring timer thread is not in a blocked state, and subtracting 1 from the third state parameter, if the third state parameter is less than the state threshold, determining that the monitoring timer thread is in a blocked state.

[0100] Step 405: If the monitoring timer thread is blocked, the terminal device is restarted based on the first kernel thread.

[0101] As an example, Figure 6 As shown, combined Figure 5 The monitoring timer thread of the first kernel thread includes: at each interval, judging whether the third state parameter count1 is less than 0, and whether the first state parameter count is greater than 10 and whether a fence timeout occurs in the kernel; if the third state parameter count1 is greater than or equal to 0, or the first state parameter count is less than or equal to 10, or the kernel does not experience a fence timeout, then the third state parameter count1 is decremented by 1, and the next execution is waited for; if the third state parameter count1 is less than 0, or the first state parameter count is greater than 10 and a fence timeout occurs in the kernel, then the dump file is saved and the terminal device is restarted.

[0102] According to the method for monitoring the application running status of the embodiment of the present disclosure, the monitoring of the running status of the monitoring timer thread is introduced, and when the monitoring timer thread is blocked, the terminal device is restarted to solve the problem of the monitoring timer thread being blocked due to underlying exceptions, thereby ensuring the monitoring of the application running status.

[0103] Figure 7 FIG. 1 is a flow chart of another method for monitoring the running status of an application according to an exemplary embodiment. Figure 7 As shown, the method may include:

[0104] Step 701, based on the first kernel thread, obtain the first state parameter in the monitoring timer thread, and determine whether the application service thread is in a blocked state according to the first state parameter; wherein the monitoring timer thread is used to monitor whether the application service thread is in a blocked state; and the first state parameter is a parameter used to characterize whether the application service thread is in a blocked state.

[0105] Step 702, based on the first kernel thread, obtain the second state parameter in the second kernel thread, and determine whether the kernel has a fence timeout state based on the second state parameter; wherein the second kernel thread is used to monitor whether the kernel has a fence timeout state; the second state parameter is a parameter used to characterize whether the kernel has a fence timeout state.

[0106] Step 703: If the application service thread is in a blocked state and the kernel is in a fence timeout state, the terminal device is restarted based on the first kernel thread.

[0107] Step 704: Based on the first kernel thread, determine whether the monitoring timer thread is in a blocked state.

[0108] Step 705: If the monitoring timer thread is blocked, the terminal device is restarted based on the first kernel thread.

[0109] That is, whether the kernel is in a fence timeout state can be monitored based on the second kernel thread, and whether the kernel is in a fence timeout state can be represented by a second state parameter.

[0110] As an implementation method, the second kernel thread can obtain the running status of the running fence mechanism thread at regular intervals, and determine whether the kernel is in a fence timeout state according to the running status of the fence mechanism thread. If the kernel is in a fence timeout state, the second state parameter is set to the fourth value. Wherein, when the kernel is not in a fence timeout state, the second state parameter is the fifth value. The second kernel thread sends the second state parameter after each execution to the first kernel thread.

[0111] Based on the above implementation method, the process of the first kernel thread can be: at regular intervals, determine whether the first state parameter is greater than the first value and whether the second state parameter is the fourth value, and at the same time determine whether the third state parameter is less than the state threshold; if the first state parameter is greater than the first value and the second state parameter is the fourth value, determine that the application service thread is in a blocked state and the kernel is in a fence timeout state, and restart the terminal device; if the third state parameter is less than the state threshold, determine that the monitoring timer thread is in a blocked state, and restart the terminal device; otherwise, decrement the third state parameter by 1, and set the second state parameter to the fifth value.

[0112] As an example, Figure 8 As shown, based on Figure 5The monitoring timer thread shown, the process of the second kernel thread is explained by taking the fourth value = 1 and the fifth value = 0 as an example. Every 30 seconds, the kernel fence is monitored to see if a timeout state occurs. If a fence timeout state occurs, the second state parameter fenceout is set to 1 and the monitoring is terminated. Otherwise, the monitoring is terminated directly. The process of the first kernel thread is: every 30 seconds, the sizes of the first state parameter count, the second state parameter fenceout and the third state parameter count1 are judged. If the first state parameter count is greater than 10 and the second state parameter fenceout is 1, it is determined that the application service thread is blocked and the kernel is in a fence timeout state, and the terminal device is restarted; if the third state parameter count1 is less than 0, it is determined that the monitoring timer thread is blocked and the terminal device is restarted; if the third state parameter count1 is greater than or equal to 0, or the first state parameter count is less than or equal to 10, or the second state parameter fenceout is 0, the second state parameter fenceout is set to 0 and the third state parameter count1 is decremented by 1 and the monitoring is terminated.

[0113] According to the method for monitoring the application running status of the embodiment of the present disclosure, based on the first kernel thread, the second state parameter in the second kernel thread is obtained, and according to the second state parameter, it is determined whether the kernel is in a fence timeout state, that is, the monitoring timer thread is used to monitor whether the application service thread is in a blocked state, and the second kernel thread is used to monitor whether the kernel is in a fence timeout state, and the first kernel thread uses the monitoring results of the monitoring timer thread and the second kernel thread to determine whether to restart the terminal device. This solution can improve the monitoring efficiency of the application running status by running multiple threads in parallel, and can also restart the terminal device in time when an abnormality occurs at the bottom layer to improve the user experience of the terminal device.

[0114] Fig. 9 FIG. 1 is a block diagram of a monitoring device for an application running state according to an exemplary embodiment. Fig. 9 As shown, the device includes a first monitoring module 901, a second monitoring module 902 and a first restarting module 903. Among them:

[0115] The first monitoring module 901 is used to monitor whether the application service thread running in the terminal device is blocked;

[0116] The second monitoring module 902 is used to monitor whether the kernel of the terminal device is in a fence timeout state;

[0117] The first restart module 903 is used to restart the terminal device if the application service thread is in a blocked state and the kernel is in a fence timeout state.

[0118] As a possible implementation manner, the first monitoring module 901 is specifically used for:

[0119] Based on the first kernel thread, a first state parameter in the monitoring timer thread is obtained, and according to the first state parameter, it is determined whether the application service thread is in a blocked state; wherein the monitoring timer thread is used to monitor whether the application service thread is in a blocked state; and the first state parameter is a parameter used to characterize whether the application service thread is in a blocked state.

[0120] In some embodiments of the present disclosure, the second monitoring module 902 is specifically used to:

[0121] Based on the first kernel thread, the running state of the running fence mechanism thread is obtained, and according to the running state of the fence mechanism thread, it is determined whether the kernel is in a fence timeout state.

[0122] Among them, the fence mechanism threads include GPU fence threads and display fence threads.

[0123] In some embodiments of the present disclosure, the first restart module 903 is specifically used to:

[0124] Based on the first kernel thread, the terminal device is restarted.

[0125] In some other embodiments of the present disclosure, the device further includes:

[0126] A determination module 904 is used to determine whether the monitoring timer thread is in a blocked state based on the first kernel thread;

[0127] The second restart module 905 is used to restart the terminal device based on the first kernel thread if the monitoring timer thread is in a blocked state.

[0128] In some other embodiments of the present disclosure, the second monitoring module 902 is specifically used for:

[0129] Based on the first kernel thread, a second state parameter in the second kernel thread is obtained, and according to the second state parameter, it is determined whether the kernel is in a fence timeout state; wherein the second kernel thread is used to monitor whether the kernel is in a fence timeout state; and the second state parameter is a parameter used to characterize whether the kernel is in a fence timeout state.

[0130] According to the monitoring device for the application running status of the embodiment of the present disclosure, by monitoring whether the application service thread running in the terminal device is in a blocked state, and monitoring whether the kernel of the terminal device is in a fence timeout state, the terminal device is restarted when the application service thread is in a blocked state and the kernel is in a fence timeout state. This solution can solve the problem that when the kernel is in a fence timeout state and the application service thread is blocked, only restarting the system still cannot restore to normal, thereby improving the user experience of the terminal device.

[0131] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0132] Fig.10 This is a block diagram of a terminal device structure according to an exemplary embodiment. For example, the terminal device 1000 may be a mobile phone, a computer, a digital broadcast terminal, a message transceiver device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0133] Reference Fig.10 The terminal device 1000 may include one or more of the following components: a processing component 1002 , a memory 1004 , a power component 1006 , a multimedia component 1008 , an audio component 1010 , an input / output (I / O) interface 1012 , a sensor component 1014 , and a communication component 1016 .

[0134] The processing component 1002 generally controls the overall operation of the terminal device 1000, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 1002 may include one or more processors 1020 to execute instructions to complete all or part of the steps of the above-mentioned method. In addition, the processing component 1002 may include one or more modules to facilitate the interaction between the processing component 1002 and other components. For example, the processing component 1002 may include a multimedia module to facilitate the interaction between the multimedia component 1008 and the processing component 1002.

[0135] The memory 1004 is configured to store various types of data to support operations on the device 1000. Examples of such data include instructions for any application or method operating on the terminal device 1000, contact data, phone book data, messages, pictures, videos, etc. The memory 1004 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0136] The power component 1006 provides power to various components of the terminal device 1000. The power component 1006 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the terminal device 1000.

[0137] The multimedia component 1008 includes a screen that provides an output interface between the terminal device 1000 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 1008 includes a front camera and / or a rear camera. When the device 1000 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and the rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0138] The audio component 1010 is configured to output and / or input audio signals. For example, the audio component 1010 includes a microphone (MIC), and when the terminal device 1000 is in an operation mode, such as a call mode, a recording mode, and a speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 1004 or sent via the communication component 1016. In some embodiments, the audio component 1010 also includes a speaker for outputting audio signals.

[0139] I / O interface 1012 provides an interface between processing component 1002 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: home button, volume button, start button, and lock button.

[0140] The sensor assembly 1014 includes one or more sensors for providing various aspects of status assessment for the terminal device 1000. For example, the sensor assembly 1014 can detect the open / closed state of the device 1000, the relative positioning of the components, such as the display and keypad of the terminal device 1000, and the sensor assembly 1014 can also detect the position change of the terminal device 1000 or a component of the terminal device 1000, the presence or absence of contact between the user and the terminal device 1000, the orientation or acceleration / deceleration of the terminal device 1000, and the temperature change of the terminal device 1000. The sensor assembly 1014 may include a proximity sensor configured to detect the presence of a nearby object without any physical contact. The sensor assembly 1014 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 1014 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0141] The communication component 1016 is configured to facilitate wired or wireless communication between the terminal device 1000 and other devices. The terminal device 1000 can access a wireless network based on a communication standard, such as WiFi, 2G or 3G, or a combination thereof. In an exemplary embodiment, the communication component 1016 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 1016 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0142] In an exemplary embodiment, the terminal device 1000 can be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors or other electronic components to perform the above method.

[0143] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 1004 including instructions, and the instructions can be executed by the processor 1020 of the terminal device 1000 to complete the above-mentioned application running state monitoring method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0144] In an exemplary embodiment, a computer program product is provided. When instructions in the computer program product are executed by a processor of a terminal device 1000, the terminal device 1000 is enabled to execute the above-mentioned method for monitoring the running status of an application.

[0145] Those skilled in the art will readily appreciate other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses or adaptations of the present invention that follow the general principles of the present invention and include common knowledge or customary techniques in the art that are not disclosed in this disclosure. The specification and examples are to be considered exemplary only, and the true scope and spirit of the present invention are indicated by the following claims.

[0146] It should be understood that the present invention is not limited to the exact construction that has been described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A method for monitoring the running status of an application, characterized in that: include: Monitor whether the application service thread running in the terminal device is blocked; Monitoring whether a fence timeout state occurs in the kernel of the terminal device; If the application service thread is in a blocked state and the kernel is in a fence timeout state, the terminal device is restarted.

2. The method according to claim 1, characterized in that The monitoring of whether the application service thread running in the terminal device is in a blocked state includes: Based on the first kernel thread, a first state parameter in the monitoring timer thread is obtained, and according to the first state parameter, it is determined whether the application service thread is in a blocked state; wherein the monitoring timer thread is used to monitor whether the application service thread is in a blocked state; and the first state parameter is a parameter used to characterize whether the application service thread is in a blocked state.

3. The method according to claim 2, characterized in that The monitoring of whether a fence timeout state occurs in the kernel of the terminal device includes: Based on the first kernel thread, the running state of the running barrier mechanism thread is obtained, and according to the running state of the barrier mechanism thread, it is determined whether the kernel is in a barrier timeout state.

4. The method according to claim 3, characterized in that The barrier mechanism threads include a graphics processor barrier thread and a display barrier thread.

5. The method according to claim 3, characterized in that: The restarting of the terminal device includes: Based on the first kernel thread, the terminal device is restarted.

6. The method according to claim 5, characterized in that The method further comprises: Based on the first kernel thread, determining whether the monitoring timer thread is in a blocked state; If the monitoring timer thread is in a blocked state, the terminal device is restarted based on the first kernel thread.

7. The method according to claim 2, characterized in that The monitoring of whether a fence timeout state occurs in the kernel of the terminal device includes: Based on the first kernel thread, obtain the second state parameter in the second kernel thread, and determine whether the kernel is in a fence timeout state based on the second state parameter; wherein the second kernel thread is used to monitor whether the kernel is in a fence timeout state; the second state parameter is a parameter used to characterize whether the kernel is in a fence timeout state.

8. A device for monitoring the running status of an application, characterized in that: include: The first monitoring module is used to monitor whether the application service thread running in the terminal device is blocked; A second monitoring module, used for monitoring whether a fence timeout state occurs in the kernel of the terminal device; The first restart module is used to restart the terminal device if the application service thread is in a blocked state and the kernel is in a fence timeout state.

9. The device according to claim 8, characterized in that The first monitoring module is specifically used for: Based on the first kernel thread, a first state parameter in the monitoring timer thread is obtained, and according to the first state parameter, it is determined whether the application service thread is in a blocked state; wherein the monitoring timer thread is used to monitor whether the application service thread is in a blocked state; and the first state parameter is a parameter used to characterize whether the application service thread is in a blocked state.

10. The device according to claim 9, characterized in that The second monitoring module is specifically used for: Based on the first kernel thread, the running state of the running barrier mechanism thread is obtained, and according to the running state of the barrier mechanism thread, it is determined whether the kernel is in a barrier timeout state.

11. The device according to claim 10, characterized in that The barrier mechanism threads include a graphics processor barrier thread and a display barrier thread.

12. The device according to claim 10, characterized in that The first restart module is specifically used for: Based on the first kernel thread, the terminal device is restarted.

13. The device according to claim 12, characterized in that The device also includes: A judging module, configured to judge whether the monitoring timer thread is in a blocked state based on the first kernel thread; The second restart module is used to restart the terminal device based on the first kernel thread if the monitoring timer thread is in a blocked state.

14. The device according to claim 9, characterized in that The second monitoring module is specifically used for: Based on the first kernel thread, obtain the second state parameter in the second kernel thread, and determine whether the kernel is in a fence timeout state based on the second state parameter; wherein the second kernel thread is used to monitor whether the kernel is in a fence timeout state; the second state parameter is a parameter used to characterize whether the kernel is in a fence timeout state.

15. A terminal device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the method for monitoring the application running status as described in any one of claims 1 to 7 is implemented.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for monitoring the application running status according to any one of claims 1 to 7 is implemented.

17. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the computer program implements the method for monitoring the application running status according to any one of claims 1 to 7.

Images