Performance optimization method and device, electronic equipment and computer readable medium

Abstract

The invention discloses a performance optimization method and device, electronic equipment and a computer readable medium. The method comprises the steps of determining a current target application scene of the electronic equipment; based on predetermined thread scheduling strategies corresponding to different application scenarios, determining a target thread scheduling strategy corresponding to the target application scenario, the thread scheduling strategy corresponding to the application scenario including the thread scheduling strategy corresponding to the target application scenario under the condition that the application scenario meets normal operation; using strategies of the threads participating in the application scene for different processors; and running each thread in the target application scene in a processor corresponding to the thread based on the target thread scheduling strategy. Therefore, the processor participating in the operation of the partial thread of the application scene can be determined based on the current application scene, so that the setting of the core selection strategy can be adapted to the current application scene.

Description

Technical Field

[0001] This application relates to the technical field of mobile terminals, and more particularly, to a performance optimization method, apparatus, electronic device, and computer-readable medium. Background Art

[0002] The performance optimization of intelligent hardware devices (such as smart phones, smart tablets, etc.) plays a crucial role in modern technology. With the continuous improvement of hardware performance, users' expectations for devices are also getting higher and higher, requiring the devices to efficiently utilize limited hardware resources (such as processors, memory, batteries, etc.) while maintaining high performance. Therefore, performance optimization not only concerns the performance improvement of the device, but also directly affects the user experience, the durability of the device, and the service life of the battery.

[0003] However, despite the many benefits brought by performance optimization, there are also some deficiencies. Performance optimization often relies on the pre-set configuration files of the manufacturer and the scheduling algorithms built into the chip. These optimization measures are usually a default setting and have poor applicability. Summary of the Invention

[0004] This application proposes a performance optimization method, apparatus, electronic device, and computer-readable medium to improve the above-mentioned defects.

[0005] In a first aspect, this application provides a performance optimization method applied to an electronic device, where the electronic device includes multiple processors. The method includes: determining the current target application scenario of the electronic device; based on the pre-determined thread scheduling strategies corresponding to different application scenarios, determining the target thread scheduling strategy corresponding to the target application scenario, where the thread scheduling strategy corresponding to the application scenario includes the usage strategies of each thread participating in the application scenario for different processors when the application scenario meets the normal operation requirements; based on the target thread scheduling strategy, running each thread in the target application scenario on the processor corresponding to the thread.

[0006] In a second aspect, this application also provides a performance optimization apparatus applied to an electronic device, where the electronic device includes multiple processors. The apparatus includes: a determination unit, an acquisition unit, and an execution unit. The determination unit is configured to determine the current target application scenario of the electronic device. The acquisition unit is configured to determine the target thread scheduling strategy corresponding to the target application scenario based on the pre-determined thread scheduling strategies corresponding to different application scenarios, where the thread scheduling strategy corresponding to the application scenario includes the usage strategies of at least some threads participating in the application scenario for different processors when the application scenario meets the normal operation requirements. The execution unit is configured to run at least some threads in the target application scenario on the processor corresponding to the thread based on the target thread scheduling strategy.

[0007] In a third aspect, the present application also provides an electronic device, including: one or more processors; a memory; one or more applications, where the one or more applications are stored in the memory and configured to be executed by the one or more processors, and the one or more applications are configured to execute the above method.

[0008] In a fourth aspect, the present application also provides a computer-readable medium, where the readable storage medium stores program code executable by a processor, and when the program code is executed by the processor, the processor executes the above method.

[0009] The performance optimization method, device, electronic device, and computer-readable medium provided by the present application determine the current target application scenario of the electronic device; based on the pre-determined thread scheduling policies corresponding to different application scenarios, determine the target thread scheduling policy corresponding to the target application scenario, where the thread scheduling policy corresponding to the application scenario includes the usage policies of at least some threads participating in the application scenario for different processors when the application scenario meets normal operation; based on the target thread scheduling policy, run at least some threads in the target application scenario on the processors corresponding to the threads. Therefore, based on the current application scenario, the processors for running some threads participating in the application scenario can be determined, so that the setting of the core selection policy can adapt to the current application scenario.

[0010] Other features and advantages of the present application will be described in the subsequent specification, and part of them will become obvious from the specification, or be understood by implementing the present application. The objectives and other advantages of the present application can be achieved and obtained through the structures specifically pointed out in the written specification, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] To more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are only some embodiments of the present application. For those skilled in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0012] Figure 1 Shows the method flow chart of the performance optimization method provided by an embodiment of the present application;

[0013] Figure 2 Shows the method flow chart of the performance optimization method provided by another embodiment of the present application;

[0014] Figure 3 Shows the method flow chart of the performance optimization method provided by yet another embodiment of the present application;

[0015] Figure 4 shows the logic architecture diagram corresponding to the performance optimization method provided by an embodiment of the present application;

[0016] Figure 5 shows the schematic diagram of the application scenario provided by an embodiment of the present application;

[0017] Figure 6 shows the schematic diagram of the application scenario provided by another embodiment of the present application;

[0018] Figure 7 shows the module block diagram of the performance optimization device provided by an embodiment of the present application;

[0019] Figure 8 shows the structural block diagram of the electronic device provided by the embodiment of the present application;

[0020] Figure 9 shows the storage unit for storing or carrying the program code for implementing the method according to the embodiment of the present application. Detailed implementation manners

[0021] In order to enable those skilled in the art to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Usually, the components of the embodiments of the present application described and illustrated in the accompanying drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application to be protected, but only represents the selected embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application.

[0022] It should be noted that: similar reference numerals and letters denote similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of the present application, the terms "first", "second", etc. are only used for descriptive distinction and cannot be understood as indicating or implying relative importance.

[0023] The performance optimization of intelligent hardware devices (such as smart phones, smart tablets, etc.) plays a crucial role in modern technology. With the continuous improvement of hardware performance, users' expectations for devices are also getting higher and higher, requiring the devices to efficiently utilize limited hardware resources (such as processors, memory, batteries, etc.) while maintaining high performance. Therefore, performance optimization not only concerns the performance improvement of the device, but also directly affects the user experience, the durability of the device, and the service life of the battery.

[0024] Currently, the performance optimization of intelligent hardware devices (such as smart phones, smart tablets, etc.) usually relies on relevant preset configuration files or the chip's own scheduling algorithms, which can specifically include Energy-Aware Scheduling (EAS) and preset scheduling policy configurations. Among them, Energy-Aware Scheduling (EAS) enables the scheduler to predict the impact of its decisions on the energy consumed by the CPU. EAS relies on the CPU's Energy Model (EM) to select an energy-efficient CPU for each task. The preset scheduling policy configuration analyzes and optimizes the test results of limited scenarios to obtain a series of configuration items to guide the scheduling of corresponding scenarios, so as to improve the fluency of corresponding scenarios. If strategies such as core binding are applied to the critical threads of some applications.

[0025] However, the inventors found in the research that the current Energy-Aware Scheduling and preset scheduling policy configurations have the following disadvantages:

[0026] EAS selects a core based on some past scheduling information of the task and the current platform energy model, ignoring the impact of specific services on fluency. The preset scheduling policy configuration allocates performance resources through a preset fixed configuration file, and it is difficult to flexibly adjust in the face of changing application scenarios and user behaviors. When problems occur, only measures such as changing the user's mobile phone version, such as ota upgrade, can be used to change the configuration file in the mobile phone.

[0027] It can be seen that although performance optimization brings many benefits, there are also some deficiencies. Performance optimization often relies on the configuration files preset by manufacturers and the scheduling algorithms built into the chip. These optimization measures are usually a default setting and have poor applicability.

[0028] Therefore, to overcome the above defects, please refer to Figure 1 , an embodiment of the present application provides a performance optimization method, which is applied to an electronic device. The electronic device includes multiple processors. Exemplarily, the data processing capabilities and power consumption capabilities of the multiple processors may not be all the same, and among them, the data processing capability is positively correlated with the power consumption capability. Exemplarily, the multiple processors may include big-core processors and small-core processors. The big-core processors and small-core processors may be packaged in one chip or independently packaged into two chips.

[0029] "Big core" and "small core" are used to describe the processing units (CPUs) in a multi-core processor architecture, and are widely used especially in heterogeneous computing architectures. The "big" and "small" in "big core" and "small core" mainly refer to the differences in processing capabilities, performance, and power consumption.

[0030] Exemplarily, high-performance cores usually refer to processors with relatively high performance, high power consumption, high complexity, etc. Exemplarily, high performance means that high-performance cores have a higher main frequency, a larger cache, more complex execution units, and higher processing capabilities, etc., and can handle complex computing tasks and high-load applications; Exemplarily, high power consumption means that high-performance core processors usually consume more power due to their high-performance design; Exemplarily, high complexity means that high-performance core processors usually adopt more complex architectures, such as superscalar architectures, deep pipelines, etc., to achieve higher performance. In addition, an electronic device can use a high-performance core processor to execute tasks that require high computing capabilities, such as high-load computing, graphics processing, video encoding and decoding, etc.

[0031] Exemplarily, compared with high-performance cores, high-efficiency cores usually have characteristics such as relatively low power consumption, low performance, and low complexity. Exemplarily, low power consumption means that high-efficiency core processors focus on power efficiency, have lower power consumption and better energy utilization, and are suitable for use in power-constrained environments; Exemplarily, low performance means that the processing capabilities of high-efficiency core processors are lower than those of high-performance cores, but are still sufficient for handling light-load tasks and routine operations; Exemplarily, low complexity means that high-efficiency core processors adopt a simple design, that is, high-efficiency cores usually have a simpler design, fewer execution units and caches, aiming to provide better power efficiency. An electronic device usually uses high-efficiency cores to process light-load tasks, such as background tasks, lightweight applications, partial sensor control, or routine operations, which can help extend battery life or reduce system power consumption.

[0032] As Figure 1 shown, the method includes: S101 to S103.

[0033] S101: Determine the current target application scenario of the electronic device.

[0034] It should be noted that the application scenario can refer to a scenario related to interaction within the electronic device, where the interaction-related can refer to displaying content or the user operating the electronic device, etc. That is to say, the electronic device will analyze based on the user's behavior and interaction pattern with the electronic device. For example, by monitoring the applications opened and switched by the user, the system can infer the current application scenario. For example, frequently switching to the map application and navigation-related functions indicates that the user may be navigating. For example, by analyzing the user's interaction method with the application, such as staying in a certain application for a long time, quickly scrolling or clicking, to judge the type of user activity. These behaviors can be used to identify scenarios such as watching videos, browsing social media, and working.

[0035] It should be noted that the application scenarios may include, but are not limited to, sliding scenarios and switching scenarios, etc. Moreover, for different applications, the application scenarios corresponding to the application have their own identity identifiers, namely named scenario identifiers. Different scenarios of each application have corresponding scenario identifiers. That is to say, the scenario identifier includes the application identifier corresponding to the scenario and the type of the scenario. Among them, the scenario types include sliding scenarios and switching scenarios, etc.

[0036] For the sliding scenario, the sliding behavior of the user can be recognized by the sliding operation (such as touch events) on the touch screen, combined with the data of the accelerometer and gyroscope. Specifically, in the Android operating system, the onScroll event or onTouch event can be listened to. When a sliding action is detected, it can be determined that a sliding scenario is detected. Further, when a sliding action is detected and at the same time, it is detected that the content on the screen presents a sliding state (such as a web page or a list), it can be identified as a scrolling scenario.

[0037] For the switching scenario, the switching operation between user interfaces can be detected, such as page switching or application switching. For page switching, the Activity lifecycle (Android) can usually be listened to. For application switching, when the application interface changes and the user jumps from one page to another page, it can be identified as the "page switching mode" or the "interface switching mode".

[0038] Of course, the scenario types can also include other types. For example, the input mode and the playback mode. Among them, it is determined whether it is in the input mode by identifying whether the user is performing text input (such as clicking on a text box, opening the keyboard, etc.). In addition, when a video application or a video playback interface is detected, it can be determined as the playback mode.

[0039] S102: Based on the thread scheduling policies corresponding to different pre-determined application scenarios, determine the target thread scheduling policy corresponding to the target application scenario.

[0040] It should be noted that the thread scheduling policy corresponding to this application scenario includes the usage policies of at least some of the threads participating in the application scenario for different processors when the application scenario meets the normal operation conditions. Exemplarily, various application scenarios of the electronic device can be pre-identified, and then a thread scheduling policy is set for each application scenario. The thread scheduling policy corresponding to each application scenario includes the CPU usage policy, that is, the processor usage policy, of at least some of the threads referring to this application scenario. The processor usage policy includes the type of the processor on which the thread runs and the running period on this type of processor. Here, the type includes big cores and small cores, that is, it is determined whether the processor for running the thread is a big core or a small core, and the running period on this processor. Here, the period can set the running order and running duration of each thread on the big core or small core.

[0041] As an implementation manner, the correspondence between the thread scheduling policy and the scenario can be defined based on the different load characteristics and resource requirements of different threads participating in the scenario. Among them, the load characteristics can include compute-intensive, I / O-intensive, and real-time characteristics. For example, for compute-intensive threads, strong CPU computing power is required, and usually the threads need to be assigned to high-performance cores, and cores with higher performance may be preferentially used. For I / O-intensive threads, since these tasks usually do not require a large amount of CPU computing resources, they are suitable to be assigned to low-power cores to avoid overloading high-performance cores. For threads with relatively high real-time requirements, that is, high-real-time threads, such as threads related to video display, it should be ensured that the threads are assigned to cores with lower latency and faster response speed.

[0042] In the embodiments of the present application, it is possible to pre-statistically analyze each thread participating in the application scenario under different application scenarios of the electronic device, and statistically analyze the load characteristics of each thread, and then set the usage policy of the processor corresponding to each thread. As an implementation manner, the thread scheduling policy corresponding to the application scenario can be to determine the usage policy of the processor corresponding to all the threads participating in the application scenario. Of course, it can also be to determine the usage policy of the processor corresponding to some threads. Here, some threads refer to the threads that can seriously affect the normal operation of this scenario.

[0043] Exemplarily, in a multi-threaded environment, to determine the threads that can seriously affect the normal operation of the application scenario, it is usually necessary to analyze the execution behavior of the threads and the occupancy of system resources. The threads that affect the normal operation of the scenario generally manifest as consuming too many resources, blocking other threads, or causing delays or errors. Therefore, the threads that can affect the normal operation of this scenario can be used as the aforementioned some threads, and the normal operation of this scenario means that the scenario does not experience stuttering.

[0044] By monitoring the resource occupancy of each thread (such as CPU, memory, I / O, etc.), it is possible to identify which threads may affect the performance of the entire scenario, i.e., the normal operation. Usually, the threads with higher resource occupancy belong to the threads that can affect the normal operation of the scenario. Among them, the threads with higher resource occupancy refer to the threads whose CPU occupancy rate, memory occupancy, and I / O blocking duration are all higher than their corresponding normal thresholds. In addition, some of the above threads can also include threads whose execution duration is greater than a preset duration, and can also include threads with dependency relationships. Among them, having a dependency relationship means a thread that directly or indirectly has a dependency relationship with the main thread of the application scenario.

[0045] It can be understood that the thread scheduling policies corresponding to different predetermined application scenarios can represent that, for different application scenarios, at least some of the threads participating in the application scenario have usage policies for different processors. When using this usage policy, it can ensure the normal operation of the application scenario. Among them, the core idea of this usage policy is to avoid the lag of each thread, that is, to ensure that each thread can be completed quickly. Usually, it is related to the load characteristics of the thread. Threads with a large load are preferentially allocated large cores, and threads with a small load are preferentially allocated small cores.

[0046] S103: Based on the target thread scheduling policy, run at least some of the threads in the target application scenario on the processor corresponding to the thread.

[0047] When determining the target thread scheduling policy corresponding to the current application scenario, based on the target thread scheduling policy, the running processor, i.e., the running core, of the threads participating in the target application scenario can be adjusted, that is, allocate large cores or small cores for the threads of the target application scenario.

[0048] That is to say, determine the current target application scenario of the electronic device; based on the thread scheduling policies corresponding to different predetermined application scenarios, determine the target thread scheduling policy corresponding to the target application scenario. Among them, the thread scheduling policy corresponding to the application scenario includes the usage policies of at least some of the threads participating in the application scenario for different processors when the application scenario meets the normal operation; based on the target thread scheduling policy, run at least some of the threads in the target application scenario on the processor corresponding to the thread. Therefore, based on the current application scenario, the running processors of some of the threads participating in the application scenario can be determined, so that the setting of the core selection policy can adapt to the current application scenario.

[0049] Please refer to Figure 2 , the embodiment of the present application provides a performance optimization method, which is applied to the above-mentioned electronic device. The method includes: S201 to S205.

[0050] S201: Determine the scene smoothness information of multiple historical application scenarios during which the electronic device operates within a preset time period, as well as the scheduling information corresponding to each historical application scenario, where the scheduling information includes the processors on which the respective threads participating in the application scenario run and the load information.

[0051] Among them, the preset time period may refer to the sampling period corresponding to the determination of the thread scheduling policy for different application scenarios, which can be set based on actual usage requirements. For example, it can be the time period between the moment when the electronic device is first used by the user and the current moment, or it can be a preset time length before the current moment, such as a week, a month, or a quarter before the current moment, etc.

[0052] As an implementation manner, the scene smoothness information corresponding to the application scenario is used to evaluate whether the application scenario can run normally, that is, the probability of occurrence of an abnormality, when the electronic device is running the application scenario. That is to say, through the scene smoothness information of the historical application scenario, it is possible to determine the smoothness of the historical application scenario when the electronic device is running the historical application scenario. Exemplarily, the scene smoothness information includes a first state and a second state, where the first state is used to represent that the application scenario runs normally, and the second state is used to represent that the scenario does not run normally.

[0053] In the embodiment of the present application, the normal operation of the application scenario means that the application scenario does not freeze, that is, the display content corresponding to the application scenario can be normally displayed without freezing. Then, the scene smoothness information may be the frame rate smoothness corresponding to the application scenario.

[0054] It should be noted that the frame rate smoothness means that the interface of the application scenario can be normally displayed without freezing. Exemplarily, assume that the current screen refresh rate is 90Hz, that is, the screen is refreshed 90 times in 1 second. The electronic device needs to ensure that the content to be displayed currently is ready, that is, the rendering is completed, before each screen refresh. Otherwise, the screen refresh display will still be the content of the previous frame, and the user will feel unsmooth. Therefore, the drawing of a new page should be completed every 1s / 90 = 11.11ms for each frame.

[0055] Therefore, in the implementation manner of determining the scene smoothness information of the historical application scenario, it is determined whether the electronic device freezes when the electronic device is running the historical application scenario. If it freezes, then it is determined that the scene smoothness information of the application scenario is frame rate not smooth or frame rate frozen, that is, it is set to the second state. If it does not freeze, then it is determined that the scene smoothness information of the application scenario is frame rate smooth or frame rate not frozen, that is, it is set to the first state.

[0056] As an implementation manner, the way to determine the frame rate smoothness of an application scenario can be to determine the frame rate of the electronic device when the electronic device is running the application scenario. If the frame rate is less than the screen refresh rate of the electronic device, it is determined that the frame rate smoothness of the application scenario is not smooth or stuck. Otherwise, it is determined that the frame rate of the application scenario is smooth. The frame rate (Frames Per Second, FPS) represents the number of frames rendered by the graphics engine (or application) per second, and the frame rate can be obtained using the GPU Renderer tool of Android or through ADB commands. The screen refresh rate is the number of times the display device (such as a monitor, mobile phone screen, etc.) refreshes the image per second. If the frame rate (FPS) is lower than the refresh rate, the screen will still refresh, but the picture will be stuck or delayed because the number of rendered frames is not enough to match the refresh speed of the monitor.

[0057] As an implementation manner, the scheduling information of the application scenario includes the processors on which the various threads participating in the application scenario run and the load information. Specifically, the processors on which the various threads run can include, when the electronic device is running the application scenario, the identifier of each processor on which the threads participating in the application scenario run and the corresponding running information. The running information can include the time period during which the thread runs on the processor, where the time period includes the start time, the end time, and the time length. The load information is used to characterize the processor usage of the thread. The higher the load of the thread, the higher the possibility of causing stuck.

[0058] Exemplarily, the scheduling information includes the main thread participating in the application scenario, the child threads that have a dependency relationship with the main thread, the processors on which the various threads run, and the load information, and the thread scheduling strategy is used to ensure the normal operation of the main thread of the application scenario.

[0059] In the embodiments of the present application, a scene recognition module and a scheduling collection module are provided in the electronic device. The scene recognition module can recognize the scene in which the application is currently located and the frame rate smoothness in this scene. The scenes include but are not limited to sliding and switching. The scheduling collection module can, according to the scene recognition result, collect the application core threads in the same scene and the dependency relationships between the threads, form a thread service dependency tree, and perform further scheduling information statistics on these related threads and classify them according to the load. Among them, the application core thread is the main thread of the application scenario. In the embodiments of the present application, the main thread can be a thread used for updating and interacting with the user interface of the application scenario.

[0060] In many applications, especially graphical user interface (GUI) applications, the main thread is responsible for handling interactions with the user interface. The responsibilities of the main thread include: Interface updates: such as refreshing the screen, drawing buttons, displaying text, etc.; Event handling: receiving user input (such as touch) and making corresponding responses. In Android, the main thread is called the UI thread, which is responsible for handling all work related to the user interface, including interface updates, user input processing, event distribution, etc. In Android, a child thread is a thread created by the main thread and used to execute background tasks, such as network requests, file reading, long-running calculations, etc. Since the main thread cannot perform time-consuming operations for a long time, otherwise it will cause the application to become unresponsive (ANR), time-consuming operations need to be placed in a child thread.

[0061] The main thread usually depends on the task results of the child thread and passes the results back to the main thread through a callback function for processing. For example, Handler and Looper are used for communication between the main thread and the child thread. The main thread receives messages through the Handler and then performs the corresponding UI update operations. Therefore, the child thread that has a dependency relationship with the main thread can be determined through the callback function in the main thread. That is to say, the child thread that has a dependency relationship with the main thread can be determined through the task communication mechanism. For example, if the child thread communicates with the main thread through mechanisms such as Handler, FutureTask, AsyncTask, etc., it can be determined that there is a dependency relationship between the main thread and the child thread. That is to say, the existence of this dependency relationship means that the main thread needs to depend on the content returned by the child thread to continue executing the task. That is to say, in order to complete the task of interface display or interaction in the current application scenario, the main thread needs to hand over some functions (also called subtasks) to some child threads for execution and continue to execute the main task after obtaining the reply results from the child threads. Then, this child thread can be regarded as a thread that has a dependency relationship with the main thread.

[0062] As an implementation, the load information of the thread is used to measure the usage rate of the CPU of the electronic device by the thread. Exemplarily, the load information of the threads in the application scenario can be a relative value. Exemplarily, the main thread of the application scenario and the multiple child threads corresponding to the main thread are determined, and there is a dependency relationship between each child thread and the main thread. Thus, the child thread having a dependency relationship with the main thread can be named as the target child thread. During the process of the scenario, the type of the processor on which the target child thread runs and the length of time of running on the processor, i.e., the running duration, are determined. The type of the processor includes big cores and small cores. The first running frequency of the big core and the second running frequency of the small core are determined. For example, the running frequency of the big core is 2.0 GHz and the running frequency of the small core is 1.0 GHz. Then, for each target child thread, the ratio between the product of the running frequency, running duration, and processor computing power of the processor on which the target child thread runs and the reference value is used as the load information of the target child thread.

[0063] It should be noted that the reference value can be a benchmark value set in the electronic device, which can be a fixed value. In the embodiments of the present application, the benchmark value can be the product of the running frequency and running duration of the processor on which the designated target child thread in the application scenario runs. The designated target child thread can be the minimum value of the product of the running frequency and running duration among all the target child threads corresponding to the application scenario. That is to say, for the application scenario, the product of the running frequency and running duration of the processor on which each target child thread in the application scenario runs is determined as the target value of the target child thread. Then, the minimum target value is used as the benchmark value. Then, the ratio between the target value of each target child thread and the benchmark value is used as the first ratio. Then, the ratio between the computing power of the processor on which the target child thread corresponding to the minimum value runs and the computing power of the target child thread is obtained as the second ratio. Then, the product of the first ratio and the second ratio is used as the load information of the target child thread.

[0064] For example, assume that there is now a thread A which is a related thread of the main thread, i.e., a target sub-thread with a dependency relationship with the main thread. The scheduling information of thread A includes the processor on which thread A runs (i.e., whether it runs on a big core or a small core), the running time, and the frequency of the core where it is located. Assume that thread A runs at a frequency of 2.0 GHz on a big core for 6 ms, and thread B runs at 1.0 GHz on a small core for 3 ms. Given that the computing power of a big core is 3 times that of a small core at the same frequency on this platform, then within the same frame period, the load of thread A is (2.0 GHz / 1.0 GHz) * (6 ms / 3 ms) * 3 = 12 times that of thread B. That is to say, if thread B is used as a reference value, then the load information of thread A is 12 times that of the load of B. Thus, the load classification of each sub-thread corresponding to this application scenario can be determined. For example, sub-threads with load information greater than N times the load of B are regarded as high-load sub-threads, and sub-threads with load information less than or equal to N times the load of B are regarded as low-load sub-threads.

[0065] S202: Determine the thread scheduling strategy corresponding to each application scenario based on the scenario smoothness information of each historical application scenario and the scheduling information corresponding to the historical application scenario.

[0066] It can be understood that the scenario smoothness information of an application scenario can characterize whether the application scenario is stuck. For example, the scenario smoothness information can be represented by the frame rate in this scenario. The higher the frame rate, the higher the smoothness of this scenario. The scheduling information corresponding to the historical application scenario can characterize the load conditions of each thread on which the main thread in the application scenario depends.

[0067] As an implementation, a machine learning module is set in the electronic device. The scenario smoothness information of each historical application scenario collected by the scenario recognition module and the scheduling information corresponding to the historical application scenario collected by the scheduling collection module are sent to the machine learning module. The machine learning module is trained through the scenario smoothness information of each historical application scenario and the scheduling information corresponding to the historical application scenario, so as to learn the relationship between the thread allocation of each processing core and the smoothness of the scenario for a certain scenario.

[0068] Exemplarily, the machine learning module may adopt various models, such as a regression model, a decision tree, a random forest, a gradient boosting decision tree (GBDT), or a deep learning model, to establish the relationship between thread core selection and smoothness. Then, through training, the machine learning model learns the mapping between the load, dependency relationship, and scheduling behavior of the thread and the scenario smoothness, so as to form a preliminary scheduling strategy. The optimization strategy is that for an application scenario, within one frame output period, threads with a large load are preferentially allocated to big cores, and threads with a small load are preferentially allocated to small cores, and are preferentially executed during scheduling, and appropriate frequency modulation is performed according to the load information to ensure that the corresponding services are completed within the frame output period.

[0069] That is to say, for threads with heavy loads, they are preferentially allocated to large cores to ensure efficient execution. For threads with light loads, they are preferentially allocated to small cores to improve the energy efficiency of the system and reduce power consumption. During the frame output period, the scheduling policy needs to ensure that the priorities of threads are reasonably allocated to ensure that critical tasks can be completed on time. Specifically, based on the priorities and execution time requirements of tasks, a real-time scheduling policy can be implemented. For example, real-time graphics rendering and UI updates need to be preferentially executed to ensure completion within one frame period. For some non-real-time tasks (such as background data synchronization, etc.), they can be appropriately delayed to execute, thereby releasing more resources for real-time tasks. In addition, the implementation method of appropriately adjusting the frequency according to the load information is that when the system load is high, the frequency of the large core can be increased to ensure the efficient execution of threads. When the load is low, the frequency of the large core can be reduced, or the small core can continue to execute tasks to reduce the total power consumption of the system. For example, when it is detected that the load on the large core is high, the frequency of the large core is dynamically adjusted to provide sufficient computing power and avoid performance bottlenecks at critical moments. When the small core processes lightweight tasks, the frequency of the small core is reduced to reduce power consumption.

[0070] Therefore, the machine learning model learns the fluency and related threads, and associates the thread load with the current platform capabilities (i.e., the architecture of the processor of the current electronic device. For example, the architecture of the processor may be a combination of 2 large cores and 6 small cores, or a combination of 4 large cores and 4 small cores, or a combination of 1 super-large core, 3 large cores and 4 small cores) based on the scenario fluency information of each historical application scenario and the scheduling information corresponding to the historical application scenario.

[0071] As an implementation method, the thread scheduling policy corresponding to the application scenario may include the running policies of the target sub-threads corresponding to the main thread in the application scenario for different processors. Among them, the running policy includes the type of processor on which the target sub-thread runs and the running duration on this processor. Of course, the running policy may also include the running priority of the target sub-thread. This priority refers to the priority of the target sub-thread running on the large core. Since the resources of the large core are relatively scarce, each sub-thread will compete to use the large core. In order to avoid the main thread from being stuck due to the stuck of a certain sub-thread, therefore, a higher priority is set for some heavy-loaded sub-threads to ensure that when the sub-thread is running, it can quickly use the large core.

[0072] For example, Thread A needs to run for 3 ms before Thread B can be awakened to start running. Thread B is an overloaded thread and may require Thread A to run as short a time as possible (so the big core is selected). When the overloaded Thread B starts running, the big core is selected, but there may not be enough big cores. Therefore, Thread A needs to be migrated to the small core, and the big core is given to Thread B to run. That is to say, for the first sub-thread of the overload, if the second sub-thread runs before the first sub-thread, then the running processor of the second sub-thread is set to the big core, the running processor of the first sub-thread is set to the big core, and when the first sub-thread runs, the second sub-thread is migrated from the big core to the small core.

[0073] As another implementation, when the second sub-thread starts running, there may be many other threads already queued on the big core. However, since the second sub-thread is more likely to affect the fluency of the current application scenario compared to other threads, after the second sub-thread is awakened, it should be immediately scheduled on the big core (prioritized scheduling, and other threads continue to queue). That is, after the second sub-thread is awakened, it has the highest priority to use the big core.

[0074] S203: Determine the current target application scenario of the electronic device.

[0075] S204: Based on the pre-determined thread scheduling policies corresponding to different application scenarios, determine the target thread scheduling policy corresponding to the target application scenario.

[0076] S205: Based on the target thread scheduling policy, run at least some of the threads in the target application scenario on the processor corresponding to the thread.

[0077] Please refer to Figure 3 , this embodiment of the present application provides a performance optimization method, which is applied to the above-mentioned electronic device, and the method includes: S301 to S305.

[0078] S301: Determine the current target application scenario of the electronic device.

[0079] S302: Based on the pre-determined thread scheduling policies corresponding to different application scenarios, determine the target thread scheduling policy corresponding to the target application scenario.

[0080] As an implementation, if the target application scenario is a specified type of application scenario, then based on the pre-determined thread scheduling policies corresponding to different application scenarios, determine the target thread scheduling policy corresponding to the target application scenario. Among them, the specified type of application scenario can be set based on actual requirements.

[0081] Exemplarily, the application scenario of this specified type may refer to an application scenario related to user interaction. That is to say, the main thread of this target application scenario is a main thread related to user interaction.

[0082] As an implementation manner, the main thread corresponds to thread attributes, which may include a first attribute and a second attribute. Among them, the first attribute is used to characterize that the thread is related to user interaction, and the second attribute is used to characterize that the thread is not related to user perception. Specifically, being related to user interaction may mean having perception with at least one of the user's vision, hearing, and touch. That is to say, if a thread has the first attribute, it means that the thread is a thread related to user interaction. Then, if a thread has the second attribute, it means that the thread has nothing to do with the user's vision, hearing, and touch, that is, it does not belong to the thread related to user interaction.

[0083] Specifically, a thread related to user interaction may refer to a thread that is used to obtain operation data generated when the user operates the application, or a thread that is used to output data related to user interaction. For the former, the user operation may be a sliding operation, a click operation, etc. on a certain interface of the application. Then, if the application includes a thread that can detect the sliding operation and the click operation, then this thread belongs to the thread related to user interaction. For the latter, outputting data related to user interaction may be playing audio data, video data, etc., which are data that can be perceived by the user's hearing or vision.

[0084] In addition, the thread related to user interaction may also be a thread related to each display interface of the application, that is, a thread serving the display interface. For example, taking a certain video playback interface of the application as an example, there is a video playback control on the video playback interface. Then, the thread used to serve the video playback control so that the video playback control can play the video belongs to the thread related to user interaction.

[0085] Then, the aforementioned data related to user operations, data that can be perceived by the user, or the interfaces displayed by the application all belong to the data related to user interaction for the user. Therefore, compared with some threads running in the background without interaction with the user, if the threads that can generate or obtain these data cause lags, the user can strongly perceive it.

[0086] Therefore, if the main thread of the target application scenario belongs to the thread related to user interaction, it is determined that the target application scenario is an application scenario of the specified type; otherwise, it is determined that the target application scenario does not belong to the application scenario of the specified type.

[0087] S303: Based on the target thread scheduling policy, run at least some of the threads in the target application scenario on the processor corresponding to the thread.

[0088] S304: Determine the scene smoothness information corresponding to the target application scenario to which the target thread scheduling policy has been applied.

[0089] S305: Optimize the target thread scheduling policy based on the scene smoothness information.

[0090] Specifically, as Figure 4 shown, the electronic device includes a scene recognition module, a scheduling collection module, a machine learning module, and a customized scheduling module. The scene recognition module is used to recognize the scene in which the application is currently located and the frame rate smoothness in this scene. The scenes include but are not limited to sliding and switching. The scheduling collection module is used to collect the application core UI thread and its inter-thread dependency relationship in the same scene according to the scene recognition result, form a thread service dependency tree, and further perform scheduling information statistics on these related threads and classify them according to the load. The machine learning module is used to form a preliminary relevant thread scheduling policy based on the thread service dependency and scheduling statistical information obtained by the collection module. After that, when the scene recognition module recognizes the corresponding scene, the previously obtained core selection scheduling policy is sent to the customized scheduling module and scored according to the scene smoothness. By trying and comparing the scores, the optimal policy is obtained. The customized scheduling module is used to receive and execute the core selection scheduling policy produced by the machine learning module.

[0091] As an implementation manner, the implementation manner of determining the scene smoothness information corresponding to the target application scenario to which the target thread scheduling policy has been applied may be to obtain the frame rate smoothness of the target application scenario to which the target thread scheduling policy has been applied; based on the frame rate smoothness, determine the scene smoothness information. Specifically, in the case where the target thread scheduling policy is applied to the target application scenario, obtain the frame rate smoothness of the target application scenario. As an implementation manner, the frame rate smoothness may be the frame rate of the electronic device in the case where the target thread scheduling policy is applied to the target application scenario. When the frame rate is greater than the current screen refresh rate of the electronic device, the frame rate may be used as the frame rate smoothness. Then, use the frame rate smoothness as the scene smoothness information. That is, after running at least some threads in the target application scenario on the processor corresponding to the thread, determine the frame rate corresponding to the target application scenario to which the target thread scheduling policy has been applied, and optimize the target thread scheduling policy based on the frame rate.

[0092] Specifically, determine whether the frame rate is less than the screen refresh rate. If it is less than the screen refresh rate, optimize the target thread scheduling policy. The optimization method may refer to the foregoing optimization strategy and will not be elaborated here.

[0093] Therefore, based on the scene fluency information of historical application scenarios and the scheduling information corresponding to the historical application scenarios, through a machine learning model, it is possible to learn which threads related to the main thread have excessive loads when the scene lags, and thus it is possible to determine the overloaded child threads related to the main thread. Herein, the overloaded child thread refers to a child thread with excessive load information during its execution process. The statistical method of the load information can refer to the foregoing content, and the excessive load information means that the load information is greater than a preset threshold. Specifically, the overloaded child thread processes too many tasks, resulting in excessive consumption of system resources (such as CPU, memory, etc.), thereby affecting the performance of the system. This situation may lead to a slowdown in the system's response and even system crashes.

[0094] Exemplarily, as Figure 5 shown, the area filled with gray represents that the thread is in the running state, and the area filled with diagonal lines represents that the thread is in the ready state. For the Figure 5 application scenario shown, there is a frame drop phenomenon. As can be seen from Figure 4 this, the reason for the frame drop is that during the frame drawing process of the application main thread, it sleeps and waits for thread A to wake up. Due to reasons such as heavy overall machine load, thread A cannot be scheduled, resulting in the ready state lasting too long. When the main thread outputs a frame, it exceeds the theoretical latest frame output time, resulting in frame drop and lag.

[0095] Combined with the embodiments of the present application, a thread scheduling strategy can be set for this application scenario to make thread A execute faster. On the one hand, it can improve the running speed of thread A, that is, reduce the continuous duration of thread A in the running state. On the other hand, it can also reduce the waiting duration of thread A, that is, reduce the duration of thread A in the ready state. As Figure 6 shown, the execution priority of thread A can be set, that is, set thread A to execute first, thereby reducing the waiting duration of thread A, that is, reducing the duration of thread A in the ready state. It can be seen that through the statistical information of the scheduling collection module, thread A is identified in this application scenario and given priority scheduling, Figure 5 and the frame drop scenario can be improved.

[0096] Therefore, in the embodiments of the present application, by collecting and classifying the fluency frame rates and related scheduling statistics of different apps in various scenarios, selecting appropriate CPU cores for key business threads and scheduling them preferentially, the device performance and the user's fluency experience are improved; the information collection and training are repeated in a loop, and optimization and adjustment can be achieved in 3 to 5 days without relying on OTA upgrades, and timely adjustments can also be made to the preset information on the device side; optimization is carried out according to the user's actual usage habits and environment on the device side to achieve different configurations for different users. Fine-grained monitoring of specific user operation information, lag information of specific applications, performance resource information, etc. provides fine-grained information support for further optimization; starting from the core threads of the application, identifying dependent related business threads, and performing scheduling information statistics and classification on them, and giving scheduling guidance strategies for these associated business threads in combination with the current hardware platform capabilities (CPU architecture and computing power), so as to efficiently complete the application UI drawing task and improve the user's fluency experience.

[0097] In addition, the embodiments of the present application are not only applicable to mobile devices such as smartphones and tablets, but can also be extended to various intelligent devices such as smart watches and smart home devices to achieve collaborative optimization between multiple devices; designing special optimization strategies for different types of application programs (such as games, video playback, office software, etc.) to achieve hierarchical optimization under a unified framework; by uploading the collected fine-grained information, the cloud server analyzes and processes the data of a large number of user devices to provide a customized optimization solution for each user device to achieve personalized optimization effects; being compatible with devices of different operating systems (such as Android, iOS, Windows, etc.) and providing a unified cross-platform optimization algorithm.

[0098] Please refer to Figure 7 , which shows a structural block diagram of a performance optimization device 700 provided by the embodiments of the present application. The device may include: a determination unit 701, an acquisition unit 702, and an execution unit 703.

[0099] The determination unit 701 is configured to determine the current target application scenario of the electronic device.

[0100] The acquisition unit 702 is configured to determine the target thread scheduling policy corresponding to the target application scenario based on the thread scheduling policies corresponding to different pre-determined application scenarios, where the thread scheduling policy corresponding to the application scenario includes the usage policies of at least some threads participating in the application scenario for different processors when the application scenario meets the normal operation condition.

[0101] Further, the obtaining unit 702 is further configured to determine the scene fluency information of multiple historical application scenarios in which the electronic device operates within a preset time period, and the scheduling information corresponding to each historical application scenario, where the scheduling information includes the processors on which the respective threads participating in the application scenario run and the load information; based on the scene fluency information of each historical application scenario and the scheduling information corresponding to the historical application scenario, determine the thread scheduling policy corresponding to each application scenario.

[0102] Further, the scheduling information includes the main thread participating in the application scenario, the child threads dependent on the main thread, the processors on which the respective threads run, and the load information, and the thread scheduling policy is used to ensure the normal operation of the main thread of the application scenario.

[0103] Further, the main thread is a thread for updating and interacting with the user interface of the application scenario.

[0104] Further, if the target application scenario is an application scenario of a specified type, the obtaining unit 702 is further configured to determine the target thread scheduling policy corresponding to the target application scenario based on the thread scheduling policies corresponding to different application scenarios determined in advance.

[0105] The execution unit 703 is configured to run at least some of the threads in the target application scenario on the processor corresponding to the thread based on the target thread scheduling policy.

[0106] Further, the execution unit 703 is further configured to determine the scene fluency information corresponding to the target application scenario to which the target thread scheduling policy has been applied; optimize the target thread scheduling policy based on the scene fluency information.

[0107] Further, the execution unit 703 is further configured to obtain the frame rate fluency of the target application scenario to which the target thread scheduling policy has been applied; determine the scene fluency information based on the frame rate fluency.

[0108] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the foregoing method embodiments, and will not be described herein again.

[0109] In several embodiments provided in the present application, the coupling between modules may be electrical, mechanical, or other forms of coupling.

[0110] In addition, in each embodiment of the present application, the various functional modules may be integrated into one processing module, or each module may exist physically alone, or two or more modules may be integrated into one module. The above-mentioned integrated modules may be implemented in the form of hardware or in the form of software functional modules.

[0111] Please refer to Figure 8 , which shows a structural block diagram of an electronic device provided in an embodiment of the present application. The electronic device 100 may be an electronic device capable of running application programs such as a smart phone, a tablet computer, an e-book, etc. The electronic device 100 in the present application may include one or more of the following components: a processor 110, a memory 120, and one or more application programs, where one or more application programs may be stored in the memory 120 and configured to be executed by one or more processors 110, and one or more programs are configured to execute the methods described in the foregoing method embodiments.

[0112] The processor 110 may include one or more processing cores. The processor 110 uses various interfaces and lines to connect various parts within the entire electronic device 100, and by running or executing instructions, programs, code sets, or instruction sets stored in the memory 120, and calling data stored in the memory 120, it executes various functions of the electronic device 100 and processes data. Optionally, the processor 110 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The processor 110 may integrate one or several combinations of a central processing unit (CPU), a graphics processing unit (GPU), and a modem, etc. Among them, the CPU mainly processes the operating system, user interface, application programs, etc.; the GPU is responsible for rendering and drawing the displayed content; the modem is used to process wireless communication. It can be understood that the above-mentioned modem may not be integrated into the processor 110 and may be implemented separately by a communication chip.

[0113] The memory 120 may include random access memory (RAM), and may also include read-only memory. The memory 120 may be used to store instructions, programs, codes, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area. Among them, the program storage area may store instructions for implementing the operating system, instructions for implementing at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the following various method embodiments, etc. The data storage area may also store data created during the use of the electronic device 100 (such as phone book, audio and video data, chat record data, etc.).

[0114] Please refer to Figure 9 , which shows a structural block diagram of a computer-readable medium provided by an embodiment of the present application. Program code is stored in the computer-readable medium 900, and the program code can be called by a processor to execute the method described in the above method embodiment.

[0115] The computer-readable medium 900 can be an electronic memory such as a flash memory, EEPROM (electrically erasable programmable read-only memory), EPROM, hard disk, or ROM. Optionally, the computer-readable medium 900 includes a non-transitory computer-readable storage medium. The computer-readable medium 900 has a storage space for the program code 910 that executes any of the method steps in the above method. These program codes can be read from or written into one or more computer program products. The program code 910 can be compressed in an appropriate form, for example.

[0116] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and are not intended to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A performance optimization method, characterized in that: Applied to an electronic device, the electronic device includes a plurality of processors, and the method includes: Determining a current target application scenario of the electronic device; Determine a target thread scheduling strategy corresponding to the target application scenario based on the predetermined thread scheduling strategies corresponding to different application scenarios, wherein the thread scheduling strategy corresponding to the application scenario includes a usage strategy for different processors for at least some threads participating in the application scenario when the application scenario satisfies normal operation; Based on the target thread scheduling policy, at least part of the threads in the target application scenario are run on the processor corresponding to the thread.

2. The method according to claim 1, characterized in that Before determining the target thread scheduling strategy corresponding to the target application scenario based on the thread scheduling strategies corresponding to the predetermined different application scenarios, the method further includes: Determine scene fluency information of multiple historical application scenes run by the electronic device within a preset time period, and scheduling information corresponding to each historical application scene, wherein the scheduling information includes processors and load information of each thread running in the application scene; Based on the scene fluency information of each historical application scene and the scheduling information corresponding to the historical application scene, a thread scheduling strategy corresponding to each application scene is determined.

3. The method according to claim 2, characterized in that The scheduling information includes the main thread participating in the application scenario, the sub-threads having a dependency relationship with the main thread, the processors on which each thread runs, and load information. The thread scheduling strategy is used to ensure the normal operation of the main thread of the application scenario.

4. The method according to claim 3, characterized in that The main thread is a thread used for updating and interacting with the user interface of the application scenario.

5. The method according to any one of claims 1 to 4, characterized in that: After running at least part of the threads in the target application scenario on the processor corresponding to the thread based on the target thread scheduling policy, the method further includes: Determine scene fluency information corresponding to a target application scene to which the target thread scheduling strategy has been applied; Based on the scene fluency information, the target thread scheduling strategy is optimized.

6. The method according to claim 5, characterized in that The determining of the scene fluency score corresponding to the target application scene to which the target thread scheduling policy has been applied includes: Obtaining the frame rate smoothness of the target application scenario to which the target thread scheduling strategy has been applied; Based on the frame rate smoothness, the scene smoothness information is determined.

7. The method according to any one of claims 1 to 4, characterized in that: The determining of the target thread scheduling strategy corresponding to the target application scenario based on the predetermined thread scheduling strategies corresponding to different application scenarios includes: If the target application scenario is an application scenario of a specified type, a target thread scheduling policy corresponding to the target application scenario is determined based on predetermined thread scheduling policies corresponding to different application scenarios.

8. A performance optimization device, characterized in that: Applied to an electronic device, the electronic device includes a plurality of processors, and the device includes: A determination unit, configured to determine a current target application scenario of the electronic device; An acquisition unit is used to determine a target thread scheduling strategy corresponding to the target application scenario based on the predetermined thread scheduling strategies corresponding to different application scenarios, wherein the thread scheduling strategy corresponding to the application scenario includes a usage strategy for different processors for at least some threads participating in the application scenario when the application scenario satisfies normal operation; The execution unit is used to run at least part of the threads in the target application scenario on the processor corresponding to the thread based on the target thread scheduling policy.

9. An electronic device, characterized in that: include: one or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, and the one or more applications are configured to execute the method according to any one of claims 1-7.

10. A computer-readable medium, characterized in that The computer-readable medium stores a program code executable by a processor, and when the program code is executed by the processor, the processor executes the method according to any one of claims 1 to 7.

Images