Transaction hierarchical acceleration method and device, terminal equipment and storage medium

Abstract

The application discloses a transaction hierarchical acceleration method and device, a terminal equipment and a storage medium. The method comprises the following steps: detecting an asynchronous Binder transaction when a foreground application is in a target scene; determining whether the asynchronous Binder transaction is a target asynchronous Binder transaction when the asynchronous Binder transaction is detected; and performing hierarchical acceleration processing on the target asynchronous Binder transaction when the asynchronous Binder transaction is the target asynchronous Binder transaction. The method can shorten the queuing blocking time of a key asynchronous Binder transaction in a Binder message queue, improve the problems of lag, frame drop and picture lag, and improve the interface interaction fluency.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a transaction layering acceleration method, apparatus, terminal device, and storage medium. Background Technology

[0002] As a mainstream inter-process communication method in Android, the Binder mechanism is responsible for data interaction, message notification, and task assignment between system services and application processes. Asynchronous Binder transactions are one-way, non-responsive inter-process communication calls. After initiating a request, the calling party does not block its current thread to wait for the server's response. These communication transactions are forwarded by the Binder driver to the asynchronous task queue corresponding to the target process, and are subsequently scheduled and processed sequentially by the target process's Binder thread pool according to the order of enqueueing.

[0003] In existing technologies, all asynchronous Binder transactions are typically queued and executed according to a default scheduling strategy. Critical transactions in the rendering pipeline cannot be prioritized, making them susceptible to resource consumption and latency by unrelated background tasks, resulting in UI stuttering and frame drops. For example, in a foreground application scrolling scenario, user actions drive continuous interface refreshes. SurfaceFlinger uses asynchronous Binder transactions to notify the application's RenderThread to complete buffer reclamation, layer compositing, and frame synchronization. These tasks must respond within the VSync cycle. If they are blocked and delayed by lower-priority background Binder transactions in the queue, rendering timeouts can occur, leading to scrolling stutters, ghosting, and frame rate drops. Summary of the Invention

[0004] This application provides a transaction layering acceleration method, apparatus, terminal device, and storage medium, which can specifically shorten the queuing blocking time of critical asynchronous Binder transactions in the Binder message queue, improve stuttering, frame drops, and screen ghosting issues, and enhance the smoothness of interface interaction.

[0005] Firstly, this application provides a transaction layering acceleration method, including: When the foreground application is identified as being in the target scenario, asynchronous Binder transactions are detected. When an asynchronous Binder transaction is detected, determine whether the asynchronous Binder transaction is the target asynchronous Binder transaction; When the asynchronous Binder transaction is the target asynchronous Binder transaction, the target asynchronous Binder transaction is processed in layers to accelerate its processing.

[0006] In some implementations of this application, determining whether an asynchronous Binder transaction is the target asynchronous Binder transaction includes: Determine whether the initiator of the asynchronous Binder transaction is a service of the target system; If the initiator of an asynchronous Binder transaction does not serve the target system, then the asynchronous Binder transaction is determined not to be the target asynchronous Binder transaction. When the initiator of an asynchronous Binder transaction is a service of the target system, the asynchronous Binder transaction is determined to be the target asynchronous Binder transaction based on the target processing thread of the asynchronous Binder transaction.

[0007] In some implementations of this application, determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction based on the target processing thread of the asynchronous Binder transaction includes: Determine whether the target thread for the asynchronous Binder transaction is a target type thread; When the target processing thread of an asynchronous Binder transaction is not a target type thread, it is determined that the asynchronous Binder transaction is not the target asynchronous Binder transaction; When the target processing thread of an asynchronous Binder transaction is a target type thread, the asynchronous Binder transaction is determined to be a target asynchronous Binder transaction based on the application to which the target processing thread belongs.

[0008] In some implementations of this application, determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction is based on the application to which the target processing thread belongs, including: When the application to which the target processing thread belongs is a foreground application, the asynchronous Binder transaction is determined to be the target asynchronous Binder transaction; If the application to which the target processing thread belongs is not a foreground application, determine that the asynchronous Binder transaction is not the target asynchronous Binder transaction.

[0009] In some implementations of this application, determining whether the initiator of the asynchronous Binder transaction is a target system service includes: Obtain the process identifier and user identifier of the calling process of the asynchronous Binder transaction; When the user identifier is a preset identifier and the main process name corresponding to the process identifier is the target process name, the initiator of the asynchronous Binder transaction is determined to be the target system service; If the user identifier is not the default identifier, or if the main process name corresponding to the process identifier is not the target process name, it is determined that the initiator of the asynchronous Binder transaction is not the target system service.

[0010] In some implementations of this application, determining whether the target processing thread of the asynchronous Binder transaction is a target type thread includes: Get the interface number of the asynchronous Binder transaction; When the interface corresponding to the interface number is the target interface, the target processing thread of the asynchronous Binder transaction is determined to be the target type thread; If the interface corresponding to the interface number is not the target interface, it is determined that the target processing thread of the asynchronous Binder transaction is not the target type thread.

[0011] In some implementations of this application, the application to which the target processing thread belongs is obtained through the following steps: The client object corresponding to the asynchronous Binder transaction is determined based on the graphical surface identifier carried in the Binder data packet corresponding to the asynchronous Binder transaction. Based on the client object and thread association information, determine the thread identifier corresponding to the target processing thread; the thread association information is used to represent the correspondence between the client object and the thread identifier. Based on the thread identifier corresponding to the target processing thread, determine the process identifier corresponding to the target processing thread; Based on the process identifier, determine the application to which the target processing thread belongs.

[0012] In some implementations of this application, the target asynchronous Binder transaction is accelerated in a tiered manner, including: Write the target asynchronous Binder transaction to the first priority queue; the first priority queue has a higher priority than the second priority queue, which is used to store other asynchronous Binder transactions besides the target asynchronous Binder transaction. When processing the target asynchronous Binder transaction, increase the scheduling priority of the processing thread corresponding to the target asynchronous Binder transaction.

[0013] In some embodiments of this application, after the target asynchronous Binder transaction is written to the first priority queue, the following is included: During the asynchronous Binder transaction scheduling process, if there is a target asynchronous Binder transaction to be processed in the first priority queue, the target asynchronous Binder transaction in the first priority queue is selected and scheduled for execution. If there is no pending asynchronous Binder transaction in the first priority queue, select and schedule the asynchronous Binder transaction in the second priority queue for execution.

[0014] In some implementation schemes of this application, the target scenarios include one or more of the following: foreground application swiping scenario, foreground video playback and rendering scenario, foreground frame-by-frame animation scenario, page transition animation scenario, game rendering scenario, camera preview scenario, map interaction scenario, motion effect loop playback scenario, and real-time hand-drawn drawing scenario.

[0015] Secondly, embodiments of this application also provide a transaction layering acceleration device, comprising: The transaction detection module is used to detect asynchronous Binder transactions when the foreground application is identified as being in the target scenario. The transaction determination module is used to determine whether an asynchronous Binder transaction is the target asynchronous Binder transaction when an asynchronous Binder transaction is detected. The transaction acceleration module is used to perform tiered acceleration processing on the target asynchronous Binder transaction when the asynchronous Binder transaction is the target asynchronous Binder transaction.

[0016] Thirdly, this application also provides a terminal device, which includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor to implement the transaction tiering acceleration method of any of the first aspects.

[0017] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, the computer program being loaded by a processor to perform the steps in the transaction layering acceleration method of any of the first aspects.

[0018] The beneficial effects of this application are as follows: By determining whether an asynchronous Binder transaction is the target asynchronous Binder transaction when it is detected, transactions that are crucial to the smoothness of foreground rendering can be accurately selected from a large number of asynchronous transactions, avoiding unnecessary acceleration processing of non-critical transactions, thereby saving system resources and improving acceleration efficiency; By performing layered acceleration processing on the target asynchronous Binder transaction when it is the target asynchronous Binder transaction, the queuing blocking time of critical asynchronous Binder transactions in the Binder message queue can be shortened in a targeted manner, ensuring that rendering instructions are issued and executed in a timely manner within the VSync frame cycle, effectively improving the stuttering, frame drops, and screen ghosting problems during page scrolling, pop-up switching, and animation playback, and improving the smoothness of interface interaction; By detecting asynchronous Binder transactions when the foreground application is identified as being in the target scenario, system resources can be avoided in non-critical scenarios. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of a scenario for the transaction layering acceleration system provided in this application embodiment; Figure 2 This is a schematic flowchart of an embodiment of the transaction layering acceleration method provided in this application; Figure 3 This is a schematic diagram of the framework of the transaction layering acceleration method provided in the embodiments of this application; Figure 4 This is a schematic flowchart of a specific embodiment of the transaction layering acceleration method provided in this application. Figure 5 This is a diagram illustrating asynchronous Binder transaction processing using the default scheduling strategy; Figure 6 This is a schematic diagram illustrating the acceleration of asynchronous Binder transaction processing using the transaction layering acceleration method provided in the embodiments of this application; Figure 7 This is a schematic diagram of a specific embodiment of the transaction layering acceleration device provided in this application. Figure 8 This is a schematic diagram of an embodiment of the terminal device provided in this application. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] In the description of this application, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more features.

[0023] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0024] It should be noted that since the method in this application embodiment is executed in a terminal device, the processing objects of each terminal device exist in the form of data or information, such as time, which is essentially time information. It can be understood that if size, quantity, position, etc. are mentioned in subsequent embodiments, they are all corresponding data that exist so that the terminal device can process them. Specific details will not be elaborated here.

[0025] This application provides a transaction layering acceleration method, apparatus, terminal device, and storage medium, which will be described in detail below.

[0026] Please see Figure 1 , Figure 1 This is a schematic diagram of a transaction layering acceleration system provided in an embodiment of this application. The transaction layering acceleration system may include a terminal device 100, which integrates a transaction layering acceleration device, such as... Figure 1 Terminal devices in the process.

[0027] In this embodiment, the terminal device 100 is mainly used to detect asynchronous Binder transactions when the foreground application is identified as being in a target scenario; when an asynchronous Binder transaction is detected, it determines whether the asynchronous Binder transaction is the target asynchronous Binder transaction; when the asynchronous Binder transaction is the target asynchronous Binder transaction, it performs layered acceleration processing on the target asynchronous Binder transaction, which can allocate network resources to the target application on demand and differentiate them. This can not only ensure the stable transmission of high-time-efficiency services, but also avoid non-latency tasks from occupying high-priority channels, effectively improve channel utilization, ensure the smooth operation of various services, and optimize network service quality.

[0028] In this embodiment, the terminal device 100 can be a device that includes both receiving and transmitting hardware, i.e., a device with receiving and transmitting hardware capable of performing bidirectional communication on a bidirectional communication link. Such a device may include cellular or other communication devices having a single-line display, a multi-line display, or a cellular or other communication device without a multi-line display. Specifically, the terminal device 100 can be a desktop terminal or a mobile terminal, and may also be a smart TV, mobile phone, tablet computer, laptop computer, etc.

[0029] Those skilled in the art will understand that Figure 1 The application environment shown is merely one application scenario of the solution in this application and does not constitute a limitation on the application scenario of the solution in this application. Other application environments may include those that are more specific to this application. Figure 1 The number of more or fewer terminal devices shown, for example Figure 1 Only one terminal device is shown in the diagram. It is understood that the transaction tiering acceleration system may also include one or more other services, which are not specified here.

[0030] In addition, such as Figure 1 As shown, the transaction layering acceleration system may also include a memory 200 for storing data, such as identifier information, such as process identifiers, user identifiers, etc., and Binder transaction information, such as the initiator of the asynchronous Binder transaction, the target processing thread of the asynchronous Binder transaction, etc.

[0031] It should be noted that, Figure 1 The schematic diagram of the transaction layering acceleration system shown is merely an example. The transaction layering acceleration system and scenario described in this application are for the purpose of more clearly illustrating the technical solutions of this application and do not constitute a limitation on the technical solutions provided in this application. As those skilled in the art will know, with the evolution of transaction layering acceleration systems and the emergence of new business scenarios, the technical solutions provided in this application are also applicable to similar technical problems.

[0032] First, this application provides a transaction layering acceleration method. The execution subject of the transaction layering acceleration method is a transaction layering acceleration device, which is applied to a terminal device. The transaction layering acceleration method includes: detecting asynchronous Binder transactions when the foreground application is identified as being in a target scenario; determining whether the asynchronous Binder transaction is the target asynchronous Binder transaction when it is detected; and performing layering acceleration processing on the target asynchronous Binder transaction when the asynchronous Binder transaction is the target asynchronous Binder transaction.

[0033] like Figure 2The diagram shown is a flowchart of an embodiment of the transaction layering acceleration method in this application. The transaction layering acceleration method may include the following steps S201 to S203, as detailed below: Step S201: When the foreground application is identified as being in the target scenario, the asynchronous Binder transaction is detected.

[0034] In this embodiment, the foreground application refers to an application process that currently has system focus, directly interacts with the user, and whose interface is visible on the top layer of the display screen and is in an active display state. The target scenario refers to a scenario where the foreground application needs continuous rendering. Target scenarios include one or more of the following: foreground application swiping scenarios, foreground video playback rendering scenarios, foreground frame-by-frame animation scenarios, page transition animation scenarios, game rendering scenarios, camera preview scenarios, map interaction scenarios, motion effect looping playback scenarios, and real-time hand-drawn rendering scenarios. Since the interface refreshes frequently in target scenarios, the transaction processing latency on the rendering path directly affects smoothness. This application avoids consuming system resources in non-critical scenarios by starting detection in target scenarios.

[0035] In this embodiment, the foreground application sliding scenario refers to a human-computer interaction scenario where the terminal is running in the foreground, receiving continuous touch input commands from the user and driving the continuous displacement and scrolling of page view content. Whether the current scenario is a foreground application sliding scenario can be determined by listening to touch events reported by the system and combining this with the page scrolling status. The foreground video playback and rendering scenario refers to a business scenario where the application is running in the foreground, continuously outputting video image frames based on the media decoding module, and driving the display to periodically refresh the screen. This scenario can be identified and determined by listening to the media player status callback results and combining this with the screen rendering frame rate detection results. The foreground frame-by-frame animation scenario refers to an interactive scenario where the application is running in the foreground, rendering and outputting images sequentially according to a preset image frame sequence, continuously presenting dynamic image effects. This scenario can be identified and determined by listening to system animation framework callback information or by listening to and detecting view frame refresh events. The page transition animation scenario refers to a scenario where the application is in the foreground visible state, and during the transition between two different page views, the system or application executes an interface transition animation to complete the page display change. This scenario can be identified and determined by listening to page switching trigger events and combining this with animation running status detection. Game rendering scenarios refer to high-refresh-rate continuous rendering scenarios where game applications are active in the foreground, relying on the game engine to continuously generate frames and drive the GPU to complete the rendering output. This scenario can be identified by collecting frame rate statistics from the game engine or monitoring the application's rendering thread load. Camera preview scenarios are rendering scenarios where the camera application outputs the view in real-time while running in the foreground. This can be identified through camera service status callbacks and preview frame rate detection. Map interaction scenarios are interactive scenarios where the map application responds to touch commands such as zooming and panning and continuously renders the map view. Looping animation scenarios are scenarios where the application loops preset animations and periodically refreshes the screen. This scenario can be identified by detecting the animation loop status. Real-time hand-drawn drawing scenarios are interactive scenarios where the application collects touch handwriting in real-time and renders doodles frame by frame. This scenario can be identified by collecting touch events combined with drawing thread status detection.

[0036] Furthermore, asynchronous Binder transactions refer to inter-process communication transactions initiated through the Binder mechanism that do not require waiting for a response, for example, referring to... Figure 3 As shown, in the Android system, SurfaceFlinger may wake up RenderThread through asynchronous Binder transactions to trigger rendering processing. By detecting asynchronous Binder transactions, communication events that may be located on the critical rendering path can be captured, providing a basis for subsequent identification.

[0037] In some embodiments, the steps for detecting asynchronous Binder transactions specifically include: acquiring Binder communication messages during transmission; parsing the Binder communication messages to determine whether the Binder communication messages carry a one-way call flag; and determining that the current communication transaction belongs to an asynchronous Binder transaction when the Binder communication messages carry a one-way call flag. This embodiment, by capturing Binder communication messages transmitted in the link and relying on the one-way call flag built into the messages as the basis for judgment, can accurately and completely identify all asynchronous Binder transactions, avoiding misjudgment or omission of transaction types, and providing an accurate data foundation for subsequent differentiated scheduling processing.

[0038] S202. When an asynchronous Binder transaction is detected, determine whether the asynchronous Binder transaction is the target asynchronous Binder transaction.

[0039] In this embodiment, the target asynchronous Binder transaction refers to an asynchronous Binder transaction that meets preset conditions. These preset conditions include the initiator of the asynchronous Binder transaction being a target system service, the target processing thread being a target type thread, and the application to which the target processing thread belongs being one or more foreground applications. Specifically, the target system service refers to an Android system background service that issues asynchronous Binder transactions related to the UI rendering chain to the application process and directly participates in frame synchronization, layer management, buffer scheduling, and window display control. The target system service includes one or more of SurfaceFlinger, WindowManagerService (WMS), and DisplayManagerService (DMS). The target type thread refers to a thread within the application process that undertakes tasks such as UI drawing, layer rendering, image compositing, and frame data processing. The target type thread includes one or more of RenderThread, UI main thread, and Surface drawing worker threads. For example, refer to... Figure 3 and Figure 4 As shown, the preset conditions include the initiator of the asynchronous Binder transaction being SurfaceFlinger, the target processing thread of the asynchronous Binder transaction being the RenderThread thread, and the application to which the target processing thread belongs being a foreground application. This embodiment, by determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction, can accurately filter out transactions crucial to the smoothness of foreground rendering from a large number of asynchronous transactions, avoiding unnecessary acceleration processing of non-critical transactions, thereby saving system resources and improving acceleration efficiency.

[0040] Optionally, when determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction, it can be determined whether the initiator of the asynchronous Binder transaction is a target system service. If the initiator of the asynchronous Binder transaction is a target system service, the asynchronous Binder transaction is determined to be a target asynchronous Binder transaction. Alternatively, it can be determined whether the target processing thread of the asynchronous Binder transaction is a target type thread. If the target processing thread of the asynchronous Binder transaction is a target type thread, the asynchronous Binder transaction is determined to be a target asynchronous Binder transaction. Alternatively, it can be determined whether the application to which the target processing thread belongs is a foreground application. If the application to which the target processing thread belongs is a foreground application, the asynchronous Binder transaction is determined to be a target asynchronous Binder transaction.

[0041] In some embodiments, refer to Figure 4 As shown, the steps for determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction specifically include: determining whether the initiator of the asynchronous Binder transaction is a service of the target system; if the initiator of the asynchronous Binder transaction is not a service of the target system, determining that the asynchronous Binder transaction is not a target asynchronous Binder transaction; if the initiator of the asynchronous Binder transaction is a service of the target system, determining whether the asynchronous Binder transaction is a target asynchronous Binder transaction based on the target processing thread of the asynchronous Binder transaction. This embodiment, by sequentially verifying the initiating service source and the target processing thread of the asynchronous Binder transaction, can achieve two-layer condition filtering, accurately identifying the target asynchronous Binder transactions that need to be prioritized in the interface rendering chain. This can filter out a large number of invalid pending tasks, reduce the identification computation load, and prevent non-critical tasks from preempting scheduling resources.

[0042] In this embodiment, the initiator of the asynchronous Binder transaction refers to the process that actively initiates the inter-process communication (IPC) call, constructs the Binder transaction data packet, and sends the request via the Binder driver during this Binder inter-process communication. In some embodiments, the step of determining whether the initiator of the asynchronous Binder transaction is a target system service specifically includes: obtaining the process identifier and user identifier of the calling process of the asynchronous Binder transaction; when the user identifier is a preset identifier and the main process name corresponding to the process identifier is the target process name, the initiator of the asynchronous Binder transaction is determined to be a target system service; when the user identifier is not a preset identifier, or the main process name corresponding to the process identifier is not the target process name, the initiator of the asynchronous Binder transaction is determined not to be a target system service. This embodiment verifies the initiator's identity through a dual-dimensional check of the user identifier and the process name corresponding to the process identifier, and completes the determination based on the system's native process identifier. It has strong adaptability and is not easily affected by system iteration and interface changes. The dual verification mechanism can accurately identify asynchronous Binder transactions issued by the target system service, filter out irrelevant communication tasks in advance, and reduce subsequent redundant calculations.

[0043] In this embodiment, the User Identifier (UID) is a numerical number assigned by the operating system to a process to identify the user identity and permission type of the process. The UID is used to quickly filter asynchronous Binder transactions initiated by non-system services, avoiding unnecessary subsequent judgments on Binder transactions initiated by ordinary application processes, thereby reducing identification overhead. The Process Identifier (PID) is a numerical number dynamically assigned by the operating system to each currently running process, uniquely identifying a single process within the system's runtime. The PID is used to locate the specific process initiating the asynchronous Binder transaction. For example, if the default identifier is 1000 and the target process name is surfaceflinger, when UID=1000 and the main process corresponding to the PID is named surfaceflinger, the initiator of the asynchronous Binder transaction is determined to be the target system service.

[0044] In this embodiment, the target processing thread refers to the target execution thread that receives the inter-process communication message and executes the business logic corresponding to this call after the asynchronous Binder transaction is forwarded to the target process by the Binder driver. By combining the initiator and the target processing thread for dual judgment, the asynchronous Binder transaction located on the critical rendering path of the foreground application can be located more accurately, avoiding the mistaken inclusion of transactions processed by other threads in the acceleration scope.

[0045] In some embodiments, the step of determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction based on the target processing thread of the asynchronous Binder transaction specifically includes: determining whether the target processing thread of the asynchronous Binder transaction is a target type thread; when the target processing thread of the asynchronous Binder transaction is not a target type thread, determining that the asynchronous Binder transaction is not a target asynchronous Binder transaction; and when the target processing thread of the asynchronous Binder transaction is a target type thread, determining that the asynchronous Binder transaction is a target asynchronous Binder transaction.

[0046] In other embodiments, the step of determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction based on the target processing thread of the asynchronous Binder transaction specifically includes: determining whether the target processing thread of the asynchronous Binder transaction is a target type thread; when the target processing thread of the asynchronous Binder transaction is not a target type thread, determining that the asynchronous Binder transaction is not a target asynchronous Binder transaction; when the target processing thread of the asynchronous Binder transaction is a target type thread, determining whether the asynchronous Binder transaction is a target asynchronous Binder transaction based on the application to which the target processing thread belongs.

[0047] In this embodiment, the target type thread refers to a thread within the application process that undertakes tasks such as interface drawing, layer rendering, image compositing, and frame data processing. Target type threads include one or more of the following: RenderThread, UI main thread, and Surface drawing worker thread. By identifying whether the target processing thread is a target type thread, asynchronous Binder transactions that, although initiated by a service of the target system, are not processed by the target type thread, can be filtered out. This refines the identification scope to threads directly related to rendering. For example, if the target type thread is RenderThread, and the target processing thread of an asynchronous Binder transaction is not RenderThread, then the asynchronous Binder transaction is determined not to be a target asynchronous Binder transaction. If the target processing thread of an asynchronous Binder transaction is RenderThread, then the asynchronous Binder transaction is determined to be a target asynchronous Binder transaction based on the application to which the RenderThread thread belongs.

[0048] In some embodiments, the step of determining whether the target processing thread of an asynchronous Binder transaction is a target type thread specifically includes: obtaining the interface number of the asynchronous Binder transaction; when the interface corresponding to the interface number is the target interface, determining that the target processing thread of the asynchronous Binder transaction is a target type thread; when the interface corresponding to the interface number is not the target interface, determining that the target processing thread of the asynchronous Binder transaction is not a target type thread. This embodiment, by parsing the interface number and comparing it with a preset target interface, can quickly determine whether the target processing thread of an asynchronous Binder transaction is a target type thread. Furthermore, the determination method is based on inherent message information, resulting in low invasiveness, low runtime overhead, and wide adaptability.

[0049] In this embodiment, the interface number, i.e., the code transaction code within the Binder communication message, is a unique numerical identifier assigned to each remote call method under the same Binder service in the Binder mechanism. The target interface is the remote call interface through which the target system service issues graphics display control instructions, triggers application layer updates and frame rendering, and is processed by the target type thread. The target interface includes one or more of the following: buffer reclamation interface, layer transaction interface, frame synchronization-type graphics notification interface, window state change interface, Surface lifecycle management interface, and display parameter adaptation interface. For example, the target interface includes the SurfaceFlinger buffer reclamation interface, layer transaction interface, and frame synchronization-type graphics notification interface. When the interface corresponding to the interface number is the SurfaceFlinger buffer reclamation interface, layer transaction interface, or frame synchronization-type graphics notification interface, the target processing thread for the asynchronous Binder transaction is determined to be the RenderThread thread.

[0050] In this embodiment of the application, the application to which the target processing thread belongs refers to the application process to which the target processing thread belongs. By determining whether the application to which the target processing thread belongs is a foreground application, it can further filter out those asynchronous Binder transactions that, although the target thread is a target type thread, serve non-foreground applications, thereby ensuring that acceleration resources are only used for applications that the current user is interacting with.

[0051] In some embodiments, the step of determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction based on the application to which the target processing thread belongs specifically includes: determining that the asynchronous Binder transaction is a target asynchronous Binder transaction when the application to which the target processing thread belongs is a foreground application; and determining that the asynchronous Binder transaction is not a target asynchronous Binder transaction when the application to which the target processing thread belongs is not a foreground application.

[0052] In some embodiments, the application to which the target processing thread belongs is obtained through the following steps: determining the client object corresponding to the asynchronous Binder transaction based on the graphical surface identifier carried in the Binder data packet corresponding to the asynchronous Binder transaction; determining the thread identifier corresponding to the target processing thread based on the client object and thread association information; the thread association information is used to characterize the correspondence between the client object and the thread identifier; determining the process identifier corresponding to the target processing thread based on the thread identifier corresponding to the target processing thread; and determining the application to which the target processing thread belongs based on the process identifier.

[0053] In this embodiment, the graphic surface identifier is carried in the Binder communication data packet and is generated and allocated by the graphics compositing service. It is a unique identifier for a single Surface graphic canvas layer instance globally within the system. The client object runs within the application process acting as the client and is bound one-to-one with the graphic surface identifier. It also attaches the BufferQueue producer interface IGraphicBufferProducer, which is a proxy object used by the application process to manage the graphics buffer and initiate graphics-related cross-process Binder calls. Thread association information refers to a data structure that represents the correspondence between client objects and thread identifiers. Thread association information can be implemented using a mapping table or an associative array to record the rendering thread identifier corresponding to each client object. Through the thread association information, the thread identifier corresponding to the target processing thread can be quickly found.

[0054] Furthermore, a thread identifier is a unique identifier for a thread, which can be implemented using a thread ID or a TID to distinguish different threads. The thread identifier is used to trace the process to which the thread belongs, thereby determining whether the application corresponding to that process is a foreground application. A process identifier is a unique identifier for a process, which can be implemented using a process ID or a PID to distinguish different processes. The process identifier is used to determine the application to which the target processing thread belongs, thereby determining whether that application is the current foreground application. This embodiment of the application achieves precise tracing of the application to which the target processing thread belongs by combining the graphical surface identifier carried in the Binder data packet with client object and thread association information. This tracing method based on graphical buffer identifiers avoids directly relying on thread names or process names for judgment, improving the accuracy and reliability of identification. It can more accurately identify asynchronous Binder transactions located on the critical rendering path of the foreground application, providing a more reliable identification foundation for subsequent layered accelerated processing.

[0055] It should be noted that in the above embodiments, the determination of whether an asynchronous Binder transaction is a target asynchronous Binder transaction follows the order of first determining whether the initiator of the asynchronous Binder transaction is a target system service, then determining whether the target processing thread of the asynchronous Binder transaction is a target type thread, and finally determining whether the application to which the target processing thread belongs is a foreground application. In other embodiments, the determination of whether an asynchronous Binder transaction is a target asynchronous Binder transaction can also follow the same order. Alternatively, it can be determined by first determining whether the target processing thread of the asynchronous Binder transaction is a target type thread, then determining whether the target processing thread belongs to a target system service, and finally determining whether the application to which the target processing thread belongs is a foreground application. This embodiment does not limit the determination of whether an asynchronous Binder transaction is a target asynchronous Binder transaction.

[0056] In other embodiments, the step of determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction specifically includes: determining whether the target processing thread of the asynchronous Binder transaction is a target type thread; when the target processing thread of the asynchronous Binder transaction is not a target type thread, determining that the asynchronous Binder transaction is not a target asynchronous Binder transaction; when the target processing thread of the asynchronous Binder transaction is a target type thread, determining whether the asynchronous Binder transaction is a target asynchronous Binder transaction based on the initiator of the asynchronous Binder transaction.

[0057] In some embodiments, the step of determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction based on the initiator of the asynchronous Binder transaction specifically includes: when the initiator of the asynchronous Binder transaction is not a target system service, determining that the asynchronous Binder transaction is not a target asynchronous Binder transaction; when the initiator of the asynchronous Binder transaction is a target system service, determining whether the asynchronous Binder transaction is a target asynchronous Binder transaction based on the application to which the target processing thread belongs.

[0058] In other embodiments, the step of determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction specifically includes: determining whether the target processing thread of the asynchronous Binder transaction is a target type thread; when the target processing thread of the asynchronous Binder transaction is not a target type thread, determining that the asynchronous Binder transaction is not a target asynchronous Binder transaction; when the target processing thread of the asynchronous Binder transaction is a target type thread, determining whether the asynchronous Binder transaction is a target asynchronous Binder transaction based on the application to which the target processing thread belongs.

[0059] In some embodiments, the step of determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction based on the application to which the target processing thread belongs specifically includes: when the application to which the target processing thread belongs is not a foreground application, determining that the asynchronous Binder transaction is not a target asynchronous Binder transaction; when the application to which the target processing thread belongs is a foreground application, determining whether the asynchronous Binder transaction is a target asynchronous Binder transaction based on the initiator of the asynchronous Binder transaction.

[0060] In some embodiments, the step of determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction based on the initiator of the asynchronous Binder transaction specifically includes: determining that the asynchronous Binder transaction is not a target asynchronous Binder transaction when the initiator of the asynchronous Binder transaction is not a target system service; and determining that the asynchronous Binder transaction is a target asynchronous Binder transaction when the initiator of the asynchronous Binder transaction is a target system service.

[0061] S203. When the asynchronous Binder transaction is the target asynchronous Binder transaction, perform layered acceleration processing on the target asynchronous Binder transaction.

[0062] In this embodiment, layered acceleration processing refers to a differentiated scheduling method that elevates the scheduling level and processing priority of the target asynchronous Binder transaction, making it dequeued and allocated to threads for execution before ordinary Binder transactions. This reduces cross-process communication latency. Layered acceleration processing includes at least one of queue-side acceleration and CPU-side acceleration. Queue-side acceleration writes the target asynchronous Binder transaction into a higher-priority queue, allowing it to be processed first during scheduling. CPU-side acceleration elevates the scheduling priority of the corresponding thread when processing the target asynchronous Binder transaction, enabling it to obtain CPU execution opportunities faster. By performing layered acceleration processing on the target asynchronous Binder transaction, this embodiment can specifically shorten the queuing blocking time of the target asynchronous Binder transaction in the Binder message queue, ensuring that rendering instructions are issued and executed in a timely manner within the VSync frame period. This effectively improves the stuttering, frame drops, and screen tearing issues during page scrolling, pop-up switching, and animation playback, enhancing the smoothness of interface interaction.

[0063] In some embodiments, combined with Figure 3 and Figure 4 As shown, the steps for performing layered acceleration processing on the target asynchronous Binder transaction specifically include: writing the target asynchronous Binder transaction into a first priority queue; the first priority queue has a higher priority than the second priority queue, and the second priority queue is used to store other asynchronous Binder transactions besides the target asynchronous Binder transaction; when processing the target asynchronous Binder transaction, increasing the scheduling priority of the processing thread corresponding to the target asynchronous Binder transaction.

[0064] In this embodiment, the first priority queue is a queue specifically used to store the target asynchronous Binder transaction, and the second priority queue is a queue used to store other asynchronous Binder transactions besides the target asynchronous Binder transaction. The first priority queue has a higher priority than the second priority queue. The role of the first priority queue is to ensure that the target asynchronous Binder transaction can be scheduled before other ordinary asynchronous Binder transactions during the queuing phase, thereby reducing its waiting time in the queue and avoiding transaction processing delays on critical rendering paths due to excessively long queues. The role of the second priority queue is to serve as a storage area for ordinary transactions, forming a hierarchical scheduling structure with the first priority queue. This allows critical and non-critical transactions to be treated differently during scheduling, preventing critical transactions from being blocked by a large number of ordinary transactions. By writing the target asynchronous Binder transaction into the first priority queue, during subsequent asynchronous Binder transaction scheduling, the system will prioritize selecting transactions from the first priority queue for scheduling and execution. Only when the first priority queue is empty will a transaction be selected from the second priority queue, thus accelerating the target asynchronous Binder transaction during the queuing phase and shortening its processing latency.

[0065] Furthermore, increasing the scheduling priority of the processing thread corresponding to the target asynchronous Binder transaction means raising the priority of the thread handling the transaction in CPU scheduling when the target asynchronous Binder transaction enters the execution phase. By increasing the scheduling priority, the target asynchronous Binder transaction can obtain a running opportunity more quickly in CPU resource contention, thereby shortening the processing time of the target asynchronous Binder transaction and ensuring that tasks on the critical rendering path can be completed in a timely manner. For example, increasing the scheduling priority of the processing thread corresponding to the target asynchronous Binder transaction makes its scheduling priority higher than that of general threads other than real-time (RT) threads.

[0066] In some embodiments, after writing the target asynchronous Binder transaction into the first priority queue, the process includes: during asynchronous Binder transaction scheduling, if there is a target asynchronous Binder transaction to be processed in the first priority queue, selecting and scheduling the target asynchronous Binder transaction in the first priority queue for execution; if there is no target asynchronous Binder transaction to be processed in the first priority queue, selecting and scheduling the asynchronous Binder transaction in the second priority queue for execution. In the prior art, all asynchronous Binder transactions share the same queue and are processed according to a first-in-first-out or default priority order, which may cause transactions on the critical rendering path to be blocked by a large number of ordinary transactions. This application, by prioritizing the processing of transactions in the first priority queue, can significantly shorten the queuing time of critical transactions and avoid rendering response delays caused by queuing delays.

[0067] In this embodiment, scheduled execution refers to the process of selecting transactions from the queue and assigning them to processing threads for actual processing. Specifically, during asynchronous Binder transaction scheduling, the scheduler first checks the status of the first priority queue. If there is a target asynchronous Binder transaction to be processed in the first priority queue, the scheduler immediately selects the transaction from the queue and assigns it to the corresponding processing thread for execution. Only when the first priority queue is empty will the scheduler switch to the second priority queue, select and schedule ordinary asynchronous Binder transactions within it. This scheduling strategy ensures that asynchronous Binder transactions on the critical rendering path are always processed with priority over other asynchronous Binder transactions, thereby reducing the queuing time of asynchronous Binder transactions on the critical rendering path.

[0068] For example, refer to Figure 5 As shown, for asynchronous Binder transactions processed according to the default scheduling strategy, the critical SF→RenderThread transaction is queued together with ordinary transactions such as Transaction A, Transaction B, and Transaction C, resulting in a long queuing time for the critical SF→RenderThread transaction and causing stuttering during decoding. (Refer to...) Figure 6As shown, after performing layered acceleration processing on SF→RenderThread critical transactions 1 and SF→RenderThread critical transactions 2 according to the transaction layering acceleration method provided in this application embodiment, since SF→RenderThread critical transactions 1 and SF→RenderThread critical transactions 2 are written into the first priority queue, SF→RenderThread critical transactions 1 and SF→RenderThread critical transactions 2 will be executed with priority compared to ordinary transactions A, B and C, thereby shortening the processing latency of SF→RenderThread critical transactions 1 and SF→RenderThread critical transactions 2 and improving the smoothness of the interface; in addition, by increasing the scheduling priority of the processing thread corresponding to SF→RenderThread critical transactions 1 and SF→RenderThread critical transactions 2 when processing SF→RenderThread critical transactions 1 and SF→RenderThread critical transactions 2, SF→RenderThread critical transactions 1 and SF→RenderThread critical transactions 2 can be accelerated in both the queuing stage and the execution stage, which can further shorten the processing latency of critical transactions.

[0069] To better implement the transaction layering acceleration method in the embodiments of this application, a transaction layering acceleration device is also provided in the embodiments of this application, such as... Figure 7 As shown, the transaction layering acceleration device 600 includes: The transaction detection module 610 is used to detect asynchronous Binder transactions when the foreground application is identified as being in the target scenario; The transaction determination module 620 is used to determine whether the asynchronous Binder transaction is the target asynchronous Binder transaction when an asynchronous Binder transaction is detected. The transaction acceleration module 630 is used to perform layered acceleration processing on the target asynchronous Binder transaction when the asynchronous Binder transaction is the target asynchronous Binder transaction.

[0070] In this embodiment, by determining whether an asynchronous Binder transaction is a target asynchronous Binder transaction when it is detected, transactions crucial to the smoothness of foreground rendering can be accurately selected from a large number of asynchronous transactions. This avoids unnecessary acceleration processing of non-critical transactions, thereby saving system resources and improving acceleration efficiency. By performing layered acceleration processing on the target asynchronous Binder transaction when it is a target asynchronous Binder transaction, the queuing blocking time of critical asynchronous Binder transactions in the Binder message queue can be shortened in a targeted manner. This ensures that rendering instructions are issued and executed in a timely manner within the VSync frame cycle, effectively improving stuttering, frame drops, and screen ghosting issues during page scrolling, pop-up switching, and animation playback, and improving the smoothness of interface interaction. By detecting asynchronous Binder transactions when the foreground application is identified as being in a target scenario, system resources can be avoided in non-critical scenarios.

[0071] In some embodiments of this application, the transaction determination module 620 is specifically used for: Determine whether the initiator of the asynchronous Binder transaction is a service of the target system; If the initiator of an asynchronous Binder transaction does not serve the target system, then the asynchronous Binder transaction is determined not to be the target asynchronous Binder transaction. When the initiator of an asynchronous Binder transaction is a service of the target system, the asynchronous Binder transaction is determined to be the target asynchronous Binder transaction based on the target processing thread of the asynchronous Binder transaction.

[0072] In some embodiments of this application, the transaction determination module 620 is further configured to: Determine whether the target thread for the asynchronous Binder transaction is a target type thread; When the target processing thread of an asynchronous Binder transaction is not a target type thread, it is determined that the asynchronous Binder transaction is not the target asynchronous Binder transaction; When the target processing thread of an asynchronous Binder transaction is a target type thread, the asynchronous Binder transaction is determined to be a target asynchronous Binder transaction based on the application to which the target processing thread belongs.

[0073] In some embodiments of this application, the transaction determination module 620 is further configured to: When the application to which the target processing thread belongs is a foreground application, the asynchronous Binder transaction is determined to be the target asynchronous Binder transaction; If the application to which the target processing thread belongs is not a foreground application, determine that the asynchronous Binder transaction is not the target asynchronous Binder transaction.

[0074] In some embodiments of this application, the transaction determination module 620 is further configured to: Obtain the process identifier and user identifier of the calling process of the asynchronous Binder transaction; When the user identifier is a preset identifier and the main process name corresponding to the process identifier is the target process name, the initiator of the asynchronous Binder transaction is determined to be the target system service; If the user identifier is not the default identifier, or if the main process name corresponding to the process identifier is not the target process name, it is determined that the initiator of the asynchronous Binder transaction is not the target system service.

[0075] In some embodiments of this application, the transaction determination module 620 is further configured to: Get the interface number of the asynchronous Binder transaction; When the interface corresponding to the interface number is the target interface, the target processing thread of the asynchronous Binder transaction is determined to be the target type thread; If the interface corresponding to the interface number is not the target interface, it is determined that the target processing thread of the asynchronous Binder transaction is not the target type thread.

[0076] In some embodiments of this application, the application to which the target processing thread belongs is obtained by the transaction determination module 620 based on the following steps: The client object corresponding to the asynchronous Binder transaction is determined based on the graphical surface identifier carried in the Binder data packet corresponding to the asynchronous Binder transaction. Based on the client object and thread association information, determine the thread identifier corresponding to the target processing thread; the thread association information is used to represent the correspondence between the client object and the thread identifier. Based on the thread identifier corresponding to the target processing thread, determine the process identifier corresponding to the target processing thread; Based on the process identifier, determine the application to which the target processing thread belongs.

[0077] In some embodiments of this application, the transaction acceleration module 630 is specifically used for: Layered acceleration processing is applied to the target asynchronous Binder transaction, including: Write the target asynchronous Binder transaction to the first priority queue; the first priority queue has a higher priority than the second priority queue, which is used to store other asynchronous Binder transactions besides the target asynchronous Binder transaction. When processing the target asynchronous Binder transaction, increase the scheduling priority of the processing thread corresponding to the target asynchronous Binder transaction.

[0078] In some embodiments of this application, the transaction acceleration module 630 is further configured to: During the asynchronous Binder transaction scheduling process, if there is a target asynchronous Binder transaction to be processed in the first priority queue, the target asynchronous Binder transaction in the first priority queue is selected and scheduled for execution. If there is no pending asynchronous Binder transaction in the first priority queue, select and schedule the asynchronous Binder transaction in the second priority queue for execution.

[0079] In some embodiments of this application, the target scenarios include one or more of the following: foreground application swiping scenario, foreground video playback and rendering scenario, foreground frame-by-frame animation scenario, page transition animation scenario, game rendering scenario, camera preview scenario, map interaction scenario, motion effect loop playback scenario, and real-time hand-drawn drawing scenario.

[0080] This application embodiment also provides a terminal device that integrates any of the transaction layering acceleration devices provided in this application embodiment. The terminal device includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor from the steps of the transaction layering acceleration method in any of the embodiments described above.

[0081] This application also provides a terminal device that integrates any of the transaction layering acceleration devices provided in this application. For example... Figure 8 As shown, it illustrates a structural schematic diagram of the terminal device involved in the embodiments of this application. Specifically: The terminal device may include components such as a processor 801 with one or more processing cores, a memory 802 with one or more computer-readable storage media, a power supply 803, and an input unit 804. Those skilled in the art will understand that... Figure 8 The terminal device structure shown does not constitute a limitation on the terminal device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 801 is the control center of the terminal device. It connects various parts of the terminal device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 802, and by calling data stored in the memory 802, it performs various functions and processes data of the terminal device, thereby providing overall monitoring of the terminal device. Optionally, the processor 801 may include one or more processing cores; preferably, the processor 801 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into the processor 801.

[0082] The memory 802 can be used to store software programs and modules. The processor 801 executes various functional applications and data processing by running the software programs and modules stored in the memory 802. The memory 802 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the terminal device, etc. In addition, the memory 802 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 802 may also include a memory controller to provide the processor 801 with access to the memory 802.

[0083] The terminal device also includes a power supply 803 that supplies power to the various components. Preferably, the power supply 803 can be logically connected to the processor 801 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 803 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0084] The terminal device may also include an input unit 804, which can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0085] Although not shown, the terminal device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 801 in the terminal device loads the executable files corresponding to the processes of one or more applications into the memory 802 according to the following instructions, and the processor 801 runs the applications stored in the memory 802 to realize various functions, as follows: When the foreground application is identified as being in the target scenario, asynchronous Binder transactions are detected. When an asynchronous Binder transaction is detected, determine whether the asynchronous Binder transaction is the target asynchronous Binder transaction; When the asynchronous Binder transaction is the target asynchronous Binder transaction, the target asynchronous Binder transaction is processed in layers to accelerate its processing.

[0086] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0087] Therefore, embodiments of this application provide a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc. A computer program is stored thereon, and the computer program is loaded by a processor to execute the steps in any of the transaction layering acceleration methods provided in embodiments of this application. For example, the computer program loaded by the processor can execute the following steps: When the foreground application is identified as being in the target scenario, asynchronous Binder transactions are detected. When an asynchronous Binder transaction is detected, determine whether the asynchronous Binder transaction is the target asynchronous Binder transaction; When the asynchronous Binder transaction is the target asynchronous Binder transaction, the target asynchronous Binder transaction is processed in layers to accelerate its processing.

[0088] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed descriptions of other embodiments above, which will not be repeated here.

[0089] In practice, each of the above units or structures can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units or structures, please refer to the previous method embodiments, which will not be repeated here.

[0090] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0091] The foregoing has provided a detailed description of a transaction layering acceleration method, apparatus, terminal device, and storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A transaction layering acceleration method, characterized in that, include: When the foreground application is identified as being in the target scenario, asynchronous Binder transactions are detected. When an asynchronous Binder transaction is detected, determine whether the asynchronous Binder transaction is the target asynchronous Binder transaction; When the asynchronous Binder transaction is the target asynchronous Binder transaction, the target asynchronous Binder transaction is subjected to tiered acceleration processing.

2. The transaction layering acceleration method according to claim 1, characterized in that, Determining whether the asynchronous Binder transaction is the target asynchronous Binder transaction includes: Determine whether the initiator of the asynchronous Binder transaction is the target system service; If the initiator of the asynchronous Binder transaction does not serve the target system, then the asynchronous Binder transaction is determined not to be the target asynchronous Binder transaction. When the initiator of the asynchronous Binder transaction is the target system service, the asynchronous Binder transaction is determined to be a target asynchronous Binder transaction based on the target processing thread of the asynchronous Binder transaction.

3. The transaction layering acceleration method according to claim 2, characterized in that, Determining whether the asynchronous Binder transaction is a target asynchronous Binder transaction based on the target processing thread of the asynchronous Binder transaction includes: Determine whether the target processing thread of the asynchronous Binder transaction is a target type thread; If the target processing thread of the asynchronous Binder transaction is not the target type thread, it is determined that the asynchronous Binder transaction is not the target asynchronous Binder transaction; When the target processing thread of the asynchronous Binder transaction is the target type thread, it is determined whether the asynchronous Binder transaction is a target asynchronous Binder transaction based on the application to which the target processing thread belongs.

4. The transaction layering acceleration method according to claim 3, characterized in that, The step of determining whether the asynchronous Binder transaction is a target asynchronous Binder transaction based on the application to which the target processing thread belongs includes: When the application to which the target processing thread belongs is the foreground application, the asynchronous Binder transaction is determined to be the target asynchronous Binder transaction; If the application to which the target processing thread belongs is not the foreground application, it is determined that the asynchronous Binder transaction is not the target asynchronous Binder transaction.

5. The transaction layering acceleration method according to claim 2, characterized in that, Determining whether the initiator of the asynchronous Binder transaction is the target system service includes: Obtain the process identifier and user identifier of the calling process of the asynchronous Binder transaction; When the user identifier is a preset identifier and the main process name corresponding to the process identifier is the target process name, the initiator of the asynchronous Binder transaction is determined to be the target system service. If the user identifier is not the preset identifier, or if the main process name corresponding to the process identifier is not the target process name, it is determined that the initiator of the asynchronous Binder transaction is not the target system service.

6. The transaction layering acceleration method according to claim 3, characterized in that, Determining whether the target processing thread of the asynchronous Binder transaction is a target type thread includes: Obtain the interface number of the asynchronous Binder transaction; When the interface corresponding to the interface number is the target interface, the target processing thread of the asynchronous Binder transaction is determined to be the target type thread; If the interface corresponding to the interface number is not the target interface, it is determined that the target processing thread of the asynchronous Binder transaction is not the target type thread.

7. The transaction layering acceleration method according to claim 4, characterized in that, The application to which the target processing thread belongs is obtained through the following steps: The client object corresponding to the asynchronous Binder transaction is determined based on the graphical surface identifier carried in the Binder data packet corresponding to the asynchronous Binder transaction. Based on the client object and thread association information, determine the thread identifier corresponding to the target processing thread; The thread association information is used to characterize the correspondence between the client object and the thread identifier; Based on the thread identifier corresponding to the target processing thread, determine the process identifier corresponding to the target processing thread; Based on the process identifier, the application to which the target processing thread belongs is determined.

8. The transaction layering acceleration method according to claim 1, characterized in that, The layered acceleration process for the target asynchronous Binder transaction includes: The target asynchronous Binder transaction is written into a first priority queue; the first priority queue has a higher priority than the second priority queue, which is used to store other asynchronous Binder transactions besides the target asynchronous Binder transaction. When processing the target asynchronous Binder transaction, increase the scheduling priority of the processing thread corresponding to the target asynchronous Binder transaction.

9. The transaction layering acceleration method according to claim 8, characterized in that, After writing the target asynchronous Binder transaction into the first priority queue, the process includes: During the asynchronous Binder transaction scheduling process, if there is a target asynchronous Binder transaction to be processed in the first priority queue, the target asynchronous Binder transaction in the first priority queue is selected and scheduled for execution. When there is no pending asynchronous Binder transaction in the first priority queue, the asynchronous Binder transaction in the second priority queue is selected and scheduled for execution.

10. The transaction layering acceleration method according to claim 1, characterized in that, The target scenarios include one or more of the following: front-end application sliding scenario, front-end video playback and rendering scenario, front-end frame-by-frame animation scenario, page transition animation scenario, game rendering scenario, camera preview scenario, map interaction scenario, motion effect loop playback scenario, and real-time hand-drawn drawing scenario.

11. A transaction layering acceleration device, characterized in that, include: The transaction detection module is used to detect asynchronous Binder transactions when the foreground application is identified as being in the target scenario. The transaction determination module is used to determine whether the asynchronous Binder transaction is the target asynchronous Binder transaction when an asynchronous Binder transaction is detected. The transaction acceleration module is used to perform layered acceleration processing on the target asynchronous Binder transaction when the asynchronous Binder transaction is the target asynchronous Binder transaction.

12. A terminal device, characterized in that, The terminal device includes: One or more processors; Memory; and One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor to implement the transaction layering acceleration method of any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, It stores a computer program, which is loaded by a processor to perform the steps in the transaction layering acceleration method according to any one of claims 1 to 10.

Images