Method and device for testing thread jamming, electronic device, and storage medium

Abstract

Embodiments of the present application disclose a method and apparatus for testing thread jamming, an electronic device, and a storage medium. The method includes: detecting, through a run loop mechanism, whether a thread is in a state indicating suspected jamming; if it is in a state indicating suspected jamming, sending a test task packet to the thread to instruct the thread to execute a test task; obtaining the processing duration of the thread for the test task; and determining whether the thread has jammed based on the relationship between the processing duration and a first preset duration. The technical solution of the embodiments of the present application can, on the basis of detection by the run loop mechanism, further obtain the processing duration through a test task packet, and further determine whether the thread has jammed, improving the accuracy of jamming detection.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and in particular, to a method and apparatus for testing thread jank, an electronic device, and a computer-readable storage medium. Background Art

[0002] Jank is a problem that seriously affects the user experience during the process of users using application programs. The analysis and governance of it have always been a long-discussed topic. Currently, in related technologies, most detections of jank are based on the run loop mechanism. However, when the run loop mechanism is idle, the corresponding program is in a dormant state, and threads such as threads and processes that do not have jank will be identified as being in a jank state, resulting in low accuracy and efficiency of jank detection. Summary of the Invention

[0003] To solve the above technical problems, embodiments of the present application provide a method and apparatus for testing thread jank, an electronic device, and a computer-readable storage medium, aiming to solve the technical problem of low accuracy of jank detection in related technologies and improve the accuracy of jank detection.

[0004] Other features and advantages of the present application will become apparent through the following detailed description, or will be partially learned through the practice of the present application.

[0005] According to one aspect of the embodiments of the present application, a method for testing thread jank is provided, including:

[0006] Detecting whether a thread is in a state representing suspected jank through a run loop mechanism;

[0007] If in a state representing suspected jank, sending a test task packet to the thread to instruct the thread to execute a test task;

[0008] Obtaining the processing duration of the thread for the test task;

[0009] Determining whether the thread has jank based on the relationship between the processing duration and a first preset duration.

[0010] According to one aspect of the embodiments of the present application, an apparatus for testing thread jank is provided, including:

[0011] A detection module configured to detect whether a thread is in a state representing suspected jank through a run loop mechanism;

[0012] A sending module configured to, if in a state representing suspected jank, send a test task packet to the thread to instruct the thread to execute a test task;

[0013] An obtaining module configured to obtain the processing duration of the thread for the test task;

[0014] A determination module configured to determine whether a thread is stuck based on the relationship between the processing duration and a first preset duration.

[0015] According to one aspect of the embodiments of the present application, there is provided an electronic device, including: one or more processors; a storage device for storing one or more programs, and when the one or more programs are executed by the one or more processors, the electronic device implements the method for testing thread stuck as described above.

[0016] According to one aspect of the embodiments of the present application, there is provided a computer-readable storage medium, on which computer-readable instructions are stored, and when the computer-readable instructions are executed by a processor of a computer, the computer is caused to execute the method for testing thread stuck as described above.

[0017] According to one aspect of the embodiments of the present application, there is provided a computer program product or a computer program, the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method for testing thread stuck provided in the above various alternative embodiments.

[0018] In the technical solution provided by the embodiments of the present application, by using a run loop mechanism to determine whether a thread is in a state representing suspected stuck, it is possible to simply obtain whether the thread is stuck. However, there is a situation where a thread in a sleep state may also be recognized as stuck through the run loop mechanism. Therefore, after determining that the thread is in a state of suspected stuck, a test task packet is sent to the thread, and based on the processing duration of the test task packet, it is further determined whether the thread is stuck. In this way, by combining the run loop mechanism and the test task packet, it is possible to more accurately determine whether the thread is stuck, avoid the situation where a thread in a dormant state is also recognized as stuck, and accurately locate the thread where the stuck occurs, improving the accuracy of stuck monitoring.

[0019] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings herein are incorporated into the specification and form a part of the specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application. Obviously, the accompanying drawings in the following description are only some embodiments of the present application, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts. In the drawings:

[0021] Figure 1It is a use case diagram of a method for testing thread jank involved in this application;

[0022] Figure 2 It is a flowchart of a method for testing thread jank in an embodiment involved in this application;

[0023] Figure 3 It is a flowchart of step S210 in an embodiment involved in this application;

[0024] Figure 4 It is a flowchart of step S210 in an embodiment involved in this application;

[0025] Figure 5 It is a flowchart of step S220 in an embodiment involved in this application;

[0026] Figure 6 It is a flowchart of step S230 in an embodiment involved in this application;

[0027] Figure 7 It is a flowchart of a method for testing thread jank in an embodiment involved in this application;

[0028] Figure 8 It is a flowchart of step S730 in an embodiment involved in this application;

[0029] Figure 9 It is a flowchart of a method for testing thread jank in an embodiment involved in this application;

[0030] Figure 10 It is a flowchart of a method for testing thread jank in an embodiment involved in this application;

[0031] Figure 11 It is a block diagram of a device for testing thread jank in an embodiment involved in this application;

[0032] Figure 12 It is a schematic structural diagram of a computer system of an electronic device suitable for implementing the embodiments of this application. Detailed implementation manners

[0033] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with this application. On the contrary, they are merely examples of devices and methods consistent with some aspects of this application as detailed in the appended claims.

[0034] The block diagrams shown in the drawings are only functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software form, or implemented in one or more hardware modules or integrated circuits, or implemented in different networks and / or processor devices and / or microcontroller devices.

[0035] The flowcharts shown in the drawings are only illustrative and do not have to include all the content and operations / steps, nor do they have to be executed in the described order. For example, some operations / steps can be decomposed, while some operations / steps can be combined or partially combined, so the actual execution order may change according to the actual situation.

[0036] It should also be noted that: "a plurality of" mentioned in this application means two or more. "And / or" describes the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects before and after.

[0037] Please refer to Figure 1 , the method for testing thread jank involved in this application can be applied in an application program. Figure 1 FIG. is a use case diagram of the method for testing thread jank applied in an application program. The use case diagram of this application program includes a login class 110, a general configuration module class 120, a jank detection service helper class 130, a jank detection service class 140, a parsing and processing class 150, a jank management class 160, and a jank data storage class 170. The detailed introduction of each class is as follows:

[0038] After the application program starts, the user will log in. The login class 110 pulls the configuration file after the user logs in successfully.

[0039] The general configuration module class 120 parses the pulled configuration file to obtain an array of UIDs (User Identification), and the general configuration module class 120 throws a notification to all listeners after the parsing is completed.

[0040] The lag detection service helper class 130, as one of the listeners, will perform gray user judgment based on the parsed UID array and the account information entered by the user during login, that is, determine whether the account information entered by the user exists in the UID array. Secondly, if the lag detection service helper class 130 detects that the application is restarted, it will obtain the last startup time of the lag detection service, and detect whether the interval between the startup time and the current time is the second preset duration. If the interval is the second preset duration, it will restart the lag detection service to implement the anti-continuous crash policy solution to ensure that continuous program crashes will not be caused by opening the lag detection service;

[0041] The lag detection service class 140 provides the opening and closing of the lag detection service for external calls, and transmits the associated data of the lag to the parsing and processing class 150 when a lag is detected;

[0042] After receiving the associated data, the parsing and processing class 150 parses and processes the associated data to obtain lag data, and then gives the obtained lag data to the lag management class 160;

[0043] After receiving the lag data, the lag management class 160 first performs a hash operation on the lag data to obtain the corresponding hash data, matches the obtained hash data with the stored hash data, determines that the obtained hash data does not exist in the stored hash data, and when it is determined that the obtained hash data does not exist in the stored hash data, calls the lag data storage class 170 to perform data local storage, and uploads the obtained lag data to the specified management device.

[0044] Through the solution provided by this application, it is possible to monitor the lag problems generated during the user's use of the application, and perform associated data parsing and reporting work to help developers locate the problem code where the lag occurs. The lag detection service class 140, the parsing and processing class 150, the lag management class 160, the lag data storage class 170, etc. are connected to the application in the form of a private library. By using the run loop mechanism to determine whether the thread is in a state representing suspected lag, it is possible to simply obtain whether the thread is lagging. However, there will be a situation where the thread is also considered lagging when it is in the sleep state through the run loop mechanism. Therefore, after determining that the thread is in a suspected lag state, a test task packet is sent to the thread, and through the processing duration of the test task packet, it is further determined whether the thread is lagging, which can more accurately determine whether the thread is lagging, exclude the situation where the thread is considered lagging when it is in the sleep state, and can effectively monitor the lag situation during the use of the application.

[0045] Figure 2 It is a flowchart of a method for testing thread lag shown according to an exemplary embodiment. This method can be applied to Figure 1 the application shown, such as Figure 2As shown, in an exemplary embodiment, the method for testing thread lag may include steps S210 to S240, which are introduced in detail as follows:

[0046] Step S210, detecting whether the thread is in a state indicating suspected lag through a run loop mechanism.

[0047] In the embodiment of the present application, the run loop mechanism is an event listening loop for managing events / messages, allowing the thread to sleep when there is no message to be processed to avoid resource occupation and being immediately awakened when a message arrives. The above threads include each thread in an application in the iOS system. When the program is started, a process is created by the operating system, and at the same time, the main thread also starts running immediately. Therefore, detecting whether the thread is in a state indicating suspected lag can detect whether the main thread is in a state indicating suspected lag.

[0048] The states of the run loop mechanism when processing events or messages include but are not limited to kCFRunLoopEntry (about to enter the loop), kCFRunLoopBeforeTimers (about to process Timers), kCFRunLoopBeforeSources (about to process Sources), kCFRunLoopBeforeWaiting (about to enter the sleep state), kCFRunLoopAfterWaiting (just awakened from the sleep state), kCFRunLoopExit (about to exit the loop), kCFRunLoopAllActivit (all state changes). The run loop mechanism mainly processes events between kCFRunLoopBeforeSources and kCFRunLoopAfterWaiting. Therefore, when it is detected that the thread is in a state indicating suspected lag, that is, when the thread is in any one of the states of kCFRunLoopBeforeSources or kCFRunLoopAfterWaiting, the thread may be in a lag situation.

[0049] In an embodiment of the present application, please refer to Figure 3 , in step S210, detecting whether the thread is in a state indicating suspected lag through a run loop mechanism includes steps S310 to S330, which are introduced in detail as follows:

[0050] Step S310, periodically detecting whether the thread is in a specified state through a run loop mechanism.

[0051] In the embodiments of the present application, by running a loop mechanism, it is periodically detected whether a thread is in a specified state, and the above-mentioned specified state can be any one of kCFRunLoopBeforeSources or kCFRunLoopAfterWaiting. The above-mentioned periodic detection can be continuous detection, that is, after one detection is completed, the detection is immediately carried out again. It can also be that after one detection is completed, after a certain time interval, another detection is carried out, and the time interval can be custom-set according to the situation.

[0052] Step S320, if the number of times the thread is detected to be in the specified state reaches a preset number threshold, it is determined that the thread is in a state indicating suspected freeze.

[0053] In the embodiments of the present application, when periodically detecting whether a thread is in a specified state, if the thread is in the specified state for a continuous preset number threshold, it can be determined that the thread is in a state indicating suspected freeze. For example, when the thread is in any one of kCFRunLoopBeforeSources or kCFRunLoopAfterWaiting for 3 consecutive times, it is determined that the thread is in a state indicating suspected freeze. The above-mentioned preset number threshold can be custom-set according to the situation of the thread in actual application.

[0054] Step S330, if the number of times the thread is detected to be in the specified state does not reach the preset number threshold, it is determined that the thread is not in a state indicating suspected freeze.

[0055] In the embodiments of the present application, when periodically detecting whether a thread is in a specified state, if the thread is not in the specified state for a continuous preset number threshold, it can be determined that the thread is not in a state indicating suspected freeze.

[0056] In the embodiments of the present application, by periodically detecting whether a thread is in a specified state and determining whether the thread is in the specified state according to whether the number of times in the specified state reaches the preset number threshold, the accuracy of detecting whether the thread is in a state indicating suspected freeze is improved.

[0057] In an embodiment of the present application, please refer to Figure 4 , the thread includes the main thread. In step S210, when detecting whether the thread is in a state indicating suspected freeze through the run loop mechanism, the thread includes:

[0058] Step S410, create an observer and a first semaphore, add the observer to the main thread, and use the observer to monitor the run loop state of the main thread so that when the observer monitors that the run loop state of the main thread is in a preset state, the first semaphore is issued.

[0059] In the embodiment of the present application, when detecting whether a thread is in a state indicating suspected lag, first create an observer runLoopObserver, and add the created observer to the common mode of the main thread's run loop to observe the state of the main thread's run loop. At the same time, create a first semaphore dispatchSemaphore to ensure synchronous operations. Consume the first semaphore regularly when detecting the run loop state. When it is detected that the state of the main thread's run loop is in a preset state, trigger a callback, and send the first semaphore in the callback to change the value of the first semaphore.

[0060] Step S420: Create a monitoring child thread to receive the first semaphore through the monitoring child thread, and determine whether the main thread is in a state indicating suspected lag according to the time when the monitoring child thread receives the first semaphore and the current run loop state of the main thread.

[0061] In the embodiment of the present application, create a monitoring child thread, and start a continuous loop in the monitoring child thread to receive the first semaphore, and determine whether the thread is in a state indicating suspected lag according to the time when the first semaphore is received and the current run loop state, that is, when the time interval for receiving the first semaphore is greater than the receiving time threshold, and at the same time the current run loop state of the main thread is in any one of kCFRunLoopBeforeSources or kCFRunLoopAfterWaiting, the main thread is in a state indicating suspected lag.

[0062] Step S220: If in a state indicating suspected lag, send a test task package to the thread to instruct the thread to execute the test task.

[0063] In the embodiment of the present application, the run loop mechanism is used to detect whether a thread is in a state indicating suspected lag. When the thread is in a state indicating suspected lag, a test task package can be sent to the thread. After receiving the test task package, the thread will execute the corresponding test task for the test task package. When the thread is in a sleep state, it will not execute the test task. Therefore, through the test task package, it can be detected whether the thread is in a sleep state when it is in a state indicating suspected lag.

[0064] In an embodiment of the present application, please refer to Figure 5 , the thread includes the main thread. Sending a test task package to the thread in step S220 to instruct the thread to execute the test task includes step S510 and step S520, which are introduced in detail as follows:

[0065] Step S510: Create a test child thread and a second semaphore.

[0066] In the embodiment of the present application, a test sub-thread and a second semaphore are created. When the thread finishes executing the test task, the second semaphore is released.

[0067] Step S520: Send the tested task package to the main thread through the test sub-thread, so that when the receiving flag bit of the main thread is modified from the first value to the second value according to the test task package, the second semaphore is issued.

[0068] In the embodiment of the present application, the test task package is sent to the main thread by the detection sub-thread. The receiving flag bit in the main thread is the first value, and the first value can be Yes or No. When the main thread is not in a sleep or stuck state, after receiving the test task package, the main thread executes the test task according to the test task package and modifies the receiving flag bit from the first value to the second value. The second value is a variable different from the first value. For example, when the first value is Yes, the second value is No, or when the first value is No, the second value is Yes.

[0069] In the embodiment of the present application, by modifying the receiving flag bit of the main thread, the processing duration of the main thread for the test task package is obtained. Since the main thread will not modify the receiving flag bit when it is in a sleep or stuck state, it can be determined whether the main thread is in a sleep or stuck state according to the modification of the receiving flag bit of the main thread.

[0070] Step S230: Obtain the processing duration of the thread for the test task.

[0071] In the embodiment of the present application, after sending the test task package to the thread, the thread will execute the corresponding test task according to the test task package. When executing the test task, a corresponding processing duration is generated. Obtaining the processing duration of the thread for the test task is the time interval between the moment of sending the test task package and the moment of receiving the response to the test task.

[0072] In an embodiment of the present application, please refer to Figure 6 , obtaining the processing duration of the thread for the test task in step S230 includes step S610 and step S620, which are introduced in detail as follows:

[0073] Step S610: Receive the second semaphore and record the reception time of the second semaphore.

[0074] In the embodiment of the present application, after the main thread finishes executing the test task, the second semaphore is released. According to the second semaphore, it can be accurately known whether the main thread has completed the test task.

[0075] Step S620: Obtain the creation time of the second semaphore, and calculate the processing duration of the main thread for the test task according to the creation time and the reception time of the second semaphore.

[0076] In an embodiment of the present application, when creating a second semaphore, record the corresponding creation time, calculate the time interval between the creation time and the reception time, and use this time interval as the processing duration of the main thread for the test task.

[0077] Step S240, based on the relationship between the processing duration and the first preset duration, determine whether the thread is stuck.

[0078] In an embodiment of the present application, when the thread is not in a sleep or stuck state, the thread can quickly respond to the test task package, and thus the obtained processing duration is relatively short. Therefore, according to the relationship between the processing duration and the first preset duration, it can be determined whether the thread is stuck. The relationship between the processing duration and the first preset duration includes that the processing duration is less than the first preset duration and the processing duration is greater than or equal to the first preset duration.

[0079] In an embodiment of the present application, by running a loop mechanism to determine whether the thread is in a state representing suspected stuck, it can be simply obtained whether the thread is stuck. However, there will be a situation where the thread is also considered stuck in the sleep state through the running loop mechanism. Therefore, after determining that the thread is in a suspected stuck state, send a test task package to the thread, and further determine whether the thread is stuck through the processing duration of the test task package, which can more accurately determine whether the thread is stuck and exclude the situation where the thread is considered stuck in the sleep state.

[0080] In another embodiment, after sending the test task package to the thread, after an interval of the first preset duration, detect whether a response from the thread to the test task package is received. When a response from the thread to the test task package is received, it can be determined that the thread has not become stuck. When no response from the thread to the test task package is received after an interval of the first preset time, it can be determined that the thread has become stuck.

[0081] In an embodiment of the present application, the detailed description of determining whether the thread is stuck based on the relationship between the processing duration and the first preset duration in step S240 is as follows:

[0082] If the processing duration is less than the first preset duration, it is determined that the thread has not become stuck;

[0083] If the processing duration is greater than or equal to the first preset duration, it is determined that the thread has become stuck.

[0084] In an embodiment of the present application, when the processing duration is less than the first preset duration, it indicates that the thread quickly responds to the test task package, and the thread is not in a sleep state or a stuck state. Further, after determining that the thread is not in a sleep or stuck state, the number of times of uploading stuck data recorded before the current moment can be cleared.

[0085] In the embodiments of the present application, when the processing duration is greater than or equal to the first preset duration, it indicates that the thread does not respond to the test data within the first preset duration, and thus it can be determined that the thread is currently stuck.

[0086] Further, in this embodiment, before determining whether the thread is stuck based on the relationship between the processing duration and the first preset duration in step S240, the following process may further be included:

[0087] Generate the corresponding relationship between the difficulty parameter of the task and the first preset duration based on the historical operation data;

[0088] Calculate the difficulty parameter corresponding to the test task based on the data volume, the number of data interfaces, and the task type;

[0089] Determine the first preset duration corresponding to the difficulty parameter based on the difficulty parameter and the corresponding relationship.

[0090] Specifically, considering that the difficulties of various tasks are different, the data volumes to be processed and the numbers of involved data interfaces are also different, so the processing times corresponding to different tasks may vary, and it is difficult to determine whether there is a stuck by a fixed duration. Therefore, in this embodiment, the difficulty parameters of these tasks are determined through the historical operation data of some tasks, and the first preset duration is determined based on their running times, which is used to measure the length of the running time of a task. Then, based on the data volume Tas_dta, the number of data interfaces Tas_ine, and the task type Tas_nae, the difficulty parameter Tas_dic of the test task is determined as:

[0091] Tas_dic = α·Tas_nae·log(Tas_dta + Tas_ine)

[0092] Where α represents the task factor. Then, the first preset duration corresponding to each test task is determined based on the difficulty parameter and the corresponding relationship to improve the comprehensiveness and objectivity of the stuck evaluation.

[0093] In an embodiment of the present application, please refer to Figure 7 , if it is determined that the thread is stuck, the method for testing the thread stuck further includes steps S710 to S730, which are introduced in detail as follows:

[0094] Step S710, obtain the associated data corresponding to the thread stuck.

[0095] In the embodiments of the present application, the above-mentioned associated data includes the thread stack information, such as the address array at the time of getting stuck, the function call address and other information.

[0096] Step S720: Parse and process the associated data, and determine the lag data from the associated data based on the parsing and processing.

[0097] In the embodiment of the present application, when parsing and processing the associated data, specifically, symbol parsing can be performed on the function call addresses in the associated data to obtain information such as the function names and the classes to which they belong implemented by the code, and then the lag data can be obtained.

[0098] Step S730: Send the lag data to a specified management device so that the specified management device can optimize the thread based on the lag data.

[0099] In the embodiment of the present application, the lag data is uploaded to a specified management device. The specified management device may include the background of the application or a device specified by the developer. The lag data includes information such as the parsed function names and the classes to which they belong. Subsequently, the developer can view the corresponding lag information in the specified management device, and then locate the specific problem code that causes the lag according to the lag information. By using the method provided in the embodiment of the present application to upload the lag data to the specified management device, it is beneficial for the developer to locate and correct the problem code that causes the lag.

[0100] In an embodiment of the present application, please refer to Figure 8 , in step S730, sending the lag data to the specified management device includes steps S810 to S830:

[0101] Step S810: Perform a hash operation on the lag data to obtain the hash data corresponding to the lag data.

[0102] In the embodiment of the present application, when performing a hash operation on the lag data, specifically, a hash operation can be performed on the function call addresses in the lag data. After the lag data undergoes the hash operation, it becomes a hash data with a fixed length, and this hash data is unique.

[0103] Step S820: Match the hash data corresponding to the lag data with the stored hash data; where the stored hash data is obtained by performing a hash operation on historical lag data.

[0104] In the embodiments of the present application, stutter detection is a long-term process. Each time stutter data is detected, hash operation is performed on the stutter data to obtain corresponding hash data. When calculating the hash data, if hash operation is only performed on a certain item of data in the stutter data, then when subsequent stutter data is obtained, hash operation is also only performed on this item of data, and the obtained hash data is stored. The stored hash data is obtained within the startup cycle of the current stutter detection service. After the next startup cycle of the stutter detection service arrives, the hash data in the previous startup cycle of the stutter detection service can be deleted. After obtaining the hash data corresponding to the latest stutter data, it is matched with the stored hash data.

[0105] Step S830, if the hash data corresponding to the stutter data does not match the stored hash data, then send the stutter data to the specified management device.

[0106] In the embodiments of the present application, when the hash data does not match the stored hash data, it is uploaded to the specified management device. When the hash data matches the stored hash data, it indicates that the stutter data is the same as a certain stutter data that has been uploaded to the specified management device. To avoid developers repeatedly processing the code that causes the same stutter problem, the stutter data corresponding to the hash data that matches the stored hash data is not uploaded to the specified management device.

[0107] In the embodiments of the present application, when reporting stutter data, duplicate transaction processing is performed on the stutter data based on hash operation. That is, if the hash data of the stutter data matches the stored hash data, it means that the same stutter has been detected and the corresponding stutter data has been uploaded to the specified management device. At this time, there is no need to upload again, avoiding developers repeatedly performing corresponding processing on the stutter data.

[0108] In an embodiment of the present application, please refer to Figure 9 , start the stutter detection service to detect whether the thread is in a state representing suspected stutter through a run loop mechanism; the method for testing thread stutter further includes steps S910 to S950, which are introduced in detail as follows:

[0109] Step S910, within the startup cycle of the stutter detection service, send the stutter data corresponding to the stuttering thread to the specified management device respectively, and record the number of times of sending.

[0110] In the embodiments of the present application, within the startup cycle of the stutter detection service, that is, from the start to the end of the stutter detection service, during this process, at least one stutter detection will be performed. Each time stutter data is detected, the stutter data is sent to the specified management device, and each time it is sent, it is recorded once.

[0111] Step S920, if the number of times is greater than the preset number threshold, stop sending the lag data corresponding to the lagging thread to the specified management device.

[0112] In the embodiment of the present application, the number of times of the recorded uploaded lag data is compared with the preset number threshold. If the number of times of the recorded lag data is greater than the preset number threshold, the lag data will no longer be sent to the specified management device.

[0113] In the embodiment of the present application, the interface for sending lag data to the specified management device consumes a lot of resources. In order to avoid continuously sending lag data to the specified management device and considering the data pressure of the specified management device, within the startup cycle of a lag detection service, at most the lag data is sent the number of times of the preset number threshold. The preset number threshold can be set to 10 times. In other embodiments, the preset number threshold can be adjusted according to actual needs.

[0114] In another embodiment, the lag data sent to the specified management device can be processed by removing duplicate transactions as described above, and then the lag data can be allowed to be uploaded to the specified management device the number of times of the preset number threshold. When uploading lag data to the specified management device, a certain amount of resources are required. Lag detection is a continuous process. The same lag problem may be detected multiple times, and then the lag data is repeatedly uploaded to the specified management device, wasting a certain amount of resources. Therefore, in the optional embodiment, after the lag data is processed for duplicate transaction removal, the number of times of uploading the lag data to the specified management device is controlled to avoid the impact of uploading lag data on the performance of the application program and improve the user experience. Further, after receiving the lag data of the preset number threshold, the specified management device can remind the developer through a preset prompt message, so that the developer can know that there are many lags in the application program. At the same time, the lag detection service is closed to save resources for the operation of the application program.

[0115] Step S930, within the startup cycle of the lag detection service, obtain the number of lagging threads among the multiple threads included in the application program.

[0116] In the embodiment of the present application, an application program includes multiple threads. Each thread is detected to determine whether it lags, and the number of lagging threads is determined.

[0117] Step S940, if the number is greater than the preset quantity threshold, determine the application program as the first type.

[0118] In the embodiment of the present application, when it is determined that the number of lagging threads is greater than the preset quantity threshold, it indicates that there are many threads in the application program that lag. The application program is determined as the first type, and the first type can represent poor performance.

[0119] Step S950: If the quantity is less than or equal to a preset quantity threshold, then determine the application as the second type; wherein, the application performance of the second type is higher than that of the first type.

[0120] In the embodiment of the present application, when it is determined that the number of threads with lags is less than or equal to the preset quantity threshold, it indicates that there are fewer threads with lags in the application, and the application is determined as the second type, and the second type can represent better performance.

[0121] In this way, by implementing the optional embodiment, according to the number of threads with lags among the multiple threads included in the application obtained during the startup cycle of the lag detection service, the type data of the application regarding performance can be determined, thereby facilitating the subsequent update, management, etc. of the application and improving the user experience.

[0122] In an embodiment of the present application, the method for testing thread lags further includes the following steps, which are introduced in detail as follows:

[0123] If it is detected that the application is restarted, then obtain the most recent startup time of the lag detection service.

[0124] In the embodiment of the present application, during the use of the application, there will be a situation where the program crashes, which generally causes the application to close automatically. At this time, the user generally restarts the application. When it is detected that the application is restarted, obtain the most recent startup time of the lag detection service.

[0125] Detect whether the time interval between the startup time and the current time is a second preset duration.

[0126] In the embodiment of the present application, detect whether the time interval between the most recent startup time and the current time reaches the second preset duration. The second preset duration can be set to 1 hour. In other embodiments, the second preset duration can be set according to actual needs.

[0127] If the interval is the second preset duration, then restart the lag detection service.

[0128] In the embodiment of the present application, when the time interval between the most recent startup time and the current time reaches the second preset duration, then start the lag detection service. If the time interval between the most recent startup time and the current time does not reach the second preset duration, then do not start the lag detection service.

[0129] In an embodiment of the present application, when the application exits, the lag detection service will also be closed accordingly. After restarting, when the lag detection service is running, it will consume certain resources. To avoid the situation where the application crashes continuously after restarting the application, the application does not immediately start the lag detection service after each restart. Instead, it first detects whether the time interval between the most recent startup time and the current time reaches a second preset duration. When it reaches, the lag detection service is then started.

[0130] In an embodiment of the present application, after the user starts the application, the user will log in. When logging in, the configuration file of the application is pulled and parsed to obtain a UID array, which includes a complete_uid array and a uid_suffix array. The user inputs their account information. The account information input by the user is matched with the parsed UID array. When the two match successfully, it means that the account input by the user is in the whitelist, and the lag detection service can be started; when the two do not match, the lag detection service is not started. In this embodiment, it is necessary to authenticate the user who logs in to the application, and start the lag detection service for the account that passes the authentication. In this embodiment, by only starting the lag detection service for the account that passes the authentication, and the number of accounts in the UID array can be configured online, it is avoided to overwrite all when there is a problem.

[0131] Among them, the running code for determining whether the account input by the user exists in the whitelist is as follows:

[0132] "caton_monitor_config":{

[0133] "complete_uid":["101132133"],

[0134] "uid_suffix":["01","03"]

[0135] In the above code, the complete_uid array contains the whitelist user accounts that need to turn on the lag detection service, and the uid_suffix array contains the trailing accounts of the users that need to be in the gray scale. The complete_uid array is matched according to the account information logged in by the user. When the match is successful, it means that the user is in the whitelist and the lag detection service is started; when the match is unsuccessful, the uid_suffix array is then matched according to the account information logged in by the user. If the match is successful, it means that the user is in the whitelist and the lag detection service is started; when the account information logged in by the user is not matched in both arrays, the lag detection service is not started.

[0136] In an embodiment of the present application, please refer to Figure 10 , Figure 10It is a flowchart of a method for testing thread jank according to an exemplary embodiment, including steps S1001 to S1008, which are introduced in detail as follows:

[0137] Step S1001, start monitoring the running loop state of the main thread.

[0138] In the embodiment of the present application, the run loop can manage threads. After the run loop of a thread is started, the thread will be in a dormant state after completing a task, waiting to receive new tasks at any time instead of exiting. The run loop of the main thread is enabled by default, so after the application is started, the run loop of the main thread is enabled.

[0139] Step S1002, use a monitoring sub-thread to loop-detect whether the running loop state of the main thread is in the kCFRunLoopBeforeSources state.

[0140] In the embodiment of the present application, after starting the monitoring of the main thread run loop, a monitoring sub-thread is created, and the monitoring sub-thread is used to loop-detect whether the running loop state of the main thread is in the kCFRunLoopBeforeSources state. If the running loop state of the main thread is not in the kCFRunLoopBeforeSources state, go to step S1006, that is, detect whether the running loop state of the main thread is in any one of the kCFRunLoopBeforeSources or kCFRunLoopAfterWaiting states three times.

[0141] Step S1003, if the running loop state of the main thread is in the kCFRunLoopBeforeSources state, create a test sub-thread, and send a test task packet to the main thread through the test sub-thread, so that the main thread modifies the received flag bit from the first value to the second value according to the test task packet.

[0142] In the embodiment of the present application, when the running loop state of the main thread is in the kCFRunLoopBeforeSources state, a test sub-thread is created, and the test task packet is sent to the main thread through the test sub-thread. After the main thread receives the test task packet, if the main thread is not in the dormant state, it will immediately execute the test task and modify the received flag bit from the first value to the second value, such as modifying Yes to No.

[0143] Step S1004, after the test sub-thread sleeps for a certain period of time, detect whether the main thread has janked.

[0144] In the embodiment of the present application, after the sleep processing duration of the test sub-thread is measured, it is detected whether the main thread is stuck, that is, after the sleep processing duration, it is detected whether a semaphore indicating that the main thread has completed the test task is received. When the semaphore is received, it indicates that the main thread is not stuck. When the semaphore is not received, it indicates that the main thread is stuck.

[0145] Step S1005, if it is detected that the main thread is not stuck, reset to before the stuck detection, and enter step S1002.

[0146] In the embodiment of the present application, when it is detected that the main thread is not stuck, it is necessary to reset to before the stuck state and enter step S1002 to re-execute the corresponding steps.

[0147] Step S1006, if it is detected that the main thread is stuck, detect whether the run loop state of the main thread is in any one of the states of kCFRunLoopBeforeSources or kCFRunLoopAfterWaiting for more than 3 times.

[0148] In the embodiment of the present application, after it is detected that the main thread is stuck, it is repeatedly detected whether the run loop state of the main thread is in any one of the states of kCFRunLoopBeforeSources or kCFRunLoopAfterWaiting, and the number of times exceeds 3 times. By repeatedly detecting the run loop state, the detection accuracy is improved.

[0149] Step S1007, if it exceeds 3 times, collect the thread stack information.

[0150] In the embodiment of the present application, when it is detected that the number of times exceeds 3 times, collect the thread stack information and send the collected thread stack information to a specified management device for storage.

[0151] Step S1008, after collecting the thread stack information, reset to before the stuck monitoring.

[0152] In the embodiment of the present application, after the thread stack information is collected, it will be transmitted to a specified management device accordingly. After transmission, a stuck count will be generated accordingly, and the stuck count will be cleared to 0 before resetting to before the stuck state for continuous monitoring.

[0153] In the embodiments of the present application, by monitoring to determine whether the main thread is in a state indicating suspected stuttering, it is possible to simply obtain whether the main thread is stuttering. However, with the run loop mechanism, there may be a situation where a thread is also considered stuttering when it is in the sleep state. Therefore, after determining that the main thread is in a state of suspected stuttering, a test task packet is sent to the main thread, and based on the processing duration of the test task packet, it is further determined whether the main thread is stuttering. In this way, by combining the run loop mechanism and the test task packet, it is possible to more accurately determine whether a thread is stuttering, avoiding the situation where a thread is also considered stuttering when it is in the sleep state. At the same time, after determining that the main thread is stuttering, the run loop state of the main thread is detected multiple times to see if it is in any one of the kCFRunLoopBeforeSources or kCFRunLoopAfterWaiting states. If so, the thread stack information is collected, further avoiding inaccurate collection of thread stack information.

[0154] In an exemplary embodiment of the present application, please refer to Figure 11 , Figure 11 which is a block diagram of a device for testing thread stuttering shown according to an exemplary embodiment, including:

[0155] A detection module 1110, configured to detect whether a thread is in a state indicating suspected stuttering through a run loop mechanism;

[0156] A sending module 1120, configured to send a test task packet to the thread to instruct the thread to execute a test task if it is in a state indicating suspected stuttering;

[0157] An acquisition module 1130, configured to acquire the processing duration of the thread for the test task;

[0158] A determination module 1140, configured to determine whether the thread is stuttering based on the relationship between the processing duration and a first preset duration.

[0159] In an exemplary embodiment, the detection module 1110 includes:

[0160] A detection sub-module, configured to periodically detect whether a thread is in a specified state through a run loop mechanism;

[0161] A first determination sub-module, configured to determine that the thread is in a state indicating suspected stuttering if the number of times the thread is detected to be in the specified state reaches a preset number threshold;

[0162] A second determination sub-module, configured to determine that the thread is not in a state indicating suspected stuttering if the number of times the thread is detected to be in the specified state does not reach the preset number threshold.

[0163] In an exemplary embodiment, a thread includes a main thread, and a detection module 1110, including:

[0164] An adding sub-module, configured to create an observer and a first semaphore, add the observer to the main thread, and use the observer to monitor the running loop state of the main thread, so that when the observer monitors that the running loop state of the main thread is in a preset state, a first semaphore is issued;

[0165] A judging sub-module, configured to create a monitoring sub-thread to receive the first semaphore through the monitoring sub-thread, and judge whether the main thread is in a state indicating suspected lag according to the time when the monitoring sub-thread receives the first semaphore and the current running loop state of the main thread.

[0166] In an exemplary embodiment, a thread includes a main thread, and a sending module 1120, including:

[0167] A creating sub-module, configured to create a test sub-thread and a second semaphore;

[0168] A sending sub-module, configured to send a test task package to the main thread through the test sub-thread, so that when the receiving flag bit of the main thread is modified from a first value to a second value according to the test task package, a second semaphore is issued.

[0169] In an exemplary embodiment, an obtaining module 1130, including:

[0170] A receiving sub-module, configured to receive the second semaphore and record the receiving time of the second semaphore;

[0171] An obtaining sub-module, configured to obtain the creation time of the second semaphore, and calculate the processing duration of the main thread for the test task according to the creation time and the receiving time of the second semaphore.

[0172] In an exemplary embodiment, the device for testing thread lag further includes:

[0173] An associated data module, configured to obtain the associated data corresponding to the thread lag;

[0174] An analysis module, configured to perform analysis processing on the associated data, and determine lag data from the associated data based on the analysis processing;

[0175] A management device module, configured to send the lag data to a specified management device, so that the specified management device performs optimization processing on the thread based on the lag data.

[0176] In an exemplary embodiment, the management device module includes:

[0177] A hash operation sub-module, configured to perform a hash operation on the lag data to obtain hash data corresponding to the lag data;

[0178] A matching sub-module, configured to match the hash data corresponding to the lag data with the stored hash data; wherein, the stored hash data is obtained by performing a hash operation on historical lag data.

[0179] A management device sub-module, configured to send the lag data to a specified management device if the hash data corresponding to the lag data does not match the stored hash data.

[0180] In an exemplary embodiment, a lag detection service is started to detect whether a thread is in a state indicating suspected lag through a running loop mechanism; the device for testing thread lag further includes:

[0181] A recording module, configured to send the lag data corresponding to the lagging thread to a specified management device respectively during the startup period of the lag detection service, and record the number of times of sending.

[0182] A stop module, configured to stop sending the lag data corresponding to the lagging thread to a specified management device if the number of times is greater than a preset number threshold.

[0183] A second acquisition unit, configured to acquire the number of lagging threads among multiple threads included in an application during the startup period of the lag detection service.

[0184] A first determination unit, configured to determine the application as a first type if the number is greater than a preset number threshold.

[0185] A second determination unit, configured to determine the application as a second type if the number is less than or equal to a preset number threshold; wherein, the application performance of the second type is higher than that of the first type.

[0186] In an exemplary embodiment, the device for testing thread lag further includes:

[0187] A third acquisition unit, configured to acquire the most recent startup time of the lag detection service if it is detected that the application is restarted.

[0188] A detection unit, configured to detect whether the time interval between the startup time and the current time is a second preset duration.

[0189] A startup unit, configured to restart the lag detection service if the time interval is a second preset duration.

[0190] It should be noted that the device for testing thread lag provided in the above embodiment and the method for testing thread lag provided in the above embodiment belong to the same concept. The specific manners in which each module, sub-module, and unit perform operations have been described in detail in the method embodiment, and will not be repeated here.

[0191] An embodiment of the present application further provides an electronic device, including: one or more processors; a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the method for testing thread jank provided in each of the above embodiments.

[0192] Figure 12 FIG. shows a schematic structural diagram of a computer system of an electronic device suitable for implementing the embodiments of the present application.

[0193] It should be noted that Figure 12 The computer system 1200 of the electronic device shown is only an example and should not impose any limitation on the functions and usage scope of the embodiments of the present application.

[0194] As Figure 12 shown, the computer system 1200 includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1202 or the program loaded from the storage section 1208 into the random access memory (RAM) 1203, such as executing the method described in the above embodiments. In the RAM 1203, various programs and data required for system operation are also stored. The CPU 1201, ROM 1202, and RAM 1203 are connected to each other via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0195] The following components are connected to the I / O interface 1205: an input section 1206 including a keyboard, a mouse, etc.; an output section 1207 including such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the I / O interface 1205 as required. A removable medium 1211, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1210 as required so that the computer program read from it can be installed into the storage section 1208 as required.

[0196] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 1209, and / or installed from the removable medium 1211. When the computer program is executed by the central processing unit (CPU) 1201, various functions defined in the system of the present application are executed.

[0197] It should be noted that the computer-readable medium shown in the embodiments of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer-readable storage medium can be any tangible medium that contains or stores a program, and the program can be used by or in combination with an instruction execution system, apparatus, or device. In the present application, the computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable computer program. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium, and the computer-readable medium can send, propagate, or transmit a program for use by or in combination with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted by any suitable medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0198] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. Among them, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, and the above-mentioned module, program segment, or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order from that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, as well as the combination of blocks in the block diagram or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0199] The units described in the embodiments of the present application can be implemented in software or in hardware, and the described units can also be provided in a processor. Among them, the names of these units do not constitute a limitation on the units themselves in some cases.

[0200] Another aspect of the present application also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the method described above is implemented. The computer-readable storage medium may be included in the electronic device described in the above embodiments, or may exist alone without being assembled into the electronic device.

[0201] Another aspect of the present application also provides a computer program product or a computer program, and the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the methods provided in the above various embodiments.

[0202] The above content is only a preferred exemplary embodiment of the present application and is not used to limit the implementation of the present application. Those of ordinary skill in the art can easily make corresponding adaptations or modifications according to the main concept and spirit of the present application. Therefore, the protection scope of the present application should be subject to the protection scope required by the claims.

Claims

1. A method for testing thread lag, characterized in that, Including: Detecting whether a thread is in a state representing suspected lag by running a loop mechanism; If in the state representing suspected lag, sending a test task packet to the thread to instruct the thread to execute a test task; Obtaining the processing duration of the thread for the test task; Determining whether the thread has a lag based on the relationship between the processing duration and a first preset duration; The detecting whether a thread is in a state representing suspected lag by running a loop mechanism includes: Periodically detecting whether the thread is in a specified state by running a loop mechanism; the specified state includes the state of about to process sources (kCFRunLoopBeforeSources) or the state of just waking up from dormancy (kCFRunLoopAfterWaiting); If the number of times the thread is detected to be in the specified state reaches a preset number threshold, determining that the thread is in a state representing suspected lag; If the number of times the thread is detected to be in the specified state does not reach the preset number threshold, determining that the thread is not in a state representing suspected lag.

2. The method according to claim 1, wherein The thread includes the main thread, and the detecting whether a thread is in a state representing suspected lag by running a loop mechanism includes: Creating an observer and a first semaphore, adding the observer to the main thread, and using the observer to monitor the run loop state of the main thread so that when the observer monitors that the run loop state of the main thread is in a preset state, the first semaphore is issued; Creating a monitoring sub-thread to receive the first semaphore through the monitoring sub-thread and determining whether the main thread is in a state representing suspected lag based on the time when the monitoring sub-thread receives the first semaphore and the current run loop state of the main thread.

3. The method according to claim 1, characterized in that, The thread includes the main thread, and the sending a test task packet to the thread to instruct the thread to execute a test task includes: Creating a test sub-thread and a second semaphore; Sending the test task packet to the main thread through the test sub-thread so that when the reception flag of the main thread is modified from a first value to a second value according to the test task packet, the second semaphore is issued; the second semaphore is used to represent that the main thread has completed the test task.

4. The method according to any one of claims 1 to 3, characterized in that, If it is determined that the thread has a lag, the method further includes: Obtaining associated data corresponding to the lag of the thread; Performing parsing processing on the associated data and determining lag data from the associated data based on the parsing processing; Sending the lag data to a specified management device so that the specified management device performs optimization processing on the thread based on the lag data.

5. The method according to claim 4, wherein The sending the lag data to a specified management device includes: Performing a hash operation on the lag data to obtain hash data corresponding to the lag data; Matching the hash data corresponding to the lag data with stored hash data; wherein, the stored hash data is obtained by performing a hash operation on historical lag data; If the hash data corresponding to the lag data does not match the stored hash data, the lag data is sent to the specified management device.

6. The method according to any one of claims 1 to 3, characterized in that, Start the lag detection service to detect whether a thread is in a state indicating suspected lag through a run loop mechanism; the method further includes: During the startup period of the lag detection service, send the lag data corresponding to the lagging threads to the specified management device respectively, and record the number of transmissions. If the number is greater than a preset number threshold, stop sending the lag data corresponding to the lagging threads to the specified management device. During the startup period of the lag detection service, obtain the number of lagging threads among the multiple threads included in the application. If the number is greater than a preset number threshold, determine the application as the first type. If the number is less than or equal to the preset number threshold, determine the application as the second type; wherein, the application performance of the second type is higher than that of the first type.

7. A device for testing thread jamming, characterized in that, Includes: A detection module configured to detect whether a thread is in a state indicating suspected lag through a run loop mechanism. A sending module configured to, if in the state indicating suspected lag, send a test task package to the thread to instruct the thread to execute the test task. An obtaining module configured to obtain the processing duration of the thread for the test task. A determining module configured to determine whether the thread has lags based on the relationship between the processing duration and a first preset duration. The detection module includes: A detection sub-module configured to periodically detect whether the thread is in a specified state through a run loop mechanism; the specified state includes the state of about to process sources (kCFRunLoopBeforeSources) or the state of just waking up from sleep (kCFRunLoopAfterWaiting). A first determination sub-module configured to determine that the thread is in a state indicating suspected lag if the number of times the thread is detected to be in the specified state reaches a preset number threshold. A second determination sub-module configured to determine that the thread is not in a state indicating suspected lag if the number of times the thread is detected to be in the specified state does not reach the preset number threshold.

8. An electronic device, characterized in that, Includes: One or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the method for testing thread lags as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, Stored thereon are computer-readable instructions, which, when executed by a processor of a computer, cause the computer to execute the method for testing thread lags as described in any one of claims 1 to 6.

Images