CN113961442A

CN113961442A - Method and device for monitoring stuck anomaly, terminal equipment and medium

Info

Publication number: CN113961442A
Application number: CN202010706187.2A
Authority: CN
Inventors: 王举; 张仓; 张楠
Original assignee: Beijing Xiaomi Mobile Software Co Ltd
Current assignee: Beijing Xiaomi Mobile Software Co Ltd
Priority date: 2020-07-21
Filing date: 2020-07-21
Publication date: 2022-01-21

Abstract

The disclosure relates to a method, a device, a terminal device and a medium for monitoring stuck anomaly, wherein the method comprises the following steps: monitoring time information of the terminal equipment during operation; determining whether the terminal equipment is in abnormal jamming during the operation period or not according to the time information; and when the stuck abnormality occurs, storing abnormal log information corresponding to the stuck abnormality, wherein the abnormal log information comprises a stuck abnormality position and stuck abnormality time. By using the method, whether the terminal equipment is blocked or not in the operation process can be monitored in real time, and the abnormal log information can be stored in time when the terminal equipment is blocked, so that a user can conveniently and quickly know the cause of the blockage according to the abnormal log information.

Description

Method and device for monitoring stuck anomaly, terminal equipment and medium

Technical Field

The present disclosure relates to the field of terminals, and in particular, to a method and an apparatus for monitoring a stuck anomaly, a terminal device, and a medium.

Background

With the development of the technology, the application range of the terminal equipment is wider and wider. The terminal device can support a variety of applications based on the terminal device's operating system (e.g., android). In the using process of the terminal equipment, as more and more application programs are installed, a stuck phenomenon can occur in the using process. Methods for effectively finding and solving the problem of terminal equipment blockage are lacked in the related art.

Disclosure of Invention

In order to overcome the problems in the related art, the present disclosure provides a stuck anomaly monitoring method, device, terminal device and medium.

According to a first aspect of the embodiments of the present disclosure, there is provided a stuck anomaly monitoring method applied to a terminal device, including:

monitoring time information of the terminal equipment during operation;

determining whether the terminal equipment is in abnormal jamming during the operation period or not according to the time information;

and when the stuck abnormality occurs, storing abnormal log information corresponding to the stuck abnormality, wherein the abnormal log information comprises a stuck abnormality position and stuck abnormality time.

Optionally, the monitoring time information during the operation of the terminal device includes:

monitoring time information during application program operation, monitoring time information of interprocess communication, monitoring time information of system service process and/or system operation time information.

Optionally, the stuck exception location comprises an exception location in an application process, an interprocess communication, a system service process, and/or a system.

Optionally, the determining, according to the time, whether a stuck abnormality occurs during the operation of the terminal device includes:

and determining whether the terminal equipment is abnormally clamped or not during the operation period according to the time information and a preset clamping threshold corresponding to the time information.

Optionally, the determining, according to the time information and a preset stuck threshold corresponding to the time information, whether a stuck abnormality occurs during the operation of the terminal device includes:

judging whether the time information exceeds the preset stuck threshold value or not;

and if the time information exceeds the preset stuck threshold, determining that stuck abnormity occurs during the operation of the terminal equipment.

Optionally, the method further comprises:

receiving abnormal log request information;

and outputting the abnormal log information to external equipment, and/or displaying the abnormal log information on terminal equipment.

According to a second aspect of the embodiments of the present disclosure, there is provided a stuck anomaly monitoring device applied to a terminal device, including:

the monitoring module is used for monitoring time information of the terminal equipment during the operation period;

the determining module is used for determining whether the terminal equipment is in abnormal jamming during the running period according to the time information;

the storage module is used for storing abnormal log information corresponding to the stuck abnormality when the stuck abnormality occurs, and the abnormal log information comprises a stuck abnormal position and stuck abnormal time.

Optionally, the monitoring module is specifically configured to:

Optionally, the determining module is specifically configured to:

Optionally, the determining module includes:

the judging submodule is used for judging whether the time information exceeds the preset stuck threshold value or not;

and the determining submodule is used for determining that the terminal equipment is in abnormal jam during the operation period if the time information exceeds the preset jam threshold value.

Optionally, the apparatus further comprises:

the receiving module is used for receiving abnormal log request information;

and the output module is used for outputting the abnormal log information to external equipment and/or displaying the abnormal log information on terminal equipment.

According to a third aspect of the embodiments of the present disclosure, there is provided a terminal device, including:

a processor;

a memory for storing executable instructions of the processor;

wherein the processor is configured to perform the stuck anomaly monitoring method as defined in any one of the above.

According to a fourth aspect of embodiments of the present disclosure, there is provided a non-transitory computer-readable storage medium, wherein instructions of the storage medium, when executed by a processor of a smart device, enable a terminal device to perform the stuck anomaly monitoring method as described in any one of the above.

The technical scheme provided by the embodiment of the disclosure can have the following beneficial effects: by using the method, whether the terminal equipment is blocked or not in the operation process can be monitored in real time, and the abnormal log information can be stored in time when the terminal equipment is blocked, so that a user or a developer can conveniently and quickly know the cause of the blockage according to the abnormal log information.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

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.

FIG. 1 is a flow chart illustrating a method according to an example embodiment.

FIG. 2 is a flow chart illustrating a method according to an example embodiment.

FIG. 3 is a flow chart illustrating a method according to an example embodiment.

FIG. 4 is a flow chart illustrating a method according to an example embodiment.

FIG. 5 is a flow chart illustrating a method according to an example embodiment.

FIG. 6 is a monitoring block diagram illustrating a method in accordance with an exemplary embodiment.

Fig. 7 is a schematic diagram of a time node shown in accordance with an example embodiment.

Fig. 8 is a block diagram illustrating an apparatus according to an example embodiment.

Fig. 9 is a block diagram illustrating an apparatus according to an example embodiment.

FIG. 10 is a block diagram illustrating an apparatus according to an example embodiment.

Fig. 11 is a block diagram of a terminal device shown according to an example embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like 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. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the invention, as detailed in the appended claims.

With the development of the technology, the application range of the terminal equipment is wider and wider. The terminal device can support a variety of applications based on the terminal device's operating system (e.g., android).

The terminal device generally includes a processor, a memory, and a display screen to implement the operation of the terminal device system or the operation of the application program. Wherein the processor performs various functions of the smart device and processes data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory, and invoking data stored in the memory. For example, the processor may integrate one or more of a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a modem, and the like. Wherein, the CPU mainly processes an operating system, a user interface, an application program and the like; the GPU is used for rendering and drawing the content required to be displayed by the display screen; the modem is used to handle wireless communications. The memory may be used to store an instruction, a program, code, a set of codes, or a set of instructions. For example, the storage program area of the memory may store instructions for implementing an operating system, instructions for performing at least one function (such as a touch function, a sound playing function, an image playing function, and the like), instructions for implementing a control method, and the like.

Taking an intelligent device with an operating system as an android system as an example, a Linux kernel layer, a system running library layer, an application framework layer and an application layer are stored in the memory. The Linux kernel layer provides underlying drivers for various hardware of the intelligent device, such as a display driver and an audio driver. The system operation library layer provides main characteristic support for the Android system through some C/C + + libraries, for example, the OpenGL/ES library provides support for 3D drawing. The application framework layer provides various APIs that may be used when building an application, such as the following: window management, view management, etc. At least one application program runs in the application layer, and the application programs can be self-contained by an operating system, such as a short message program; or may be an application developed by a third-party developer, such as a WeChat program, a QQ program, or the like.

In the using process of the terminal equipment, as more and more application programs are installed, a stuck phenomenon can occur in the using process. Methods for effectively finding and solving the problem of terminal equipment blockage are lacked in the related art.

The development test is carried out to ensure the quality of the terminal equipment, but only a part of the blockage problem of the terminal equipment can be solved in the development test process, and in the use process, due to the diversification of the use scenes and the operation habits of the terminal equipment, the blockage phenomenon occurs occasionally, and the reasons of the blockage phenomenon are different.

In the related art, in the process of solving the card performance problem of the terminal device, a sysrace (system call tracing provider) tool is often adopted, but the tool is difficult to use, and developers need to perform secondary analysis to know the abnormal reason. Or performance analysis is only carried out according to a native budget log system of the Android system, but the budget analysis needs strong speciality and the analysis process is complicated.

In order to solve the above technical problem, the present disclosure provides a stuck anomaly monitoring method, applied to a terminal device, including: monitoring time information of the terminal equipment during operation; determining whether the terminal equipment is in abnormal jamming during the operation period or not according to the time information; when the pause abnormality occurs, storing abnormal log information corresponding to the pause abnormality, wherein the abnormal log information comprises a pause abnormal position and pause abnormal time. By using the method, whether the terminal equipment is blocked or not in the operation process can be monitored in real time, and the abnormal log information can be stored in time when the terminal equipment is blocked, so that a user can conveniently and quickly know the cause of the blockage according to the abnormal log information.

In an exemplary embodiment, the method of the present embodiment is applied to a terminal device, wherein the terminal device may be a portable electronic device such as a mobile phone, a tablet computer, a notebook computer, and an electronic book. The terminal device may be a terminal device whose operating system is an Android (Android) system, or may be a terminal device whose operating system is an iOS system.

Taking a terminal device with an operating system as an Android system as an example, in this embodiment, a MITurbo module is integrated in a budget of the terminal device, and the MITurbo module can monitor log information of the terminal device during operation in real time. In addition, in the MIturbo disclosed by the disclosure, the log printing position, the log printing content and the log printing quantity of the MIturbo log information are optimized by adopting a log enhancement technology, so that the information contained in the log information obtained by the MIturbo log enhancement technology is richer, for example, the log information contains the running time and the running condition of an event in the embodiment, when a stuck anomaly occurs, the MIturbo can monitor the abnormal log information, and the position and the reason of the stuck anomaly can be known through the abnormal log information monitored by the MIturbo.

As shown in fig. 1, the method of the present embodiment includes the following steps:

and S110, monitoring the running time information of the application program during the running period of the terminal equipment.

And S120, determining whether the terminal equipment is in abnormal jamming during the operation period according to the time information.

S130, when the stuck abnormality occurs, storing abnormal log information corresponding to the stuck abnormality, wherein the abnormal log information comprises a stuck abnormality position and a stuck abnormality time.

In step S110, the MITurbo can monitor log information of the application program of the terminal device in the running process, that is, obtain the log information of the APP running layer. Referring to fig. 6, the log information of the mitroco during the running process of the application program is obtained based on the real-time monitoring of Looper messages, and the monitored log information may include: main thread message elapsed time monitoring logs, Callback monitoring logs, and elapsed time statistics logs (Running time, and Sleep time).

The Looper in the Android system is responsible for managing a message queue and a message loop of a thread, and one thread may have one message queue and one message loop (Looper). The Android main thread is generally responsible for interface updating operation (a Looper object of the main thread of the current process can be obtained through loop. For example, in the process of updating a UI (user interface) by using a message mechanism, a thread for updating the UI (for example, Activity is a UI thread running in a main thread) has a Looper, and messages are continuously called in a loop method thereof, so that the execution time of each message can be monitored. In addition, the Android system sends a VSYNC (vertical synchronization) signal at regular intervals (for example, 16ms), and notifies the interface to redraw and render. In the process, Callback (Callback) monitoring is involved, log information obtained by monitoring comprises time periods of two callbacks, and whether the process is jammed or not can be judged according to whether the time periods of the two callbacks are overtime or not. It can be understood that Running time, Running state time and Sleep time of a certain event can be known through the time-consuming statistical log.

In this step, the time information of the application running period may be, for example, the actual running time of an event in the application, for example, the time information of the application in which the event starts running is t1, the time information of the event in which the running is ended is t2, and the actual running time Δ t of the event, Δ t, is the time information of the event in the application running period.

In step S120, any event in the application program has a corresponding preset running time or preset running time range, and when each event in the application program runs at the corresponding preset running time or runs within the preset running time range, the event is considered to be normally running and has no stuck abnormality. And when the actual running time of the event is greater than the preset running time or the preset running time range, the event is considered to be stuck, and the position of the stuck exception is the event in the application process.

In this step, whether the terminal device is stuck abnormally during the operation period is determined according to the actual operation time information and the preset stuck threshold corresponding to the actual operation time information.

In one example, the preset stuck threshold refers to a preset running time corresponding to any event in an application program, and in the running process of the application program, whether time information of each event exceeds the corresponding preset stuck threshold is judged in real time; and if the time information exceeds a preset stuck threshold value, determining that stuck abnormity occurs during the operation of the terminal equipment.

In another example, the preset stuck threshold refers to a preset running time range corresponding to any event in the application program, and in the running process of the application program, whether the time information of each event exceeds the corresponding preset stuck threshold (exceeds the upper limit of the preset running time range) is judged in real time; and if the time information exceeds a preset stuck threshold value, determining that stuck abnormity occurs during the operation of the terminal equipment.

In step S130, when a stuck-in abnormality occurs, storing abnormal log information corresponding to the application program in the MITurbo log information, where the abnormal log information includes a stuck-in occurrence position (for example, a specific stuck-in event) and a stuck-in abnormality time (for example, a time for which the stuck-in event is delayed). For example, when the UI (user interface) is not updated timely, the user perceives that the system is stuck, and the following log information monitored by the MITurbo can be monitored: and the main thread of the application program App has time-consuming messages, so that the UI is not updated timely, and meanwhile, the log messages contain the time-consuming messages of the main thread and output time-consuming statistics.

In one example, the following main thread doFrameLate exception log information is monitored by the mitrocosh:

01-21 12:07:01.255 21147 21147W Looper:Slow Looper:doFrame is 321ms late because of 12msg,msg 1took 90ms(cputime＝6ms late＝50ms h＝com.android.systemui.statusbar.CommandQueue$H w＝655360),msg 10took 217ms(cputime＝4ms late＝110ms h＝com.android.systemui.statusbar.CommandQueue$H w＝589824)

according to the log Message of the present example, the main thread of the application is busy, the drawing delay time of a certain frame is 321ms (doFrame is 321ms late), 12 messages are executed in the drawing process (12 msg), and the execution time of each Message (for example, msg 1 hook 90 ms: 1 st Message 90ms) is known. Among them, the most time-consuming message is the most dominant cause of dropped frames (causing a stuck). Therefore, the reason of the frame dropping (stuck) can be directly known through the log message.

In another example, MIturbo monitors the following Activity Late exception log information:

01-21 12:07:49.169 7619 7619W Looper:Slow Looper:

Activity com.android.quicksearchbox/.SearchActivity is 633ms late(process＝+54ms cputime＝+8ms ClientTransaction{lifecycleRequest＝android.app.servertransaction

.PauseActivityItem})because of 33msg,

msg 1took 543ms(cputime＝157ms late＝1ms h＝android.os.Handler c＝com.android.quicksearchbox.SearchActivity$a),

msg 7took 82ms

(cputime＝3ms late＝650ms h＝android.view.Choreographer$FrameHandler c＝android.view.Choreographer$FrameDisplayEventReceiver),

msg 22took 72ms

(cputime＝5ms late＝585ms h＝com.miui.org.chromium.base.SystemMessageHandler w＝1)

as can be seen by the log messages of this example, the application main thread is busy, and the time-consuming Message information causes the Activity Lifecycle callback to be slow. Such as: onPause (PauseActivityItem) callback of SearchActivity of quick search box delayed 633 ms; in the total duration (633ms) causing callback delay, Looper executed 33 messages (beacon of 33msg), and three time-consuming messages, the 1 st message, the 7 th message, and the 22 nd message, were the main causes of Activity callback delay. Wherein, the 1 st message takes 543ms to execute, the cpu running time (cpu running time) takes 157ms, and handle is android. The 7 th message takes 82ms to execute and the 22 nd message takes 72ms to execute.

In another example, the following anomaly log information is monitored by the mitroco:

02-22 08:19:33.764 10231 30213 30213W Looper:Slow Looper main:Long Msg:seq＝103338plan＝08:18:56.765late＝1ms wall＝36996ms running＝4ms runnable＝4ms h＝android.view.Choreographer$FrameHandlerc＝android.view.Choreographer$FrameDisplayEventReceiver

from the log message of this example, the application main thread is busy for reasons including the delay of long messages (1ms) and the running time (4ms) and running time (4ms) of the message are known.

In an exemplary embodiment, as shown in fig. 2, the method of the present embodiment includes the following steps:

and S210, monitoring system operation time information during the operation period of the terminal equipment.

And S220, determining whether the terminal equipment is in abnormal jamming during the operation period according to the time information.

And S230, storing abnormal log information corresponding to the pause abnormality when the pause abnormality occurs, wherein the abnormal log information comprises a pause abnormal position and pause abnormal time.

In step S210, the MITurbo can monitor log information of the terminal device in the system operation, that is, log information of the system layer, where the system operation monitoring in this embodiment refers to monitoring of the core system module. Referring to fig. 6, in the monitoring log information of the core system module, the monitored log information may include: reporting exception monitoring, SurfaceFlinger composite image monitoring and Input distribution process monitoring by the SurfaceFlinger Vsync. The Surface flunger can receive the Surface (interface) as input, and calculates the position of each Surface in the final composite image according to parameters such as transparency, size and position. And determining whether the stuck abnormal position is in the operation of the system module through monitoring the core system module, such as display monitoring of SF and full link monitoring of Input events.

Step S220 is a step of determining whether the system operation time information has a stuck abnormality, which may refer to step S120 and is not described herein again.

In step S230, when a stuck-in anomaly occurs, storing anomaly log information in the MITurbo log information during system operation, where the anomaly log information includes a stuck-in anomaly location (e.g., a specific stuck event) and a reason (e.g., a time for which the stuck event is delayed).

In one example, the log information can include an Input distribution flow monitoring log. The delivery process of a user input event can be simplified as follows: hardware, kernel, system _ server, App (application program). Four time nodes (T1, T2, T3 and T4) as shown in fig. 7 are defined according to the transfer process, T1 represents the time when the inputthreader reads out the event from/dev/input/xxx, T2 represents the time when the InputDispatcher transmits the event to the App, T3 represents the time when the App main thread starts to process the input event, and T4 represents the time when the App main thread finishes processing the input event. The time consumed by the system _ server is (T2-T1), the time consumed before the application program is processed is (T3-T1), and the time consumed by the application program is (T4-T3).

For example, the MITurbo monitors the following abnormal log information:

03-26 18:25:06.590 1306 1773W InputTransport:Slow Input:372ms so far,channel'3908d6b NavigationBar(server)'publisher～publishMotionEvent:seq＝3004,deviceId＝6,source＝0x1002,action＝0x2,actionButton＝0x00000000,

flags＝0x0,edgeFlags＝0x0,metaState＝0x0,buttonState＝0x0,xOffset＝0.000000,yOffset＝-2210.000000,

xPrecision＝1.000000,yPrecision＝1.000000,downTime＝28011572008000,eventTime＝28011595886000,pointerCount＝1

as can be seen from the log messages, in sending an event to App, Input times out (InputTransport: Slow Input), and this time is the elapsed time period of system _ server (T2-T1) or the elapsed time period before application processing (T3-T1). The reason for the timeout is known from the log information as the InputDispatcher thread of system _ server processes the timeout. The reason why the Input event is not processed in time in this example is a system problem.

For another example, the following abnormal log information is monitored by the mitroco:

03-22 11:04:07.692 7001 7001W InputEventReceiver:App Input:Dispatching InputEvent took 114ms in main thread！

as can be seen from the log messages, when the App runs, the Input is overtime, i.e. the log information in this example is in the application processing time-consuming period (T4-T3), and the reason for the timeout is that the application main thread is overtime (look 114ms in main thread). The reason why the Input event is not processed in time in this example is the App problem.

As can be seen from the above example, in the Input distribution flow monitoring log information, the reason why the Input is overtime can be output, and whether the reason why the Input event is not processed in time is a system problem or an App problem can be distinguished.

In another example, the log information may further include a surfefinger composite image monitoring log. The monitoring log information of the SurfaceFlinger synthesized image can accurately locate the pause caused by hardware synthesis. For example, the MITurbo monitors the following abnormal log information:

12-20 18:34:40.653 16190 16190W SurfaceFlinger:Slow operation:98ms so far,now at doComposition completed.

as can be seen from the log message of this example, the SF runs slowly and the SF synthesis times out.

In the surfaflinger composite image monitoring, the time consumption check of a certain event may be, for example, to check the time consumption of the event by dotting the recording start time at the start of the event and recording the end time after the event is completed. For example, in this example, the point is taken when frame refresh is started, and the check is performed at the end time of preparframe, docomposion, and postComposition, respectively.

In another example, the log information may further include a surfafinger Vsync report exception monitoring log, for example, mitro monitors that the following exception log information exists:

02-07 16:59:53.289 26972 26999W SurfaceFlinger:Slow vsync-app on display(19261116564980353),last period is 22ms

as can be seen from the log message of this example, the surfefinger is abnormal when Vsync (vertical synchronization signal) reporting App is displayed.

In an exemplary embodiment, as shown in fig. 3, the method of the present embodiment includes the following steps:

s310, monitoring time information of a system service process during the operation of the terminal equipment.

And S320, determining whether the terminal equipment is in abnormal jamming during the operation period according to the time information.

S330, when the stuck abnormality occurs, storing abnormal log information corresponding to the stuck abnormality, wherein the abnormal log information comprises a stuck abnormality position and a stuck abnormality time.

In step S310, the mitroc can monitor the log information of the system service process (SystemServer) during the operation of the terminal device, and the monitoring of this embodiment is still the log information at the system level. Referring to fig. 6, the MITurbo monitors log information of a system service process, and the monitored log information may include ams (activity manager service) monitoring, wms (windowmanager service) monitoring, and pms (packet manager service) monitoring. The AMS, the WMS, the PMS and the like are all threads running in the SystemServer process, the AMS is used for managing the Activity of the application program, the WMS is used for managing the hiding or displaying of each window and the like, and the PMS is used for managing and tracking the APK, the installation, the analysis, the control authority and the like of the application program.

Step S320 determines whether the time information of the system service process is abnormal, which can refer to step S120 and is not described herein again.

In step S330, when a stuck-in anomaly occurs, the mitrocar stores the anomaly log information in the monitored system service process, where the anomaly log includes a stuck-in anomaly location (e.g., a specific stuck event) and a cause (e.g., a time for a stuck event delay) in the system service process.

In an exemplary embodiment, as shown in fig. 4, the method of the present embodiment includes the following steps:

and S410, monitoring time information of inter-process communication during the operation of the terminal equipment.

And S420, determining whether the terminal equipment is in abnormal jamming during the operation period according to the time information.

S430, when the stuck abnormality occurs, storing abnormal log information corresponding to the stuck abnormality, wherein the abnormal log information comprises a stuck abnormality position and a stuck abnormality time.

In step S410, the MITurbo can monitor log information of an inter-process communication mechanism (IPC mechanism) during the operation of the terminal device, and the IPC mechanism between the application processes of the terminal device of the Android system generally adopts a Binder communication mode.

Step S420 is a step of determining whether the time information of the inter-process communication is abnormal, which may refer to step S120 and is not described herein again.

In step S430, when a stuck-in exception occurs, the mitroche outputs exception log information in the monitored inter-process communication mechanism, where the exception log includes a stuck-in exception location (e.g., a specific stuck-in event) and a reason (e.g., a time for a stuck-in event delay) of the Binder communication.

In an exemplary embodiment, as shown in fig. 5, the method of the present embodiment includes the following steps:

and S510, monitoring time information of the terminal equipment during operation.

S520, determining whether the terminal equipment is in abnormal jamming during the operation period according to the time information.

S530, when the stuck abnormality occurs, storing abnormal log information corresponding to the stuck abnormality, wherein the abnormal log information comprises a stuck abnormality position and a stuck abnormality time.

And S540, receiving the abnormal log request information.

And S550, outputting the abnormal log information to the external equipment, and/or displaying the abnormal log information on the terminal equipment.

In step S510, the time information during the running of the terminal device may include time information during the running of the application program, time information of inter-process communication, time information of a system service process, and/or time information of system running, that is, the time information involved in the embodiments corresponding to fig. 1to fig. 4 may be monitored at the same time.

Step S520 may refer to step S120 for determining whether the time information is abnormal for stuck, and details are not repeated here.

In step S530, according to the monitored log information, the location where the stuck anomaly occurs may be an application process, inter-process communication, a system service process and/or a system, which may specifically refer to the embodiments corresponding to fig. 1to 4.

In step S540, the abnormality log request information may be sent by the user, or may be sent by the manufacturer of the mobile phone, App developer, or system developer.

In step S550, the MITurbo of this embodiment monitors log information during the operation of the terminal device in real time, but only needs to store (may adopt a cache manner) the abnormal log information when a stuck abnormality occurs. After receiving the abnormal log request information, the MITurbo may output the abnormal log information to the external device and/or display the abnormal log information on the terminal device. After the abnormal log is output, the abnormal log information stored by the MIturbo can be deleted in time.

For example, when the request information is sent by the developer, the abnormal log information can be output to the computer device of the developer, so that the developer can improve the performance of the terminal device according to the abnormal reason. For another example, when the request information is sent by the user, the abnormal log information may be directly displayed on the terminal device, which is convenient for the user to view. The abnormal log information in the embodiment includes the cause and the result of the stuck abnormal, so that even an ordinary user can conveniently know the cause of the abnormal, and corresponding processing measures can be conveniently taken for the cause of the abnormal, so as to improve the performance of the terminal device. In this embodiment, the MITurbo of the terminal device may store the manufacturer experience, and after the stuck anomaly occurs, the user may feed back the problem to the developer through the problem feedback application, and the bug report system integrated with the MITurbo may automatically generate an improvement scheme and notify the corresponding process of the terminal device.

By integrating the above embodiments, the method in the present disclosure can automatically determine whether the App is a problem or a system problem according to the log information monitored by the MITurbo log enhancement mode when a checkpoint occurs during the use of the terminal device, and store or print out the related abnormal log information. The user or the developer can quickly locate the cause of the stuck abnormity, and provide a proper solution according to the cause, so that the efficiency of analyzing the problem is greatly improved. Compared with a Systrace tool in the related technology, the method disclosed by the invention has the characteristics of non-real time (log output or storage is carried out when the stuck abnormality occurs), automatic analysis (log information contains the cause of the stuck abnormality) and the like, and is a more convenient performance analysis technology.

In an exemplary embodiment, the present disclosure provides a stuck anomaly monitoring device, as shown in fig. 8, applied to a terminal device, including: a monitoring module 110, a determination module 120, and a storage module 130. In implementation, the monitoring module 110 is used to monitor time information during the operation of the terminal device. The determining module 120 is configured to determine whether a stuck anomaly occurs during the operation of the terminal device according to the time information. The storage module 130 is configured to store exception log information corresponding to the katze exception when the katze exception occurs, where the exception log information includes a position of the katze exception and a time of the katze exception. When the monitoring module 110 is used to monitor the time information during the running of the application program, the apparatus in this embodiment is used to implement the method shown in fig. 1. When the monitoring module 110 is used to monitor the time information of the system operation, the apparatus in this embodiment is used to implement the method shown in fig. 2. When the monitoring module 110 is used to monitor the time information of the system service process, the apparatus in this embodiment is used to implement the method shown in fig. 3. When the monitoring module 110 is used to monitor time information of inter-process communication, the apparatus in this embodiment is used to implement the method shown in fig. 4. The stuck-in exception location may include, among other things, an exception location (stuck-in event) in an application process, interprocess communication, system service process, and/or system.

In an exemplary embodiment, referring to fig. 9, the apparatus of the present embodiment includes: the monitoring module 110, the determining module 120 and the storing module 130, wherein the determining module 120 includes a determining sub-module 1201 and a determining sub-module 1202. In the implementation process, the determining module is specifically configured to determine whether a stuck abnormality occurs during the operation of the terminal device according to the time information and a preset stuck threshold corresponding to the time information. The judgment sub-module 1201 is configured to judge whether the time information exceeds a preset stuck threshold. The determining submodule 1202 is configured to determine that a stuck anomaly occurs during the operation of the terminal device if the time information exceeds a preset stuck threshold.

In an exemplary embodiment, referring to fig. 10, the apparatus of the present embodiment includes: the monitoring module 110, the determining module 120, the storing module 130, the receiving module 140, and the outputting module 150, and the apparatus in this embodiment is used to implement the method shown in fig. 5. In implementation, the receiving module 140 is configured to receive exception log request information. The output module 150 is configured to output the abnormal log information to the external device, and/or display the abnormal log information on the terminal device.

Fig. 11 is a block diagram of a terminal device. The present disclosure also provides for a terminal device, for example, device 500 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, and the like.

Device 500 may include one or more of the following components: a processing component 502, a memory 504, a power component 506, a multimedia component 508, an audio component 510, an input/output (I/O) interface 512, a sensor component 514, and a communication component 516.

The processing component 502 generally controls overall operation of the device 500, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing components 502 may include one or more processors 520 to execute instructions to perform all or a portion of the steps of the methods described above. Further, the processing component 502 can include one or more modules that facilitate interaction between the processing component 502 and other components. For example, the processing component 502 can include a multimedia module to facilitate interaction between the multimedia component 508 and the processing component 502.

The memory 504 is configured to store various types of data to support operation at the device 500. Examples of such data include instructions for any application or method operating on device 500, contact data, phonebook data, messages, pictures, videos, and so forth. The memory 504 may be implemented by any type or combination of volatile or non-volatile memory devices 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 or optical disks.

Power component 506 provides power to the various components of device 500. The power components 506 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for the apparatus 500.

The multimedia component 508 includes a screen that provides an output interface between the device 500 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 an input signal from a 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 boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 508 includes a front facing camera and/or a rear facing camera. The front-facing camera and/or the rear-facing camera may receive external multimedia data when the device 500 is in an operating mode, such as a shooting mode or a video mode. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

The audio component 510 is configured to output and/or input audio signals. For example, the audio component 510 includes a Microphone (MIC) configured to receive external audio signals when the device 500 is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals may further be stored in the memory 504 or transmitted via the communication component 516. In some embodiments, audio component 510 further includes a speaker for outputting audio signals.

The I/O interface 512 provides an interface between the processing component 502 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to: a home button, a volume button, a start button, and a lock button.

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

The communication component 516 is configured to facilitate communications between the device 500 and other devices in a wired or wireless manner. The device 500 may 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 516 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 516 further includes a Near Field Communication (NFC) module to facilitate short-range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

In an exemplary embodiment, the device 500 may 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, micro-controllers, microprocessors or other electronic components for performing the above-described methods.

A non-transitory computer readable storage medium, such as the memory 504 including instructions executable by the processor 520 of the device 500 to perform the method, is provided in another exemplary embodiment of the present disclosure. For example, the computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like. The instructions in the storage medium, when executed by a processor of the electronic device, enable the terminal device to perform the above-described method.

Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

It will be understood that the invention is not limited to the precise arrangements 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 invention is limited only by the appended claims.

Claims

1. A method for monitoring abnormal jamming is applied to terminal equipment and is characterized by comprising the following steps:

monitoring time information of the terminal equipment during operation;

2. The katton anomaly monitoring method according to claim 1, wherein the monitoring of the time information during the operation of the terminal device comprises:

3. The katton anomaly monitoring method of claim 2, wherein the katton anomaly location comprises an application process, an interprocess communication, a system service process, and/or an anomaly location in a system.

4. The stuck anomaly monitoring method according to claim 1, wherein the determining whether the stuck anomaly occurs during the operation of the terminal equipment according to the time comprises:

5. The stuck anomaly monitoring method according to claim 4, wherein the step of determining whether the stuck anomaly occurs during the operation of the terminal device according to the time information and a preset stuck threshold corresponding to the time information comprises the following steps:

6. The katton anomaly monitoring method of claim 1, further comprising:

receiving abnormal log request information;

7. The utility model provides a calorie of unusual monitoring devices of dun, is applied to terminal equipment, its characterized in that includes:

8. The katton anomaly monitoring device of claim 7, wherein the monitoring module is specifically configured to:

9. The katton anomaly monitoring device of claim 8, wherein the katton anomaly location comprises an application process, an interprocess communication, a system service process, and/or an anomaly location in a system.

10. The katton anomaly monitoring device of claim 7, wherein the determining module is specifically configured to:

11. The katton anomaly monitoring device of claim 10, wherein the determination module comprises:

12. The katton anomaly monitoring device of claim 7, further comprising:

the receiving module is used for receiving abnormal log request information;

13. A terminal device, comprising:

a processor;

a memory for storing executable instructions of the processor;

wherein the processor is configured to perform the stuck anomaly monitoring method of any one of claims 1to 6.

14. A non-transitory computer readable storage medium, wherein instructions in the storage medium, when executed by a processor of a smart device, enable a terminal device to perform the katton anomaly monitoring method according to any one of claims 1to 6.