CN111752719A

CN111752719A - Method and device for detecting stuck

Info

Publication number: CN111752719A
Application number: CN202010598543.3A
Authority: CN
Inventors: 黄伟平
Original assignee: Tencent Music Entertainment Technology Shenzhen Co Ltd
Current assignee: Tencent Music Entertainment Technology Shenzhen Co Ltd
Priority date: 2020-06-28
Filing date: 2020-06-28
Publication date: 2020-10-09

Abstract

The application discloses a method and a device for detecting stuck, and belongs to the technical field of computers. The method comprises the following steps: when the main thread accesses the locked data container, the access time is recorded, wherein the data container is locked by the first sub-thread. And when the first sub thread releases the lock of the data container, recording the time when the lock is released. And determining the waiting time of the main thread by the first sub-thread based on the access time and the lock releasing time. And if the waiting time is longer than a card pause time threshold, determining that card pause exists, and acquiring card pause information, wherein the card pause information comprises the call stack of the first sub-thread, the call stack of the main thread and the waiting time. By adopting the method and the device, the blockage caused by locking can be found, and the information related to the blockage can be acquired for the analysis of developers, so that the blockage problem can be solved timely.

Description

Method and device for detecting stuck

Technical Field

The application relates to the technical field of computers, in particular to a method and a device for detecting stuck.

Background

A thread is the smallest unit capable of performing operation scheduling in an operating system, and the operating system can simultaneously execute a plurality of threads. During the lifecycle of an application, multiple threads may be executing simultaneously. Among them, the threads can be divided into a main thread and a sub-thread. The main thread is a thread for processing user interaction events in the application, and if the main thread has events such as waiting and too long execution time, the application can be directly blocked, and user experience is influenced. A child thread refers to a thread other than a main thread.

During the operation, the data container is locked in order to ensure the safety and consistency of data reading and writing in a multi-thread scene. When a thread locks a data container and before the thread releases the lock, other threads access the data container, the execution is suspended, and the lock release is waited. If the thread waiting for the lock release is the main thread, the application may be stuck and the user experience may be affected.

Therefore, how to timely detect the jamming caused by the locking of the main thread and acquire the information related to the jamming for the analysis of developers so as to timely solve the jamming problem is a problem worthy of research.

Disclosure of Invention

The embodiment of the application provides a method and a device for detecting stuck, which can solve the technical problems in the related art. The technical scheme of the method and the device for detecting the stuck signal is as follows:

in a first aspect, a method for detecting stuck is provided, the method comprising:

when a main thread accesses a locked data container, recording the access time, wherein the data container is locked by a first sub-thread;

when the first sub thread releases the lock of the data container, recording the time of releasing the lock;

determining, by the first child thread, a waiting duration of the main thread based on the access time and the lock release time;

and if the waiting time is longer than a card pause time threshold, determining that card pause exists, and acquiring card pause information, wherein the card pause information comprises the call stack of the first sub-thread, the call stack of the main thread and the waiting time.

In one possible implementation manner, the obtaining the stuck information includes:

acquiring a call stack of the first sub-thread through the first sub-thread;

and returning to the main thread, and acquiring a call stack of the main thread through the main thread.

opening a second sub thread;

and acquiring the call stack of the first sub-thread and the call stack of the main thread through the second sub-thread.

In a possible implementation manner, the morton information further includes data container information, and the obtaining the morton information further includes:

and determining data container information based on the call stack of the first sub-thread and the call stack of the main thread, wherein the data container information comprises the identification of the data container and the logic information of reading and writing the data container by the first sub-thread.

In a possible implementation manner, the morton information further includes the access time and/or application program related information, and the application program related information at least includes name information and version information of the application program which is subjected to the morton.

In a possible implementation manner, the application related information further includes a user account number to which the stuck application is logged.

In one possible implementation, after the obtaining the morton information, the method further includes:

outputting the morton information to an Integrated Development Environment (IDE).

and reporting the jamming information to a jamming detection background corresponding to the application program which is subjected to jamming.

In a second aspect, there is provided an apparatus for detecting stuck, the apparatus comprising:

the recording module is used for recording the access moment when the main thread accesses the locked data container, wherein the data container is locked by the first sub-thread;

the recording module is further configured to record a lock releasing time when the first child thread releases the lock of the data container;

the determining module is used for determining the waiting time of the main thread through the first sub-thread based on the access time and the lock releasing time;

and the obtaining module is used for determining that the card pause exists and obtaining card pause information if the waiting time is greater than a card pause time threshold, wherein the card pause information comprises the call stack of the first sub-thread, the call stack of the main thread and the waiting time.

In a possible implementation manner, the obtaining module is configured to:

acquiring a call stack of the first sub-thread through the first sub-thread;

In a possible implementation manner, the obtaining module is configured to:

opening a second sub thread;

In a possible implementation manner, the morton information further includes the data container, and the obtaining module is further configured to:

In one possible implementation, the apparatus further includes an output module configured to:

and outputting the card pause information to the IDE.

In a possible implementation manner, the apparatus further includes a reporting module, configured to:

In a third aspect, a terminal is provided, which includes a processor and a memory, where the memory stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement the method for detecting katon according to the first aspect.

In a fourth aspect, a computer-readable storage medium is provided, in which at least one instruction is stored, the at least one instruction being loaded and executed by a processor to implement the method for detecting kation according to the first aspect.

The beneficial effects brought by the technical scheme provided by the embodiment of the application at least comprise:

the embodiment of the application provides a method for detecting stuck, which records the access time when a main thread accesses a locked data container. When the first child thread releases the data container, the lock release time is recorded. And determining the waiting time length through the first sub-thread according to the lock releasing time and the access time. And comparing the waiting time with a card pause time threshold value to determine whether the card pause exists. And when the existence of the stuck time is determined, the stuck information comprising the call stack of the main thread, the call stack of the first sub-thread and the waiting time is obtained. Therefore, the jam caused by locking of the main thread can be detected in time, and the jam information is acquired for being analyzed by developers, so that the jam problem can be solved in time.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

Fig. 1 is a flowchart of a method for detecting stuck in according to an embodiment of the present disclosure;

FIG. 2 is a schematic structural diagram of an apparatus for detecting stuck in a container according to an embodiment of the present disclosure;

fig. 3 is a schematic structural diagram of a terminal according to an embodiment of the present application;

FIG. 4 is a diagram illustrating a display of stuck information according to an embodiment of the present disclosure;

fig. 5 is a flowchart of detecting stuck in according to an embodiment of the present disclosure.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

The embodiment of the application provides a method for detecting stuck, which can be realized by a terminal. The terminal can be a mobile terminal such as a mobile phone, a tablet computer and a notebook computer, and can also be a fixed terminal such as a desktop computer.

The method for detecting the stuck state provided by the embodiment of the application can be used for detecting the stuck state of the application caused by locking on the terminal, and obtaining the stuck state information comprising the call stack of the first sub-thread, the call stack of the main thread and the waiting time in time when the stuck state is detected. Therefore, developers can analyze the cause of the blockage through the blockage information, so that the application program can be optimized in time, the probability of the blockage of the application program is reduced, and the user experience is improved. The method for detecting stuck in provided by the embodiment of the application can be applied to a Development Environment (that is, an application runs on a test terminal), and in this case, after the test terminal acquires stuck information, the stuck information can be output to an Integrated Development Environment (IDE), where the IDE is an application program for providing an application program Development Environment and generally includes tools such as a code editor, a compiler, a debugger, and a graphical user interface. The method for detecting the stuck state provided by the embodiment of the application can also be applied to an external network environment (namely, a user normally uses the application), and under the condition, after the terminal acquires the stuck information, the stuck information can be reported to a stuck detection background corresponding to an application program where the stuck occurs, so that developers can acquire the stuck information through a stuck detection platform.

In addition, the method for detecting katon provided by the embodiment of the present application may be applied to an ios (iphone operation system) system, and may also be applied to an android system or other systems, which is not limited in this application.

As shown in fig. 1, a process flow of the method for detecting katon provided by the embodiment of the present application may include the following steps:

in step 101, when the main thread accesses a locked data container, the access time is recorded.

Wherein the data container is locked by the first child thread.

In implementation, during the lifecycle of an application (or application program), multiple threads may be executing simultaneously. For the main thread, various data containers are accessed during execution of the main thread. If the data container accessed by the main thread is not locked, the main thread locks the data container and normally executes corresponding logic. If the main thread accesses the locked data container, the main thread needs to wait for the release of the lock of the data container before the main thread can normally execute the data container. During this waiting process, if the waiting time is too long, it may be perceived by the user that the application is stuck.

The method provided by the embodiment of the application can judge whether the jamming occurs or not through the waiting time of the main thread. Thus, to facilitate determining the latency of the main thread, when the main thread accesses a locked data container, the access time may be recorded. In one possible implementation, when recording the access time, it may be that the main thread records the access time. Thus, it is not necessary for the application to start a new child thread to record the access time, and performance loss can be reduced. In another possible implementation manner, a new child thread may also be started to record the access time, which is not limited in this application.

In step 102, when the first child thread releases the lock of the data container, the lock release time is recorded.

In implementation, after the first child thread locks the data container, the corresponding logic is executed normally. And releasing the lock of the data container after the first sub-thread finishes executing, and immediately acquiring the lock of the data container and executing by the main thread. As can be seen, the waiting time of the main thread is the time between the access time when the main thread accesses the data container and the lock releasing time when the first sub-thread releases the data container.

Therefore, to facilitate determining the wait duration of the main thread, the time of release of the lock for the data container may be recorded. In a possible implementation manner, when the lock release time is recorded, the lock release time can be recorded by the first sub-thread, so that the application does not need to open a new sub-thread to record the lock release time, and the performance loss can be reduced. In another possible implementation, a new child thread may also be opened to record the lock release time, and the child thread may be the same child thread as the child thread that records the access time.

In step 103, the wait duration of the main thread is determined by the first child thread based on the access time and the release lock time.

In an implementation, the wait duration of the main thread may be obtained by subtracting the access time from the lock release time. And then, judging whether the card pause exists according to the size of the waiting time length.

For example, the waiting time duration may be compared with a pause time duration threshold, and if the waiting time duration is greater than the pause time duration threshold, which indicates that the waiting time duration is too long, the user may feel that the application is stuck, and it is determined that the application is stuck, and in this case, the waiting time duration may be referred to as a pause time duration. And if the waiting time length is less than the pause time length threshold value, the waiting time length is short, and the user may not perceive the waiting time length, and the application is determined not to have pause. In addition, for the case that the waiting time length is equal to the card pause time length threshold, it may be considered that there is card pause, and it may also be considered that there is no card pause, which is not limited in this application.

It should be noted that the katton time long threshold may be set by a developer according to experience. For example, the stuck duration threshold may be set to 16 ms. In addition, different stuck time threshold values may be set for different classes of applications.

And if the existing first sub-thread determines whether the stuck state exists, the application does not need to start a new sub-thread, so that the performance loss of the application can be reduced. Of course, in another possible implementation manner, a new sub-thread may also be started to determine whether there is a stuck, and the new sub-thread may be the same sub-thread as the sub-thread recording the access time and the record lock release time.

In step 104, if the waiting duration is greater than the katon duration threshold, determining that there is katon, and acquiring katon information, wherein the katon information includes a call stack of the first sub-thread, a call stack of the main thread, and the waiting duration.

The call stack refers to record information of a certain thread execution method and logic, and the logic executed by the thread, a corresponding code and the like can be analyzed through the call stack of the certain thread. The call stack may also be referred to as a stack.

In addition, the morton information may also include data container information, access time and application related information. The application related information may include name information and version information of the application in which the stuck application occurs, and a user account number to which the stuck application is logged in.

In an implementation, after determining that there is stuck, stuck information may be obtained. The pause information comprises a call stack of the first sub-thread, a call stack of the main thread and waiting time.

The occurrence of a stuck in the main thread due to waiting for the lock of which data container and waiting for which sub-thread can be analyzed by the call stack of the main thread. And the logic of reading and writing the data container executed by the corresponding sub-thread during the locking period can be analyzed through the call stack of the first sub-thread. Therefore, a developer can determine the cause of the stuck according to the call stack of the main thread and the call stack of the first sub-thread and solve the stuck problem of the application.

It should be noted that at least two ways exist when the call stack of the first sub-thread and the call stack of the main thread are acquired, and the two ways are described below:

in one possible implementation, in order to reduce the performance loss of the application, the corresponding processing procedure of step 104 may be as follows, and the call stack of the first child thread is acquired by the first child thread. And returning to the main thread, and acquiring a call stack of the main thread through the main thread.

In implementation, the call stack of the first child thread may be retrieved immediately after the first child thread determines that there is a stuck. And after the acquisition is finished, the application returns to execute the main thread, and the main thread acquires the call stack of the main thread. The calling stack of the application is acquired through the existing first sub-thread and the main thread, and no extra performance loss exists in the application.

In another possible implementation manner, in order to obtain the call stack more accurately, the corresponding processing procedure in step 104 may be as follows, the second sub-thread is started, and the call stack of the first sub-thread and the call stack of the main thread are obtained through the second sub-thread.

In implementation, the call stack of the main thread and the call stack of the first sub-thread are obtained by starting the second sub-thread, so that the obtained call stacks are more accurate. The second child thread may be the child thread that records the access time, releases the lock time, and determines whether there is a stuck.

In addition, by including the stuck time length in the stuck information, the developer can clearly know the stuck time length of the main thread caused by locking, so that the developer can perform corresponding processing.

In a possible implementation manner, the morton information may further include data container information, and the corresponding processing procedure in step 104 may be as follows, and the data container information is determined based on the call stack of the first sub-thread and the call stack of the main thread.

The data container information comprises a data container identifier and logic information of a first sub-thread read-write data container.

In implementation, the identifier of the data container may be analyzed by the main thread call stack, and the logic information of the data container read and written by the first sub-thread may be analyzed by the first sub-thread call stack. By determining the data container information, the cause of the application jamming is clearer.

It should be noted that the morton information may not include data container information, but is obtained by a developer through analysis according to the call stack of the main thread and the call stack of the first sub-thread, and the application does not limit this.

In addition, after the mortgage information is acquired, the mortgage information needs to be sent to the developer, so that the developer can solve the mortgage problem according to the mortgage information.

In one possible implementation, in the testing phase, the application may run on the testing terminal, and then the terminal running the application may output the stuck information to the IDE.

In the IDE environment, the card pause information may further include access time and application program related information, where the application program related information at least includes name information and version information of the application program in which the card pause occurs. Optionally, the application related information may further include a user account into which the application that is stuck is logged. The access time may also be referred to as the time of occurrence of the stuck event, i.e. the time at which the stuck event starts to occur.

In another possible implementation manner, after the application program is online, if the user terminal obtains the stuck information, the user terminal may report the stuck information to a stuck detection background corresponding to the stuck application program, and the developer may obtain the stuck information through the stuck detection platform. This situation may also be referred to as an extranet environment.

In the external network environment, the stuck information may further include access time and application program related information, and the application program related information may include name information and version information of the application program that is stuck, and a user account number to which the application program that is stuck logs in. The access time may also be referred to as the time of occurrence of the stuck event.

In implementation, as shown in fig. 4, a schematic diagram of morton information reported to a morton detection platform according to an embodiment of the present application is provided. The morton information includes a main thread call stack, a first sub-thread call stack, a morton time and data container information, and in addition, also includes information such as a report date, a user account (i.e. a user account logged in by an application program which has been subjected to morton), and a version (which may include a name and a version number of the application program). In a possible implementation manner, the reporting date may be determined by the terminal according to the obtained access time, or the reporting date may also be determined by the morton detection background based on the access time in the received morton information. Illustratively, the access time is 1 minute 17.195820 seconds at 10 months, 21 days and 10 hours in 2019, and the reporting date can be 10 months, 21 days in 2019. In another possible implementation manner, the reporting date may also be determined by the morton detection background according to the receiving time of the morton information.

As shown in fig. 5, a flowchart of a method for detecting katon according to an embodiment of the present application is provided:

in step 501, in order to ensure the read-write security and consistency of the data container during the progress of the application, the first child thread locks the data container when reading and writing the data container.

In step 502, the main thread accesses the locked data container, and waits for the lock to be released and records the access time t 1.

In step 503, after the first child thread logic finishes executing, the lock is released, and the lock release time t2 is recorded, and the interval between t2 and t1 is determined.

In step 504, it is determined whether t2-t1 is greater than the katton time threshold (e.g., 16 ms).

In step 505, it is determined that katton occurred if it is greater than the katton time long threshold. And recording the call stack and the pause time of the first sub-thread through the first sub-thread, and then calling back to the main thread.

After returning the main thread, the call stack of the main thread is recorded in step 506.

In step 507, outputting the stuck information to the IDE in the development environment; reporting to the morton detection platform under the environment of the external network.

It should be noted that if t2-t1 is smaller than the katton time threshold, it is determined that there is no katton, and then the subsequent process of acquiring katton information is not performed.

By adopting the scheme, developers can find some main thread locking and blocking scenes in the development stage and analyze and optimize the main thread locking and blocking scenes. Meanwhile, in an external network environment, a main thread locking and blocking scene which is difficult to find at ordinary times can be captured and reported for analysis. The call stack of the first sub-thread is obtained through the first sub-thread, and the call stack of the main thread is obtained through the main thread. Through the scheme, the method and the device can help developers to locate the reason for the main thread plus locking and blocking, so that the probability of occurrence of application blocking is reduced, user experience is improved, and product public praise is improved.

Based on the same technical concept, an embodiment of the present application further provides a device for detecting stuck, which may be a terminal, as shown in fig. 2, and the device includes:

the recording module 201 is configured to record an access time when the main thread accesses a locked data container, where the data container is locked by a first sub-thread;

the recording module 201 is further configured to record a lock releasing time when the first child thread releases the lock of the data container;

the determining module 202 is configured to determine, by the first sub-thread, a waiting duration of the main thread based on the access time and the lock release time;

the obtaining module 203 is configured to determine that there is a stuck if the waiting duration is greater than the stuck duration threshold, and obtain stuck information, where the stuck information includes a call stack of the first sub-thread, a call stack of the main thread, and the waiting duration.

In a possible implementation manner, the obtaining module 203 is configured to:

acquiring a call stack of the first sub-thread through the first sub-thread;

In a possible implementation manner, the obtaining module 203 is configured to:

opening a second sub thread;

In a possible implementation manner, the morton information further includes a data container, and the obtaining module 203 is further configured to:

and determining data container information based on the call stack of the first sub-thread and the call stack of the main thread, wherein the data container information comprises the identification of the data container and the logic information of the data container read-written by the first sub-thread.

In a possible implementation manner, the morton information further includes access time and/or application program related information, and the application program related information at least includes name information and version information of the application program which is subjected to the morton.

In a possible implementation manner, the stuck information further includes a user account, and the user account is a user account logged in by the application program that has stuck.

the morton information is output to the integrated development environment IDE.

With regard to the apparatus in the above-described embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

It should be noted that: in the apparatus for detecting a stuck state provided in the above embodiment, only the division of the above functional modules is exemplified when detecting a stuck state, and in practical applications, the above function distribution may be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the above described functions. In addition, the apparatus for detecting stuck and the method embodiment for detecting stuck provided by the above embodiments belong to the same concept, and the specific implementation process thereof is detailed in the method embodiment and will not be described herein again.

Fig. 3 is a block diagram of a terminal according to an embodiment of the present disclosure. The terminal 300 may be a portable mobile terminal such as: smart phones, tablet computers. The terminal 300 may also be referred to by other names such as user equipment, portable terminal, etc.

Generally, the terminal 300 includes: a processor 301 and a memory 302.

The processor 301 may include one or more processing cores, such as a 4-core processor, an 8-core processor, and so on. The processor 301 may be implemented in at least one hardware form of a DSP (Digital Signal Processing), an FPGA (Field-Programmable Gate Array), and a PLA (Programmable Logic Array). The processor 301 may also include a main processor and a coprocessor, where the main processor is a processor for processing data in an awake state, and is also called a Central Processing Unit (CPU); a coprocessor is a low power processor for processing data in a standby state. In some embodiments, the processor 301 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the display screen. In some embodiments, the processor 301 may further include an AI (Artificial Intelligence) processor for processing computing operations related to machine learning.

Memory 302 may include one or more computer-readable storage media, which may be tangible and non-transitory. Memory 302 may also include high speed random access memory, as well as non-volatile memory, such as one or more magnetic disk storage devices, flash memory storage devices. In some embodiments, a non-transitory computer readable storage medium in memory 302 is used to store at least one instruction for execution by processor 301 to implement the method of detecting katton provided herein.

In some embodiments, the terminal 300 may further include: a peripheral interface 303 and at least one peripheral. Specifically, the peripheral device includes: at least one of radio frequency circuitry 304, display screen 305, camera assembly 306, audio circuitry 307, positioning assembly 308, and power supply 309.

The peripheral interface 303 may be used to connect at least one peripheral related to I/O (Input/Output) to the processor 301 and the memory 302. In some embodiments, processor 301, memory 302, and peripheral interface 303 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 301, the memory 302 and the peripheral interface 303 may be implemented on a separate chip or circuit board, which is not limited by the embodiment.

The Radio Frequency circuit 304 is used for receiving and transmitting RF (Radio Frequency) signals, also called electromagnetic signals. The radio frequency circuitry 304 communicates with communication networks and other communication devices via electromagnetic signals. The rf circuit 304 converts an electrical signal into an electromagnetic signal to transmit, or converts a received electromagnetic signal into an electrical signal. Optionally, the radio frequency circuit 304 comprises: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a subscriber identity module card, and so forth. The radio frequency circuitry 304 may communicate with other terminals via at least one wireless communication protocol. The wireless communication protocols include, but are not limited to: the world wide web, metropolitan area networks, intranets, generations of mobile communication networks (2G, 3G, 4G, and 5G), Wireless local area networks, and/or WiFi (Wireless Fidelity) networks. In some embodiments, the rf circuit 304 may further include NFC (Near Field Communication) related circuits, which are not limited in this application.

The display screen 305 is used to display a UI (User Interface). The UI may include graphics, text, icons, video, and any combination thereof. The display screen 305 also has the ability to capture touch signals on or over the surface of the display screen 305. The touch signal may be input to the processor 301 as a control signal for processing. The display screen 305 is used to provide virtual buttons and/or a virtual keyboard, also referred to as soft buttons and/or a soft keyboard. In some embodiments, the display 305 may be one, providing the front panel of the terminal 300; in other embodiments, the display screens 305 may be at least two, respectively disposed on different surfaces of the terminal 300 or in a folded design; in still other embodiments, the display 305 may be a flexible display disposed on a curved surface or on a folded surface of the terminal 300. Even further, the display screen 305 may be arranged in a non-rectangular irregular figure, i.e. a shaped screen. The Display screen 305 may be made of LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), and the like.

The camera assembly 306 is used to capture images or video. Optionally, camera assembly 306 includes a front camera and a rear camera. Generally, a front camera is used for realizing video call or self-shooting, and a rear camera is used for realizing shooting of pictures or videos. In some embodiments, the number of the rear cameras is at least two, and each of the rear cameras is any one of a main camera, a depth-of-field camera and a wide-angle camera, so that the main camera and the depth-of-field camera are fused to realize a background blurring function, and the main camera and the wide-angle camera are fused to realize a panoramic shooting function and a VR (Virtual Reality) shooting function. In some embodiments, camera assembly 306 may also include a flash. The flash lamp can be a monochrome temperature flash lamp or a bicolor temperature flash lamp. The double-color-temperature flash lamp is a combination of a warm-light flash lamp and a cold-light flash lamp, and can be used for light compensation at different color temperatures.

Audio circuit 307 is used to provide an audio interface between the user and terminal 300. Audio circuitry 307 may include a microphone and a speaker. The microphone is used for collecting sound waves of a user and the environment, converting the sound waves into electric signals, and inputting the electric signals to the processor 301 for processing or inputting the electric signals to the radio frequency circuit 304 to realize voice communication. The microphones may be provided in plural numbers, respectively, at different portions of the terminal 300 for the purpose of stereo sound collection or noise reduction. The microphone may also be an array microphone or an omni-directional pick-up microphone. The speaker is used to convert electrical signals from the processor 301 or the radio frequency circuitry 304 into sound waves. The loudspeaker can be a traditional film loudspeaker or a piezoelectric ceramic loudspeaker. When the speaker is a piezoelectric ceramic speaker, the speaker can be used for purposes such as converting an electric signal into a sound wave audible to a human being, or converting an electric signal into a sound wave inaudible to a human being to measure a distance. In some embodiments, audio circuitry 307 may also include a headphone jack.

The positioning component 308 is used to locate the current geographic location of the terminal 300 to implement navigation or LBS (location based Service). The positioning component 308 may be a positioning component based on the GPS (global positioning System) in the united states, the beidou System in china, or the galileo System in russia.

The power supply 309 is used to supply power to the various components in the terminal 300. The power source 309 may be alternating current, direct current, disposable batteries, or rechargeable batteries. When the power source 309 includes a rechargeable battery, the rechargeable battery may be a wired rechargeable battery or a wireless rechargeable battery. The wired rechargeable battery is a battery charged through a wired line, and the wireless rechargeable battery is a battery charged through a wireless coil. The rechargeable battery may also be used to support fast charge technology.

In some embodiments, the terminal 300 also includes one or more sensors 310. The one or more sensors 310 include, but are not limited to: acceleration sensor 311, gyro sensor 312, pressure sensor 313, fingerprint sensor 314, optical sensor 315, and proximity sensor 316.

The acceleration sensor 311 may detect the magnitude of acceleration in three coordinate axes of a coordinate system established with the terminal 300. For example, the acceleration sensor 311 may be used to detect components of the gravitational acceleration in three coordinate axes. The processor 301 may control the display screen 305 to display the user interface in a landscape view or a portrait view according to the gravitational acceleration signal collected by the acceleration sensor 311. The acceleration sensor 311 may also be used for acquisition of motion data of a game or a user.

The gyro sensor 312 may detect a body direction and a rotation angle of the terminal 300, and the gyro sensor 312 may cooperate with the acceleration sensor 311 to acquire a 3D motion of the user on the terminal 300. The processor 301 may implement the following functions according to the data collected by the gyro sensor 312: motion sensing (such as changing the UI according to a user's tilting operation), image stabilization at the time of photographing, game control, and inertial navigation.

The pressure sensor 313 may be disposed on a side bezel of the terminal 300 and/or on a lower layer of the display screen 305. When the pressure sensor 313 is disposed at the side frame of the terminal 300, a user's grip signal of the terminal 300 can be detected, and left-right hand recognition or shortcut operation can be performed according to the grip signal. When the pressure sensor 313 is disposed at the lower layer of the display screen 305, the operability control on the UI interface can be controlled according to the pressure operation of the user on the display screen 305. The operability control comprises at least one of a button control, a scroll bar control, an icon control and a menu control.

The fingerprint sensor 314 is used for collecting a fingerprint of a user to identify the identity of the user according to the collected fingerprint. Upon identifying that the user's identity is a trusted identity, processor 301 authorizes the user to perform relevant sensitive operations including unlocking the screen, viewing encrypted information, downloading software, paying, and changing settings, etc. The fingerprint sensor 314 may be disposed on the front, back, or side of the terminal 300. When a physical button or a vendor Logo is provided on the terminal 300, the fingerprint sensor 314 may be integrated with the physical button or the vendor Logo.

The optical sensor 315 is used to collect the ambient light intensity. In one embodiment, the processor 301 may control the display brightness of the display screen 305 based on the ambient light intensity collected by the optical sensor 315. Specifically, when the ambient light intensity is high, the display brightness of the display screen 305 is increased; when the ambient light intensity is low, the display brightness of the display screen 305 is reduced. In another embodiment, the processor 301 may also dynamically adjust the shooting parameters of the camera head assembly 306 according to the ambient light intensity collected by the optical sensor 315.

A proximity sensor 316, also known as a distance sensor, is typically provided on the front face of the terminal 300. The proximity sensor 316 is used to collect the distance between the user and the front surface of the terminal 300. In one embodiment, when the proximity sensor 316 detects that the distance between the user and the front surface of the terminal 300 gradually decreases, the processor 301 controls the display screen 305 to switch from the bright screen state to the dark screen state; when the proximity sensor 316 detects that the distance between the user and the front surface of the terminal 300 is gradually increased, the display screen 305 is controlled by the processor 301 to switch from the breath-screen state to the bright-screen state.

Those skilled in the art will appreciate that the configuration shown in fig. 3 is not intended to be limiting of terminal 300 and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components may be used.

In an exemplary embodiment, a computer-readable storage medium is further provided, in which at least one instruction is stored, and the at least one instruction is loaded and executed by a processor to implement the method for detecting katton in the above-described embodiments. 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.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, where the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The above description is only exemplary of the present application and should not be taken as limiting, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method of detecting stuck, the method comprising:

2. The method of claim 1, wherein the obtaining the katon information comprises:

acquiring a call stack of the first sub-thread through the first sub-thread;

3. The method of claim 1, wherein the obtaining the katon information comprises:

opening a second sub thread;

4. The method of claim 1, wherein the morton information further comprises data container information, and wherein the obtaining the morton information further comprises:

5. The method according to claim 4, wherein the katon information further comprises the access time and/or application related information, the application related information comprising at least name information and version information of an application that is subject to katon.

6. The method of claim 5, wherein the application-related information further comprises a user account to which the stuck application is logged.

7. The method of any of claims 1-6, wherein after the obtaining the katon information, the method further comprises:

and outputting the card pause information to the integrated development environment IDE.

8. The method of any of claims 1-6, wherein after the obtaining the katon information, the method further comprises:

9. An apparatus for detecting stuck, the apparatus comprising:

10. A terminal, characterized in that the terminal comprises a memory and a processor, the memory having stored therein at least one instruction, the at least one instruction being loaded and executed by the processor to implement the method of detecting stuck according to any one of claims 1-8.