Thread scheduling method and device

Abstract

The embodiment of the invention provides a thread scheduling method and device.The method comprises the steps that at the first moment, in response to a first instruction, terminal equipment modifies the processing priority of a second thread from a first priority to a second priority before executing a first task on the basis of the first instruction, the processing priority of the second priority is higher than the processing priority of the first priority, the second thread carries a first identifier after the first moment, the first identifier is used for indicating that the second thread is in a priority improvement state, and the first instruction is an instruction corresponding to the first task; the terminal equipment executes the first task based on a second thread with a second priority; and at the second moment, when the terminal equipment determines that no to-be-executed task exists in the second thread and the second thread carries the first identifier, the terminal equipment does not recover the processing priority of the second thread. In this way, the terminal equipment can delay recovery of the processing priority of the second thread so as to reduce runnable situations of the second thread.

Description

Thread scheduling method and device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on May 29, 2023, with application number 202310623835.1 and application name “Thread Scheduling Method and Device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of terminal technology, and in particular to a thread scheduling method and device. Background Art

[0003] With the development of terminal technology, terminal devices have become an important tool in people's lives. Terminal devices need to perform multiple tasks. For example, when processing a task, the terminal device will cache the task data in the cache area and process the task based on the task data in the cache area. Then, after processing the task, the terminal device releases the task data in the cache area.

[0004] In the prior art, a terminal device releases task data in a cache area based on a binder thread; the binder thread needs to wait to be scheduled before it can release the task data in the cache area.

[0005] However, the above thread scheduling method may cause the binder thread to be unable to be scheduled in time, resulting in the terminal device being unable to process new tasks in time.

[0006] Summary of the Invention

[0007] The embodiments of the present application provide a thread scheduling method and apparatus, so that a terminal device can delay the restoration of the processing priority of a second thread to reduce the runnable situation of the second thread.

[0008] In a first aspect, an embodiment of the present application provides a thread scheduling method, which is applied to a terminal device, wherein a first process and a first thread are running in the terminal device, the first thread is a thread for processing tasks, the first process includes a second thread, the second thread is a binder thread, and the second thread includes: a first task, the method comprising: at a first moment, in response to a first instruction, the terminal device, based on the first instruction, modifies the processing priority of the second thread from the first priority to the second priority before executing the first task, wherein the processing priority of the second priority is higher than the processing priority of the first priority, after the first moment, the second thread carries a first identifier, the first identifier is used to indicate that the second thread is in a priority-enhanced state, and the first instruction is an instruction corresponding to the first task shown; the terminal device executes the first task based on the second thread with the second priority; at a second moment, when the terminal device determines that there is no task to be executed in the second thread and the second thread carries the first identifier, the terminal device does not restore the processing priority of the second thread. In this way, the terminal device can delay the restoration of the processing priority of the second thread to reduce the runnable situation of the second thread.

[0009] In one possible implementation, the second thread also includes a second task. After the second moment, the method also includes: at a third moment, in response to the second instruction, when the terminal device determines based on the second instruction that the processing priority of the second thread is changed from the first priority to the second priority, and the terminal device is in the second priority after the second moment, the terminal device does not restore the processing priority of the second thread, and executes the second task based on the second thread with the second priority, and the second instruction is an instruction corresponding to the second task; or, when the terminal device determines based on the second instruction not to change the processing priority of the second thread from the first priority to the second priority, and the terminal device is in the second priority after the second moment, the terminal device restores the second priority to the first priority, and executes the second task based on the second thread with the first priority.

[0010] It is understandable that before the binder thread in the terminal device executes the next task, the binder driver can determine whether to restore the processing priority of the binder thread, so that the priority restoration process is delayed from the end of the current task to the start of the next task, so as to better solve the problem of long runnable time caused by restoring the priority after the end of the current task.

[0011] In one possible implementation, the second instruction includes one or more of the following: a binder communication number, an interface descriptor, or an asynchronous communication identifier, the binder communication number is used to indicate a communication interface, the interface descriptor is used to indicate a client and a server for communication, and the asynchronous communication identifier is used to indicate a communication mode. The terminal device determines based on the second instruction that the processing priority of the second thread is changed from the first priority to the second priority, including: when the second thread is determined based on the second instruction and the second thread meets a preset condition, the terminal device changes the processing priority of the second thread from the first priority to the second priority, wherein the preset condition includes one or more of the following: the communication interface indicated by the binder communication number is the communication interface between the first thread and the second thread, the interface descriptor indicates that the client for communication is the first thread and the server for communication is the second thread, or the asynchronous communication identifier indicates that the first thread and the second thread are asynchronous binder communications. In this way, the terminal device can accurately identify a certain fixed binder call, so that the terminal device can improve the accuracy of priority processing for the binder thread.

[0012] In one possible implementation, after the first moment and before the third moment, a third thread is running in the terminal device. The third thread is a thread initiated by the second thread for the binder call. The third thread includes: a fourth task. The method further includes: the terminal device inserts the third task into the queue executed by the second thread based on the third thread; in response to a third instruction, when the terminal device determines to restore the processing priority of the second thread based on the third instruction and the third task meets the preset first task type, the terminal device does not restore the processing priority of the second thread, the third instruction being an instruction corresponding to the third task; the terminal device executes the third task based on the second thread with the second priority; and the terminal device executes the fourth task. In this way, before executing a task, the binder driver in the terminal device can determine the processing priority of the binder call based on S703-S704 and filter out the preset tasks that cause the binder thread to restore its priority in advance, thereby reducing the number of times the binder thread is in a runnable state.

[0013] In a possible implementation, the first task type includes: a task type used to indicate that a communication transaction is completed and handed over to the initiating end for processing, and / or a task type used to indicate that a communication transaction fails and is handed over to the initiating end for processing.

[0014] In one possible implementation, after the first moment and before the third moment, a fourth thread is running in the terminal device. The fourth thread is a thread that initiates a synchronous binder call initiated by the second thread. The fourth thread includes: a fifth task. The method further includes: after the terminal device executes the fifth task, inserting a sixth task into the second thread, the sixth task is used to instruct the terminal device to complete processing of the fifth task; in response to a fourth instruction, when the terminal device determines to restore the processing priority of the second thread based on the fourth instruction and the sixth task meets the preset second task type, the terminal device does not restore the processing priority of the second thread, the fourth instruction is an instruction corresponding to the sixth task; the terminal device executes the sixth task based on the second thread with the second priority; and the terminal device executes the fifth task. In this way, before executing a task, the binder driver in the terminal device can determine the processing priority of the binder call based on S703-S704 and filter out the preset tasks that cause the binder thread to restore its priority in advance, so as to reduce the number of times the binder thread is in a runnable state.

[0015] In a possible implementation, the second task type includes: a task type replied by the server.

[0016] In one possible implementation, the first task is a task identified by the terminal device during an asynchronous binder call, and the second thread also includes: a seventh task, the seventh task is a task identified by the terminal device during a synchronous binder call, and before the second moment, the second thread carries a second identifier, and the second identifier is used to indicate that the second thread is an asynchronous binder call. Before the second moment and after the first moment, the method also includes: at the fourth moment, in response to the fifth instruction, when the terminal device detects the seventh task and the second thread with the second identifier, the terminal device restores the processing priority of the second thread before executing the seventh task, and the fifth instruction is the instruction corresponding to the seventh task; at the fifth moment, the terminal device changes the processing priority of the second thread from the first priority to the second priority, and processes the seventh task based on the second priority; after the fourth moment, the second thread is in a synchronous binder call state in the first time period after the fifth moment, and the second thread is in an asynchronous binder call state between the fourth moment and the fifth moment. In this way, when the terminal device detects a conflict between the task identified by the synchronous binder and the task identified by the asynchronous binder, it first restores the processing priority of the asynchronous call, and then improves the processing priority of the synchronous call. It can be understood that for a period of time after the binder driver improves the processing priority of the binder thread's synchronous call, the binder thread follows the synchronous binder call scheme.

[0017] In a possible implementation, after the fifth moment, the method further includes: at a sixth moment, the terminal device restores the processing priority of the second thread, and the processing priority of the second thread is at the first priority in a second time period after the sixth moment.

[0018] In one possible implementation, the first thread is a thread for image synthesis, and the first process is a process for image drawing; or, the first process is a process for generating window data of window information, and the first thread is a thread for updating system window information.

[0019] In the second aspect, an embodiment of the present application provides a thread scheduling device, in which a first process and a first thread are running, the first thread is a thread for processing tasks, the first process includes a second thread, the second thread is a binder thread, and the second thread includes: a first task, a first moment, in response to a first instruction, the processing unit modifies the processing priority of the second thread from the first priority to the second priority based on the first instruction before executing the first task, wherein the processing priority of the second priority is higher than the processing priority of the first priority, and after the first moment, the second thread carries a first identifier, the first identifier is used to indicate that the second thread is in a state of increased priority, and the first instruction is an instruction corresponding to the first task shown; an execution unit is also used to execute the first task based on the second thread with the second priority; at the second moment, when the terminal device determines that there is no task to be executed in the second thread and the second thread carries the first identifier, the processing unit does not restore the processing priority of the second thread.

[0020] In a third aspect, an embodiment of the present application provides a terminal device, comprising: a processor and a memory, wherein the memory is used to store a computer program; the processor is used to call and execute the computer program so that the terminal device performs the method in the first aspect and any possible implementation thereof.

[0021] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium for storing a computer program. When the computer program is run on a computer, the computer executes the method in the first aspect and any possible implementation thereof.

[0022] In a fifth aspect, the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the method in the first aspect and any possible implementation thereof.

[0023] It can be understood that the beneficial effects of the above-mentioned second to fifth aspects can refer to the beneficial effects of the first aspect and any possible implementation thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] FIG1 is a schematic diagram of the hardware structure of a terminal device provided in an embodiment of the present application;

[0025] FIG2 is a schematic diagram of a software structure of a terminal device provided in an embodiment of the present application;

[0026] FIG3 is a schematic diagram of a process for displaying an image on a terminal device according to an embodiment of the present application;

[0027] FIG4 is a schematic diagram of a flow chart of an asynchronous binder call provided in an embodiment of the present application;

[0028] FIG5 is a flow chart of a method for increasing priority in an asynchronous binder call provided by an embodiment of the present application;

[0029] FIG6 is a schematic diagram of viewing thread status from a trace tool according to an embodiment of the present application;

[0030] FIG7 is a flow chart of a thread scheduling method provided in an embodiment of the present application;

[0031] FIG8 is a schematic diagram of another method of viewing thread status from a trace tool according to an embodiment of the present application;

[0032] FIG9 is a schematic diagram of another method of viewing thread status from a trace tool according to an embodiment of the present application;

[0033] FIG10 is a schematic diagram of another method of viewing thread status from a trace tool according to an embodiment of the present application;

[0034] FIG11 is a schematic diagram of another method of viewing thread status from a trace tool according to an embodiment of the present application;

[0035] FIG12 is a schematic diagram of a scenario in which a synchronous call and an asynchronous call conflict, provided by an embodiment of the present application;

[0036] FIG13 is a schematic diagram of another method of viewing thread status from a trace tool according to an embodiment of the present application;

[0037] FIG14 is an architectural diagram 1 of a thread scheduling method based on a terminal device provided in an embodiment of the present application;

[0038] FIG15 is a second architecture diagram of a thread scheduling method based on a terminal device provided in an embodiment of the present application;

[0039] FIG16 is a schematic structural diagram of a thread scheduling device provided in an embodiment of the present application;

[0040] FIG17 is a schematic diagram of the hardware structure of another terminal device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0041] In order to clearly describe the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. For example, the first value and the second value are merely used to distinguish different values ​​and do not limit their order. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit different values.

[0042] It should be noted that, in this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described in this application as "exemplary" or "for example" should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0043] In this application, "at least one" means one or more, and "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers 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 mean: a, b, c, a and b, a and c, b and c, or a, b and c, where a, b, c can be single or multiple.

[0044] It should be noted that the "at..." in the embodiments of the present application can be the instant when a certain situation occurs, or it can be a period of time after the situation occurs, and the embodiments of the present application do not specifically limit this. In addition, the display interface provided in the embodiments of the present application is only an example, and the display interface can also include more or less content.

[0045] In order to better understand the embodiment of the present application, the structure of the terminal device of the embodiment of the present application is introduced below. For example, Figure 1 is a schematic diagram of the hardware structure of a terminal device provided in the embodiment of the present application.

[0046] The terminal device can be called a terminal, user equipment (UE), mobile station (MS), mobile terminal (MT), etc. For example, the terminal device can be a mobile phone, a smart TV, a wearable device, a tablet computer (Pad), a computer with wireless transceiver function, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical surgery, a wireless terminal in smart grid, a wireless terminal in transportation safety, a wireless terminal in smart city, a wireless terminal in smart home, etc. The embodiments of the present application do not limit the specific technology and specific device form adopted by the terminal device.

[0047] As shown in Figure 1, the terminal device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, an indicator 192, a camera 193, and a display screen 194, etc.

[0048] The sensor module 180 may include one or more of the following, for example: a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, or a bone conduction sensor.

[0049] It is understood that the structures illustrated in the embodiments of the present application do not constitute specific limitations on the terminal device. In other embodiments of the present application, the terminal device may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0050] The processor 110 may include one or more processing units. The different processing units may be independent devices or integrated into one or more processors. The processor 110 may also be provided with a memory for storing instructions and data.

[0051] The USB interface 130 is an interface that complies with USB standards and specifications, and may be a Mini USB interface, a Micro USB interface, a USB Type-C interface, or the like. The USB interface 130 can be used to connect a charger to charge the terminal device, or to transfer data between the terminal device and peripheral devices. It can also be used to connect headphones to play audio. The interface can also be used to connect other devices, such as AR devices.

[0052] The charging management module 140 is used to receive charging input from a charger. The charger can be a wireless charger or a wired charger. The power management module 141 is used to connect the charging management module 140 to the processor 110.

[0053] The wireless communication function of the terminal device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160 and baseband processor.

[0054] Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. The antennas in a terminal device can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization.

[0055] Mobile communication module 150 provides wireless communication solutions for terminal devices, including 2G / 3G / 4G / 5G. It can include at least one filter, switch, power amplifier, and low-noise amplifier (LNA). Mobile communication module 150 receives electromagnetic waves from antenna 1, filters and amplifies them, and transmits them to a modem for demodulation.

[0056] The wireless communication module 160 can provide wireless communication solutions applied to terminal devices, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), etc.

[0057] The modem may include a modulator and a demodulator. The modulator is used to modulate the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After being processed by the baseband processor, the low-frequency baseband signal is passed to the application processor. The application processor outputs a sound signal through an audio device (not limited to a speaker, a receiver, etc.) or displays an image or video through the display screen 194. In some embodiments, the modem may be an independent device. In other embodiments, the modem may be independent of the processor 110 and be set in the same device as the mobile communication module 150 or other functional modules.

[0058] The terminal device implements display functions through a GPU, display screen 194, and an application processor. The GPU is a microprocessor for image processing that connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering.

[0059] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. In some embodiments, the terminal device may include 1 or N display screens 194, where N is a positive integer greater than 1.

[0060] The terminal device can realize the shooting function through the ISP, camera 193, video codec, GPU, display 194 and application processor.

[0061] The camera 193 is used to capture static images or videos. In some embodiments, the terminal device may include 1 or N cameras 193, where N is a positive integer greater than 1.

[0062] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the terminal device. The external memory card communicates with the processor 110 via the external memory interface 120 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.

[0063] The internal memory 121 can be used to store computer executable program codes, which include instructions. The internal memory 121 can include a program storage area and a data storage area.

[0064] The terminal device can implement audio functions such as music playback and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.

[0065] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The speaker 170A, also known as the "speaker", is used to convert audio electrical signals into sound signals. The terminal device can listen to music or listen to hands-free calls through the speaker 170A. The receiver 170B, also known as the "earpiece", is used to convert audio electrical signals into sound signals. When the terminal device answers a call or voice message, the voice can be heard by placing the receiver 170B close to the human ear. The headphone jack 170D is used to connect a wired headset. The microphone 170C, also known as the "microphone" or "microphone", is used to convert sound signals into electrical signals. In an embodiment of the present application, the terminal device may have a microphone 170C.

[0066] Keys 190 include a power button, a volume button, and other buttons. Keys 190 can be mechanical or touch-sensitive. The terminal device can receive key inputs and generate key signal inputs related to user settings and function control of the terminal device. Indicator 192 can be an indicator light that can be used to indicate charging status, battery level changes, messages, missed calls, notifications, and the like.

[0067] In addition, the device also runs an operating system on top of the above components, such as the iOS operating system, the Android operating system, or the Windows operating system. Applications can be installed and run on the operating system.

[0068] The software system of the terminal device can adopt a layered architecture, event-driven architecture, micro-core architecture, micro-service architecture, or cloud architecture, etc., which will not be described in detail here. The embodiment of this application takes the Android system with a layered architecture as an example to illustrate the software structure of the terminal device.

[0069] For example, FIG2 is a schematic diagram of the software structure of a terminal device provided in an embodiment of the present application.

[0070] A layered architecture divides software into several layers, each with distinct roles and responsibilities. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

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

[0072] As shown in FIG2 , the application package may include applications such as camera, calendar, phone, map, telephone, music, settings, mailbox, video, social, etc.

[0073] The application framework layer provides an application programming interface (API) and programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0074] As shown in FIG2 , the application framework layer may include a window manager, a content provider, a resource manager, a view system, a notification manager, and the like.

[0075] The window manager is used to manage window programs. The window manager can obtain the display size, determine whether there is a status bar, lock the screen, touch the screen, drag the screen, take screenshots, etc.

[0076] Content providers are used to store and retrieve data and make it accessible to applications. Data can include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0077] The view system includes visual controls, such as those for displaying text and images. The view system is used to build applications. A display interface can consist of one or more views. For example, a display interface containing a text notification icon might include a view for displaying text and a view for displaying images.

[0078] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0079] The system library can include multiple functional modules, such as surface manager, media library, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc.

[0080] The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

[0081] The media library supports playback and recording of a variety of common audio and video formats, as well as static image files. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0082] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0083] A 2D graphics engine is a drawing engine for 2D drawings.

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

[0085] The following describes the workflow of the terminal device software and hardware by way of example, with reference to the scenario of application startup or interface switching within an application.

[0086] The following describes in detail the thread scheduling process based on an application in a terminal device provided by an embodiment of the present application in conjunction with the accompanying drawings. It should be noted that the "at..." in the embodiment of the present application can be the instant when a certain situation occurs, or it can be a period of time after the occurrence of a certain situation, and the embodiment of the present application does not specifically limit this.

[0087] Typically, the interface displayed by a terminal device relies on various internal modules for rendering, synthesis, and display. Figure 3 is a schematic diagram of the image display process of a terminal device provided in an embodiment of the present application. As shown in Figure 3, the terminal device may include an application (APP), a surface flinger, and a display driver.

[0088] The display of each frame of image in the terminal device requires three main steps: image drawing and rendering by the APP, image synthesis by the surface flinger, and image display by the display driver. Alternatively, the process from image drawing to display may also include other steps, which are not limited in the embodiments of the present application.

[0089] S301 , the APP may obtain a cache area (buffer area), draw image data, and store the drawn image data in the cache area.

[0090] The APP may include a process for implementing image drawing and rendering (or referred to as a first process), the first process being used to implement drawing and rendering of image data. For example, when the APP receives a trigger operation from a user, the APP may execute the steps shown in S301.

[0091] S302. The APP passes the drawn image data to the surface flinger.

[0092] S303 : The surface flinger performs image synthesis on the drawn image data and stores the synthesized image data in a buffer area.

[0093] It is understandable that after S303 , S304 and S306 may be executed simultaneously or sequentially, and this is not specifically limited in the embodiments of the present application.

[0094] S304 : The surface flinger transmits the synthesized image data to the display driver.

[0095] S305: The display driver performs image display.

[0096] S306 : After passing the completed image data to the display driver, the surface flinger may initiate a request to the APP to release the cache area.

[0097] S307: The APP releases the image data in the cache area, so that the APP can subsequently cache new image data in the cache area and process and subsequently display the new image data.

[0098] In the process of S306-S307 APP releasing the image data in the cache area, the terminal device needs to call the binder thread (or second thread) in the APP for releasing the cache area for processing, and the surface flinger and the APP need to call the binder thread through the binder driver in the kernel kernel. For the specific asynchronous binder call process, please refer to the embodiment corresponding to Figure 4.

[0099] FIG4 is a flow chart of an asynchronous binder call provided in an embodiment of the present application.

[0100] The asynchronous binder call process may involve: client thread, server thread, binder driver in the kernel layer and libbinder.so in the native layer. The client thread may be the surface flinger thread (or first thread) in the surface flinger, and the server thread may be the binder process (or second thread) in the app.

[0101] The specific implementation of the S306-S307 process can be: the surface flinger thread sends a request for releasing the cache area to the libbinder.so in the runtime layer (or native layer), and the request for releasing the cache area can be used to initiate an asynchronous binder call. Native can send the asynchronous binder call to the binder driver through the ioctl command. The binder driver copies the user space data transmitted in the ioctl command, and parses the tasks in the binder asynchronous call and the binder thread of the binder asynchronous call, thereby waking up the binder thread on the server side and sending the asynchronous binder call to the binder thread through the libbinder.so in the native layer. The binder thread releases the image data in the cache area. In a non-blocking state, the client thread and the server thread can continue to execute the steps of releasing the image data in the cache area based on the asynchronous binder call.

[0102] It is understandable that the terminal device will execute the above-mentioned asynchronous binder call process after drawing each frame, and use the binder thread to release the image data corresponding to the frame image in the cache area. The binder thread usually corresponds to a processing priority. When the processing priority of the binder thread is low and the terminal device is in a high-load scenario, the execution order of other threads with higher priority than the binder thread will be higher than the binder thread, resulting in the binder thread taking longer to release the cache area, and being in a long waiting state (or runnable state) while waiting for the cache area to be released, thereby affecting the subsequent drawing, synthesis and display process of the image frame, causing the terminal device to experience screen freezes. Among them, the runnable state refers to the state where the thread can run but needs to continue waiting for CPU scheduling.

[0103] Therefore, in order to solve the problem of screen freeze in terminal devices due to the low processing priority of the binder thread, the embodiment of the present application can provide a method for increasing the priority in asynchronous binder calls (see the embodiment corresponding to Figure 5), so that the terminal device can accurately identify the binder thread used to release the cache area in the APP, and increase the processing priority of the binder thread, so that the binder thread can process tasks at a high priority to improve subsequent screen freezes.

[0104] For example, FIG5 is a flowchart of a method for increasing priority in an asynchronous binder call provided in an embodiment of the present application.

[0105] S501: The surface flinger thread sends a request for releasing a cache area to the binder driver. The request for releasing the cache area is an asynchronous binder call.

[0106] Among them, the asynchronous binder call can be a binder_ioctl command, which is used to carry one or more of the following information in the request to release the cache area: an asynchronous communication identifier, a binder communication number, or an interface descriptor, etc. The asynchronous communication identifier is used to indicate that the binder call is an asynchronous call, the binder communication number is used to indicate the communication interface, and the interface descriptor is used to indicate the client and server for communication.

[0107] S502: The binder driver copies user space data and parses asynchronous binder calls.

[0108] S503: The binder driver determines whether to increase the processing priority of the binder thread.

[0109] When the asynchronous binder call meets the preset conditions, the binder driver changes the processing priority of the binder thread from the first priority to the second priority; or when the asynchronous binder call does not meet the preset conditions, the binder driver maintains the first priority. The second priority is higher than the first priority. The binder driver can determine whether to change the processing priority of the binder thread based on information carried in the request for releasing the cache area.

[0110] Exemplarily, the preset conditions include one or more of the following: the communication interface indicated by the binder communication number is the communication interface between the surface flinger thread and the binder thread, the interface descriptor indicates that the client for communication is the surface flinger thread and the server for communication is the binder thread, or the asynchronous communication identifier indicates that the communication between the surface flinger thread and the binder thread is asynchronous binder communication.

[0111] In one implementation, if it is determined that the communication interface indicated by the binder communication number is the communication interface between the surface flinger thread and the binder thread, and the interface descriptor indicates that the initiator of the communication is the surface flinger thread and the processing end of the communication is the first process, the processing priority of the binder thread is modified from the first priority to the second priority.

[0112] In another implementation, if it is determined that the communication interface indicated by the binder communication number is the communication interface between the surface flinger thread and the binder thread, and the interface descriptor indicates that the initiator of the communication is the surface flinger thread and the processing end of the communication is the first process, and the asynchronous communication identifier indicates that the communication between the surface flinger thread and the first process is asynchronous binder communication, then the processing priority of the binder thread is modified from the first priority to the second priority.

[0113] Furthermore, the binder driver may wake up the binder after modifying the priority of the binder thread, and then execute the step shown in S504.

[0114] S504: The binder driver initiates an asynchronous binder call to the binder thread.

[0115] S505: The binder thread releases the image data in the cache area.

[0116] After the binder thread releases the image data in the cache area, the binder thread may return to the binder driver (as shown by the dotted line after S505 ), causing the binder driver to execute the subsequent steps shown in S506 .

[0117] S506: The binder driver determines whether to restore the processing priority of the binder thread.

[0118] For example, when the binder thread is in an idle state, the binder driver will restore the processing priority of the binder thread, so that the processing priority of the binder thread is restored from the second priority to the first priority; or, when the binder thread is not in an idle state, the binder driver does not restore the processing priority of the binder thread, and the processing priority of the binder thread is still at the second priority.

[0119] The fact that the binder thread is in an idle state can be understood as there being no tasks (work) to be executed in the binder thread, and the fact that the binder thread is not in an idle state can be understood as there being tasks to be executed in the binder thread.

[0120] Based on the solution of improving the binder thread processing priority in the embodiment corresponding to FIG5 , the binder driver can accurately identify the binder thread used to release the cache area in S503 and improve the processing priority of the binder thread before waking up the binder thread, so that the binder thread can run at a high priority. In addition, after the binder thread finishes running the current task in the queue, the binder driver determines whether the binder thread is currently in an idle state. If it is in an idle state, the binder thread processing priority is restored. If it is not in an idle state, the binder thread processing priority is not restored.

[0121] However, the embodiment corresponding to FIG5 has the following problems:

[0122] Problem 1: In S506, the binder driver does not restore the binder thread's processing priority when the binder thread is not idle, leaving the binder thread at a high priority. When the binder thread processes tasks in the queue, it can occupy important resources in the terminal device due to its high priority. This reduces the device resources available to other threads, affecting their ability to run.

[0123] Problem 2: In S506, when the binder thread is in the idle state, the binder driver will restore the binder thread's processing priority, causing the binder thread to be in a low priority state. Other high-priority threads running in the terminal device will preempt the CPU, causing the binder thread to switch from the running state to the runnable state. When the terminal device is heavily loaded, the runnable state will be longer, affecting the subsequent execution of the binder thread.

[0124] Regarding question 2, Figure 6 is a schematic diagram of viewing the thread status from a trace tool provided in an embodiment of the present application. The trace tool can be understood as a tool for viewing the running status of each process (or thread) in the CPU of a terminal device, and the horizontal direction in the trace can be understood as a timeline.

[0125] As shown in the first row of Figure 6, the binder thread 601 can be in the running state or the runnable state at different time periods. As shown in the second row of Figure 6, the specific binder thread 601 can execute the task of releasing the image data in the cache area during the running state.

[0126] It is understandable that since the binder thread 601 is in an idle state, the binder driver can restore its priority, and other high-priority threads in the terminal device preempt the CPU, causing the binder thread 601 to be in a runnable state for a period of time after the task is executed.

[0127] The runnable time period before the running state can be understood as the time period when the binder thread 601 is queuing for CPU scheduling, and the running time period after the last runnable state can be understood as the time period when the binder thread 601 is finishing its work.

[0128] In a possible implementation, FIG6 may also include other tasks running in the binder thread 601, which is not limited in the embodiments of the present application.

[0129] In view of the problem described in the embodiment corresponding to Figure 5, an embodiment of the present application provides a thread scheduling method, so that after the binder thread completes the current task, the binder driver can determine that the binder thread is in an idle state and the binder thread has previously increased its priority. It does not restore the priority of the binder thread, so that the binder thread can restore the priority by delaying, thereby reducing the runnable situation of the binder thread.

[0130] Furthermore, before the binder thread executes the next task, the binder driver can determine whether to restore the processing priority of the binder thread, so that the priority restoration process is delayed from the end of the current task to the start of the next task, so as to better solve the problem of long runnable time caused by restoring the priority after the end of the current task.

[0131] The following specific embodiments are used to describe in detail the technical solution of the present application and how the technical solution of the present application solves the above technical problems. The following specific embodiments can be implemented independently or in combination with each other. For the same or similar concepts or processes, some embodiments may not be described in detail.

[0132] For example, FIG7 is a flowchart of a thread scheduling method provided in an embodiment of the present application. As shown in FIG7 , the thread scheduling method may include the following steps:

[0133] S701: The surface flinger thread sends a request for releasing a cache area to the binder driver. The request for releasing the cache area is an asynchronous binder call.

[0134] S702: The binder driver copies user space data and parses asynchronous binder calls.

[0135] S703: The binder driver determines whether to increase the processing priority of the binder thread.

[0136] When the binder driver determines to increase the processing priority of the binder thread, the binder driver may add a flag (or referred to as a first flag) for indicating the increased priority to the binder thread, and the flag may be "true".

[0137] The description in S701-S703 can be found in S501-S503 and will not be repeated here.

[0138] S704: The binder driver determines whether to restore the processing priority of the binder thread.

[0139] When the binder thread is currently at the second priority and the binder thread needs to be promoted to the second priority based on the judgment in S703 (the task in the binder thread has a label indicating that the priority needs to be promoted), the binder driver does not restore the processing priority of the binder thread, that is, the binder driver keeps the processing priority of the binder thread at the second priority.

[0140] Alternatively, when the binder thread is currently at the second priority and the binder thread does not need to increase its priority based on the judgment in S703 (the task in the binder thread does not carry a label for indicating a priority increase), the binder driver restores the priority of the binder thread, that is, the processing priority of the binder driver is modified from the second priority to the first priority.

[0141] It can be understood that S703 may be a step executed by the surface flinger thread in the binder driver, and S704 may be a step executed by the binder thread after the binder driver wakes up the binder thread.

[0142] It is understandable that the binder driver can combine S703 and S704 to comprehensively determine how to handle the processing priority of the asynchronous binder call. For example, when the binder driver determines that the asynchronous binder call meets the preset conditions and the binder thread is the second priority, the second priority of the binder thread is maintained; or, when the binder driver determines that the asynchronous binder call does not meet the preset conditions and the binder is the second priority, the first priority of the binder thread is restored.

[0143] S705: The binder driver initiates an asynchronous binder call to the binder thread.

[0144] S706: The binder thread releases the image data in the cache area.

[0145] S707: When the binder thread is in an idle state and the binder thread has a flag indicating that the priority is increased, the binder driver does not restore the priority of the binder thread, that is, the binder driver maintains the second priority of the binder thread.

[0146] Similarly, when the binder thread is not in the idle state, the binder driver does not restore the binder thread's processing priority, so that the binder thread remains at the second priority. Therefore, after the binder thread can cache the image data in the area, the priority will not be restored regardless of the binder thread's current state, thereby achieving the purpose of delaying priority restoration.

[0147] In a possible implementation, after S707 , the terminal device may again implement the binder's judgment on the priority before executing the next task based on the steps shown in S701 - S704 .

[0148] In combination with the embodiment corresponding to Figure 5 and the embodiment corresponding to Figure 7, it can be understood that in the embodiment corresponding to Figure 5, the binder driver can restore the processing priority of the binder thread when the binder thread executes and releases the image data in the cache area and the binder thread is in an idle state, thereby causing the binder thread to become runnable.

[0149] In the embodiment corresponding to Figure 7, the binder driver may temporarily not restore the processing priority of the binder thread when the binder thread has completed executing the release of the image data in the cache area and the binder thread is in an idle state, and delay the judgment of restoring the priority until the binder thread processes the next task, so as to reduce the runnable problem caused by restoring the binder priority and ensure that the task of releasing the cache area can run with high priority.

[0150] For example, FIG8 is another schematic diagram of viewing the thread status from the trace tool provided in an embodiment of the present application. As shown in FIG8 , the binder thread 801 can increase the priority before executing the task for the first time, and the processing priority of the binder thread 801 is not restored after the first task ends. When the binder thread 801 executes the second task, the binder driver determines whether the priority needs to be increased based on S703 and whether the priority needs to be restored based on S704. For example, the binder driver can determine that the binder thread 801 does not need to increase the priority before executing the second task. Similarly, the binder driver performs non-restoration priority processing on the third to fifth tasks, so that the binder thread is at the second priority.

[0151] Before the binder thread 801 executes the sixth task, the binder driver determines based on the judgment of S703-S704 that the priority of the binder thread needs to be restored. Among them, the processing priority of the first running time period of the sixth task is the second priority, and the processing priority of the second running time period of the sixth task is the first priority, so as to realize the restoration of the priority.

[0152] Based on the embodiment corresponding to Figure 7, the following problems may arise, for example: when the binder thread is in the period of priority enhancement, the binder thread of the terminal device (such as the second thread) initiates other binder calls (such as initiating a third thread), the binder driver will insert the task corresponding to the other binder call into the queue of the client thread (such as the second thread), so that the binder thread restores the processing priority of the binder thread when processing the task corresponding to the other binder call. In this scenario, the binder thread may become runnable.

[0153] Typically, in the embodiment corresponding to FIG7 , when a thread initiates a binder asynchronous call, the binder driver places the current task in the task where the binder asynchronous call is located, and inserts a work indicating the completion of the communication transaction into the task queue of the client thread to notify the client thread of the binder asynchronous call.

[0154] It is understandable that each process may include multiple binder threads, which are used to communicate with binder threads in other processes. Binder threads are managed uniformly in the binder driver, and the queue corresponding to any binder thread may include tasks that the binder thread needs to complete.

[0155] However, when the binder thread (such as the second thread) initiates other binder calls (such as initiating the third thread) during the period of priority increase, the binder driver will insert a task for indicating the completion of the communication transaction into the queue where the binder thread (such as the second thread) is located. The binder driver restores the processing priority of the binder thread (such as the second thread) based on the task for indicating the completion of the communication transaction, causing the binder thread to become runnable.

[0156] When a binder thread (such as the second thread) initiates a synchronous binder call (such as initiating the fourth thread) during the priority increase period, the binder thread will receive the binder reply work after the task is completed. The binder driver will insert the binder reply work into the queue where the binder thread is located. The binder driver restores the processing priority of the binder thread based on the binder reply work, causing the binder thread to become runnable.

[0157] The period during which the binder thread is in a priority enhancement period can be understood as the period from when the binder thread starts executing the first task to when the binder thread starts executing the second task.

[0158] 9 is a schematic diagram of another embodiment of the present invention to view the thread status from the trace tool. As shown in FIG9, the binder 901 can be in a priority-enhanced state in the solid-line frame 900. At this time, the processing priority of the binder 901 can be 97.

[0159] When binder901 is in the process of priority enhancement, when binder901 initiates a call to binder902, the binder driver will insert a work in binder902 and insert a task in binder901 to indicate the completion of the communication transaction. The binder driver restores the priority of binder901 in advance based on the task in binder901 to indicate the completion of the communication transaction, for example, restores the processing priority of binder901 to 120, and further uses binder901 to execute the task to indicate the completion of the communication transaction. It can be understood that the processing priority of binder901 in the subsequent running process can be 120, and binder901 may be blocked after the priority is restored. Among them, the higher the priority value, the lower the level of priority processing and the later the processing time.

[0160] In view of this, an embodiment of the present application provides a process scheduling method so that when the binder driver executes a task, while determining the processing priority of the binder call based on S703-S704, it filters out preset tasks that cause the binder thread to restore its priority in advance.

[0161] The preset tasks may include: a first task type and a second task type. For example, the first task type may include: a work type for indicating that a communication transaction is completed and handed over to the initiating end for processing, and a work type for indicating that a communication transaction fails and is handed over to the initiating end for processing. The second task type may include: a work type for indicating a reply from the server.

[0162] Among them, the work used to indicate that the communication transaction is completed and handed over to the initiator for processing may include: BINDER_WORK_TRANSACTION_COMPLETE and BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT, the work type used to indicate that the communication transaction fails and is handed over to the initiator for processing may include: BINDER_WORK_RETURN_ERROR, and the work type used to indicate the server's reply may include: binder reply work. This is not limited in the embodiments of the present application.

[0163] For example, when it is determined based on S703 and S704 that the binder thread does not need to increase its priority (or it can also be understood that the processing priority of the binder driver can be restored), and the task executed by the binder thread meets the above-mentioned preset task, the binder driver may not restore the processing priority of the binder thread, so that the processing priority of the binder thread is at the second priority, so as to reduce the problem of the priority being restored in advance during the period when the binder thread is in the priority increase period.

[0164] When another binder call is initiated for the binder thread, the binder driver inserts a task for indicating the completion of the communication transaction into the queue where the binder thread is located, causing the binder thread to become runnable during the period when the priority is increased. By filtering the preset tasks, the binder thread is in the running state, see the corresponding embodiment of Figure 10.

[0165] For example, Figure 10 is another schematic diagram of viewing the thread status from the trace tool provided by an embodiment of the present application. As shown in Figure 10, when binder1001 is in the process of priority improvement, when binder1001 initiates a call to binder1002, the binder driver inserts a work into binder1002 and inserts a task for indicating the completion of the communication transaction into binder1001. When the binder driver determines that there is no need to improve the priority at present and detects that the task for indicating the completion of the communication transaction meets the preset task, the binder driver will not restore the processing priority of binder1001, so that the subsequent processing priority of binder1001 is 97 and it is always in the running state.

[0166] When another synchronous binder call is initiated for the binder thread, the binder thread receives the binder reply work, which causes the binder thread to become runnable during the priority increase period. By filtering the preset tasks, the binder thread is put into the running state, see the embodiment corresponding to Figure 11.

[0167] For example, Figure 11 is another schematic diagram of viewing the thread status from the trace tool provided by an embodiment of the present application. As shown in Figure 11, when binder1101 is in the process of priority improvement, when binder1001 initiates a synchronous binder1102 call, the binder driver inserts a work into binder1102, and after binder1102 completes the task, it replies binder reply work to binder1101. When the binder driver determines that there is no need to improve the priority at present and detects that the binder reply work meets the preset task, the binder driver will not restore the processing priority of binder1101, so that the subsequent processing priority of binder1101 is 97, and it is always in the running state.

[0168] Based on the embodiment corresponding to FIG. 7 , the following problems may occur. For example, when the terminal device executes an asynchronous binder call and a synchronous binder call at the same time, a conflict between the asynchronous binder call and the synchronous binder call may cause the screen to freeze.

[0169] The execution process of the asynchronous binder call can be seen in the embodiment corresponding to Figure 7. During the synchronous binder call process, the framework layer can pass the processing priority of the important thread to the processing priority of the server-side binder thread in the binder driver when determining that the surface flinger is a preset important thread. The binder driver can restore the processing priority of the binder thread when determining the binder thread reply.

[0170] For example, FIG12 is a schematic diagram of a scenario in which a synchronous call conflicts with an asynchronous call provided in an embodiment of the present application.

[0171] As shown in Figure 12, a is a solution based on asynchronous binder call priority increase (also called asynchronous solution). When the binder driver detects the first task, it can increase the processing priority of the binder thread (see the upward solid arrow) and restore the priority when executing the next normal task (see the downward implementation arrow).

[0172] It can be seen that after the asynchronous solution completes any first task, the priority is not restored immediately, but before executing a normal task. The first task can be understood as a task in the binder thread that meets the preset conditions described in S701.

[0173] As shown in Figure 12 (b), this is a priority-raising scheme based on synchronous binder calls (also called a synchronous scheme). When the binder driver detects the seventh task, it can raise the processing priority of the binder thread (see the upward dotted arrow) and restore the priority when executing the next normal task (see the downward dotted arrow).

[0174] It can be seen that after the synchronization scheme completes the execution of any seventh task, the priority will be restored immediately. The seventh task can be a task in an important thread preset in the synchronization binder call.

[0175] As shown in Figure 12, c is a solution based on synchronous binder calls and asynchronous binder calls to enhance the priority (also known as a conflict solution). The binder driver can execute the first task first and then the seventh task.

[0176] The process of identifying the conflicting scheme may be: before executing the first task, raising the processing priority of the binder thread, marking the binder thread with a label indicating that the asynchronous scheme is in effect, and there is no need to restore the priority in the asynchronous scheme; further, before executing the seventh task, when the binder driver identifies that the binder thread has a label, the binder driver may determine that a conflict will occur with the synchronous scheme while the asynchronous scheme is in effect.

[0177] Therefore, the binder driver can restore the processing priority of asynchronous calls before the seventh task, and then improve the processing priority of synchronous calls. It can be understood that for a period of time after the binder driver improves the processing priority of the binder thread synchronous call, the binder thread follows the synchronous binder call scheme.

[0178] Combined with the description in the embodiment corresponding to Figure 12, it can be understood that when the binder driver detects the first task first and then the seventh task, a conflict will occur. When the binder driver detects the seventh task first and then the first task, no conflict will occur.

[0179] Exemplarily, FIG13 is another schematic diagram of viewing thread status from a trace tool provided in an embodiment of the present application.

[0180] As shown in FIG13 , binder 1302 may be a client thread, binder thread 1301 may be a server thread, and binder thread 1302 may be a synchronous binder call.

[0181] The binder thread 1301 can increase the priority of the binder asynchronous call when it is in the first running state. When it detects the task identified by the synchronous binder call, it determines that a conflict has occurred, that is, the binder driver can first restore the processing priority of the asynchronous binder call, and then increase the processing priority of the synchronous binder call in the solid box where 1300 is located, and then restore the priority of the synchronous binder call.

[0182] It is understood that the thread scheduling method provided in the embodiments of the present application can be applied not only to image drawing scenarios, for example, the first thread is a thread for image synthesis, and the first process is a process for image drawing. Alternatively, the thread scheduling method provided in the embodiments of the present application can also be applied to window information updating scenarios, for example, the first process is a process for generating window data for window information, and the first thread is a thread for updating system window information.

[0183] Combined with the description in the embodiments corresponding to Figures 3 to 13 above, Figure 14 is a first architecture diagram of a thread scheduling method based on a terminal device provided in an embodiment of the present application.

[0184] As shown in Figure 14, the terminal device has a kernel layer (Kenrel), a hardware abstraction layer (HAL), a system runtime layer (native), an application framework layer (Framework), and an application layer. The hardware abstraction layer is not shown in Figure 14. The application layer exchanges information with the cloud platform.

[0185] The application layer includes multiple applications (APPs); the application layer runs a first process; and the application layer runs management software. For example, the first process may be a Launcher process.

[0186] The application framework layer includes the system's application framework. For example, if this solution is applied to the Android system, the system's application framework is the Android Framework. The application framework layer includes the process management module and, within the process management module, the non-real-time processing subsystem. The non-real-time processing subsystem includes the feature management module, the configuration management module, and the feature switch module.

[0187] The application layer interacts with the application framework layer to transmit start events (Start events), end events (End events) and feature switches.

[0188] The system runtime layer includes Libs and ART modules. Libs includes a processing module and runs the first thread (surfaceflinger thread).

[0189] The application framework layer interacts with the system runtime layer to set the feature switch value. The first process supports asynchronous biander communication. Thus, the application framework layer transmits the feature switch value to the system runtime layer.

[0190] The kernel layer includes the Linux kernel and kernel extension subsystems. The kernel layer also performs binder communication.

[0191] The system runtime layer interacts with the kernel layer to set the feature switch value. Thus, the system runtime layer passes the feature switch value to the kernel layer.

[0192] Furthermore, the kernel layer of the processor obtains the encapsulated data transmitted by the application framework layer (Framework) or the system runtime layer (native), where the encapsulated data includes the binder communication number, the interface descriptor, and the asynchronous communication identifier.

[0193] Figure 15 is a second architectural diagram of a thread scheduling method based on a terminal device provided in an embodiment of the present application. As shown in Figure 15 , the terminal device comprises a kernel layer (Kenrel), a hardware abstraction layer (HAL), a system runtime layer (native), an application framework layer (Framework), and an application layer. The hardware abstraction layer is not shown in Figure 15 . The application layer interacts with the cloud platform.

[0194] The application layer includes multiple applications (APPs), a first process running on the application layer, and management software running on the application layer. For example, the first process is a Launcher process.

[0195] The first process includes a first setting module, which is used to read the feature configuration (i.e., read the feature switch), and to send start events and end events. It can be seen that the first setting module is used to read the start information and the close information. The start information and the close information are stored in the configuration management module of the application framework layer; the feature configuration is the start information or the close information; wherein, the start information indicates the start of the priority modification of the second thread; the close information indicates the closure of the priority modification of the second thread. The start event (i.e., the first event) represents the start of the priority modification of the second thread. The end event (i.e., the second event) represents the closure of the priority modification of the second thread.

[0196] The first process sends a start event (ie, a first event) to the application framework layer based on the read start information. The first process sends an end event (ie, a second event) to the application framework layer based on the read end information.

[0197] The application layer interacts with the application framework layer to transmit start events (Start events), end events (End events) and feature switches.

[0198] The application framework layer includes the system's application framework. For example, if this solution is applied to the Android system, the system's application framework is the Android Framework. The application framework layer includes the process management module and the non-real-time processing subsystem within the process management module. The non-real-time processing subsystem includes the second settings module and the configuration management module.

[0199] The second setting module is used to obtain the feature switch value. Among them, the first process supports asynchronous biander communication. The configuration management module is used to store and read feature configurations (i.e., store and read feature switches).

[0200] The application framework layer passes the feature switch value to the system runtime layer.

[0201] The system runtime layer includes Libs and ART modules. Libs includes a processing module and runs the first thread (surfaceflinger thread).

[0202] The processing module is used to obtain the feature switch value. The first thread is used to initiate asynchronous binder communication, thereby triggering the second thread (binder thread) to trigger the release of the cache area (buffer). For example, the first thread is the surfaceflinger thread

[0203] The system runtime layer transmits the feature switch value to the kernel layer. In addition, the first thread of the system runtime layer initiates asynchronous binder communication and increases the processing priority of the second thread (binder thread).

[0204] The kernel layer includes the Linux kernel and the boost module. The Linux kernel is used to store the process ID of the Launcher process. The boost module is used to increase the processing priority of the second thread (binder thread).

[0205] The method provided in the embodiment of the present application is described above in combination with Figures 3 to 15. The device for executing the above method provided in the embodiment of the present application is described below.

[0206] Illustratively, FIG16 is a structural diagram of a thread scheduling device provided in an embodiment of the present application. The thread scheduling device may be a router in an embodiment of the present application, or a chip or chip system in a router.

[0207] As shown in FIG16 , a thread scheduling apparatus 1600 can be used in a communication device, circuit, hardware component, or chip, and includes a processing unit 1601 and an execution unit 1602. The processing unit 1601 is used to support the thread scheduling apparatus 1600 in performing information processing steps, and the execution unit 1602 is used to support the thread scheduling apparatus 1600 in performing task execution steps.

[0208] In a possible embodiment, the thread scheduling device may further include a communication unit 1603. The communication unit 1603 is used to support the thread scheduling device 1600 in executing the steps of sending and receiving data. The communication unit 1603 may be an input or output interface, a pin, or a circuit.

[0209] In a possible embodiment, the thread scheduling device may further include a storage unit 1604. The processing unit 1601 and the storage unit 1604 are connected via a circuit. The storage unit 1604 may include one or more memories, which may be devices in one or more devices or circuits for storing programs or data. The storage unit 1604 may exist independently and be connected to the processing unit 1601 of the thread scheduling device via a communication circuit. The storage unit 1604 may also be integrated with the processing unit 1601.

[0210] Storage unit 1604 can store computer-executable instructions for the method in the router, so that processing unit 1601 can execute the method in the above embodiment. Storage unit 1604 can be a register, cache, or RAM, etc. Storage unit 1604 can be integrated with processing unit 1601. Storage unit 1604 can be a read-only memory (ROM) or other type of static storage device that can store static information and instructions. Storage unit 1604 can be independent of processing unit 1601.

[0211] Figure 17 is a schematic diagram of the hardware structure of another terminal device provided in an embodiment of the present application. As shown in Figure 17, the terminal device may include a processor 1701, a communication line 1704 and at least one communication interface (communication interface 1703 is exemplified in Figure 17).

[0212] The processor 1701 can be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present application.

[0213] Communications link 1704 may include circuitry that transmits information between the aforementioned components.

[0214] The communication interface 1703 uses any transceiver or other device for communicating with other terminal devices or communication networks, such as Ethernet, wireless local area networks (WLAN), etc.

[0215] Possibly, the terminal device may further include a memory 1702 .

[0216] The memory 1702 may be a read-only memory (ROM) or other type of static storage terminal device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage terminal device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including a compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage terminal device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory may exist independently and be connected to the processor via a communication line 1704. The memory may also be integrated with the processor.

[0217] The memory 1702 is used to store computer-executable instructions for executing the solution of the present application, and the execution is controlled by the processor 1701. The processor 1701 is used to execute the computer-executable instructions stored in the memory 1702, thereby implementing the method provided by the embodiment of the present application.

[0218] Possibly, the computer-executable instructions in the embodiments of the present application may also be referred to as application code, and the embodiments of the present application do not specifically limit this.

[0219] In a specific implementation, as an embodiment, the processor 1701 may include one or more CPUs, such as CPU0 and CPU1 in Figure 17.

[0220] In a specific implementation, as an embodiment, a terminal device may include multiple processors, such as processor 1701 and processor 1705 in FIG17 . Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. The processor herein may refer to one or more terminal devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0221] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or data center that includes one or more available media integrated. For example, the available medium can include magnetic media (e.g., floppy disk, hard disk or tape), optical media (e.g., digital versatile disc (DVD)), or semiconductor media (e.g., solid state disk (SSD)).

[0222] The present application also provides a computer-readable storage medium. The methods described in the above embodiments can be implemented in whole or in part via software, hardware, firmware, or any combination thereof. Computer-readable media can include computer storage media and communication media, and can also include any medium that can transfer a computer program from one location to another. The storage medium can be any target medium that can be accessed by a computer.

[0223] As one possible design, computer-readable media may include compact disc read-only memory (CD-ROM), RAM, ROM, EEPROM or other optical disc storage; computer-readable media may include magnetic disk storage or other magnetic disk storage devices. Moreover, any connecting line may also be appropriately referred to as a computer-readable medium. For example, if the software is transmitted from a website, server or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwave are included in the definition of medium. Disk and disc as used herein include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically using lasers.

[0224] The above combinations are also included within the scope of computer-readable media. The above are only specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A thread scheduling method, It is characterized in that Applied to a terminal device, wherein a first process and a first thread are running in the terminal device, wherein the first thread is a thread for processing tasks, wherein the first process includes a second thread, wherein the second thread is a binder thread, and wherein the second thread includes: a first task, wherein the method includes: At a first moment, in response to a first instruction, the terminal device modifies the processing priority of the second thread from the first priority to the second priority before executing the first task based on the first instruction, wherein the processing priority of the second priority is higher than the processing priority of the first priority, and after the first moment, the second thread carries a first identifier, the first identifier is used to indicate that the second thread is in a priority-enhanced state, and the first instruction is an instruction corresponding to the first task; The terminal device executes the first task based on a second thread having the second priority; At the second moment, when the terminal device determines that there is no task to be executed in the second thread and the second thread carries the first identifier, the terminal device does not restore the processing priority of the second thread.

2. The method according to claim 1, It is characterized in that The second thread also includes a second task. After the second moment, the method further includes: At a third moment, in response to a second instruction, when the terminal device determines to modify the processing priority of the second thread from the first priority to the second priority based on the second instruction, and the terminal device is at the second priority after the second moment, the terminal device does not restore the processing priority of the second thread, and executes the second task based on the second thread with the second priority, and the second instruction is an instruction corresponding to the second task; Alternatively, when the terminal device determines not to change the processing priority of the second thread from the first priority to the second priority based on the second instruction, and the terminal device is at the second priority after the second moment, the terminal device restores the second priority to the first priority, and executes the second task based on the second thread with the first priority.

3. The method according to claim 2, It is characterized in that The second instruction includes one or more of the following: a binder communication number, an interface descriptor, or an asynchronous communication identifier, the binder communication number is used to indicate a communication interface, the interface descriptor is used to indicate a client and a server for communication, and the asynchronous communication identifier is used to indicate a communication mode, and the terminal device determines to modify the processing priority of the second thread from the first priority to the second priority based on the second instruction, including: When it is determined based on the second instruction that the second thread satisfies a preset condition, the terminal device modifies the processing priority of the second thread from the first priority to the second priority, Among them, the preset conditions include one or more of the following: the communication interface indicated by the binder communication number is the communication interface between the first thread and the second thread, the interface descriptor indicates that the client for communication is the first thread and the server for communication is the second thread, or the asynchronous communication identifier indicates that the communication between the first thread and the second thread is asynchronous binder communication.

4. The method according to claim 2, It is characterized in that After the first moment and before the third moment, a third thread is running in the terminal device, the third thread is a thread called by the binder initiated by the second thread, the third thread includes: a fourth task, and the method further includes: The terminal device inserts a third task into a queue executed by the second thread based on the third thread; In response to the third instruction, the terminal device determines, based on the third instruction, a process for resuming the second thread. When the processing priority of the second thread is lower than the processing priority of the third task, and the third task meets the preset first task type, the terminal device does not restore the processing priority of the second thread, and the third instruction is an instruction corresponding to the third task; The terminal device executes the third task based on the second thread with the second priority; The terminal device performs the fourth task.

5. The method according to claim 4, It is characterized in that The first task type includes: a task type used to indicate that a communication transaction is completed and handed over to the initiating end for processing, and / or a task type used to indicate that a communication transaction fails and is handed over to the initiating end for processing.

6. The method according to any one of claims 2 to 5, It is characterized in that After the first moment and before the third moment, a fourth thread is running in the terminal device, the fourth thread is a thread of synchronous binder call initiated by the second thread, the fourth thread includes: a fifth task, and the method further includes: After executing the fifth task, the terminal device inserts a sixth task into the second thread, wherein the sixth task is used to instruct the terminal device to complete processing of the fifth task; In response to a fourth instruction, when the terminal device determines to restore the processing priority of the second thread based on the fourth instruction and the sixth task meets the preset second task type, the terminal device does not restore the processing priority of the second thread, and the fourth instruction is an instruction corresponding to the sixth task; The terminal device executes the sixth task based on the second thread having the second priority; The terminal device performs the fifth task.

7. The method according to claim 6, It is characterized in that The second task type includes: the task type replied by the server.

8. The method according to any one of claims 1 to 7, It is characterized in that The first task is a task identified by the terminal device when an asynchronous binder call is made, the second thread further includes: a seventh task, the seventh task is a task identified by the terminal device when a synchronous binder call is made, before the second moment, the second thread carries a second identifier, the second identifier is used to indicate that the second thread is an asynchronous binder call, before the second moment and after the first moment, the method further includes: At a fourth moment, in response to a fifth instruction, when the terminal device detects the seventh task and the second thread with the second identifier, the terminal device restores the processing priority of the second thread before executing the seventh task, and the fifth instruction is an instruction corresponding to the seventh task; At the fifth moment, the terminal device changes the processing priority of the second thread from the first priority to the second priority, and processes the seventh task based on the second priority; at the fifth moment after the fourth moment, the second thread is in the state of the synchronous binder call within the first time period after the fifth moment, and the second thread is in the state of the asynchronous binder call between the fourth moment and the fifth moment.

9. The method according to claim 8, It is characterized in that After the fifth moment, the method further includes: At a sixth moment, the terminal device restores the processing priority of the second thread, and the processing priority of the second thread is at the first priority in a second time period after the sixth moment.

10. The method according to any one of claims 1 to 9, It is characterized in that The first thread is a thread for image synthesis, and the first process is a process for image drawing; or, the first process is a process for generating window data of window information, and the first thread is a thread for updating window information of a system.

11. A terminal device, It is characterized in that include: processor and memory, wherein The memory is used to store computer programs; The processor is used to call and execute the computer program so that the terminal device executes the method according to any one of claims 1 to 10.

12. A computer-readable storage medium, It is characterized in that Used to store a computer program, which, when executed on a computer, causes the computer to execute the method according to any one of claims 1 to 10.

Images