Resource adjustment method and electronic device

Abstract

This application provides a resource adjustment method and an electronic device, relating to the field of terminal technology. During the operation of a game application, the electronic device uses the current frame interval to determine whether the game application's frame output is abnormal. Abnormal frame output indicates a frame drop problem, meaning the core thread of the electronic device is running abnormally. The electronic device can further determine whether there is a target auxiliary thread that interacts with the core thread (e.g., blocking or waking). If so, it indicates that the core thread may be blocked by the target auxiliary thread. Therefore, the electronic device can allocate more resources to the target auxiliary thread to improve its running speed, thereby enabling the auxiliary thread to interact with the core thread as quickly as possible, such as refreshing the semaphores required by the core thread or waking it up. This allows the core thread to run frame output normally as quickly as possible, shortening the time of screen stuttering in the game application, ensuring smooth operation of the game application, and providing a high-quality user experience.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a resource adjustment method and an electronic device. Background Technology

[0002] The threads of applications (APPs) installed on electronic devices can be mainly divided into core threads and auxiliary threads. Core threads are primarily responsible for logic processing and frame rendering, ensuring smooth application display. Auxiliary threads are used for resource reclamation, device status monitoring, system status monitoring, etc.

[0003] However, during the operation of an app on an electronic device, the app's core thread may fail to output frames normally, causing the application screen to lag and affecting the user experience. Summary of the Invention

[0004] This application provides a resource adjustment method and electronic device to increase the resources occupied by auxiliary threads, thereby avoiding the auxiliary threads from blocking the operation of core threads and thus avoiding application screen display lag.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] Firstly, this application provides a resource adjustment method applied to an electronic device. During the foreground operation of a first application on the electronic device, if the current frame interval of the first application is greater than or equal to a preset time threshold, the electronic device can increase the resources occupied by the target auxiliary thread of the first application.

[0007] The core thread mentioned above is used to generate the screen of the first application. The auxiliary thread refers to the thread of the first application other than the core thread. The generation of the screen of the first application depends on the target auxiliary thread to complete the target operation.

[0008] In this application, if the current frame interval of the first application is greater than or equal to a preset time threshold while the first application is running in the foreground, it indicates that frame dropping has occurred, meaning that the core thread of the first application has a long frame output interval. Since the target auxiliary thread must complete its target operation before the core thread can generate the corresponding screen and achieve frame output, the electronic device can increase the resources used by the target auxiliary thread to improve its running speed. This allows the target auxiliary thread to execute the target operation as quickly as possible, thereby enabling the core thread to output frames more quickly, shortening the screen lag time of the first application, ensuring the smoothness of the first application's display, and improving the user experience.

[0009] Optionally, if the current frame interval of the first application is less than a preset time threshold, it indicates that the frame output is normal and there is no problem with the display of the first application. In other words, the core thread of the first application is running normally. Therefore, the electronic device does not need to adjust the resources occupied by the target auxiliary thread.

[0010] In one possible design approach, when the core thread is in the running state, the target auxiliary thread includes either an auxiliary thread currently in the running state for a duration greater than a first duration, or an auxiliary thread currently in the runnable state for a duration greater than a second duration. Based on this, if an auxiliary thread is currently in the running state and its running duration is greater than the first duration while the core thread is running for a long time, it indicates that the auxiliary thread has also been running for a long time. Since auxiliary threads typically have a shorter running duration, this suggests that the auxiliary thread may be malfunctioning. The long-running core thread may be due to this auxiliary thread malfunction, resulting in the target operation not being executed for an extended period. Therefore, the electronic device can use this auxiliary thread as the target auxiliary thread.

[0011] Similarly, if an auxiliary thread remains in a runnable state for an extended period, it may be running abnormally. The core thread may be running for an extended period due to the auxiliary thread's abnormal operation, resulting in the failure to execute the target operation for a long time. In this case, the electronic device can use the auxiliary thread as the target auxiliary thread.

[0012] In one possible design approach, when the core thread is in a dormant state, the target auxiliary thread includes either an auxiliary thread that is currently running and has a running duration of more than a third duration, or an auxiliary thread that is currently runnable and has a runnable duration of more than a fourth duration.

[0013] Based on this, if an auxiliary thread remains in the running or running state for an extended period, it indicates that the auxiliary thread may be malfunctioning. The core thread's prolonged inactivity may be due to the auxiliary thread's malfunction, resulting in the failure to execute the target operation (such as a wake-up operation) for an extended period. Thus, the electronic device can use this auxiliary thread as the target auxiliary thread.

[0014] In one possible design approach, where the target auxiliary thread includes an auxiliary thread that is running for a duration longer than a first duration, the resource consumption of the target auxiliary thread for improving the first application includes one or more of the following operations:

[0015] The target auxiliary thread is migrated to the first kernel; wherein the frequency of the first kernel is higher than the frequency of the kernel where the target auxiliary thread was located before the migration.

[0016] Raise the priority of the target auxiliary thread to the first priority;

[0017] The target auxiliary thread is migrated to the second kernel; the load of the second kernel is less than the load of the kernel where the target auxiliary thread was located before the migration.

[0018] Based on this, electronic devices can increase the resources used by the target auxiliary thread by migrating it to a kernel with a higher frequency, increasing its priority, or migrating it to a kernel with a lower load, so that the target auxiliary thread can run normally as soon as possible and thus execute the target operation on which the core thread depends as soon as possible.

[0019] Optionally, the second kernel can belong to the same group as the kernel of the target auxiliary thread before migration, that is, of the same type. Alternatively, the two can belong to different groups, with the frequency of the second kernel being higher than that of the kernel of the target auxiliary thread before migration.

[0020] In one possible design approach, if the current frame interval of the first application is greater than or equal to a preset time threshold, and if the core thread of the first application is in a running state, the electronic device can first determine whether the resources currently occupied by the core thread meet a first condition. The first condition indicates that the resources occupied by the core thread are greater than or equal to a resource threshold.

[0021] If the first condition is not met, it indicates that the core thread is currently consuming too few resources. The core thread's malfunction may be due to insufficient resource usage. Therefore, electronic devices can increase the resources consumed by the core thread, allowing it to recover quickly and output frames faster, thus preventing prolonged screen stuttering. Furthermore, this allows for precise identification of the cause of the core thread malfunction, enabling targeted actions based on the identified cause.

[0022] If the first condition is met, it indicates that the resources currently occupied by the core thread are sufficient to meet its operational needs. Therefore, the core thread's abnormal operation is not due to insufficient resource usage, but rather is more likely due to being blocked by an auxiliary thread. Thus, the electronic device can identify the target auxiliary thread blocking the core thread. Subsequently, the electronic device can increase the resources occupied by this target auxiliary thread, enabling it to execute its target operation as quickly as possible and stop blocking the core thread.

[0023] In one possible design approach, the first condition mentioned above includes one or more of the following conditions:

[0024] The kernel where the core thread resides belongs to the third kernel, and the frequency of the third kernel is greater than or equal to the preset frequency.

[0025] The kernel frequency at which a core thread operates is equal to the highest frequency of that kernel.

[0026] The kernel load on which the core thread resides is lower than the preset load.

[0027] The priority of core threads is greater than or equal to that of the second priority.

[0028] Optionally, the aforementioned highest frequency point represents the maximum frequency point that the core is allowed to reach in the current state of the electronic device. The current state may include the temperature of the electronic device.

[0029] In one possible design, the aforementioned core thread is also used to execute the business logic of the first application. The core thread may include a rendering thread and a logic thread. The rendering thread and the logic thread are separate threads. The logic thread executes the business logic of the first application, while the rendering thread generates the visuals of the first application. The logic thread wakes up the rendering thread to generate the visuals, and this wake-up process depends on the target auxiliary thread performing the target operation.

[0030] The above logical thread refers to the thread in the first application that meets the second condition, wherein the second condition includes the frequency at which the thread wakes up the rendering thread within the first time period is greater than or equal to a preset threshold, or the duration of the thread in the running state within the first time period is longer than the duration of the rendering thread in the running state.

[0031] Based on this, the operation of the logical thread waking up the rendering thread depends on the target auxiliary thread completing the target operation; that is, the target auxiliary thread can block the execution of the logical thread. Therefore, the electronic device can determine the logical thread of the first application based on the second condition, and then use the state of the logical thread to determine the target auxiliary thread that has a dependency (or interaction) relationship with the logical thread.

[0032] In one possible design approach, the second condition also includes that the frequency with which the thread wakes up the rendering thread is greater than the frequency with which other threads of the first application wake up the rendering thread. Generally speaking, the logic thread wakes up the rendering thread the most frequently. Therefore, the electronic device can use the highest frequency of the thread waking up the rendering thread as a condition for determining the logic thread, thereby achieving accurate determination of the logic thread.

[0033] In one possible design approach, if no thread satisfies the second condition, the electronic device can determine that the logic thread and the rendering thread are the same thread.

[0034] In one possible design approach, a preset time threshold is greater than or equal to the product of the standard frame interval of the first application and a preset number of dropped frames. Optionally, the preset number of dropped frames can be greater than 1. Considering that various factors can cause the first application to lose a small number of frames, when the number of dropped frames is small, such as a single frame, the electronic device can initially refrain from increasing the resources occupied by the auxiliary thread, thereby reducing unnecessary resource adjustment operations.

[0035] In one possible design approach, the aforementioned target auxiliary thread represents an auxiliary thread that interacts with the core thread. This interaction can include a blocking relationship or a waking relationship. When the target auxiliary thread has a waking relationship with the core thread, it indicates that the target auxiliary thread is used to wake up the core thread. Accordingly, the aforementioned target operation includes a waking operation.

[0036] When a blocking relationship exists between the target auxiliary thread and the core thread, it indicates that the target auxiliary thread will block the execution of the core thread. Accordingly, the aforementioned target operation processes the data (or information) used by the core thread.

[0037] Secondly, 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 resource adjustment method as described above.

[0038] Thirdly, this application provides a chip, the chip including a communication interface and at least one processor:

[0039] The communication interface is used for inputting and / or outputting signaling or data;

[0040] The at least one processor is configured to execute a computer program to implement the resource adjustment method described above.

[0041] Fourthly, this application provides a computer-readable storage medium including a computer program that, when run on an electronic device, causes the electronic device to perform the resource adjustment method described above.

[0042] Fifthly, this application provides a computer program product, which, when executed by a processor, implements the resource adjustment method described above.

[0043] It is understood that the beneficial effects achieved by the electronic device described in the second aspect, the chip described in the third aspect, 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, which will not be repeated here. Attached Figure Description

[0044] Figure 1 A schematic diagram of a screen display scene provided in an embodiment of this application;

[0045] Figure 2 This application provides a schematic diagram of thread frame output in an embodiment. Figure 1 ;

[0046] Figure 3 This application provides a schematic diagram of thread frame output in an embodiment. Figure 2 ;

[0047] Figure 4 This application provides a schematic diagram of thread frame output in an embodiment. Figure 3 ;

[0048] Figure 5 This application provides a schematic diagram of thread frame output in an embodiment. Figure 4 ;

[0049] Figure 6 A schematic diagram of the hardware structure of an electronic device provided in this application embodiment. Figure 1 ;

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

[0051] Figure 8 A flowchart illustrating a resource adjustment method provided in this application embodiment. Figure 1 ;

[0052] Figure 9 A schematic diagram of a sliding frame window provided in an embodiment of this application;

[0053] Figure 10 This application provides a schematic diagram of thread frame output in an embodiment. Figure 5 ;

[0054] Figure 11 This application provides a schematic diagram of thread frame output in an embodiment. Figure 6 ;

[0055] Figure 12 This application provides a schematic diagram of thread frame output in an embodiment. Figure 7 ;

[0056] Figure 13This application provides a schematic diagram of thread frame output in an embodiment. Figure 8 ;

[0057] Figure 14 A flowchart illustrating a resource adjustment method provided in this application embodiment. Figure 2 ;

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

[0059] Figure 16 This is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0060] To facilitate a clear description of the technical solutions in the embodiments of this application, the terms "exemplary" or "for example" are used in the embodiments of this application to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present related concepts in a specific manner. In the embodiments of this application, "at least one" refers to one or more, and "more" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple. In the embodiments of this application, "first," "second," "1," and "2" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, features defined with "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "multiple" means two or more.

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

[0062] 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.

[0063] 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.

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

[0065] The number of cores, also known as the number of processing units, refers to the number of processing units in a central processing unit (CPU). For example, a core count of 8 means that the CPU has 8 independent processing units. The CPU's core groups (or groups of cores) can include at least small cores and large cores. Small cores are cores with lower clock speeds, while large cores are cores with higher clock speeds. Of course, CPU core groups can also include other groups, such as medium cores and super-large cores. This application does not impose any restrictions on the type of CPU cores.

[0066] With the development of electronic devices (such as mobile phones), the number and types of applications that can be installed on these devices are increasing. Some applications (such as games) primarily divide their threads into core threads and auxiliary threads based on function. Core threads are mainly responsible for logic processing and rendering frames (such as…). Figure 1 The game screen shown in image 10) ensures smooth application display. Optionally, the core thread may include a logic thread and a rendering thread. The logic thread is responsible for executing logic tasks, such as the logic thread of a game application, which is responsible for executing game logic, including processing user input, executing game scripts, and updating physics and animations. The rendering thread is responsible for rendering frames at certain time intervals. The logic thread and rendering thread can be independent threads; that is, during application operation, the electronic device runs both a logic thread and a rendering thread. Alternatively, the logic thread and rendering thread can be the same thread, responsible for both executing logic tasks and rendering frames.

[0067] Auxiliary threads are used for resource reclamation, device status monitoring, and system status monitoring. Device status can include the unfolded or folded state of the electronic device's display, and the status of the electronic device's Bluetooth function. System status can include the electronic device's battery level and load.

[0068] Due to the application's own code logic design, there may be interactions (such as blocking or waking relationships) between the application's auxiliary threads and core threads. This can lead to core threads becoming blocked if the electronic device fails to schedule auxiliary threads in a timely manner, potentially resulting in delayed frame rendering, frame drops, and stuttering, thus degrading the user experience. It should be understood that when the core thread includes independent logic threads and rendering threads, the failure to schedule auxiliary threads in a timely manner may cause the logic threads to become blocked, further impacting the rendering threads and preventing them from rendering frames promptly.

[0069] Taking the blocking relationship between the auxiliary thread and the core thread as an example, since the auxiliary thread and the core thread need to synchronize information 1 (such as semaphores, status bits, etc.), this information 1 is refreshed by the auxiliary thread. The core thread needs to wait for the refresh before processing using the refreshed information 1. Accordingly, the situations in which the operation of the auxiliary thread causes the core thread to be blocked can mainly include the following two cases:

[0070] One scenario is that the auxiliary thread runs for an extended period, causing the core thread to be blocked. For example, if the auxiliary thread runs for a long time without updating information 1 in a timely manner, the core thread needs to repeatedly query information 1 until it obtains the updated information 1, resulting in the core thread running for a long time and eventually becoming blocked.

[0071] Taking the above information 1 as an example, where the core thread needs to periodically obtain the device status, such as... Figure 2 As shown, after three frames are output, when the core thread re-enters the running state, it needs to obtain the device state, which is refreshed by the auxiliary thread. Due to factors such as the auxiliary thread running on a small core, it remains in the running state for an extended period, unable to refresh the device state in a timely manner. During this period, the core thread continuously retrieves and waits for the device state, resulting in the core thread remaining in the running state for an extended time. After the auxiliary thread refreshes the device state, the core thread can use the refreshed state for logic processing and frame output. However, because the auxiliary thread blocks the core thread, the interval between the third and fourth frames is relatively long, leading to frame drops in the electronic device.

[0072] Another scenario is that an auxiliary thread remaining in a runnable state for an extended period can block the core thread. For example, if an auxiliary thread remains inactive for a long time and fails to update information 1 in a timely manner, the core thread needs to repeatedly query information 1 until it receives the updated information, causing the core thread to wait for an extended period and ultimately resulting in core thread blocking. Specifically, such as... Figure 3As shown, due to factors such as the high load on the CPU core where the auxiliary thread resides, the auxiliary thread remains in the runnable state for an extended period, unable to refresh information in a timely manner, causing the core thread to remain in the running state for an extended period. Subsequently, the auxiliary thread enters the running state and refreshes information 1. Upon receiving the refreshed information 1, the core thread can use it for logical processing and frame output. However, because the auxiliary thread blocks the core thread, the interval between the third and fourth frames is prolonged, causing frame drops in the electronic device.

[0073] It should be noted that the synchronization information required between the auxiliary thread and the core thread described above is only an example of the blocking relationship between the auxiliary thread and the core thread. This blocking relationship can also be of other types, such as the auxiliary thread and the core thread sharing a lock (e.g., a mutex lock). This application does not impose any restrictions on the specific blocking relationship.

[0074] Next, taking the interaction between the auxiliary thread and the core thread as a wake-up relationship as an example, after the auxiliary thread finishes running, it wakes up the core thread, causing the core thread to enter the running state. Correspondingly, the situations where the execution of the auxiliary thread causes the core thread to be blocked can mainly include the following two cases:

[0075] One scenario is that a secondary thread remains running for an extended period, preventing the core thread from being woken up in a timely manner. For example, a secondary thread runs for a long time. After finishing, the secondary thread tries to wake up the core thread, causing the core thread to become blocked. Specifically, such as... Figure 4 As shown, due to factors such as the auxiliary thread running on a small core, the auxiliary thread remains in the running state for an extended period. After the auxiliary thread finishes running, it wakes up the core thread, which then enters the running state to perform logic processing and frame output. However, because the auxiliary thread fails to wake up the core thread in a timely manner, the interval between the third and fourth frames is too long, causing frame drops in the electronic device.

[0076] In another scenario, a secondary thread remaining in a runnable state for an extended period prevents the core thread from being woken up in a timely manner. For example, a secondary thread might remain in a runnable state for an extended period, causing the core thread to remain inactive for a long time. Later, the secondary thread enters a running state, and upon completion, tries to wake up the core thread, resulting in the core thread becoming blocked. Specifically, as shown... Figure 5As shown, due to factors such as high CPU core load, the auxiliary thread remained in the runnable state for an extended period before entering the running state. After completion, the auxiliary thread woke up the core thread, which then entered the running state to perform logic processing and frame output. However, because the auxiliary thread failed to wake up the core thread in a timely manner, the interval between the third and fourth frames was prolonged, causing frame drops in the electronic device.

[0077] Therefore, to address the aforementioned issues, this application proposes a scheme for dynamic scheduling of auxiliary threads. When the core thread of an application is running for an extended period or has been idle for a long time, the electronic device determines the application's auxiliary threads. If a target auxiliary thread 1, located on a small core, is in a running state for an extended period, it is presumed that there may be an interaction between the target auxiliary thread 1 and the core thread, and the operation of the target auxiliary thread 1 affects the operation of the core thread. In this case, the electronic device can migrate the target auxiliary thread 1 to a large core to improve its execution speed, reduce the duration of core thread blocking, and allow the core thread to output frames quickly, avoiding prolonged screen stuttering and ensuring smooth application operation. Alternatively, after migrating the target auxiliary thread 1 to a large core, if the core thread starts or stops running immediately after the target auxiliary thread 1 finishes running, indicating an interaction between the target auxiliary thread 1 and the core thread, the electronic device can bind the target auxiliary thread 1 to a large core to prevent subsequent blocking of the core thread by the target auxiliary thread, thus improving application smoothness.

[0078] If a target auxiliary thread 2 remains in a runnable state for an extended period and resides on a high-load kernel, it's presumed that there might be an interaction between target auxiliary thread 2 and the core thread. In this case, the electronic device can migrate target auxiliary thread 2 to a lower-load kernel, allowing it to quickly access more resources. This enables the core thread to output frames more efficiently, preventing prolonged screen stuttering and ensuring smooth application operation, thus improving user satisfaction. Alternatively, after migrating target auxiliary thread 2, if the core thread starts or terminates immediately after target auxiliary thread 2 finishes running, indicating an interaction between them, the electronic device can prioritize resource allocation to target auxiliary thread 2, such as dynamically migrating it to a lower-load kernel. This prevents target auxiliary thread 2 from blocking the core thread's execution, further improving application smoothness and ensuring a better user experience.

[0079] 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.

[0080] For example, Figure 6 A schematic diagram of the structure of electronic device 200 is shown. For example... Figure 6 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.

[0081] 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.

[0082] 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.

[0083] In some embodiments, the processor 210 may include a CPU. The CPU may include at least one CPU core. The CPU core grouping type may include at least one of the following: super-large core, large core, small core, or medium core. Different grouping types of CPU cores have different performance characteristics, such as different clock speeds. For example, the CPU cores may have 8 cores, including 1 large core, 3 medium cores, and 4 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 within the same group may have the same clock speed; for example, the 3 medium cores may have the same clock speed.

[0084] The controller can serve as the central nervous system 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.

[0085] 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.

[0086] The charging management module 211 is used to receive charging input from the charger to power the electronic device.

[0087] 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.

[0088] The mobile communication module 240 can provide wireless communication solutions, including 2G / 3G / 4G / 5G, for use on electronic devices 200.

[0089] 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 Wi-Fi), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies.

[0090] 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.

[0091] The display screen (or screen) 294 is used to display images, videos, etc. In some embodiments, the electronic device 200 may include one or N display screens 294, where N is a positive integer greater than 1.

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

[0093] 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.

[0094] 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.

[0095] 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.

[0096] Buttons 290 include a power button, volume buttons, etc. Indicators 292 can be indicator lights, used to indicate charging status, battery level changes, messages, missed calls, notifications, etc.

[0097] 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.

[0098] 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.

[0099] Figure 7 This is a schematic diagram of the software structure of the electronic device 200 according to an embodiment of the present invention.

[0100] 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.

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

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

[0103] 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.

[0104] like Figure 7 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0105] 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.

[0106] Content providers are used to store and retrieve data, and make that data accessible to applications.

[0107] The view system includes visual controls, such as controls for displaying text and controls for displaying images. The telephone manager is used to provide communication functions for electronic devices 200. For example, it manages call status (including connection and disconnection).

[0108] File Explorer provides various resources for applications.

[0109] The notification manager allows applications to display notification information in the status bar. It can be used to convey informational messages and can disappear automatically after a short time without user interaction.

[0110] The native layer includes a display module, a frame rate detection module, and a scheduling module.

[0111] The display module is used to determine the process identifier of the application running in the foreground, the rendering thread identifier of the application running in the foreground, and the timestamp of the application's frame. Additionally, the display module can receive surface information, that is, combine them to obtain a single frame. This frame can then be sent to the display screen.

[0112] The process identifier of an application can be a process control character (PID), name, or other information that indicates the process, and it is unique.

[0113] The identifier of a rendering thread can be a thread identifier, a name, or other information that indicates the process, and it is unique.

[0114] The timestamp of an application's screen indicates the display time of that screen. This display time can represent the actual time the electronic device 200 displays the screen, or, since the time required from screen generation to display is short, the screen generation time can also be considered the screen display time.

[0115] Alternatively, the aforementioned display module may be SurfaceFlinger.

[0116] Optionally, the timestamps of the above application's screen can be stored in the queenbuffer.

[0117] The frame rate detection module is used to obtain frame information of the application running in the foreground from the display module. The frame information may include the timestamp of the application's screen.

[0118] The frame rate detection module also determines the application's standard frame interval based on a voting mechanism and using the application's frame information. Simply put, there are multiple timestamps. The frame rate detection module calculates the actual frame interval using the timestamps of two adjacent frames, thus obtaining multiple actual frame intervals. The module uses the actual frame interval with the highest number of occurrences as the application's standard frame interval and sets the frame rate based on this standard frame interval as the target frame rate. For example, if the standard frame interval is 16.7ms, then the target frame rate is 60Hz.

[0119] Optionally, the standard frame interval may change. The frame rate detection module can determine the application's standard frame interval at regular intervals based on the application's actual frame interval. Alternatively, the standard frame interval can also be set by the application. For example, in response to relevant setting operations on the application, the application can set a corresponding frame rate, and the frame interval corresponding to that frame rate can be used as the standard frame interval. Of course, the standard frame interval can also be the application's default setting.

[0120] The aforementioned scheduling module may include a frequency prediction module, a scheduling information recording module, and a thread state detection module. The frequency prediction module is used to predict the frequency point matching the application based on the application's target frame rate.

[0121] The scheduling information recording module records the kernel frequency information of the thread. Specifically, this frequency information can be the highest frequency of the kernel in which the thread is located. This highest frequency can be a frequency that matches the temperature of the electronic device (such as the case temperature, junction temperature, etc. of the electronic device), such as the highest frequency that the kernel can reach at that temperature.

[0122] The thread state detection module is used to identify the application's logical threads when the application's frame rate is abnormal. Furthermore, based on the states of the logical threads and auxiliary threads, the module dynamically adjusts the resources used by auxiliary threads to improve their execution speed, thereby enabling the logical threads to run normally as quickly as possible and resolving the application's frame rate abnormality issue.

[0123] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0124] This application provides a resource adjustment method. During the foreground operation of an application (or a first application), if an abnormal frame rate is detected, it indicates that the application's core thread is running abnormally (e.g., running for a long time or not running for a long time), resulting in frame drops. Considering that auxiliary threads may interact with the core thread, and the state of auxiliary threads interacting with the core thread can also affect the normal operation of the core thread, the electronic device can first identify the target auxiliary thread that interacts with the application's core thread. Then, the electronic device performs a resource allocation operation to allocate more resources to the auxiliary thread interacting with the core thread, increasing its running speed. This allows the auxiliary thread to interact with the core thread as quickly as possible, such as refreshing the status bits required by the core thread and waking it up. This, in turn, enables the core thread to run normally and output frames as quickly as possible, avoiding prolonged screen stuttering, ensuring smooth application operation, and improving the user experience.

[0125] The following will use a mobile phone as an example and a game application as an example to introduce the implementation process of the above resource adjustment method. Figure 8 As shown, the process may include:

[0126] S301, In response to operation 1, the phone launches game application 1.

[0127] Operation 1 is used to trigger the launch of game application 1 on the phone (or can be used as an example of the first application). Game application 1 is a game application on the phone. For example, when a user wants to launch game application 1, they can click on the icon of game application 1. Here, the user's action of clicking on the icon of game application 1 is operation 1. Of course, operation 1 can also be other operations, such as the user inputting a voice command to launch the game application.

[0128] After the phone launches game application 1, the phone runs multiple threads of game application 1.

[0129] S302. While the game application 1 is running in the foreground, the mobile phone determines the current frame interval of the game application 1 every preset time interval 1. The current frame interval represents the difference between the current time and the timestamp corresponding to the previous game frame. Alternatively, the current frame interval represents the difference between the timestamps corresponding to the two most recently displayed game frames.

[0130] Optionally, the mobile phone can also determine the current frame interval of game application 1 in real time.

[0131] S303. The mobile phone determines whether the current frame interval of game application 1 is greater than or equal to the preset frame dropping time.

[0132] The preset frame drop time (or preset time threshold) is equal to the product of the standard frame interval and the preset number of frame drops. For example, if each lost frame is considered to indicate that the core thread of game application 1 has been blocked for too long, and the resources occupied by auxiliary threads of game application 1 that affect the operation of the core thread need to be dynamically adjusted, then the preset number of frame drops could be 1. Alternatively, considering that there are many reasons for triggering single-frame drops, such as the kernel frequency of game application 1 not increasing in time or other applications preempting kernel resources, the preset number of frame drops could be greater than or equal to 2 to avoid unnecessary adjustments to the resources occupied by auxiliary threads. Furthermore, the preset frame drop time can also be preset to a specific time value.

[0133] In this embodiment of the application, if the current frame interval is less than or equal to the preset frame dropping time, it indicates that the number of frame drops has not exceeded the preset number of frame drops. It can be considered that the game application 1 is producing frames normally, and the mobile phone can execute S304.

[0134] If the current frame interval is greater than the preset frame dropping time, it indicates a frame anomaly. The number of dropped frames exceeds the preset number of dropped frames. In other words, the core thread of game application 1 has been blocked for too long. It is necessary to dynamically adjust the resources occupied by auxiliary threads that affect the operation of the core thread. Then the phone can execute S305.

[0135] As mentioned earlier, the mobile phone can determine the standard frame interval of game application 1 based on a voting mechanism, using the actual frame interval of game application 1. Optionally, the mobile phone determines the latest standard frame interval of game application 1 every preset time interval of 2. Alternatively, the standard frame interval can also be the frame interval corresponding to the frame rate set by the user.

[0136] S304, The phone returns to the above S302.

[0137] S305. The mobile phone determines whether the logic thread and rendering thread of game application 1 are the same thread.

[0138] In this embodiment, the mobile phone can directly determine the rendering thread of game application 1. For simple game applications (such as single-threaded applications), the logic thread and the rendering thread are usually the same thread. For complex game applications, the logic thread and the rendering thread are independent.

[0139] Therefore, when the logic thread of game application 1 and the rendering thread of game application 1 are the same thread, the mobile phone can directly use the rendering thread as the logic thread, and then the mobile phone can execute S306.

[0140] If the logic thread of game application 1 and the rendering thread of game application 1 are not the same thread, the phone can continue to determine the logic thread, and then the phone can execute S307.

[0141] In some embodiments, during the startup of game application 1, the mobile phone can determine whether the logic thread and rendering thread of game application 1 are the same thread based on the thread execution status of game application 1 during startup initialization. Alternatively, if the mobile phone has already determined whether the logic thread and rendering thread of game application 1 are the same thread during historical execution, the mobile phone can record information 2 corresponding to game application 1, which indicates whether the logic thread and rendering thread of game application 1 are the same thread. Of course, the determination of whether the logic thread and rendering thread are the same thread can also be made by using the thread runtime and the number of times the rendering thread is woken up, as described below.

[0142] S306, the phone uses the rendering thread as a logical thread.

[0143] S307. The mobile phone determines the logical thread from the threads of the game application 1 other than the rendering thread.

[0144] For example, if a thread in game application 1 meets preset condition 1, the mobile phone can determine that the thread is a logical thread. Preset condition 1 (or the second condition) includes the frequency of waking up the rendering thread being greater than or equal to a preset number of times (or a preset threshold), and / or, the runtime being longer than the runtime of the rendering thread. Specifically, the frequency of waking up the rendering thread represents the number of times the thread wakes up the rendering thread within target time 1 (or the first time), and the thread's runtime represents the duration of the thread's runtime within target time 1, i.e., the duration it is in the running state.

[0145] Here, target time 1 is a period of time prior to the current time, such as a time interval within a preset time range. The number of game frames displayed within target time 1 reaches N. N is a positive integer greater than 1. Furthermore, the preset number of times is related to N; for example, the preset number of times is equal to N*0.8, but it can also be other values, and this application does not limit it.

[0146] Optionally, the number of times the rendering thread is woken up within the target time 1 can be determined using a sliding frame window, and the runtime of the thread within the target time 1 can also be determined using a sliding frame window. For example... Figure 9 As shown, the number of game frames within the sliding frame window is N. After rendering each game frame, the rendering thread enters a sleep state, waiting to be woken up to render another frame. Therefore, the phone can determine the identifier of the thread corresponding to each game frame within the sliding frame window. The thread corresponding to that game frame (i.e., the wake-up thread) represents the thread that wakes up the rendering thread to render the corresponding game frame. Then, for each game frame's corresponding thread, the phone can count the number of that thread's identifiers within the sliding frame window to determine the number of times that thread wakes up the rendering thread within the target time 1.

[0147] The runtime of the thread within the target time 1 represents the total duration of the thread in the running state within the sliding frame window. Optionally, when the preset condition 1 includes two conditions, the phone can determine whether both conditions are met simultaneously, or sequentially. For example, if the number of times the thread wakes up the rendering thread within the target time 1 is greater than a preset number, the phone continues to determine the runtime of the thread within the target time 1.

[0148] In addition, since none of the threads in game application 1 meet the above-mentioned preset condition 1, it indicates that the number of times the threads wake up the rendering thread is less and the runtime is shorter. In contrast, the logic thread is usually responsible for waking up the rendering thread and the runtime is longer. Therefore, the phone can determine that game application 1 does not have a separate logic thread, that is, the logic thread and the rendering thread of game application 1 are the same thread.

[0149] In some embodiments, the mobile phone can first identify the thread that wakes up the rendering thread most frequently. Then, the mobile phone can further determine whether this thread meets the aforementioned preset condition 1. If it does, the mobile phone can determine that the thread is a logic thread. If it does not, the mobile phone can determine that the game application's logic thread and rendering thread are the same thread. Of course, waking up the rendering thread most frequently can also be used as one of the preset conditions in condition 1.

[0150] S308, the mobile phone obtains the status information of the logical thread.

[0151] After identifying the logical thread of game application 1, the mobile phone can obtain the status information of the logical thread. This status information can be used to deduce the cause of any abnormalities in the logical thread's operation, and then execute corresponding solutions to ensure the rendering thread produces frames normally. The process of using the logical thread's status to execute corresponding solutions will be described below.

[0152] S309. When the above-mentioned logical thread is in the running state, the mobile phone determines whether the logical thread meets the preset condition 2.

[0153] Among them, preset condition 2 (or the first condition) indicates that the resources currently occupied by the logical thread meet the requirements. Specifically, preset condition 2 indicates that the resources occupied by the core thread are greater than or equal to the resource threshold.

[0154] As mentioned earlier, the presence of frame drops indicates that the rendering thread has not produced any frames for an extended period, meaning it has not been awakened for a long time. The logic thread should wake up the rendering thread after it finishes running. However, the logic thread is currently in a running state, indicating that it has been running for too long and is malfunctioning.

[0155] Considering that logical threads can also malfunction even with low resource consumption, the phone can first determine whether the cause of the logical thread's malfunction is related to low resource consumption by checking whether the logical thread meets preset condition 2.

[0156] If the preset condition 2 is not met, it indicates that the abnormal operation of the logical thread is likely due to the low resource consumption of the logical thread. Therefore, the phone can execute S310.

[0157] If the preset condition 2 is met, it indicates that the resources occupied by the logical thread have met the requirements. The abnormal operation of the logical thread is not due to insufficient resources, but is more likely related to the operation of the auxiliary thread. Therefore, the phone can execute S311.

[0158] Optionally, the above-mentioned preset condition 2 may include one or more of the following conditions:

[0159] Whether the kernel group in which the logical thread is located belongs to preset group 1, wherein preset group 1 indicates that the frequency of the kernel (or the third kernel) is greater than or equal to preset frequency 1;

[0160] The kernel load of the logical thread is less than the preset load of 1;

[0161] The priority of a logical thread is greater than or equal to the set priority (or second priority);

[0162] The actual frequency of the kernel where the logical thread resides is equal to the maximum frequency (or highest frequency) of that kernel.

[0163] In this application, the mobile phone can obtain thread grouping setting information. This information includes the kernel group where the logical thread resides and the kernel group where the auxiliary thread resides. The mobile phone can then determine whether the kernel group where the logical thread resides belongs to preset group 1. If it does not, it indicates that the frequency of the kernel where the logical thread resides is low, and the mobile phone can infer that the abnormal operation of the logical thread may be due to insufficient resource consumption. Optionally, preset group 1 may include large cores or super-large cores.

[0164] The phone can obtain the load of the kernel where the logical thread is located. If the load of the kernel where the logical thread is located is greater than or equal to a preset load of 1, it indicates that the load of the kernel where the logical thread is located is relatively high. In this case, the phone can infer that the reason for the abnormal operation of the logical thread may be that the logical thread is not using enough resources.

[0165] The mobile phone can obtain the maximum frequency corresponding to the kernel where the logical thread resides. This maximum frequency represents the highest frequency that the kernel is allowed to reach in the current state of the mobile phone; in other words, the maximum frequency is the frequency that matches the mobile phone's state information 1. State information 1 can include information such as the mobile phone's temperature, power consumption, and load. The temperature can include the casing temperature and junction temperature.

[0166] Check if the actual frequency of the kernel where the logical thread is located is equal to the maximum frequency. If not, it indicates that the frequency of the kernel where the logical thread is located is low. Therefore, the phone can infer that the reason for the abnormal operation of the logical thread may be that the logical thread is using too few resources.

[0167] It should be noted that when determining whether the preset conditions described in this application (such as preset condition 1, preset condition 2, etc.) are met, if the preset conditions include multiple conditions, the mobile phone can simultaneously determine whether each of the multiple conditions is met, and can determine whether each condition is met in the set order. In addition, after all the conditions included in the preset conditions are met, the mobile phone can consider that the preset conditions are met.

[0168] S310, the mobile phone increases the resources used by the logic thread.

[0169] In this application, when the logical thread does not meet the preset condition 2, it indicates that the resources currently occupied by the logical thread do not meet the requirements. Therefore, the mobile phone can increase the resources occupied by the logical thread to improve the execution speed of the logical thread, thereby enabling the logical thread to wake up the rendering thread as soon as possible and avoid long-term screen lag.

[0170] For example, the process of consuming resources by the aforementioned logical thread may include:

[0171] If the kernel group in which the logical thread resides does not belong to the preset group 1, the phone can migrate the logical thread to a kernel in the phone that belongs to the preset group 1, thereby increasing the frequency of the kernel in which the logical thread resides. For example, the preset group includes large cores. If the phone determines that the current kernel group in which the logical thread resides is a small core, indicating that the logical thread has been running on a small core for a long time, the phone can migrate the logical thread to a large core.

[0172] Optionally, the phone can increase the priority of logical threads. For example, before or after migrating a logical thread to a kernel belonging to preset group 1, the phone can increase the priority of the logical thread to ensure that the resources of the logical thread are not preempted by other threads.

[0173] If the load of the kernel where the logical thread resides is greater than or equal to a preset load of 1, the phone can first increase the priority of the logical thread to ensure that it is not preempted by other threads. Then, the phone can migrate the logical thread with the increased priority to kernel 1, where the load is less than that of the kernel where the logical thread resides. Alternatively, the phone can choose not to increase the priority of the logical thread and directly migrate it to a kernel with a lower load. Or, after migration, the phone can increase the priority of the logical thread. Optionally, when increasing the priority, the phone can raise the priority of the logical thread to priority 1, which can be a preset priority, a randomly selected priority, or the highest priority.

[0174] Optionally, kernel 1 and the kernel where the logical thread resides belong to the same group. Alternatively, kernel 1 and the kernel where the logical thread resided before the migration belong to different groups. Additionally, optionally, kernel 1 is the kernel with the lowest load.

[0175] If the priority of a logical thread is lower than the set priority, the phone can increase the priority of the logical thread, and the increased priority will be greater than the set priority.

[0176] If the actual frequency of the kernel where the logical thread resides is lower than the maximum frequency of that kernel, the phone can directly increase the frequency of the kernel where the logical thread resides to frequency point 1. Frequency point 1 is greater than the actual frequency and less than or equal to the maximum frequency. Optionally, the phone can use boost to increase the kernel frequency.

[0177] Optionally, the phone can increase the priority of logical threads. For example, before increasing the frequency, the phone can first increase the priority of logical threads.

[0178] In some embodiments, after increasing the resources occupied by the logical thread, if the rendering thread still has not produced a frame after a preset time 3, it indicates that the logical thread being in a running state for a long time may not be due to insufficient resources being used by the logical thread, but rather because it is blocked by the auxiliary thread. In this case, the phone can increase the resources occupied by the auxiliary thread so that the logical thread can recover to normal as soon as possible. Specifically, the process of increasing the resources occupied by the auxiliary thread can be referred to the following description of the case where the logical thread meets preset condition 2.

[0179] The above describes the scenario where the phone does not meet preset condition 2. However, there is also a possibility that the phone meets preset condition 2. If the phone meets preset condition 2, it indicates a high probability that the logic thread's prolonged running state is related to the operation of the auxiliary thread. Therefore, the phone can dynamically increase the resources allocated to the auxiliary thread based on its operation. The following section will continue to describe the scenario where the phone meets preset condition 2.

[0180] S311. The mobile phone obtains the status information of each auxiliary thread of game application 1. Among them, auxiliary threads refer to threads of game application 1 other than the core thread.

[0181] Since the phone has already identified the core threads (logic thread, rendering thread) of game application 1, it can use all threads of game application 1 other than the core thread as auxiliary threads, thereby determining the state of each auxiliary thread.

[0182] S312. In the presence of auxiliary thread 1, for each auxiliary thread 1, the mobile phone determines whether the kernel in which the auxiliary thread 1 is located belongs to the preset group 2.

[0183] In this context, Auxiliary Thread 1 refers to an auxiliary thread whose status information indicates a running state and whose running state duration is greater than a preset duration 1 (or the first duration). Preset Group 2 indicates that the kernel frequency is less than or equal to a preset frequency 2.

[0184] Auxiliary thread 1 represents an auxiliary thread that may have a blocking relationship with the logical thread. In other words, for the logical thread to wake up the rendering thread so that the rendering thread can generate game frames, it depends on auxiliary thread 1 to perform specific operations corresponding to the blocking relationship, such as synchronizing semaphores.

[0185] In this embodiment, for each auxiliary thread of the game application 1, if the status information of the auxiliary thread indicates a running state, and the duration of the running state is greater than a preset duration of 1, it indicates that the auxiliary thread has been running for a long time, as described above. Figure 2Based on the relevant information, the phone can infer that there is a high probability that the auxiliary thread and the logical thread are blocked. In other words, the logical thread may be blocked by the auxiliary thread, waiting for the auxiliary thread to perform a specific operation. Therefore, the phone can designate this auxiliary thread as Auxiliary Thread 1.

[0186] After determining the auxiliary thread 1, for each auxiliary thread 1, the phone determines whether the auxiliary thread belongs to the preset group 2.

[0187] If the kernel group in which auxiliary thread 1 is located belongs to preset group 2, it indicates that the low execution speed of auxiliary thread 1 may be due to the low frequency of the kernel in which the auxiliary thread is located. Therefore, the phone can perform kernel migration for auxiliary thread 1 to increase the frequency of the kernel in which the auxiliary thread is located, thereby achieving targeted resource allocation operations. Specifically, the phone can execute S313.

[0188] If the kernel group in which the auxiliary thread 1 is located does not belong to the preset group 2, it indicates that the frequency of the kernel in which the auxiliary thread 1 is located is higher. The low execution speed of the auxiliary thread 1 may not be due to the low frequency of the kernel in which the auxiliary thread is located. In this case, the mobile phone can execute S314.

[0189] S313. The mobile phone increases the priority of auxiliary thread 1 and migrates the increased-priority auxiliary thread 1 to kernel 2. Kernel 2 has a higher frequency than the kernel where auxiliary thread 1 resides.

[0190] For example, the phone raises the priority of auxiliary thread 1 to priority 2 (which could be called the first priority). Then, the phone migrates auxiliary thread 1 to a higher-frequency kernel 2 (or the first kernel) to improve its execution speed. For instance, the aforementioned preset group 2 is a small core, and kernel 2 is a large core. Once it's determined that auxiliary thread 1 is on a small core, the phone can migrate it to a large core.

[0191] Among these, kernel 2 can be randomly selected by the phone from kernels with a frequency higher than that of auxiliary thread 1, or kernel 2 can be the kernel with the highest frequency, or it can be preset. Similarly, as mentioned above, priority 2 can also be randomly selected, the highest priority, or preset.

[0192] In some embodiments, the load on kernel 2 is less than a preset load 2, thereby avoiding excessive load that could affect the operation of auxiliary thread 1. Optionally, the group in which kernel 2 is located may be the same group as the kernel in which auxiliary thread 1 was located before the migration, or it may be a different group; this application does not limit this.

[0193] It should be noted that the step of increasing the priority of auxiliary thread 1 in S313 above can also be executed by the phone after migrating auxiliary thread 1 to kernel 2, so that auxiliary thread 1 can occupy resources first and ensure the execution speed of auxiliary thread 1. In addition, the step of increasing the priority of auxiliary thread 1 is optional.

[0194] S314. The mobile phone determines whether the load of the kernel where auxiliary thread 1 is located is less than the preset load 3.

[0195] If the load on the kernel where auxiliary thread 1 is located is less than the preset load 3, it indicates that the low execution speed of auxiliary thread 1 may be due to the low priority of the auxiliary thread, which causes the resources required by the auxiliary thread to be preempted by other threads. Therefore, the phone can execute S315.

[0196] If the kernel load of the auxiliary thread 1 is greater than or equal to the preset load 3, it indicates that the low execution speed of the auxiliary thread may be due to the excessive kernel load. Therefore, the phone can execute S316.

[0197] In some embodiments, the above S314 can be described as follows: the mobile phone determines whether the load of the kernel in which the auxiliary thread 1 is located is less than the load of other kernels in the same group.

[0198] If yes, the phone can execute S315. If no, the phone can execute S316.

[0199] S315, The phone increases the priority of auxiliary thread 1.

[0200] The implementation process of S315 can be referred to the priority improvement process introduced above, and will not be repeated here.

[0201] S316. The mobile phone increases the priority of auxiliary thread 1 and migrates the increased-priority auxiliary thread 1 to kernel 3. The load on kernel 3 is lower than the load on the kernel where auxiliary thread 1 resides.

[0202] Optionally, kernel 3 and the kernel where auxiliary thread 1 was located before the migration belong to the same group. The implementation process of S316 can be referred to the relevant description above. For example, auxiliary thread 1 can be directly migrated to kernel 3 without increasing its priority, which will not be repeated here.

[0203] In some embodiments, the execution order of the operations described in S312-S316 above regarding how to increase the resources occupied by auxiliary thread 1 is merely an example, and this application does not limit the execution order. Generally speaking, for each auxiliary thread 1, the mobile phone can perform resource allocation operation 1 on that auxiliary thread 1. Resource allocation operation 1 is used to increase the resources occupied by auxiliary thread 1. Resource allocation operation 1 may include one or more operations such as increasing the priority of auxiliary thread 1, migrating auxiliary thread 1 to kernel 2, and migrating auxiliary thread 1 to kernel 3. The frequency of kernel 2 is higher than the frequency of the kernel where the auxiliary thread was located before the migration, and the load of kernel 3 is lower than the frequency of the kernel where the auxiliary thread was located before the migration.

[0204] In this embodiment, when a logical thread remains in a running state for an extended period, the mobile phone determines the cause of the abnormal operation by checking whether the logical thread meets preset condition 2, thereby achieving precise location of the cause of the abnormal operation. If the condition is not met, it indicates that the abnormal operation of the logical thread may be due to insufficient resources being used by the logical thread. Therefore, the mobile phone can allocate more resources to the logical thread to increase its running speed, enabling it to generate frames as quickly as possible and shortening the screen lag time.

[0205] If this condition is met, it indicates that the abnormal operation of the logical thread may be caused by the abnormal operation of the auxiliary thread that interacts with the logical thread. Therefore, the mobile phone can allocate more resources to the auxiliary thread to improve its running speed, so that the auxiliary thread can perform the corresponding interactive operations as soon as possible, such as performing specific operations such as refreshing the status bits that the logical thread depends on, or waking up the logical thread, so that the logical thread can run normally and output frames as soon as possible.

[0206] For example, such as Figure 10 As shown, the core thread (such as the logical thread within the core thread) is in a running state for a long time, and the auxiliary thread 1 is also in a running state for a long time. There may be a blocking relationship between the core thread and the auxiliary thread 1. The abnormal operation of the core thread may be due to the low frequency of the kernel where the auxiliary thread 1 is located. Therefore, the phone can relocate the auxiliary thread 1 to a higher frequency kernel to improve the running speed of the auxiliary thread 1, thereby shortening the running time of the auxiliary thread 1. This will enable the core thread to run normally as soon as possible and shorten the time to render the third frame.

[0207] In some embodiments, when the state of the above-mentioned logical thread is running, the mobile phone does not need to determine whether the logical thread meets the preset condition 2, that is, it does not need to determine whether the abnormal operation of the logical thread is due to the low resource consumption of the logical thread. Instead, it can infer that the abnormal operation of the logical thread is due to the auxiliary thread that has an interaction relationship with the logical thread. Then the mobile phone directly executes the above-mentioned resource allocation operation 1 on the auxiliary thread 1 to improve the running speed of the auxiliary thread.

[0208] The above describes how the phone dynamically adjusts resources for the auxiliary thread when both the logical thread and the auxiliary thread run for an extended period. The following section will describe how the phone dynamically adjusts resources for the auxiliary thread when the logical thread runs for a long time, but the auxiliary thread remains in a runnable state for an extended period.

[0209] S317. In the presence of auxiliary thread 2, for each auxiliary thread 2, the mobile phone increases the priority of auxiliary thread 2. Here, auxiliary thread 2 refers to an auxiliary thread whose status information indicates a runnable state and whose duration in the runnable state is greater than a preset duration of 2.

[0210] S318: The phone migrates the secondary thread 2, which has been given higher priority, to kernel 4. Kernel 4 has a lower load than the kernel where the secondary thread resides.

[0211] In this embodiment, for each auxiliary thread of each game application, since the status information of the auxiliary thread indicates a runnable state, and the duration of the runnable state is greater than a preset duration of 2 (or a second duration), it indicates that the auxiliary thread has not run for a long time, as described above. Figure 3 Based on the relevant information, the phone can infer that there is a high probability that the auxiliary thread and the logic thread are blocked. In other words, the logic thread may be blocked by the auxiliary thread, or waiting for the auxiliary thread to perform a specific operation. Therefore, the phone can designate this auxiliary thread as Auxiliary Thread 2.

[0212] Afterward, the phone can allocate more resources to auxiliary thread 2, increasing its execution speed and enabling it to perform specific operations as quickly as possible. Specifically, the phone can increase the priority of auxiliary thread 2, allocating resources to it accordingly. Furthermore, the phone can migrate the upgraded auxiliary thread 2 to a kernel with a lower load and higher frequency, ensuring timely scheduling and allowing it to enter the running state as quickly as possible.

[0213] Optionally, the kernel 4 and the kernel of the auxiliary thread 2 may belong to the same group or different groups.

[0214] In some embodiments, steps S317 or S318 described above are optional. For example, in the presence of an auxiliary thread 2, for each auxiliary thread 2, the phone can migrate the auxiliary thread 2 to kernel 4 (or a second kernel) without executing S317.

[0215] For example, in the presence of auxiliary thread 2, the phone can increase the priority of each auxiliary thread 2, making it the first priority, without needing to execute S318. Alternatively, the phone can migrate the auxiliary thread to a higher-frequency kernel (or the first kernel). In summary, for each auxiliary thread 2, the phone can perform resource allocation operation 2. Resource allocation operation 2 can include one or more of the following: increasing the priority of auxiliary thread 2, migrating auxiliary thread 2 to kernel 4, or migrating auxiliary thread 2 to a higher-frequency kernel.

[0216] The implementation process of S317-S318 can be referred to the relevant description above, and will not be repeated here.

[0217] In the embodiments of this application, such as Figure 11 As shown, the core thread is in the running state for a long time, while the auxiliary thread 2 is in the runnable state for a long time. There may be a blocking relationship between the core thread and the auxiliary thread 2. The abnormal operation of the core thread may be due to the high load of the kernel where the auxiliary thread 2 is located. Therefore, the phone can relocate the auxiliary thread 2 to another kernel with a lower load, so that the auxiliary thread 2 can be scheduled and enter the running state as soon as possible. In this way, the running time of the auxiliary thread is shortened, which in turn allows the core thread to run normally as soon as possible and shortens the time to render the third frame.

[0218] In some embodiments, when the logical thread runs for a long time, the mobile phone can directly obtain the status information of the auxiliary thread, such as by executing S311 above, without having to determine whether the logical thread meets the preset condition 2.

[0219] In some embodiments, if neither the aforementioned auxiliary thread 1 nor the aforementioned auxiliary thread 2 exists, it indicates that the abnormal operation of the logical thread may not be caused by the auxiliary thread. Therefore, the mobile phone can adjust the resources occupied by the logical thread according to the preset adjustment rules, such as directly migrating the logical thread to a kernel with a higher frequency or increasing the frequency.

[0220] The above mainly introduced what happens when the phone displays the above message while the logic thread is in the running state. Figure 2 or Figure 3The corresponding problem can be resolved by adjusting the resource allocation of the game application 1's threads, allowing the logic threads to run normally as quickly as possible, thereby waking up the rendering threads to output frames and effectively shortening the duration of screen stuttering. Additionally, when the logic threads are in a sleeping state, the phone can exhibit the aforementioned issues. Figure 4 or Figure 5 The corresponding problem can be solved by adjusting the resource allocation of the game application 1's thread. The following will continue with the case where the logic thread is in a sleeping state.

[0221] S319. The mobile phone obtains the status information of each auxiliary thread of game application 1. Among them, auxiliary threads refer to threads of game application 1 other than the core thread.

[0222] The implementation process of S319 can refer to the implementation process of S311 described above.

[0223] S320. In the presence of auxiliary thread 3, for each auxiliary thread 3, the mobile phone determines whether the kernel in which the auxiliary thread 3 belongs belongs to preset group 3. Here, auxiliary thread 3 refers to an auxiliary thread whose status information indicates a running state and whose running state duration is greater than a preset duration of 3. Preset group 3 indicates that the kernel frequency is less than or equal to a preset frequency of 3.

[0224] The aforementioned auxiliary thread 3 refers to an auxiliary thread that has a wake-up relationship with the logical thread.

[0225] In this embodiment, for each auxiliary thread of the game application 1, since the status information of the auxiliary thread indicates a running state, and the duration of the running state is greater than the preset duration 3 (or the third duration), it indicates that the auxiliary thread has been running for a long time, as described above. Figure 4 Based on the relevant information, the phone can infer that there is a high probability that the auxiliary thread and the logical thread have a wake-up relationship. In other words, the logical thread may need to be woken up by the auxiliary thread, so the phone can designate this auxiliary thread as auxiliary thread 3. Then, the phone can determine whether auxiliary thread 3 is in the preset group 2 to ascertain whether the abnormal operation of auxiliary thread 3 is due to insufficient resource consumption.

[0226] If the kernel group in which auxiliary thread 3 belongs belongs to preset group 2, the phone speculates that the reason auxiliary thread 3 is in a running state for a long time is because the frequency of the kernel in which auxiliary thread 3 resides is too low. Therefore, the phone can perform targeted resource allocation operations based on this specific reason, allocating more resources to auxiliary thread 3 to enable it to wake up the logical thread as soon as possible. Thus, the phone can perform kernel migration for auxiliary thread 3 to increase the frequency of the kernel in which it resides. Specifically, the phone can execute S321.

[0227] If the kernel group in which the auxiliary thread 3 is located does not belong to the preset group 2, it indicates that the kernel frequency of the auxiliary thread 1 is higher. The low execution speed of the auxiliary thread 3 may not be due to the low frequency of the kernel in which the auxiliary thread is located. In this case, the phone can execute S322.

[0228] S321. The mobile phone increases the priority of auxiliary thread 3 and migrates the increased-priority auxiliary thread 3 to kernel 5. Kernel 5 has a higher frequency than the kernel where the auxiliary thread resides.

[0229] For example, the phone increases the priority of auxiliary thread 3 to priority 3. Then, the phone migrates auxiliary thread 3 to a higher-frequency core, 5, to improve its execution speed. For instance, the aforementioned preset group 3 is a small core, and core 5 is a large core. Once it's determined that auxiliary thread 3 is on a small core, the phone can migrate it to a large core.

[0230] S322. The mobile phone determines whether the load of the kernel where the auxiliary thread 3 is located is less than the preset load 4.

[0231] If the load on the kernel where auxiliary thread 3 resides is less than the preset load 4, it indicates that the low execution speed of auxiliary thread 3 may be due to the low priority of the auxiliary thread, which causes the resources required by auxiliary thread 3 to be preempted by other threads. Therefore, the phone can execute S323.

[0232] If the kernel load of the auxiliary thread 3 is greater than or equal to the preset load 4, it indicates that the low execution speed of the auxiliary thread 3 may be due to the excessive kernel load. Therefore, the phone can execute S324.

[0233] S323, The phone increases the priority of auxiliary thread 3.

[0234] The implementation process of S323 can be referred to the priority improvement process introduced above, and will not be repeated here.

[0235] S324. The mobile phone increases the priority of auxiliary thread 3 and migrates the increased-priority auxiliary thread 3 to kernel 6. The load on kernel 6 is lower than the load on the kernel where auxiliary thread 3 resides.

[0236] Among them, kernel 6 and auxiliary thread 3 belong to the same group or different groups.

[0237] The implementation process of S324 can be referred to the relevant description above, and will not be repeated here.

[0238] In the embodiments of this application, such as Figure 12 As shown, the core thread (such as the logical thread within the core thread) remains dormant for an extended period (i.e., in a sleep state), while the auxiliary thread 3 remains in a running state for an extended period. There may be a wake-up relationship between the core thread and the auxiliary thread 3. The abnormal operation of the core thread may be due to the low frequency of the kernel where the auxiliary thread 3 resides. Therefore, the phone can relocate the auxiliary thread 3 to a higher frequency kernel, thereby increasing the running speed of the auxiliary thread 3 and shortening its running time. This would allow the auxiliary thread 3 to wake up the core thread earlier, enabling the core thread to run normally as soon as possible and shortening the time required to render the third frame.

[0239] The above describes how the phone dynamically adjusts resources for the auxiliary thread when the logical thread is in a long-term sleep state and the auxiliary thread is running for an extended period. The following section will continue to describe the process of dynamically adjusting resources for the auxiliary thread when the logical thread is in a long-term sleep state and the auxiliary thread remains in a runnable state for an extended period.

[0240] S325. In the presence of auxiliary thread 4, the mobile phone increases the priority of each auxiliary thread 4. Here, auxiliary thread 4 refers to an auxiliary thread whose status information indicates a runnable state and whose duration in the runnable state is greater than a preset duration of 4.

[0241] S326. The phone migrates the secondary thread 4, which has been given an increased priority, to kernel 7. The load on kernel 7 is lower than the load on the kernel where the secondary thread resides.

[0242] In this embodiment, for each auxiliary thread, if the status information of the auxiliary thread indicates a runnable state, and the duration of the runnable state is greater than a preset duration of 4 (or the fourth duration), it indicates that the auxiliary thread has not run for a long time, as described above. Figure 5Based on the relevant content, the phone can infer that there is a high probability that the auxiliary thread and the logical thread have a wake-up relationship. In other words, the logical thread may be blocked by the auxiliary thread, or the logical thread may need to be woken up by the auxiliary thread. Therefore, the phone can use the auxiliary thread as the aforementioned auxiliary thread 4.

[0243] Afterward, the phone can allocate more resources to auxiliary thread 4, increasing its processing speed and enabling it to execute specific operations as quickly as possible. Specifically, the phone can increase the priority of auxiliary thread 4, allocating resources to it accordingly. Furthermore, the phone can migrate the increased-priority auxiliary thread 4 to a less demanding kernel, ensuring it is scheduled promptly and enters the running state as quickly as possible.

[0244] The implementation process of S325-S326 can be referred to the relevant descriptions above, and will not be repeated here. In summary, the content introduced in S319-S26 above can be referred to S311-S318 above, and will not be repeated here.

[0245] In the embodiments of this application, such as Figure 13 As shown, the core thread (such as the logical thread within the core thread) remains dormant for an extended period (i.e., in a dormant state), while the auxiliary thread 4 remains in a runnable state for an extended period. There may be a wake-up relationship between the core thread and the auxiliary thread 4. The abnormal operation of the core thread may be due to the high load on the kernel where the auxiliary thread 4 resides. Therefore, the phone can relocate the auxiliary thread 4 to another kernel with a lower load in the same group or another group, so that the auxiliary thread 4 can be scheduled and enter the running state as soon as possible. This shortens the overall running time of the auxiliary thread, allowing the auxiliary thread 4 to wake up the core thread earlier, enabling the core thread to run normally as soon as possible and shortening the time to render the third frame.

[0246] It should be noted that the description of a logical thread in a sleeping state mentioned above can be found in the description of a logical thread in a running state, and similar content will not be repeated here.

[0247] In some embodiments, after performing corresponding resource allocation operations on auxiliary threads (such as auxiliary thread 1, auxiliary thread 2, auxiliary thread 3, and auxiliary thread 4) that are presumed to have an interaction relationship with the logical thread, thereby increasing the resources occupied by the auxiliary thread, the core thread will normally output frames after a short period of time (such as the third frame mentioned above), indicating that the auxiliary thread actually has an interaction relationship with the logical thread. Therefore, the mobile phone can directly bind the logical thread to the increased resources so that when the auxiliary thread runs again, it occupies more resources, thereby ensuring that the auxiliary thread can receive timely resource scheduling, improving the running speed of the auxiliary thread, and thus avoiding frame drops in the core thread due to abnormal operation of the auxiliary thread.

[0248] For example, the resource allocation operation mentioned above involves migrating the auxiliary thread to a kernel with a higher frequency, such as from a small core to a large core. In this case, when the auxiliary thread needs to re-enter the running or runnable state, the phone can directly run the auxiliary thread on the large core.

[0249] In this embodiment, during the foreground operation of game application 1, if frame output is abnormal, regardless of whether the core thread of game application 1 is in a running or sleeping state, the mobile phone can attempt to restore the core thread by increasing the resources occupied by the target auxiliary thread (such as the aforementioned auxiliary threads 1, 2, 3, and 4) to enable the core thread to output frames normally. The target auxiliary thread refers to an auxiliary thread that interacts with the core thread; that is, the screen generated by the core thread depends on the target auxiliary thread to perform a specific operation (i.e., the target operation). The operation of increasing the resources occupied by the target auxiliary thread can include increasing the priority of the target auxiliary thread, migrating the target auxiliary thread to a kernel with a lower load, or migrating the target auxiliary thread to a kernel with a higher frequency.

[0250] In some embodiments, the process described above of dynamically adjusting the resources occupied by the auxiliary thread based on the state of the logical thread of game application 1 in the event of frame dropping anomalies can be executed by a newly added thread state detection module in the scheduling module. The following, in conjunction with the above... Figure 7 The software modules introduced will be further introduced. Figure 8 The corresponding implementation process.

[0251] like Figure 14 As shown, the process is as follows:

[0252] S1. In response to operation 1, game application 1 is launched.

[0253] S2. During the foreground operation of game application 1, the display module records the frame information of game application 1. The frame information includes the timestamp corresponding to the game frame.

[0254] The frame information can include the timestamp of the most recently generated game frame. Alternatively, it can include the timestamps of game frames generated before the most recently generated frame.

[0255] S3. The frame rate detection module obtains frame information from the display module every preset time interval.

[0256] For example, the frame rate detection module can send a corresponding request to the display module. The display module responds to the request by sending frame information to the frame rate detection module.

[0257] Alternatively, the display module can actively send corresponding frame information to the frame rate detection module every preset time interval.

[0258] S4. The frame rate detection module calculates the current frame interval of game application 1 based on frame information.

[0259] S5. The frame rate detection module sends the current frame interval to the thread status detection module.

[0260] Optionally, the frame rate detection module can also send a standard frame interval to the thread detection module.

[0261] S6. The thread state detection module determines whether the current frame interval of game application 1 is greater than or equal to the preset frame dropping time.

[0262] In this embodiment of the application, if the current frame interval is less than or equal to the preset frame dropping time, it indicates that the number of frame drops has not exceeded the preset number of frame drops, and it can be considered that the game application 1 is producing frames normally, and the mobile phone can execute S7.

[0263] If the current frame interval is greater than the preset frame dropping time, it indicates a frame anomaly. The number of dropped frames exceeds the preset number of dropped frames. In other words, the core thread of game application 1 is blocked for too long. It is necessary to dynamically adjust the resources occupied by auxiliary threads that affect the operation of the core thread. Then the phone can execute S8.

[0264] S7. The thread status detection module confirms that game application 1 is running normally.

[0265] Once it's confirmed that game application 1 is running normally, the thread status detection module does not need to adjust the resources of the core thread or auxiliary threads. The thread status detection module can then continue to determine whether the new current frame interval is greater than or equal to the preset frame drop time.

[0266] The steps S1-S7 above describe how the phone determines the current frame interval of game application 1 after it is launched, and how it determines that game application 1 is running normally based on the current frame interval. For a detailed description, please refer to the implementation process described in S301-S304 above.

[0267] S8. The thread state detection module obtains the identifier of the rendering thread of game application 1 from the display module.

[0268] S9. The thread state detection module determines whether the rendering thread and the logic thread of game application 1 are the same thread.

[0269] When the logic thread and rendering thread of game application 1 are the same thread, the thread state detection module can directly use the rendering thread as the logic thread, and then the phone can execute S10.

[0270] If the logic thread of game application 1 and the rendering thread of game application 1 are not the same thread, the thread state detection module can continue to determine the logic thread, and then the phone can execute S11.

[0271] S10. The thread state detection module uses the identifier of the rendering thread as the identifier of the logical thread.

[0272] S11. The thread state detection module determines the identifier of the logical thread from the identifiers of threads other than the rendering thread in the game application 1.

[0273] The steps S8-S11 above describe the process of determining the logical thread of game application 1 when an abnormality is detected based on the current frame interval. For a detailed description, please refer to steps S305-S307 described above.

[0274] S12. The thread state detection module determines the state of the logical thread based on the identifier of the logical thread.

[0275] The thread state detection module finds the state of the thread corresponding to the identifier of the logical thread to obtain the state of the logical thread.

[0276] S13. When the logical thread is in the running state, the thread state detection module determines whether the logical thread meets preset condition 2. Preset condition 2 indicates that the resources currently occupied by the logical thread meet the requirements.

[0277] If the preset condition 2 is not met, it indicates that the abnormal operation of the logical thread is due to the insufficient resources occupied by the logical thread, and the possibility of it being related to the operation of the auxiliary thread is small. The thread state detection module can then execute S14.

[0278] If preset condition 2 is met, it indicates that the logical thread is consuming a lot of resources, and the reason for the abnormal operation of the logical thread is likely related to the operation of the auxiliary thread. Therefore, the phone can execute S15.

[0279] S14. The thread state detection module increases the resources used by logical threads.

[0280] For example, the thread state detection module can increase the resources used by logical threads through related modules in the scheduling module.

[0281] Sections S12-S14 describe how, when a logical thread runs for an extended period, the thread status detection module identifies the cause of the logical thread's abnormal operation by determining whether the logical thread meets preset condition 2. Furthermore, if the cause is determined to be insufficient resource usage by the logical thread, the thread status detection module can increase the resource usage of the logical thread. For a detailed implementation process, please refer to the implementation process in sections S308-S310 above.

[0282] S15. The thread state detection module obtains the state information of the auxiliary thread of game application 1.

[0283] S16. The thread state detection module determines the target auxiliary thread 3 that has a blocking relationship with the logical thread based on the status information of the auxiliary thread.

[0284] In this context, target auxiliary thread 3 refers to either auxiliary thread 1 or auxiliary thread 2 mentioned above.

[0285] S17. The thread state detection module increases the resources used by the target auxiliary thread 3.

[0286] Sections S15-S17 describe how, when the logical thread's abnormal operation might be due to an auxiliary thread blocking its normal operation, the thread state detection module can increase the resource usage of the target auxiliary thread 3, which is blocked by the logical thread. The specific implementation process can be found in Sections S311-S318 above.

[0287] The above describes the scenario where a logical thread remains in the running state for an extended period. The following section will discuss the scenario where a logical thread remains in the sleeping state for an extended period.

[0288] S18. When the logical thread is in a sleeping state, the thread state detection module obtains the state information of the auxiliary thread of game application 1.

[0289] S19. The thread state detection module determines the target auxiliary thread 4, which has a wake-up relationship with the logical thread, based on the status information of the auxiliary thread.

[0290] Here, target auxiliary thread 4 refers to either auxiliary thread 3 or auxiliary thread 4 mentioned above.

[0291] S20, The thread state detection module increases the resources used by the target auxiliary thread 4.

[0292] Sections S18-S20 describe how, if the logical thread has not run for an extended period and the thread state detection module suspects that the logical thread's abnormal operation might be due to the auxiliary thread failing to wake it up for a long time, thus blocking the logical thread's normal operation, the thread state detection module can increase the resources used by the target auxiliary thread 4, which has a wake-up relationship with the logical thread. The specific implementation process can be found in Sections S319-S326 above.

[0293] In some embodiments, if the logical thread is neither running for a long time nor idle for a long time, the thread state detection module can find a preset processing scheme based on the actual state of the logical thread to restore the normal operation of the logical thread as soon as possible, so that the game application 1 can output frames normally. This processing scheme can be set according to the actual situation, and this application does not limit it.

[0294] It is understood that the aforementioned game application is merely one possible application scenario for the solution provided in this application. This application does not impose any restrictions on this application scenario, as long as the application indicated by this scenario has core threads and auxiliary threads. Furthermore, the numbering of the steps described above is merely an example and does not represent the actual execution order of the steps. This application does not impose any restrictions on the execution order of the above steps.

[0295] It should be noted that the operations performed by the software modules in the aforementioned mobile phone (such as the thread state detection module, display module, frame rate detection module, etc.) can also be performed by other software modules. This application does not impose any restrictions on the software modules that perform the above steps. Furthermore, the operations performed by the software modules are actually all performed by the mobile phone; that is, the executing entity of the technical solution described in this application is the mobile phone.

[0296] The above mainly describes the solutions provided by the embodiments of this application from a methodological perspective. It is understood that, in order to achieve the above functions, the electronic device includes hardware structures and / or software modules corresponding to the execution of each function. Based on the units and algorithm steps of the various examples described in the embodiments disclosed in this application, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software.

[0297] Whether a function is implemented through hardware or by a computer-driven hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described function for each specific application, but such implementations should not be considered beyond the scope of the technical solutions in this application.

[0298] This application provides embodiments for dividing an electronic device into functional modules based on the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into a single processing unit. The integrated unit can be implemented in hardware or as a software functional module. It should be noted that the unit division in this application embodiment is illustrative and represents only one logical functional division; in actual implementation, other division methods may be used.

[0299] like Figure 15 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this application. This electronic device 1000 can be used to implement the methods executed by the electronic devices described in the above method embodiments. For example, the electronic device 1000 may include a processing unit 1001, a communication unit 1002, and a display unit 1003. The processing unit 1001 is used to support the electronic device 1000 in executing... Figures 1 to 14 The electronic device described in any one of the following embodiments includes a communication unit 1002 for supporting the communication function of the electronic device 1000, and a display unit 1003 for supporting the display function of the electronic device 1000.

[0300] Optional, Figure 15 The illustrated electronic device 1000 may also include a storage unit ( Figure 15 (not shown in the image), this storage unit stores a program or instruction. When the processing unit 1001 executes the program or instruction, it causes... Figure 15 The electronic device 1000 shown can perform the method described in the above-described method embodiments.

[0301] Figure 15 The technical effects of the electronic device 1000 shown can be referred to the technical effects described in the above method embodiments, and will not be repeated here. Figure 15 The processing unit 1001 in the illustrated electronic device 1000 can be implemented by a processor or processor-related circuit components, and can be a processor or processing module. The communication unit 1002 can be implemented by a transceiver or transceiver-related circuit components, and can be a transceiver or transceiver module. The display unit 1003 can be implemented by display screen-related components.

[0302] This application also provides a chip system, such as... Figure 16As shown, the chip system includes at least one processor 1101 and at least one interface circuit 1102. The processor 1101 and the interface circuit 1102 are interconnected via lines. For example, the interface circuit 1102 can be used to receive signals from other devices. As another example, the interface circuit 1102 can be used to send signals to other devices (e.g., the processor 1101). Exemplarily, the interface circuit 1102 can read instructions stored in memory and send those instructions to the processor 1101. When the instructions are executed by the processor 1101, the electronic device can perform the various steps performed by the electronic device in the above embodiments. Of course, the chip system may also include other discrete components, and this application embodiment does not specifically limit this.

[0303] Optionally, the chip system may include one or more processors. These processors can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.

[0304] Optionally, the chip system may contain one or more memories. The memory may be integrated with the processor or disposed separately from it; this application does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed separately on different chips. This application does not specifically limit the type of memory or the arrangement of the memory and processor.

[0305] For example, the chip system may be a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0306] It should be understood that each step in the above method embodiments can be completed by integrated logic circuits in the processor hardware or by instructions in software form. The method steps disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0307] This application also provides a computer storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the resource adjustment method described in the above method embodiments.

[0308] This application provides a computer program product, which includes a computer program or instructions that, when executed on an electronic device, cause the electronic device to perform the resource adjustment method described in the above method embodiments.

[0309] In addition, this application embodiment also provides an apparatus, which may specifically be a chip, component, or module. The apparatus may include a connected processor and a memory. The memory stores computer execution instructions. When the apparatus is running, the processor executes the computer execution instructions stored in the memory to cause the apparatus to perform the resource adjustment methods in the above-described method embodiments. The electronic devices, computer storage media, computer program products, or chips provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they achieve can be referred to in the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0310] Through the above description of the embodiments, those skilled in the art will 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.

[0311] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The embodiments can be combined with or referenced to each other without conflict. The apparatus embodiments described above are merely illustrative; for example, 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 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.

[0312] 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.

[0313] 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.

[0314] 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, in essence, or 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 of 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.

[0315] 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 that can be easily conceived by those skilled in the art within the scope of the technology 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 resource adjustment method, characterized in that, Applied to electronic devices, including: During the operation of the first application of the electronic device, if the current frame interval of the first application is greater than or equal to a preset time threshold, the resources occupied by the target auxiliary thread of the first application are increased; wherein, the core thread of the first application is used to generate the screen of the first application; the auxiliary thread of the first application refers to the thread of the first application other than the core thread. The generation of the screen of the first application depends on the target auxiliary thread performing the target operation.

2. The method according to claim 1, characterized in that, When the core thread is running, the target auxiliary thread includes an auxiliary thread that is running for a duration longer than a first duration, or an auxiliary thread that is runnable for a duration longer than a second duration.

3. The method according to claim 2, characterized in that, The target auxiliary thread includes auxiliary threads that are running for a duration longer than a first duration; improving the resources used by the target auxiliary thread of the first application includes one or more of the following operations: The target auxiliary thread is migrated to the first kernel; wherein the frequency of the first kernel is greater than the frequency of the kernel where the target auxiliary thread was located before the migration; Raise the priority of the target auxiliary thread to the first priority; The target auxiliary thread is migrated to a second kernel; wherein the load of the second kernel is less than the load of the kernel where the target auxiliary thread was located before the migration.

4. The method according to claim 2 or 3, characterized in that, When the core thread is running, the method further includes: If the resources occupied by the core thread meet a first condition, the target auxiliary thread of the first application is determined; wherein, the first condition indicates that the resources occupied by the core thread are greater than or equal to a resource threshold.

5. The method according to claim 4, characterized in that, The first condition includes one or more of the following conditions: The core thread resides in a third kernel, and the frequency of this third kernel is greater than or equal to a preset frequency. The frequency of the kernel where the core thread resides is equal to the highest frequency of the corresponding kernel. The kernel load where the core thread resides is less than the preset load. The priority of the core thread is greater than or equal to the second priority.

6. The method according to any one of claims 1 to 5, characterized in that, When the core thread is in a dormant state, the target auxiliary thread includes an auxiliary thread that is running for a duration of more than three durations, or an auxiliary thread that is in a runnable state for a duration of more than four durations.

7. The method according to any one of claims 1 to 6, characterized in that, The core thread includes a logic thread and a rendering thread; the logic thread is used to execute the business logic of the first application, and the rendering thread is used to generate the screen of the first application. The logic thread's ability to wake up the rendering thread to generate the screen of the first application depends on the target auxiliary thread performing the target operation. The logical thread refers to a thread in the first application that meets the second condition; wherein, the second condition includes the frequency at which the thread wakes up the rendering thread within a first time period being greater than or equal to a preset threshold and / or the duration for which the thread is in the running state within the first time period being longer than the duration for which the rendering thread is in the running state.

8. The method according to claim 7, characterized in that, The second condition also includes that the frequency with which the thread wakes up the rendering thread is greater than the frequency with which other threads of the first application wake up the rendering thread.

9. The method according to any one of claims 1 to 8, characterized in that, The preset time threshold is greater than or equal to the product of the standard frame interval of the first application and the preset number of dropped frames.

10. 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, and 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 resource adjustment method as described in any one of claims 1 to 9.

11. 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 resource adjustment method as described in any one of claims 1 to 9.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the resource adjustment method as described in any one of claims 1 to 9.

Images