A thread processing method and electronic device

Abstract

This application provides a thread processing method and an electronic device, relating to the field of terminal technology. During the operation of an app on the electronic device, the device can determine the critical thread corresponding to the app and the overloaded thread corresponding to the app. The critical thread includes the rendering thread corresponding to the app and threads that depend on the rendering thread; that is, the critical thread represents the thread that affects screen rendering. The overloaded thread represents the thread with a high load. The electronic device can then determine whether the overloaded thread is a critical thread. If it is, it indicates that the overloaded thread is related to screen rendering and can be a normal thread. If not, it indicates that the thread may be unrelated to screen rendering, and the electronic device can further determine whether the overloaded thread is an abnormal thread. Furthermore, after determining an abnormal thread, the electronic device can stop running the abnormal thread, reducing the power consumption of the electronic device.

Description

[0001] This application is a divisional application of Chinese patent application filed on January 17, 2023, with application number 202310111420.6 and entitled "A Thread Processing Method and Electronic Device". Technical Field

[0002] This application relates to the field of terminal technology, and in particular to a thread processing method and an electronic device. Background Technology

[0003] With the development of electronic devices (such as mobile phones), the number and types of applications (APPs) that can be installed on electronic devices are increasing.

[0004] During the operation of an app on an electronic device, due to reasons such as the app's own code logic, there may be abnormal threads in the thread corresponding to the app running on the electronic device, which will affect the user experience. Summary of the Invention

[0005] In view of this, this application provides a thread processing method and an electronic device that can improve the user experience.

[0006] In a first aspect, this application provides a thread processing method in which an electronic device can receive a user's startup operation on a first APP of the electronic device and, in response to the startup operation, start the first APP.

[0007] During the operation of the first APP on the aforementioned electronic device, the electronic device can determine whether the thread corresponding to the first APP meets a first preset condition. If the thread meets the first preset condition, the electronic device can determine that the thread is an abnormal thread. The first preset condition may include that the thread has no dependency relationship with the rendering thread corresponding to the first APP, and that the thread belongs to the top M threads (or overloaded threads) ranked from largest to smallest among the threads corresponding to the first APP. M is a positive integer.

[0008] If the thread does not meet the first preset condition, such as if the thread is an overloaded thread and has a dependency relationship with the rendering thread corresponding to the first APP, it indicates that the thread affects the rendering of the screen. Therefore, the electronic device can determine that the thread is a normal thread.

[0009] Afterwards, the aforementioned electronic device can stop running the abnormal thread, or reduce the runtime resources occupied by the abnormal thread.

[0010] In this application, when the thread corresponding to the first app is an overloaded thread and has no dependency on the rendering thread corresponding to the first app, it indicates that the thread has a high load and may be unrelated to the rendering of the first app's screen. Therefore, this thread may be an abnormal thread, thus enabling the identification of abnormal threads. Furthermore, after identifying the abnormal thread corresponding to the first app, the electronic device can stop running the abnormal thread or reduce the runtime resources (such as CPU resources) occupied by the abnormal thread to reduce the power consumption of the electronic device, thereby reducing the device's power consumption, avoiding high power consumption and overheating issues, and improving the user experience.

[0011] In one possible design approach, the first preset condition may further include that the thread is a self-awakening thread; the self-awakening thread indicates that the thread was not awakened by another thread. For example, the self-awakening thread may indicate that the thread was not awakened by another thread within a second preset time from the current time, that is, the time when the thread was awakened was before the current time and more than a preset time from the current time.

[0012] In this application, when a thread is an overloaded thread and has a dependency relationship with the rendering thread corresponding to the first APP, the electronic device can further determine whether the thread is a self-wake-up thread. If the thread is a self-wake-up thread, it indicates that the thread is unlikely to affect the screen rendering, and the electronic device can directly determine that the thread is an abnormal thread.

[0013] In one possible design approach, the aforementioned first preset condition also includes that the difference between the first rendering frame rate and the second rendering frame rate is greater than a preset frame rate difference.

[0014] The first rendering frame rate represents the rendering frame rate after reducing the runtime resources occupied by the thread, and the second rendering frame rate represents the rendering frame rate before reducing the runtime resources occupied by the thread.

[0015] In another possible design approach, when the difference between the first rendering frame rate and the second rendering frame rate is less than or equal to a preset frame rate difference, it indicates that the rendering frame rate of the first APP has decreased after the resource supply to the thread has been reduced. In other words, it indicates that the thread is affecting the rendering of the screen. Therefore, the electronic device can determine that the thread is a normal thread and can restore the resource supply to the thread.

[0016] In this application, when the thread corresponding to the first app is an overloaded thread and has no dependency on the rendering thread corresponding to the first app, it indicates that the thread may be an abnormal thread. Therefore, the electronic device can reduce the resource allocation to the thread to determine whether the thread affects the rendering by comparing the rendering frame rate before and after reducing the resource allocation. If the difference is greater than a preset frame rate difference, it indicates that the rendering frame rate of the first app has not changed after reducing the resource allocation to the thread, meaning that the thread does not affect the rendering. Therefore, the electronic device can determine that the thread is an abnormal thread. If the difference is less than or equal to the preset frame rate difference, it indicates that the rendering frame rate of the first app decreases after reducing the resource allocation to the thread, meaning that the thread affects the rendering. Therefore, the electronic device can determine that the thread is a normal thread.

[0017] In one possible design approach, the first preset condition also includes, when the thread is not a self-wake-up thread, the difference between the first rendering frame rate and the second rendering frame rate is greater than a preset frame rate difference.

[0018] In this application, when the thread corresponding to the first APP is an overloaded thread and has no dependency relationship with the rendering thread corresponding to the first APP, if the thread is a self-wake-up thread, the electronic device can directly determine that the thread is an abnormal thread. If the thread is not a self-wake-up thread, the electronic device can continue to determine whether the thread is an abnormal thread by the difference between the first rendering frame rate and the second rendering frame rate.

[0019] In one possible design approach, reducing the runtime resources occupied by abnormal threads includes at least one of the following: migrating the abnormal thread from a first CPU core to a target CPU core, where the frequency of the target CPU core is lower than that of the first CPU core; changing the frequency of the CPU core where the abnormal thread resides from a first frequency to a second frequency, where the second frequency is lower than the first frequency, thereby reducing the runtime resources (such as CPU resources) occupied by the abnormal thread. Similarly, reducing the runtime resources occupied by threads includes at least one of the following: migrating the thread from a first CPU core to a target CPU core, where the frequency of the target CPU core is lower than that of the first CPU core; changing the frequency of the CPU core where the thread resides from a first frequency to a second frequency, where the second frequency is lower than the first frequency, thereby reducing the runtime resources (such as CPU resources) occupied by the thread.

[0020] In one possible design approach, the process by which the electronic device determines whether a dependency exists between the thread and the rendering thread corresponding to the first app may include:

[0021] The electronic device determines the rendering thread corresponding to the first APP.

[0022] The electronic device determines the key thread corresponding to the first APP; the key thread includes the rendering thread and threads that are dependent on the rendering thread, that is, the key thread represents the thread that directly or indirectly affects the rendering of the screen.

[0023] If the thread does not belong to the aforementioned critical threads, the electronic device determines that the thread has no dependency relationship with the rendering thread corresponding to the first APP, that is, it determines that the thread may not affect the rendering of the screen.

[0024] If the thread belongs to the aforementioned critical thread, the electronic device determines that the thread has a dependency relationship with the rendering thread corresponding to the first APP, that is, it determines that the thread will affect the rendering of the screen.

[0025] For example, the aforementioned dependency relationship can indicate a wake-up relationship. Accordingly, the process for threads in the aforementioned critical thread that have a dependency relationship with the rendering thread may include: the aforementioned electronic device determining the wake-up relationship between the threads running on the electronic device based on a preset wake-up field in the log generated by the electronic device;

[0026] Based on the wake-up relationship between the threads, the electronic device determines the threads that have a wake-up relationship with the rendering thread, i.e., a dependency relationship, thereby accurately determining the threads that have a dependency relationship with the rendering thread corresponding to the first APP, and thus determining the key threads corresponding to the first APP.

[0027] For example, the rendering thread corresponding to the first APP can be determined in the following two ways.

[0028] In one implementation, if the first APP is a game, the electronic device will use the thread that calls the preset drawing instructions the most times in the thread corresponding to the first APP as the rendering thread corresponding to the first APP.

[0029] For example, the default drawing instructions include the drawcall instruction.

[0030] In another implementation, the electronic device obtains the name of the rendered screen layer and uses the thread corresponding to the name of the screen layer as the rendering thread corresponding to the first APP.

[0031] In this application, the electronic device can determine the rendering thread corresponding to the first APP by layer name or by calling a preset number of drawing instructions, thereby achieving accurate determination of the rendering thread corresponding to the first APP.

[0032] Secondly, this application provides an electronic device, which includes an abnormal thread identification module and a central processing unit (CPU) frequency control module;

[0033] The abnormal thread identification module is used to identify abnormal threads in the threads corresponding to the first application (APP) after the first application (APP) of the electronic device is launched; wherein, the abnormal thread satisfies a first preset condition, the first preset condition includes that the thread has no dependency relationship with the rendering thread corresponding to the first APP, and the thread belongs to the top M threads in terms of load from largest to smallest among the threads corresponding to the first APP; where M is a positive integer;

[0034] The CPU frequency control module is used to stop the execution of the abnormal thread identified by the abnormal thread identification module, or to reduce the running resources occupied by the abnormal thread.

[0035] In one possible design, the aforementioned electronic device further includes an application type identification module and a rendering thread identification module. The application type identification module determines the type of the first app and sends the type of the first app to the rendering thread identification module. This type indicates whether the first app is a game app.

[0036] For example, the application type identification module can match the application package name of the first APP with the APP type recorded in the cloud to find the type of the first APP.

[0037] In one possible design approach, the rendering thread identification module uses the first information to determine the thread number of the rendering thread corresponding to the first APP, and sends the thread number of the rendering thread to the key thread identification module.

[0038] For example, in one scenario, when the first app is a game, the rendering thread identification module can determine the rendering thread based on the number of times a preset drawing instruction is called and the app's application type. Accordingly, the first information can include the thread number of each thread calling the preset drawing instruction and the number of times each thread number is called. Then, the rendering thread identification module can use the thread number with the most calls as the thread number of the rendering thread corresponding to the first app.

[0039] In another scenario, the rendering thread identification module can determine the rendering thread based on the name of the rendered image layer and the correspondence between image layers and threads. Accordingly, the first information mentioned above may include the name of the currently rendered image layer.

[0040] In another scenario, the rendering thread identification module can determine the rendering thread based on the image layer and its screen display method. Accordingly, the first information may include the name of the currently rendered image layer and its screen display method.

[0041] In one possible design, the aforementioned electronic device also includes a CPU load calculation module and a thread load statistics module.

[0042] The CPU load calculation module sends a load query request to the thread load statistics module. This load query request may include the application package name of the first APP, which can be used to obtain the load of each thread in the process corresponding to the first APP.

[0043] After receiving the load query request, the thread load statistics module can respond to the load query request by returning to the CPU load calculation module the thread number corresponding to the application package name of the first APP and the load corresponding to each thread number.

[0044] After receiving the load corresponding to each thread number, the CPU load calculation module can execute step i, sort the thread numbers in descending order of load, and send the sorted thread numbers to the key thread identification module in the mobile phone.

[0045] In one possible design approach, the critical thread identification module can select the top M thread numbers from the sorted thread numbers and use them as the thread numbers of the overloaded threads. For each overloaded thread's thread number, if the overloaded thread's thread number does not belong to the critical thread's thread number, then the overloaded thread's thread number is sent to the regular thread identification module.

[0046] Among them, the aforementioned key threads include the rendering thread corresponding to the first APP and the threads that have a wake-up relationship with the rendering thread.

[0047] Thirdly, this application provides an electronic device, the electronic device including a display screen, a memory and one or more processors; the display screen, the memory and the processor are coupled; the display screen is used to display an image generated by the processor, the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the electronic device performs the thread processing method as described in any one of the first aspects above.

[0048] Fourthly, this application provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the thread processing method as described in any one of the first aspects above.

[0049] Fifthly, this application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the thread processing method as described in any one of the first aspects above.

[0050] It is understood that the beneficial effects achieved by the electronic devices described in the second and third aspects above, the computer-readable storage medium described in the fourth aspect, and the computer program product described in the fifth aspect can be referred to the beneficial effects in the first aspect and any of its possible design embodiments, and will not be repeated here. Attached Figure Description

[0051] Figure 1A A schematic diagram of an application startup interface provided in an embodiment of this application;

[0052] Figure 1B A schematic diagram of an application launch interface provided in this application embodiment. Figure 2 ;

[0053] Figure 1C A schematic diagram illustrating thread execution provided in an embodiment of this application;

[0054] Figure 2 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0055] Figure 3 A schematic diagram of the software structure of an electronic device provided in an embodiment of this application;

[0056] Figure 4 A flowchart illustrating a thread processing method provided in an embodiment of this application;

[0057] Figure 5 A schematic diagram illustrating a layer name provided in an embodiment of this application;

[0058] Figure 6 A flowchart illustrating a thread processing method provided in this application embodiment. Figure 2 . Detailed Implementation

[0059] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0060] To better understand the solutions of this application, the following describes the terminology used in the embodiments of this application.

[0061] A thread is the smallest unit of computation that an operating system can schedule. It is contained within a process and is the actual unit of operation within that process. Multiple threads can run concurrently within a process, and each thread can execute different tasks in parallel.

[0062] Runnable state: also known as ready state. Threads in the runnable state reside in the runnable thread pool, waiting to be selected by the thread scheduler to acquire CPU usage rights. In other words, threads in the runnable state have acquired all resources required for operation except for CPU resources.

[0063] Running State: When a runnable thread acquires CPU resources, its state changes to running. A thread in the running state can execute program code.

[0064] During the operation of an app on an electronic device (such as a mobile phone), due to issues such as the app's code logic, there may be abnormal threads in the thread corresponding to the app running on the electronic device, such as threads that run for a long time and are unrelated to interface rendering.

[0065] Because abnormal threads typically don't terminate automatically and can run for extended periods, electronic devices tend to allocate more CPU resources to them. This might involve migrating the thread to a more powerful CPU core or increasing the clock speed of the CPU core hosting the thread. This wastes CPU resources, leading to increased power consumption in the system-on-chip (SoC) and potentially causing overheating issues. Furthermore, the CPU resource consumption of abnormal threads can affect the allocation of resources to other normal threads, resulting in program lag and a negative user experience. For example, if an abnormal thread occupies a high-performance CPU core, the device may be unable to migrate other normal threads to that core.

[0066] For example, such as Figure 1A As shown, the user clicks on the Honor of Kings icon on their phone's home screen. TM APP10. The phone responds to this click and launches the Honor of Kings app. TM APP10. Honor of Kings TM When APP10 starts, if Figure 1B As shown, the phone can render and display the startup animation 20. (This is from the game Honor of Kings.) TM After APP10 is launched, as follows Figure 1CAs shown, the phone runs multiple threads, including Thread-19425049 (or thread 25049). Thread 25049 runs for an extended period. Because thread 25049 is running for so long, the phone allocates more CPU resources to it. For example, the phone performs continuous core migration and frequency increases on it. Ultimately, the phone can migrate it to the highest-performing CPU core, CPU7. However, thread 25049 is unrelated to game interface rendering; it is neither a rendering thread nor a logic thread. Therefore, thread 25049 is considered an abnormal thread, causing unnecessary CPU resource consumption and increasing the phone's power consumption.

[0067] Therefore, to address the aforementioned problems, this application provides a thread processing method. After an app is launched on an electronic device, the device can determine whether the thread corresponding to the app meets a first preset condition. This first preset condition may include that the thread corresponding to the app has no dependency on the app's rendering, and that the thread has a high load, meaning it belongs to the top M threads in terms of load among all threads in the app. If the thread meets the first preset condition, it indicates that the thread is unrelated to screen rendering, and the electronic device can determine that the thread is an abnormal thread. If the thread does not meet the first preset condition, the electronic device can determine that the thread is a normal thread, and the electronic device can continue to run the thread normally. Afterwards, upon identifying an abnormal thread, the electronic device can stop running the abnormal thread or perform resource reduction operations on it, reducing the consumption of the electronic device's operating resources (such as CPU resources), thereby reducing the electronic device's power consumption and heat generation. This also prevents abnormal threads from occupying high-performance CPU cores, thus avoiding program lag and improving user experience.

[0068] For example, the electronic device in this application embodiment may be a mobile phone, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, as well as wearable device, personal digital assistant (PDA), augmented reality (AR) / virtual reality (VR) device, etc., which are electronic devices capable of running APP. This application embodiment does not impose any special restrictions on the specific form of the electronic device.

[0069] For example, Figure 2 A schematic diagram of the structure of electronic device 200 is shown. For example... Figure 2 As shown, the electronic device 200 may include a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (USB) interface 230, a charging management module 211, a power management module 212, a battery 213, an antenna 1, an antenna 2, a mobile communication module 240, a wireless communication module 250, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, a headphone jack 270D, a sensor module 280, buttons 290, a motor 291, an indicator 292, a camera 293, a display screen 294, and a subscriber identification module (SIM) card interface 295, etc.

[0070] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 200. In other embodiments of this application, the electronic device 200 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0071] Processor 210 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0072] In some embodiments, the processor 210 may include a CPU. The CPU may include at least one CPU core. CPU cores can be categorized into large cores, small cores, and medium cores. Different types of CPU cores have different performance characteristics, such as different clock speeds. For example, the CPU may have eight cores, including one large core, three medium cores, and four small cores. The large core has a higher clock speed than the medium core, and the medium core has a higher clock speed than the small core. CPU cores of the same type may have the same clock speed; for example, the three medium cores may have the same clock speed. Of course, CPU cores of the same type may also have different clock speeds.

[0073] The controller can be the nerve center and command center of the electronic device 200. The controller can generate operation control signals based on the instruction opcode and timing signals to control the fetching and execution of instructions.

[0074] The processor 210 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 210 is a cache memory. This memory can store instructions or data that the processor 210 has just used or that are used repeatedly. If the processor 210 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 210, and thus improves the efficiency of the system.

[0075] In some embodiments, the processor 210 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0076] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the electronic device 200. In other embodiments of this application, the electronic device 200 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0077] The charging management module 211 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 211 receives charging input from the wired charger via a USB interface 230. In some wireless charging embodiments, the charging management module 211 receives wireless charging input via the wireless charging coil of the electronic device 200. While charging the battery 213, the charging management module 211 can also supply power to the electronic device via the power management module 212.

[0078] The wireless communication function of electronic device 200 can be implemented through antenna 1, antenna 2, mobile communication module 240, wireless communication module 250, modem processor, and baseband processor.

[0079] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 200 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0080] The mobile communication module 240 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 200. The mobile communication module 240 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 240 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 240 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 240 may be housed in the processor 210. In some embodiments, at least some functional modules of the mobile communication module 240 and at least some modules of the processor 210 may be housed in the same device.

[0081] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 270A, receiver 270B, etc.) or displays images or videos through the display screen 294. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 210 and may be housed in the same device as the mobile communication module 240 or other functional modules.

[0082] The wireless communication module 250 can provide solutions for wireless communication applications on the electronic device 200, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 250 can be one or more devices integrating at least one communication processing module. The wireless communication module 250 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 210. The wireless communication module 250 can also receive signals to be transmitted from processor 210, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0083] Electronic device 200 implements display functions through a GPU, a display screen 294, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 294 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 210 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0084] The display screen (or screen) 294 is used to display images, videos, etc. The display screen 294 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 200 may include one or N displays 294, where N is a positive integer greater than 1.

[0085] Electronic device 200 can perform shooting functions through ISP, camera 293, video codec, GPU, display screen 294 and application processor.

[0086] The external storage interface 220 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 200.

[0087] Internal memory 221 can be used to store computer executable program code, which includes instructions. Processor 210 executes various functional applications and data processing of electronic device 200 by running the instructions stored in internal memory 221. Internal memory 221 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 200 (such as audio data, phonebook, etc.). Furthermore, internal memory 221 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0088] Electronic device 200 can implement audio functions such as music playback and recording through audio module 270, speaker 270A, receiver 270B, microphone 270C, headphone jack 270D, and application processor.

[0089] Button 290 includes a power button, volume buttons, etc. Button 290 can be a mechanical button or a touch button.

[0090] Indicator 292 can be an indicator light, which can be used to indicate charging status, power changes, messages, missed calls, notifications, etc.

[0091] The sensor module 280 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, etc.

[0092] The software system of the aforementioned electronic device 200 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses the layered architecture Android system as an example to exemplify the software structure of the electronic device 200.

[0093] Figure 3 This is a structural block diagram of the electronic device 200 according to an embodiment of the present invention.

[0094] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the native layer, and the kernel layer.

[0095] The application layer can include a series of application packages.

[0096] like Figure 3 As shown, the application package may include applications such as camera, games, calendar, calling, maps, navigation, WLAN, Bluetooth, music, video, and SMS.

[0097] In some embodiments, applications in the application layer can be divided into game apps and non-game apps.

[0098] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0099] like Figure 3 As shown, the application framework layer may include a window manager, content provider, view system, resource manager, notification manager, application type identification module, etc.

[0100] The application type identification module can be used to identify the type of application.

[0101] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0102] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0103] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0104] The phone manager is used to provide communication functions for electronic devices 200. For example, it manages call status (including connection and disconnection).

[0105] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0106] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0107] The native layer includes SurfaceFlinger, libhwui, libEGL, CPU load calculation module, frame rate detection module, abnormal thread identification module, CPU frequency control module, rendering thread identification module, and critical thread identification module.

[0108] The CPU load calculation module described above can be used to sort the threads corresponding to the APP according to the load size. This CPU calculation module can also provide the sorted threads to the critical thread identification module.

[0109] The frame rate detection module described above can be used to determine the rendering frame rate.

[0110] The aforementioned abnormal thread identification module can be used to receive the thread number sent by the critical thread identification module and determine whether the thread corresponding to the thread number is an abnormal thread.

[0111] The CPU frequency control module mentioned above can be used to reduce the resource allocation for threads, such as reducing the CPU resources occupied by threads.

[0112] The rendering thread identification module described above can be used to identify the rendering thread corresponding to the APP running on the above electronic device 200.

[0113] The aforementioned critical thread identification module can be used to determine critical threads, which may include the rendering thread and threads that have a wake-up relationship with the rendering thread. Furthermore, this critical thread identification module can also be used to determine whether the top M threads in the sorted list are critical threads.

[0114] The libhwui mentioned above can include 2D graphics libraries, such as the Skia graphics library.

[0115] The libEGL mentioned above can include standard graphics libraries, i.e., 3D graphics libraries, such as Vulkan and OpenGL graphics libraries.

[0116] The SurfaceFlinger described above can be used to receive graphics display data, i.e., rendered image data, and combine them to obtain screen data. This screen data can then be sent to the display screen.

[0117] In some embodiments, the native layer may include a hardware abstraction layer. The hardware abstraction layer is an interface layer located between the operating system kernel and the hardware circuitry.

[0118] The kernel layer is the layer between hardware and software. At a minimum, the kernel layer includes display drivers, camera drivers, audio drivers, sensor drivers, CPU frequency decision modules, and thread load statistics modules.

[0119] The thread load statistics module described above can be used to quantify the load of threads.

[0120] The CPU frequency decision module mentioned above can be used to control the CPU to reduce the resource allocation to threads.

[0121] Understandable Figure 3 The layers in the illustrated structure and the components contained in each layer do not constitute a specific limitation on the electronic device 200. In other embodiments of this application, the structure may include more or fewer layers than illustrated, and each layer may include more or fewer components; this application does not impose any limitations.

[0122] This application provides a thread processing method. During the operation of an app, the electronic device can identify the threads with high load and critical threads corresponding to the app. The critical threads include the rendering thread and threads that depend on the rendering thread. These critical threads directly or indirectly affect the application's interface rendering. If a thread with high load is a critical thread, it indicates that the thread with high load is related to interface rendering, and its high load is normal. Therefore, the electronic device can determine that the thread with high load is a normal thread. However, if the thread with high load is not a critical thread, it indicates that the thread with high load may not be related to interface rendering, and it may be abnormal. Therefore, the electronic device can further determine whether the thread with high load is an abnormal thread, achieving accurate identification of abnormal threads. Furthermore, after identifying an abnormal thread, the electronic device can stop running the abnormal thread, thereby reducing CPU resource consumption, reducing the power consumption of the electronic device, and improving user satisfaction.

[0123] The thread processing method provided in this application embodiment will be described in detail below, taking the aforementioned electronic device as a mobile phone as an example, in conjunction with the accompanying drawings. Figure 4 As shown, the method may include steps S301-S311.

[0124] S301. After the first APP is launched, the mobile phone determines the rendering thread corresponding to the first APP.

[0125] The rendering thread can be the thread responsible for rendering the screen of the first app. For example, the rendering thread corresponding to the first app can be determined through the following possible implementation methods:

[0126] In one implementation, the mobile phone can obtain the name of the rendered screen layer and determine the rendering thread based on the name of the screen layer and the correspondence between the screen layer and the thread.

[0127] The image layer in question is a layer included in the image of the first app running on the aforementioned mobile phone. An image can include one or more layers. The mobile phone can obtain the thread number corresponding to the name of the image layer. The thread corresponding to the name of the image layer is the rendering thread of the first app. The name of the image layer can be used to identify the app to which the image layer belongs. The thread number can be used to identify the thread; one thread corresponds to one thread number, and each thread has a corresponding task, such as rendering an image. For example, when a thread performs a rendering task, the mobile phone can record the name of the image layer that the thread is responsible for rendering. Therefore, when the mobile phone obtains the name of the rendered image layer, it can find the corresponding thread through the name of the image layer.

[0128] like Figure 5 As shown, the name of the image layer obtained by the phone is SurfaceView[com.tencent.tmgp.sgame / com.tencent.tmgp.sgame.SGameActivity]#5(BLASTConsumer). Here, com.tencent.tmgp.sgame indicates that this layer belongs to Honor of Kings. TM In this app, the thread ID corresponding to the layer name is Thread-21222550.

[0129] Specifically, the rendering thread corresponding to the mobile app can store the rendered screen data in the queueBuffer of the phone's SurfaceFlinger module. Therefore, the phone can retrieve the rendered screen data (such as the name of the screen layer) from this queueBuffer.

[0130] In another implementation, the rendering thread is determined based on the image layer and how the image layer is displayed on the screen.

[0131] Because mobile phones can display the interfaces of multiple applications simultaneously. For example, a phone can display the interface of Honor of Kings. TMWhile the app is running, the phone can also display a WeChat mini-window. Correspondingly, the phone obtains multiple names for the rendered screen layers. Based on this, for each screen layer, the phone can obtain the corresponding screen display mode, which indicates whether the screen layer is full-screen. Then, the phone can use the thread corresponding to the name of the screen layer with the full-screen display mode as the rendering thread for the first app, thus accurately determining the rendering thread.

[0132] It should be noted that neither of the two implementation methods—determining the rendering thread based on the name of the screen layer and the correspondence between the screen layer and the thread, nor determining the rendering thread based on the screen layer and the screen display method of the screen layer—restricts the type of the first app. In other words, regardless of whether the first app is a game or a non-game app, the phone can determine the rendering thread corresponding to the first app based on either of these two implementation methods.

[0133] In another implementation, the rendering thread is determined based on the number of times a preset drawing command is called and the application type of the app.

[0134] When the app running on the phone is a game, the thread corresponding to that app can call preset drawing instructions when rendering the game screen. The thread that calls the most preset drawing instructions within a first preset time interval from the current time will be the rendering thread corresponding to the first app mentioned above.

[0135] For example, the preset drawing instructions may include drawcall instructions. Specifically, the mobile phone can hook the graphics library interface to determine the thread number of the thread that calls the drawcall instructions of the graphics library within a first preset time period from the current time, and count the number of calls corresponding to each thread number. Then, the mobile phone can use the thread number with the most calls as the thread number of the rendering thread corresponding to the aforementioned first APP.

[0136] In some embodiments, the type of the first app can be determined by the mobile phone when it launches the first app. For example, when a user launches the first app, the mobile phone can match the application package name of the first app with the app types recorded in the cloud to find the type of the first app. For instance, the application package name of the first app might be "Honor of Kings". TM The phone found the King of Glory game from the cloud. TM The type is game. For example, the application package of the first app is named Douyin™, and the phone finds that Douyin™ is a short video type, which is not a game type.

[0137] S302. The mobile phone determines the key threads based on the rendering thread corresponding to the first APP. These key threads include the rendering thread and threads that depend on it.

[0138] Threads that depend on the rendering thread (or are associated with the rendering thread) may directly or indirectly affect the rendering of the first app screen. Dependency can be described as association; that is, dependency and association in this application have the same meaning. For example, dependency can also be described as a wake-up relationship; that is, dependency and wake-up relationship in this application have the same meaning. A wake-up relationship between two threads indicates that one thread is directly or indirectly woken up by the other thread. When a thread is indirectly woken up by another thread, it means that the thread was woken up by that other thread through another thread. For example, if thread A is woken up by thread B, and thread B is woken up by thread C, then thread A is directly woken up by thread B, and thread A is indirectly woken up by thread C.

[0139] Understandably, once a thread is awakened, it begins executing its corresponding task. When one thread needs to invoke another thread, it can first awaken the other thread.

[0140] Optionally, the wake-up relationship can be included in the thread log, the association tree, or the thread scheduling table. The following describes several possible implementation methods for determining the aforementioned critical threads.

[0141] In one implementation, dependencies can be obtained by querying thread logs. For example, the phone can query the thread logs for threads that have dependencies on the rendering thread corresponding to the first app mentioned above. For instance, the phone can determine the wakeup relationship between threads through the wakeup field in the thread logs; this wakeup relationship is actually a direct wakeup. For example, the thread log might include "thread A wakeup by thread B." This thread log entry indicates that thread A was directly woken up by thread B, where thread A and thread B both refer to thread IDs.

[0142] Because the inter-thread calling relationships are complex, all threads corresponding to the app may have wake-up relationships with each other. Therefore, the phone can select N threads that have wake-up relationships with the rendering thread corresponding to the first app, in descending order of their association relationships. N is a positive integer.

[0143] The strength of the association between a thread and the rendering thread can be determined by the number of intermediate threads corresponding to that thread. Intermediate threads enable the thread to establish an association with the rendering thread. It should be understood that if a thread is directly associated with the rendering thread, then that thread has no corresponding intermediate threads, or the number of intermediate threads corresponding to that thread is zero. If the association is indirect, then the thread has corresponding intermediate threads, and the number of these intermediate threads is not zero. For example, the number of intermediate threads corresponding to a thread is inversely proportional to the association between that thread and the rendering thread; for instance, the fewer intermediate threads there are, the stronger the association between that thread and the rendering thread, and vice versa.

[0144] For example, consider a rendering thread being awakened by thread A, and thread A being awakened by thread B. The rendering thread is directly awakened by thread A, but indirectly awakened by thread B. In other words, thread A and the rendering thread are directly related, while thread B is indirectly related to the rendering thread through thread A. Both thread A and thread B are associated with the rendering thread. However, there is no intermediate thread between thread A and the rendering thread, indicating a strong association. Thread B, on the other hand, is associated with the rendering thread through thread A, meaning there is only one intermediate thread, resulting in a weaker association between thread B and the rendering thread.

[0145] In another implementation, dependencies can be obtained by querying an association tree. The phone can generate the association tree corresponding to the rendering thread based on the wake-up relationships between threads, with the rendering thread as the root node. The child nodes of the root node are the threads directly associated with the rendering thread. Then, the phone can select N threads from this association tree in a top-down order and treat these N threads as threads that have dependencies on the rendering thread.

[0146] It should be understood that the greater the correlation between a thread and a rendering thread, the more likely that thread is to affect the rendering of the screen. Therefore, when the mobile phone determines the threads that have a dependency relationship (or wake-up relationship) with the rendering thread corresponding to the first APP, it can select N threads that have a wake-up relationship with the rendering thread corresponding to the first APP in descending order of correlation.

[0147] In another implementation, dependencies can be obtained using a thread scheduling table. For example, the phone can retrieve the thread scheduling table from its cache. This table records wake-up relationships between threads, specifically direct wake-ups. When a thread is woken up, the phone can record which thread directly woke it up. Then, the phone can determine from the thread scheduling table the threads that have dependencies on the rendering thread of the first app. For instance, the phone can select N threads from the thread scheduling table that have wake-up relationships with the rendering thread of the first app, arranged in descending order of dependency.

[0148] In this embodiment, when the first app runs in the foreground of the phone, the rendering thread in the process corresponding to the first app on the phone can render the screen that the app needs to display. Since the screen displayed on the phone is constantly refreshed, the rendering thread needs to continuously perform rendering work, resulting in a relatively high load on the rendering thread. Furthermore, threads that depend on the rendering thread may also directly or indirectly affect screen rendering; therefore, the load on these dependent threads will also be high. To reduce the phone's power consumption due to abnormal threads, the phone can determine the key thread corresponding to the first app, so that it can be used to identify abnormal threads among the threads corresponding to the first app running on the phone. That is, if the thread corresponding to the first app is not a key thread, it indicates that the thread corresponding to the first app may be unrelated to screen rendering, and the thread corresponding to the first app may be an abnormal thread, thus achieving the identification of abnormal threads.

[0149] S303. The mobile phone determines the overloaded threads in the threads corresponding to the first APP. The overloaded threads refer to the top M threads in terms of load, ranked from highest to lowest, in the threads corresponding to the first APP.

[0150] For example, the mobile phone can obtain the load of each thread in the process corresponding to the first APP from the phone's Linux kernel. Then, the phone can sort all the threads corresponding to the process according to the load from largest to smallest, obtaining the sorted threads. The phone can then use the top M threads from this sorted list as the overloaded threads corresponding to the first APP, thus obtaining the threads with the largest load for the first APP. Here, M is a positive integer.

[0151] In some embodiments, the load of the aforementioned thread can be the actual amount of computation consumed by the thread, quantified based on the WALT (Windows-Assist Load Tracing) algorithm. Factors influencing the thread's load include the real-time computing power and runtime of the CPU core on which the thread resides, where runtime represents the time the thread spends running on that CPU core. For example, the real-time computing power is quantized based on the CPU core's frequency. It should be understood that the higher the CPU core's frequency, the greater its real-time computing power. The real-time computing power of a large CPU core is greater than that of a medium CPU core, and the real-time computing power of a medium CPU core is greater than that of a small CPU core. For instance, assuming CPU5 has a frequency of 1.8 GHz and a corresponding computing power of 900, and thread 1 runs on CPU5 for 10 seconds, then the load of thread 1 can be 900 * 10.

[0152] S304. For each of the above overloaded threads, the phone determines whether the overloaded thread is a critical thread.

[0153] In this embodiment, the mobile phone can determine whether each overloaded thread is a critical thread. When an overloaded thread is a critical thread, it indicates that the overloaded thread will affect the screen rendering of the first APP, and the mobile phone can execute S305. When an overloaded thread is not a critical thread, it indicates that the overloaded thread may not affect the rendering of the mobile phone, that is, it indicates that the overloaded thread may be an abnormal thread, and the mobile phone can execute S306 to further determine whether the overloaded thread is an abnormal thread.

[0154] S305. The above-mentioned mobile phone has determined that the overloaded thread is a normal thread.

[0155] For example, when the phone determines that the overloaded thread is a normal thread, the phone can continue to run the overloaded thread normally, such as migrating the overloaded thread from the CPU core where the overloaded thread is currently located to a CPU core with higher performance.

[0156] S306. The above-mentioned mobile phone determines whether the overloaded thread is a self-wake-up thread.

[0157] Here, a self-awakening thread refers to a thread that is not awakened by other threads within a second preset time interval from the current time. In other words, if no other thread with a wake-up relationship with a certain thread is found within the second preset time interval from the current time, then that thread is a self-awakening thread. For example, the second preset time interval can be 1 minute, and the overloaded thread is thread 1. If, within 1 minute from the current time, the phone does not find a thread with a wake-up relationship with thread 1 in the thread log, the association tree, or the thread scheduling table, then the phone can determine that thread 1 is a self-awakening thread.

[0158] In this embodiment, if it is determined that the overloaded thread is not a critical thread, the mobile phone can determine whether the overloaded thread was woken up by another thread within a second preset time from the current time. If it was not woken up by another thread, it indicates that the overloaded thread is a self-wake-up thread. In this case, the mobile phone can consider that the overloaded thread is unrelated to the interface rendering of the first APP. In other words, the mobile phone can determine that the overloaded thread is an unnecessary thread. Therefore, the mobile phone can execute S307. If the overloaded thread was woken up by another thread, it indicates that the overloaded thread is not a self-wake-up thread. In this case, the mobile phone can mark the overloaded thread as a suspected abnormal thread and execute S308 to further determine whether the overloaded thread is an abnormal thread, thereby achieving accurate identification of abnormal threads.

[0159] S307. The phone determines that the overloaded thread is an abnormal thread and stops running the abnormal thread.

[0160] In some embodiments, after determining that the overloaded thread is an abnormal thread, the mobile phone can reduce the resources of the overloaded thread. In other words, the mobile phone can reduce the running resources (such as CPU resources, network resources, storage resources, etc.) occupied by the abnormal thread without stopping the abnormal thread. This can avoid the operation of the first APP being affected by the termination of the abnormal thread, ensuring that the user can use the first APP normally. Furthermore, by reducing the consumption of mobile phone resources by the abnormal thread, the high power consumption and heat generation problems of the mobile phone can be improved.

[0161] For example, the resource reduction operation described above could refer to the phone migrating a thread (such as the abnormal thread mentioned above) from a first CPU core to a target CPU core. The first CPU core represents the CPU core where the thread currently resides, and the target CPU core has a lower frequency than the first CPU core. Alternatively, the resource reduction operation could refer to the phone changing the frequency of the CPU core where the thread resides from a first frequency point to a second frequency point. The first frequency point represents the current frequency of the CPU core, and the second frequency point is lower than the first frequency point.

[0162] S308. The mobile phone performs a resource reduction operation on the overloaded thread. The resource reduction operation is used to indicate a reduction in the running resources occupied by the overloaded thread.

[0163] S309. After performing a resource reduction operation on the aforementioned overloaded thread, the mobile phone determines the first rendering frame rate and the second rendering frame rate of the aforementioned first APP.

[0164] Here, the first rendering frame rate refers to the current rendering frame rate of the phone, and the second rendering frame rate refers to the rendering frame rate of the phone before the resource reduction operation was performed on the aforementioned overloaded thread (here, the overloaded thread actually refers to the suspected abnormal thread). The rendering frame rate represents the rate (or frequency) at which the phone displays the screen of the aforementioned first APP.

[0165] In this embodiment, when the overloaded thread is not a self-wake-up thread, the mobile phone can treat the overloaded thread as a suspected abnormal thread. Then, the mobile phone can perform a resource reduction operation on the suspected abnormal thread to reduce the resource supply to it. It should be understood that after the resources of the suspected abnormal thread are reduced, if the suspected abnormal thread affects the rendering of the first app, the rendering frame rate of the first app will decrease. If the suspected abnormal thread is unrelated to rendering, the rendering frame rate of the first app generally will not change or will change very little. Thus, after performing a resource reduction operation on the suspected abnormal thread, the mobile phone can obtain its current rendering frame rate (or first rendering frame rate) and compare it with the rendering frame rate before the resource reduction operation on the suspected abnormal thread (or second rendering frame rate) to determine whether the suspected abnormal thread affects rendering, thereby determining whether the suspected abnormal thread is an abnormal thread.

[0166] S310. If the difference between the first rendering frame rate and the second rendering frame rate is less than or equal to a preset frame rate difference, the mobile phone determines that the aforementioned reloaded thread is a normal thread. Wherein, the preset frame rate difference is less than 0.

[0167] S311. If the difference between the first rendering frame rate and the second rendering frame rate is greater than the preset frame rate difference, the mobile phone determines that the above-mentioned reload thread is an abnormal thread.

[0168] In this embodiment, the mobile phone can calculate the difference between the first rendering frame rate and the second rendering frame rate. When the difference is less than or equal to a preset frame rate difference, it indicates that the current rendering frame rate has decreased significantly, meaning that the suspected abnormal thread is affecting the screen rendering. Therefore, the mobile phone can determine that the suspected abnormal thread is a normal thread. Furthermore, to ensure normal screen rendering of the first app, the mobile phone can perform resource recovery operations on the suspected abnormal thread to restore resource supply to it.

[0169] If the difference between the first and second rendering frame rates is greater than a preset frame rate difference, it indicates that reducing resource allocation to the suspected abnormal thread has little or no impact on the rendering frame rate of the first app. This means the suspected abnormal thread is unrelated to the rendering of the first app, and therefore, the phone can confirm that the suspected abnormal thread is indeed an abnormal thread. Furthermore, to reduce the abnormal thread's resource consumption, the phone can stop running the abnormal thread, thereby reducing power consumption.

[0170] For example, the resource recovery operation described above corresponds to the resource reduction operation described above. For instance, if the resource reduction operation instructs the migration of a suspected abnormal thread from a first CPU core to a target CPU core, then the resource recovery operation could instruct the migration of the suspected abnormal thread from the target CPU core back to the first CPU core. As another example, if the resource reduction operation instructs the change of the frequency of the CPU core containing the suspected abnormal thread from a first frequency to a second frequency, then the resource recovery operation could instruct the change of the frequency of the CPU core containing the suspected abnormal thread from a second frequency to a first frequency.

[0171] In some embodiments, after determining that a suspected abnormal thread is indeed an abnormal thread, the mobile phone may not stop running the abnormal thread. Since the suspected abnormal thread has already consumed relatively little of the mobile phone's resources, the mobile phone may not perform any operation on the abnormal thread. This reduces resource waste while ensuring the normal operation of the first APP.

[0172] In some embodiments, after determining that the suspected abnormal thread is a normal thread, the mobile phone can stop judging whether the suspected abnormal thread is abnormal for a certain period of time. In other words, the reloaded threads determined by the mobile phone within this period of time may not include the suspected abnormal thread, thereby avoiding repeated thread judgments. After a certain period of time, the mobile phone can continue to judge whether the suspected abnormal thread is abnormal normally, avoiding misjudgment of threads due to frame drops or other reasons.

[0173] In some embodiments, after the first APP is launched, the mobile phone can periodically identify abnormal threads in the thread corresponding to the first APP. Alternatively, after performing an abnormal thread identification once, the mobile phone can re-perform the abnormal thread identification after a third preset time, to avoid misjudgment of threads due to frame drops or other reasons, thereby reducing the power consumption of the mobile phone due to abnormal threads.

[0174] It should be noted that because the thread with a higher load (or heavy-load thread) corresponding to the first app consumes more power, while the threads with a lower load (i.e., threads other than the heavy-load thread corresponding to the first app) consume less power, the phone can determine whether the heavy-load thread corresponding to the first app is an abnormal thread, but not whether the thread with a lower load corresponding to the first app is an abnormal thread. Of course, the phone can also determine whether each thread corresponding to the first app is an abnormal thread; the process of determining whether each thread corresponding to the first app is an abnormal thread is similar to the process of determining whether the heavy-load thread corresponding to the first app is an abnormal thread.

[0175] In this application, during the operation of the first app, the mobile phone can first identify the thread with a high load corresponding to the first app. Then, the mobile phone can further determine whether the thread with a high load is a critical thread. The critical thread includes the rendering thread corresponding to the first app and threads that depend on the rendering thread; that is, the critical thread represents the thread that affects the rendering of the first app's screen. If the thread with a high load is a critical thread, it indicates that the thread affects the rendering of the first app's screen, meaning that the high load on this thread is normal. Therefore, the mobile phone can determine that the thread with a high load is a normal thread.

[0176] If the heavily loaded thread is not a critical thread, it indicates that the thread may be unrelated to screen rendering. The phone can determine whether the heavily loaded thread is a self-wake-up thread to further verify whether it is an abnormal thread. If the heavily loaded thread is a self-wake-up thread, it indicates that the heavily loaded thread is unrelated to screen rendering, and the phone can directly determine that the heavily loaded thread is an abnormal thread. If it is not a self-wake-up thread, it indicates that the heavily loaded thread may be related to screen rendering, and the phone can reduce the resource allocation to the heavily loaded thread and, based on the rendering frame rate before and after the resource allocation reduction, determine whether the heavily loaded thread affects the phone's screen rendering.

[0177] If the rendering frame rate decreases significantly after the resource supply reduction compared to before the reduction, it indicates that the heavily loaded thread is affecting image rendering. In this case, the phone can determine that the heavily loaded thread is a normal thread, and the phone can restore resource supply to the heavily loaded thread to ensure normal rendering of the first app. If the rendering frame rate does not change or changes only slightly after the resource supply reduction, it indicates that the heavily loaded thread has little impact on image rendering. In this case, the phone can determine that the heavily loaded thread is an abnormal thread, thus achieving accurate identification of abnormal threads.

[0178] In some embodiments, after executing S304 above, if the overloaded thread is a critical thread, the mobile phone can determine that the overloaded thread is a normal thread. If the overloaded thread is not a critical thread, the mobile phone can directly determine that the overloaded thread is an abnormal thread without needing to use other conditions (such as whether the overloaded thread is a self-wake-up thread) to determine whether the overloaded thread is an abnormal thread. That is, if the mobile phone determines that the thread corresponding to the first APP meets the first preset condition, the mobile phone can determine that the thread is an abnormal thread; otherwise, the mobile phone can determine that the thread can be a normal thread. The first preset condition may include that the thread is an overloaded thread and that the thread is not a critical thread.

[0179] In some embodiments, after executing S304 above, if the reloaded thread is a critical thread, the phone can determine that the reloaded thread is a normal thread. If the reloaded thread is not a critical thread, the phone can directly perform a resource reduction operation on the reloaded thread. After performing the resource reduction operation, the phone determines the first rendering frame rate and the second rendering frame rate of the first APP, so that the phone can use the difference between the first rendering frame rate and the second rendering frame rate to determine whether the reloaded thread is an abnormal thread. That is, if the thread corresponding to the first APP meets the first preset condition, the phone can determine that the thread is an abnormal thread; otherwise, the phone can determine that the thread can be a normal thread. The first preset condition may include that the thread is a reloaded thread, the thread is not a critical thread, and the difference between the first rendering frame rate and the second rendering frame rate is greater than a preset frame rate difference.

[0180] It should be understood that when the phone determines a thread, it is actually determining the thread ID of that thread. For example, when determining the rendering thread corresponding to the first app, the phone determines the thread ID of that rendering thread. Similarly, when determining the overloaded thread corresponding to the first app, the phone determines the thread ID of that overloaded thread. Furthermore, when determining a thread that depends on the rendering thread corresponding to the first app, the phone also determines the thread ID of that dependent thread.

[0181] This application provides a thread handling method. After the first app is launched on the mobile phone, that is, during the operation of the first app, the mobile phone can determine whether the thread corresponding to the app is a thread affecting screen rendering based on the threads that affect screen rendering (such as the rendering thread corresponding to the first app and threads that have a wake-up relationship with the rendering thread), thus identifying abnormal threads. Furthermore, after identifying an abnormal thread, the mobile phone can terminate the execution of the abnormal thread or reduce the runtime resources (such as CPU resources) occupied by the abnormal thread, thereby reducing unnecessary consumption of mobile phone resources by threads, and consequently reducing the phone's power consumption. The following will combine the above... Figure 3The software structure shown illustrates a possible thread processing procedure. For example, such as... Figure 6 As shown, the thread processing procedure may include the following steps.

[0182] First, when a user launches the first app from the phone's home screen, the app type identification module on the phone can perform step a: determine the type of the first app and send the type of the first app to the rendering thread identification module on the phone. This type indicates whether the first app is a game app.

[0183] For example, the application type identification module can match the application package name of the first APP with the APP type recorded in the cloud to find the type of the first APP.

[0184] Of course, the application type identification module described above, which determines the type of the first app based on cloud records, is only one example. This module can also use other methods to determine the type of the first app, such as determining the type based on the layer type of the first app's screen. This application does not limit the method used to determine the type of the first app.

[0185] During the operation of the first app on the aforementioned mobile phone, the phone needs to render the app's screen. It should be understood that the rendering process (or drawing process) differs between game apps and non-game apps. When the first app is a game, after obtaining its image data, libEGL on the phone can execute step b, using the GPU to render the image data of the first app, and then send the rendered image data to the SurfaceFlinger module on the phone. Here, the image data of the first app can be understood as the image data displayed on the screen of the first app.

[0186] When the first APP is a non-game type, after obtaining the image data of the first APP, libwui in the phone can execute step c, render the image data of the first APP, and send the rendered image data to the SurfaceFlinger module in the phone.

[0187] Then, the SurfaceFlinger module can perform step d: synthesize the rendered image data to obtain screen data, and send the screen data to the phone's display screen to display the corresponding screen.

[0188] During the rendering of the first APP's screen, the SurfaceFlinger module can perform step e, sending first information to the rendering thread identification module, so that the rendering thread identification module can use the first information to identify the thread number of the rendering thread corresponding to the first APP.

[0189] After receiving the first information, the rendering thread identification module can execute step f, use the first information to determine the thread number of the rendering thread corresponding to the first APP, and send the thread number of the rendering thread to the key thread identification module in the mobile phone.

[0190] For example, in one scenario, when the first app is a game, the rendering thread identification module can determine the rendering thread based on the number of times a preset drawing instruction is called and the app's application type. Accordingly, the first information can include the thread number of each thread calling the preset drawing instruction and the number of times each thread number is called. Then, the rendering thread identification module can use the thread number with the most calls as the thread number of the rendering thread corresponding to the first app.

[0191] In another scenario, the rendering thread identification module can determine the rendering thread based on the name of the rendered image layer and the correspondence between image layers and threads. Accordingly, the first information mentioned above may include the name of the currently rendered image layer.

[0192] In another scenario, the rendering thread identification module can determine the rendering thread based on the image layer and its screen display method. Accordingly, the first information may include the name of the currently rendered image layer and its screen display method.

[0193] Furthermore, during the operation of the aforementioned first APP, the CPU load calculation module in the phone can execute step g, sending a load query request to the thread load statistics module in the phone. This load query request may include the application package name of the first APP, which can be used to obtain the load of each thread in the process corresponding to the first APP.

[0194] After receiving the load query request, the thread load statistics module can execute step h and, in response to the load query request, return to the CPU load calculation module the thread number corresponding to the application package name of the first APP and the load corresponding to each thread number.

[0195] After receiving the load corresponding to each thread number, the CPU load calculation module can execute step i, sort the thread numbers in descending order of load, and send the sorted thread numbers to the key thread identification module in the mobile phone.

[0196] Subsequently, the aforementioned critical thread identification module can execute step j, selecting the top M thread numbers from the sorted thread numbers and using them as the thread numbers of the overloaded threads. For each overloaded thread's thread number, if the overloaded thread's thread number does not belong to the critical thread's thread number, then the overloaded thread's thread number is sent to the abnormal thread identification module in the aforementioned mobile phone.

[0197] Among them, the aforementioned key threads include the rendering thread corresponding to the first APP and the threads that have a wake-up relationship with the rendering thread.

[0198] Subsequently, after receiving the thread number of the overloaded thread from the critical thread identification module, the abnormal thread identification module indicates that it needs to verify whether the overloaded thread is an abnormal thread. The abnormal thread identification module can then execute step k, determine whether the overloaded thread is a self-wake-up thread, and obtain the thread number and its corresponding determination result. If the determination result for the thread number indicates that the overloaded thread corresponding to that thread number is not a self-wake-up thread, the module sends the thread number and its corresponding determination result to the CPU frequency control module in the mobile phone.

[0199] In some embodiments, if the judgment result corresponding to the thread number indicates that the overloaded thread corresponding to that thread number is a self-wake-up thread, it means that the overloaded thread corresponding to that thread number is unlikely to affect the screen rendering. Therefore, the abnormal thread identification module can directly determine that the overloaded thread corresponding to the thread number is an abnormal thread.

[0200] In some embodiments, the abnormal thread identification module can also directly send the thread number and its corresponding judgment result to the CPU frequency control module, without having to send it only when the judgment result corresponding to the thread number indicates that the overloaded thread corresponding to the thread number is not a self-wake-up thread.

[0201] After receiving the thread number and its corresponding judgment result, the CPU frequency control module can execute step 1: when the judgment result corresponding to the thread number indicates that the overloaded thread corresponding to the thread number is not a self-wake-up thread, send a resource reduction request to the CPU frequency decision module in the mobile phone. The resource reduction request may include the thread number, which is used to trigger a resource reduction operation for the thread corresponding to the thread number.

[0202] Subsequently, upon receiving the aforementioned resource reduction request, the CPU frequency decision module can control the CPU to perform resource reduction operations on the thread corresponding to the thread number in the resource reduction request.

[0203] The frame rate detection module in the aforementioned mobile phone can execute step m, monitor the rendering frame rate corresponding to the first APP, and send the monitored rendering frame rate to the CPU frequency control module. For example, since the SurfaceFlinger module records the synthesis time of each frame when compositing, the frame rate detection module can, when calculating the rendering frame rate, count the number of frames synthesized within a preset duration based on the synthesis time of each frame, and calculate the ratio of that number of frames to the preset duration to obtain the rendering frame rate. For example, if 10 frames are synthesized within 5 seconds, that is, 10 frames are rendered, then the rendering frame rate can be 2 frames / s.

[0204] Subsequently, after sending a resource reduction request, the CPU frequency control module can determine the first and second rendering frame rates from the rendering frame rates sent by the frame rate detection module. The first rendering frame rate represents the rendering frame rate after the resource reduction operation is performed on the thread corresponding to the aforementioned thread number, and the second rendering frame rate represents the rendering frame rate before the resource reduction operation is performed on the thread corresponding to the aforementioned thread number. In other words, the second rendering frame rate can represent the rendering frame rate before the CPU frequency control module sends the resource reduction request, and the first rendering frame rate can represent the rendering frame rate of the CPU frequency control module at a certain time after sending the resource reduction request, such as the rendering frame rate at the 2nd second after sending the resource reduction request.

[0205] After obtaining the first and second rendering frame rates, the CPU frequency control module can execute step n, calculating the difference between the first and second rendering frame rates. If this difference is less than or equal to a preset frame rate difference, the thread corresponding to the aforementioned thread number is determined to be a normal thread, and a resource recovery request is sent to the CPU frequency decision module. The preset frame rate difference is less than 0. This resource recovery request is used to trigger the restoration of the running resources (such as CPU resources) of the thread corresponding to that thread number.

[0206] Subsequently, upon receiving the aforementioned resource recovery request, the CPU frequency decision module can control the CPU to perform resource recovery operations on the thread corresponding to the thread number in the resource recovery request.

[0207] In some embodiments, if the difference is greater than the preset frame rate difference, it indicates that the rendering frame rate of the first APP is not affected or is only slightly affected. In other words, the thread corresponding to the thread number has little impact on the screen rendering, and the mobile phone can still render the screen of the first APP normally. Therefore, the CPU frequency control module determines that the thread corresponding to the thread number is an abnormal thread.

[0208] In some embodiments, when it is determined that the thread corresponding to the above thread number is a normal thread, the mobile phone can restart the identification of abnormal threads after a period of time. During this period of time, the mobile phone can refrain from identifying abnormal threads to avoid repeated thread identification and to avoid misjudgment due to frame drops, thus ensuring the accuracy of abnormal thread identification.

[0209] It is understandable that the above Figure 6 The modules shown in the dashed box, such as the application type identification module, rendering thread identification module, critical thread identification module, abnormal thread identification module, frame rate detection module, CPU load calculation module, and CPU frequency control module, are new modules added in this application, while the remaining modules or devices are native modules or devices.

[0210] In some embodiments, this application provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the interface display method described above.

[0211] In some embodiments, this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the interface display method described above.

[0212] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0213] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0214] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0215] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0216] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0217] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A thread processing method, characterized in that, Applied to electronic devices, the method includes: Receive the user's first action; In response to the first operation, the first application APP is launched; Run the first app; During the operation of the first APP, the electronic device stops running abnormal threads, or reduces the operating resources occupied by the abnormal threads; wherein, the abnormal thread refers to a thread among the threads corresponding to the first APP that meets a first preset condition; the first preset condition includes that the thread is not a critical thread, and that the thread belongs to the top M threads in terms of load from largest to smallest among the threads corresponding to the first APP; M is a positive integer, and the critical threads include the rendering thread corresponding to the first APP and threads that have a dependency relationship with the rendering thread; Specifically, when the first app is a game app, the screen of the first app is rendered through a first rendering process during the operation of the first app; when the first app is a non-game app, the screen of the first app is rendered through a second rendering process during the operation of the first app, and the first rendering process and the second rendering process are different.

2. The method according to claim 1, characterized in that, The first preset condition also includes that the thread is a self-wake-up thread; the wake-up time of the self-wake-up thread is before the current time and is more than a preset time away from the current time.

3. The method according to claim 1, characterized in that, The first preset condition also includes that the difference between the first rendering frame rate and the second rendering frame rate is greater than a preset frame rate difference. Wherein, the first rendering frame rate is the rendering frame rate after reducing the running resources occupied by the thread, and the second rendering frame rate is the rendering frame rate before reducing the running resources occupied by the thread.

4. The method according to claim 1, characterized in that, The first preset condition also includes, when the thread is not a self-wake-up thread, the difference between the first rendering frame rate and the second rendering frame rate is greater than a preset frame rate difference. Wherein, the first rendering frame rate represents the rendering frame rate after reducing the running resources occupied by the thread, and the second rendering frame rate represents the rendering frame rate before reducing the running resources occupied by the thread.

5. The method according to any one of claims 1 to 4, characterized in that, The electronic device includes multiple central processing unit (CPU) cores; The reduction of runtime resources occupied by the abnormal thread includes at least one of the following: The abnormal thread is migrated from the first CPU core to the target CPU core, the frequency of the target CPU core being lower than that of the first CPU core; the first CPU core and the target CPU core are each one of the plurality of CPU cores. Change the frequency of the CPU core where the abnormal thread resides from the first frequency to the second frequency, where the second frequency is lower than the first frequency.

6. The method according to claim 1, characterized in that, The dependency relationship indicates a wake-up relationship; the method further includes: The electronic device determines the wake-up relationship between the threads running on the electronic device based on a preset wake-up field in the electronic device's log. The electronic device determines the threads that have a dependency relationship with the rendering thread based on the wake-up relationship between the threads.

7. The method according to any one of claims 1 to 4, characterized in that, The method further includes: When the first APP is a game, the electronic device will use the thread that calls the preset drawing instructions the most times in the thread corresponding to the first APP as the rendering thread corresponding to the first APP.

8. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The electronic device obtains the name of the rendered screen layer and uses the thread corresponding to the name of the screen layer as the rendering thread corresponding to the first APP.

9. The method according to any one of claims 1 to 4, characterized in that, The rendering of the first app's screen through a first rendering process during the operation of the first app includes: After obtaining the image data of the first APP, libEGL in the electronic device uses the GPU to render the image data of the first APP and sends the rendered image data to the SurfaceFlinger module in the electronic device.

10. The method according to any one of claims 1 to 4, characterized in that, The rendering of the first app's screen through a second rendering process during the operation of the first app includes: After obtaining the image data of the first APP, libwui in the electronic device renders the image data of the first APP and sends the rendered image data to the SurfaceFlinger module in the electronic device.

11. An electronic device, characterized in that, The electronic device includes an abnormal thread identification module and a CPU frequency control module; The abnormal thread identification module is used to identify abnormal threads among the threads corresponding to the first APP during the operation of the first APP on the electronic device; wherein, the abnormal thread refers to a thread among the threads corresponding to the first APP that meets a first preset condition; the first preset condition includes that the thread is not a critical thread and that the thread belongs to the top M threads in terms of load from largest to smallest among the threads corresponding to the first APP; where M is a positive integer; the critical threads include the rendering thread corresponding to the first APP and threads that have a dependency relationship with the rendering thread; The CPU frequency control module is used to stop the execution of the abnormal thread identified by the abnormal thread identification module, or to reduce the running resources occupied by the abnormal thread. Specifically, when the first app is a game app, the screen of the first app is rendered through a first rendering process during the operation of the first app; when the first app is a non-game app, the screen of the first app is rendered through a second rendering process during the operation of the first app, and the first rendering process and the second rendering process are different.

12. An electronic device, characterized in that, The electronic device includes a display screen, a memory, and one or more processors; the display screen, the memory, and the processors are coupled; the display screen is used to display an image generated by the processor, the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the electronic device performs the thread processing method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the thread processing method as described in any one of claims 1 to 10.

Images