A RunLoop-based frame freezing detection method and related device

Abstract

The application provides a RunLoop-based frame freezing detection method and related device, and relates to the technical field of software, which comprises the following steps: configuring a RunLoop observer in a Debug environment of branch code, the RunLoop observer being used for monitoring RunLoop entering state and RunLoop exiting state of a main thread task; determining single RunLoop cycle time consumption of the main thread task according to system time when the RunLoop observer monitors the RunLoop entering state and the RunLoop exiting state; and determining whether the main thread task is frame frozen according to the single RunLoop cycle time consumption. The application is integrated only in the Debug environment of the branch code, and there is no any code and resource residue in the Release environment, so that the volume of the online package is not increased, the online running resources are not occupied, and the application performance is not affected.

Description

Technical Field

[0001] This application relates to the field of software technology, and in particular to a method and apparatus for detecting stuttering based on RunLoop. Background Technology

[0002] As the complexity of iOS applications increases, users' tolerance for page smoothness continues to decrease, and lag detection has become a core means of locating performance issues during the development process.

[0003] Traditional stuttering detection libraries are mostly full-environment detection libraries, which directly encode detection code in the project, resulting in increased online package size and the impact of running the monitoring code on application performance. Summary of the Invention

[0004] In view of the above problems, this application provides a method and related device for stuttering detection based on RunLoop, so as to achieve stuttering detection in a debug environment. The specific solution is as follows:

[0005] The first aspect of this application provides a stuttering detection method based on RunLoop, the stuttering detection method based on RunLoop includes:

[0006] In the debug environment of the branch code, configure a RunLoop observer, which is used to monitor the RunLoop entry and exit status of the main thread task.

[0007] The system time at which the RunLoop enters and exits is detected by the RunLoop observer is used to determine the time taken for a single RunLoop loop of the main thread task.

[0008] The main thread task is determined to be stuck based on the time taken for a single RunLoop loop.

[0009] In one possible implementation, the configuration of the RunLoop observer includes:

[0010] Create the RunLoop observer, set its priority to the highest, and bind the RunLoop observer to the RunLoop general pattern.

[0011] In one possible implementation, determining whether the main thread task is stuck based on the time consumed in a single RunLoop loop includes:

[0012] Get the time threshold for the current page;

[0013] Whether the main thread task is stuck is determined by comparing the time taken for a single RunLoop loop with the time threshold.

[0014] In one possible implementation, the time threshold for obtaining the current page includes:

[0015] Obtain a list of pages from the cloud configuration, the list of pages containing the class names and time consumption thresholds of multiple configured pages;

[0016] Obtain the class name of the current page by listening to the page's lifecycle;

[0017] If the class name of the current page is in the page list, query the page list for the time consumption threshold of the current page.

[0018] In one possible implementation, the RunLoop-based stuttering detection method further includes:

[0019] If the class name of the current page is not in the page list, release the resources used for lag detection of the current page.

[0020] In one possible implementation, the RunLoop-based stuttering detection method further includes:

[0021] If the main thread task is determined to be stuck, log information is generated by collecting the call stack and the stuck context.

[0022] In one possible implementation, the RunLoop-based stuttering detection method further includes:

[0023] In response to a visual trigger operation, a button for controlling the lag detection progress is displayed in the operation interface, and a touch event is responded to for the button.

[0024] A second aspect of this application provides a stuttering detection device based on RunLoop, the stuttering detection device based on RunLoop comprising:

[0025] The observer configuration module is used to configure RunLoop observers in the Debug environment of branch code. The RunLoop observers are used to monitor the RunLoop entry and exit status of the main thread task.

[0026] The stuttering detection module is used to determine the single RunLoop loop time of the main thread task based on the system time when the RunLoop observer detects the RunLoop entry state and the RunLoop exit state; and to determine whether the main thread task is stuttering based on the single RunLoop loop time.

[0027] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the RunLoop-based stuttering detection method described in the first aspect or any implementation thereof.

[0028] A fourth aspect of this application provides an electronic device, including at least one processor and a memory connected to the processor, wherein:

[0029] The memory is used to store computer programs;

[0030] The processor is used to execute the computer program so that the electronic device can implement the RunLoop-based stuttering detection method described in the first aspect or any implementation thereof.

[0031] The fifth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the RunLoop-based stuttering detection method described in the first aspect or any implementation thereof.

[0032] Using the above technical solution, this application provides a method and related apparatus for detecting stuttering based on RunLoop, comprising: configuring a RunLoop observer in the Debug environment of branch code, the RunLoop observer being used to monitor the RunLoop entry and exit states of the main thread task; determining the single RunLoop loop time of the main thread task based on the system time of the RunLoop entry and exit states monitored by the RunLoop observer; and determining whether the main thread task is stuttering based on the single RunLoop loop time. This application configures a RunLoop observer in the Debug environment of branch code, and determines whether stuttering occurs by monitoring the RunLoop entry and exit states of the main thread task. Since this application is only integrated in the Debug environment of branch code, and there is no code or resource residue in the Release environment, this does not increase the size of the online package, does not occupy online running resources, and therefore does not affect application performance. Attached Figure Description

[0033] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0034] Figure 1 A flowchart illustrating a stuttering detection method based on RunLoop provided in this application embodiment;

[0035] Figure 2 A partial flowchart illustrating a stuttering detection method based on RunLoop provided in this application embodiment;

[0036] Figure 3 This is another part of the flowchart of a stuttering detection method based on RunLoop provided in an embodiment of this application;

[0037] Figure 4 A schematic diagram of a stuttering detection device based on RunLoop provided in an embodiment of this application;

[0038] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0039] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0040] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0041] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0042] To facilitate understanding of this application, the relevant concepts involved in this application will be explained below:

[0043] Pod: A library integration method used by mainstream iOS dependency management tools, which supports configuring library files to be loaded only in specific compilation environments (such as Debug) to achieve "on-demand integration".

[0044] Debug / Release Environments: These are the two core compilation modes for iOS development. The Debug environment is used for development and debugging; the Release environment is used for online deployment and requires optimization of package size and performance, while shielding all debugging-related logic.

[0045] Method Swizzling: An Objective-C runtime technique that allows the implementation logic of a target method to be swapped without modifying the original code. It is often used to intercept page lifecycle methods.

[0046] Traditional stuttering detection primarily relies on fully integrated stuttering detection libraries (such as PLCrashReporter). These libraries default to a fully integrated approach, focusing on "full-scenario coverage" without specific optimizations for "debugging only" scenarios. This results in the library's core code (such as the RunLoop observer class and log reporting class) still being packaged into the online package even when the online detection function is disabled, increasing the online package size by 0.3-0.5MB and consuming user storage space. Simultaneously, the runtime on / off logic (such as if(isDebug){start monitoring}) consumes main thread resources, with each check taking 1-2ms, potentially leading to page response delays and impacting user experience over time. Furthermore, this hard-coded detection method lacks a visual interface and cloud configuration; detection control relies on code calls or command lines, and adjusting stuttering thresholds requires rewriting the code. It only considers the "developer's use case" and neglects the needs of testers, novices, and other non-technical roles. Finally, the existing solution requires developers to complete 3-5 steps, such as "testing the library → configuring the compilation script → setting macro definitions → adjusting Build Settings". It lacks "integrated installation" and relies on manual operation to achieve environment isolation and logic embedding. This leads to long integration time, configuration differences between different developers' environments (such as incorrect script paths or misspelled macro definitions), and failure of some scenario detection functions (such as incorrect integration of detection code in the Release environment or failure of detection logic in the Debug environment). It requires repeated internal communication and troubleshooting within the team, increasing collaboration costs.

[0047] To address the aforementioned problems, this application provides a stuttering detection method based on RunLoop. The stuttering detection method based on RunLoop of this application will be described in detail below with reference to the accompanying drawings.

[0048] See Figure 1 , Figure 1 This is a flowchart illustrating a stuttering detection method based on RunLoop provided in an embodiment of this application. Figure 1As shown in the figure, the stuttering detection method based on RunLoop provided in this application embodiment is applied to the client and may include steps S101 to S103, which are described in detail below.

[0049] S101. In the Debug environment of the branch code, configure the RunLoop observer. The RunLoop observer is used to monitor the RunLoop entry and exit status of the main thread task.

[0050] In this embodiment of the application, in order to solve the problem of online intrusion, the detection library is designed as a "Debug-only integration" by combining the Pod referencing the detection library and the detection code having an independent branch. The Pod configuration explicitly states that only the Debug environment loads the core code of the detection library, and the Release environment has no code or resource residues, which does not increase the size of the online package or occupy online running resources.

[0051] Specifically, based on the project's master code (mainline code, i.e., the code executed by online users), a branch code for stuttering detection is pulled (this branch code is maintained in parallel with the mainline code). The execution environment of the detection framework is specified in the project's Podfile on this branch code, ensuring that the detection code is only imported in the Debug environment, effectively isolating the release environment from the mainline code, and ensuring that no line of detection code is added to the online installation package (i.e., specifying pod xxx:configurations=>['Debug']).

[0052] Furthermore, in the release environment of the branch code, a custom RunLoop observer is created to listen only to critical states, avoiding redundant event collection. These critical states include the RunLoop entry state (i.e., kCFRunLoopEntry) and RunLoop exit state (i.e., kCFRunLoopExit) of the main thread task. The time difference between the RunLoop exit state and the RunLoop entry state directly reflects the time consumed by a single RunLoop loop (i.e., the execution time of the main thread task). Therefore, the RunLoop observer does not need to listen to other states (such as kCFRunLoopBeforeTimers), reducing resource consumption.

[0053] In one possible implementation, to ensure that state changes of the main thread task can be captured in a timely manner, the RunLoop observer is set to the highest priority in this embodiment to avoid missing stuttering events. To this end, this embodiment provides a stuttering detection method based on RunLoop, wherein step S101, "configuring the RunLoop observer," may include the following steps:

[0054] Create a RunLoop observer, set its priority to the highest, and bind the RunLoop observer to the RunLoop general pattern.

[0055] In this embodiment, a RunLoop observer is created to listen for the RunLoop's entry and exit states. The RunLoop observer's priority is set to the highest (the priority value is set to 0) to ensure that state changes can be captured in real time. In addition, the RunLoop observer is bound to the RunLoop common mode, that is, the RunLoop observer is only added to the kCFRunLoopCommonModes (including the default mode and the swipe mode) of the main thread RunLoop to ensure that it can still be monitored normally when swiping the page (such as UIScrollView) and that no stuttering in the interaction is missed.

[0056] S102, based on the system time of the RunLoop entering and exiting states monitored by the RunLoop observer, determine the time consumed by a single RunLoop loop of the main thread task.

[0057] In this embodiment, the RunLoop entry and exit states of the main thread task can be monitored through the configured RunLoop observer. The system time when the RunLoop entry and exit states are triggered can be recorded. The system time uses CACurrentMediaTime() with microsecond precision to avoid millisecond errors of NSDate.

[0058] In response, when the RunLoop exits, the system time of the RunLoop exits and the system time of the most recent RunLoop enters can be used to calculate the time difference between them. This time difference can then be used as the time consumption of a single RunLoop loop for the main thread task.

[0059] S103 determines whether the main thread task is stuck based on the time taken for a single RunLoop loop.

[0060] In this embodiment of the application, after obtaining the time consumption of a single RunLoop loop, it is possible to determine whether the main thread task is stuck based on the configured time consumption threshold. Specifically, if the time consumption of a single RunLoop loop is greater than or equal to the time consumption threshold, the main thread task is stuck; conversely, if the time consumption of a single RunLoop loop is less than the time consumption threshold, the main thread task is not stuck.

[0061] In one possible implementation, differentiated time thresholds can be set for pages with different performance requirements (e.g., complex list pages vs. simple detail pages) to improve detection accuracy. This allows for rapid adjustment of the thresholds for precise location of issues, such as sudden increases in page lag. See also Figure 2 , Figure 2 This is a partial flowchart illustrating a stuttering detection method based on RunLoop provided in an embodiment of this application. Figure 2 As shown in the embodiment of this application, a stuttering detection method based on RunLoop is provided. In step S103, "determine whether the main thread task is stuttering based on the time consumed in a single RunLoop loop", which may include steps S201 to S202. These steps are described in detail below.

[0062] S201, Get the time threshold for the current page.

[0063] In this embodiment, the corresponding time consumption threshold can be obtained based on the performance requirements of the current page.

[0064] In one possible implementation, dynamic cloud configuration capabilities can be provided, supporting cloud-based control of the list of pages for lag detection and the reporting frequency. Cloud configurations are sent to the client in real time and take effect without requiring application recompilation, thus improving the efficiency of adjusting detection rules. See also Figure 3 , Figure 3 This is another schematic diagram of a stuttering detection method based on RunLoop provided in an embodiment of this application. Figure 3 As shown in the embodiment of this application, a stuttering detection method based on RunLoop is provided. Step S201, "obtaining the time consumption threshold of the current page", may include steps S301 to S303. These steps are described in detail below.

[0065] S301 retrieves a list of pages from the cloud configuration. The list of pages contains the class names and time thresholds of multiple configured pages.

[0066] In this embodiment of the application, a list of pages for detection can be obtained from the cloud configuration. This list of pages includes the class names of multiple configured pages that are the objects of lag detection, as well as their respective time consumption thresholds.

[0067] In practical applications, the cloud-based management backend supports "Add / Delete / Edit" configuration pages. Users can enter the page class name (e.g., HomeViewController), select the page type (e.g., list page, detail page), and set differentiated time thresholds (the input box can be manually entered, ranging from 200-5000ms). Additionally, the cloud management platform can have built-in threshold templates for commonly used pages (e.g., "Complex list page 3000ms," "Simple detail page 500ms," "Splash page 1000ms"), allowing users to directly select templates without manual input.

[0068] After the configuration is distributed from the cloud, the client automatically verifies the class name in the page list (e.g., whether the class name exists locally), whether the time consumption threshold is within the threshold range, and whether the client version matches. If they do not match, the client's default detection strategy is executed (e.g., if the class name does not match, a full detection is performed, and the default threshold is 3000).

[0069] S302 obtains the class name of the current page by listening to the page lifecycle.

[0070] In this embodiment, Objective-C runtime technology is used to exchange the implementations of the `viewDidAppear` (page is displayed) and `viewDidDisappear` (page is hidden) methods of `UIViewController` to monitor the page lifecycle. By monitoring the page lifecycle, the currently displayed page can be determined, and its class name (e.g., `NSStringFromClass([self class])`) can be obtained.

[0071] S303, if the class name of the current page is in the page list, query the time consumption threshold of the current page in the page list.

[0072] In this embodiment of the application, the class name of the current page is compared with the page list. If the class name of the current page is in the page list, RunLoop monitoring is started to detect lag and the time consumption threshold of the current page is queried from the page list.

[0073] In addition, if the class name of the current page is not in the page list, the resources used for detecting lag on the current page are released, such as releasing the RunLoop observer, clearing the recorded system time, destroying the lag log cache array, and removing references to the page to avoid memory leaks, etc.

[0074] In practical applications, when the current page is detected to be hidden, RunLoop monitoring should be stopped immediately, and the current page information and stuttering log cache should be cleared to avoid consuming resources after the page is switched.

[0075] S202 determines whether the main thread task is stuck by comparing the time taken for a single RunLoop loop with the time threshold.

[0076] In this embodiment of the application, after obtaining the time threshold of the current page, the main thread task can be determined by comparing the time of a single RunLoop loop with the time threshold. Specifically, if the time of a single RunLoop loop is greater than or equal to the time threshold, the main thread task is stuck; otherwise, if the time of a single RunLoop loop is less than the time threshold, the main thread task is not stuck.

[0077] In one possible implementation, upon determining that the main thread is experiencing a stutter, logs can be immediately generated and written to a local file to prevent data loss. To this end, this application provides a stutter detection method based on RunLoop, which further includes the following steps:

[0078] If the main thread task is determined to be stuck, log information is generated by collecting the call stack and the stuck context.

[0079] In this embodiment of the application, when it is determined that the main thread task is stuck, the call stack and stuck context (page name, time consumption, device information, timestamp, etc.) of the main thread task are collected through the backtrace / backtrace_symbols interface to form log information.

[0080] In one possible implementation, low-threshold visual operation and flexible configuration can be set. In this regard, the stuttering detection method based on RunLoop provided in this application embodiment further includes the following steps:

[0081] In response to visual triggering operations, a button for controlling the lag detection progress is displayed in the operation interface, and touch events on the button are responded to.

[0082] In this embodiment of the application, in order to ensure that the lag detection is only performed in the Debug environment and does not affect the online user experience, the lag detection progress is hidden by default. Users can trigger the display through visual triggering operations. For example, after the user shakes the phone, the lag detection operation interface pops up from the bottom, and after shaking the phone again, the lag detection operation interface disappears from the bottom.

[0083] The stuttering detection interface displays buttons to control the stuttering detection progress, such as "Start Detection," "Pause Detection," and "Report Logs." "Start Detection" is displayed during initialization; clicking it starts RunLoop monitoring for stuttering detection, and the status updates to "Running." "Pause Detection" is displayed while the interface is "Running"; clicking it pauses stuttering recording, and the status updates to "Paused." "Report Logs": If the current interface is not frozen, clicking it immediately uploads locally saved stuttering logs in batches to the cloud, and provides multiple direct sharing methods (such as system sharing) to share the logs with relevant users. If the interface is frozen: the next time the application starts, a pop-up window automatically notifies the user of the existence of stuttering logs to be reported during the detection framework initialization phase.

[0084] Based on the above description, the stuttering detection method based on RunLoop provided in this application constructs a stuttering detection architecture in the iOS Debug environment, covering the entire process of "environment isolation - accurate detection - cloud management - low-threshold operation". It has the following advantages:

[0085] 1) Achieve dedicated integration for the Debug environment and zero intrusion into the online environment: By combining the Pod reference detection library with a separate branch of the detection code, it is ensured that the detection library (including core logic, visual interface, and cloud interaction functions) is integrated only in the Debug environment. There are no code or resource residues in the Release environment, which does not increase the size of the online package or consume online runtime resources. Compared with the existing full-environment integration solution, the online package size is reduced by 0.3-0.5MB, and there is no performance loss due to runtime on / off judgment. This meets the optimization requirements of "lightweight" iOS applications and avoids the impact of detection functions on the online user experience.

[0086] 2) Provides dynamic cloud configuration capabilities: Supports cloud-based adjustment of detection pages and differentiated time consumption thresholds, with modifications requiring no recompilation. In multi-page iterative development scenarios, developers only need to focus on developing new pages, without writing stuttering detection code; testers can flexibly switch detection targets according to test scenarios (such as performance testing, functional testing), without relying on developers, thus improving team collaboration efficiency.

[0087] 3) Achieve precise and low-cost monitoring of the RunLoop: Only monitor the "entry" and "exit" key states of the RunLoop, and combine this with the page lifecycle to achieve "targeted startup monitoring" (covering the entire lifecycle of page loading and interaction), keeping the main thread CPU usage below approximately 2%. Compared to existing global monitoring solutions (CPU usage around 5%-10%), application smoothness is significantly improved in the debug environment, without masking real business lag (such as lag during loading or interaction), and debug results accurately reflect actual performance issues while reducing unnecessary resource consumption.

[0088] 4) Reduced Development and Integration Costs: The detection library is encapsulated as a standard Pod library. Developers only need one line of Podfile configuration to enable all functions (monitoring, visualization interface, cloud interaction), without the need for manual adjustments to scripts or project settings, reducing the risk of configuration errors. Compared to the existing 3-5 step manual configuration solution, the integration time is shortened, and configuration failures caused by incorrect script paths or missing macro definitions are avoided; the configuration is consistent across different developer environments, eliminating the need for internal communication of configuration details within the team, thus reducing communication costs.

[0089] 5) Enables low-barrier visual operation and flexible configuration: Provides a floating visual panel, allowing non-technical personnel (testers, novices) to control the detection process and manually report logs via buttons; at the same time, the panel has a built-in cloud configuration entry, which supports direct modification of the lag threshold without the need for technical personnel assistance, improving team collaboration efficiency and detection accuracy.

[0090] The above describes a stuttering detection method based on RunLoop provided by the embodiments of this application. The following will describe the apparatus for performing the above stuttering detection method based on RunLoop.

[0091] See Figure 4 , Figure 4 This is a schematic diagram of a stuttering detection device based on RunLoop, provided as an embodiment of this application. Figure 4 As shown in the figure, an embodiment of this application provides a stuttering detection device based on RunLoop, comprising:

[0092] The observer configuration module 401 is used to configure RunLoop observers in the Debug environment of branch code. RunLoop observers are used to listen to the RunLoop entry and exit status of the main thread task.

[0093] The stuttering detection module 402 is used to determine the single RunLoop loop time of the main thread task based on the system time when the RunLoop observer listens to the RunLoop entry state and RunLoop exit state; and to determine whether the main thread task is stuttering based on the single RunLoop loop time.

[0094] In one possible implementation, the observer configuration module 401, used to configure RunLoop observers, is specifically used for:

[0095] Create a RunLoop observer, set its priority to the highest, and bind the RunLoop observer to the RunLoop general pattern.

[0096] In one possible implementation, the stuttering detection module 402, used to determine whether the main thread task is stuttering based on the time taken for a single RunLoop loop, is specifically used for:

[0097] Get the time threshold of the current page; determine whether the main thread task is stuck by comparing the time of a single RunLoop loop with the time threshold.

[0098] In one possible implementation, the stuttering detection module 402, used to obtain the time threshold of the current page, is specifically used for:

[0099] Retrieve a list of pages from the cloud configuration, which contains the class names and time thresholds of multiple configured pages; obtain the class name of the current page by listening to the page lifecycle; if the class name of the current page is in the page list, query the time threshold of the current page in the page list.

[0100] In one possible implementation, the stuttering detection module 402 is also used for:

[0101] If the class name of the current page is not in the page list, release the resources used for detecting lag on the current page.

[0102] In one possible implementation, the stuttering detection module 402 is also used for:

[0103] If the main thread task is determined to be stuck, log information is generated by collecting the call stack and the stuck context.

[0104] In one possible implementation, the stuttering detection module 402 is also used for:

[0105] In response to visual triggering operations, a button for controlling the lag detection progress is displayed in the operation interface, and touch events on the button are responded to.

[0106] For detailed functions of each module in the embodiments of this application, please refer to the corresponding disclosure of the above-mentioned RunLoop-based stuttering detection method embodiments, which will not be repeated here.

[0107] This application also provides an electronic device in its embodiments. See also... Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device in this embodiment may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0108] like Figure 5As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503. When the electronic device is powered on, the RAM 503 also stores various programs and data required for the operation of the electronic device. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0109] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, memory cards, hard drives, etc.; and communication devices 509. Communication device 509 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0110] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the RunLoop-based stuttering detection methods provided in this application.

[0111] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the RunLoop-based stuttering detection methods provided in this application.

[0112] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0113] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0114] In the above embodiments, the implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product.

[0115] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for detecting a stall based on a RunLoop, the method comprising: The stuttering detection method based on RunLoop includes: On the branch code pulled from the main project code, specify the execution environment of the detection framework in the project Podfile to import the detection code in the Debug environment of the branch code, and create a RunLoop observer, set the priority of the RunLoop observer to the highest, and only add the RunLoop observer to the kCFRunLoopCommonModes of the main thread RunLoop. The RunLoop observer is used to listen to the RunLoop entry status and RunLoop exit status of the main thread task. The system time for a single RunLoop loop of the main thread task is determined based on the system time at which the RunLoop enters and exits the RunLoop, as detected by the RunLoop observer. The system time is obtained using CACurrentMediaTime(). Obtain a list of pages from the cloud configuration, the list of pages containing the class names and time consumption thresholds of multiple configured pages; By leveraging Objective-C runtime technology, we can swap the implementations of UIViewController's viewDidAppear and viewDidDisappear methods to listen to the page lifecycle and obtain the class name of the current page. Automatically verify whether the class name in the page list exists locally, whether the time consumption threshold is within the threshold range, and whether the client version matches. If they do not match, execute the client default detection strategy, which includes full detection and using the default time consumption threshold. If the class name of the current page is in the page list, query the time consumption threshold of the current page in the page list; determine whether the main thread task is stuck by comparing the time consumption of a single RunLoop loop with the time consumption threshold. When the current page is detected to be hidden, stop RunLoop monitoring and clear the current page information and lag log cache.

2. The RunLoop-based stutter detection method of claim 1, wherein, The RunLoop-based stuttering detection method also includes: If the class name of the current page is not in the page list, release the resources used for lag detection of the current page.

3. The stuttering detection method based on RunLoop according to claim 1, characterized in that, The RunLoop-based stuttering detection method also includes: If the main thread task is determined to be stuck, log information is generated by collecting the call stack and the stuck context.

4. The stuttering detection method based on RunLoop according to claim 1, characterized in that, The RunLoop-based stuttering detection method also includes: In response to a visual trigger operation, a button for controlling the lag detection progress is displayed in the operation interface, and a touch event is responded to for the button.

5. A stuttering detection device based on RunLoop, characterized in that, The stuttering detection device based on RunLoop includes: The observer configuration module is used to specify the execution environment of the detection framework in the project Podfile on the branch code pulled based on the main code of the project, so as to import the detection code in the Debug environment of the branch code, create a RunLoop observer, set the priority of the RunLoop observer to the highest, and add only the RunLoop observer to the kCFRunLoopCommonModes of the main thread RunLoop. The RunLoop observer is used to listen to the RunLoop entry status and RunLoop exit status of the main thread task. The stuttering detection module is used to determine the single RunLoop loop time of the main thread task based on the system time of the RunLoop entry and exit states monitored by the RunLoop observer. The system time is obtained using CACurrentMediaTime(). It retrieves a page list from the cloud configuration, which contains the class names and time thresholds of multiple configured pages. Using Objective-C runtime technology, it exchanges the implementations of the `viewDidAppear` and `viewDidDisappear` methods of `UIViewController` to monitor the page lifecycle and obtain the class name of the current page. It automatically verifies whether the class name in the page list exists locally, whether the time threshold is within the threshold range, and whether the client version matches. If they do not match, it executes the client's default detection strategy, which includes full detection and using the default time threshold. If the class name of the current page is in the page list, it queries the page list for the time threshold of the current page. It determines whether the main thread task is stuttering by comparing the single RunLoop loop time with the time threshold. When the current page is detected as hidden, it stops RunLoop monitoring and clears the current page information and stuttering log cache.

6. A computer program product, characterized in that, It includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the RunLoop-based stuttering detection method as described in any one of claims 1 to 4.

7. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the RunLoop-based stuttering detection method as described in any one of claims 1 to 4.

Images