Picture rendering method, device and equipment, and readable storage medium

Abstract

The application discloses an application picture rendering method and device, equipment and a readable storage medium, and creates a rendering program container corresponding to a target mobile terminal application; obtains pre-stored binary language type shader running data for the target mobile terminal application, and loads the shader running data into the rendering program container; wherein the shader running data comprises binary program data obtained by linking and compiling a local terminal shader program, and binary mapping data representing a syntax variable mapping relationship between a mobile terminal shader program of the target mobile terminal application and the local terminal shader program, the local terminal shader program being obtained by syntax translation based on the mobile terminal shader program; based on the binary program data and the binary mapping data in the rendering program container, a corresponding target shader program is executed to render a picture of the target mobile terminal application in an emulator. The application improves the rendering efficiency of the application picture and improves the security of the shader program.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to an application screen rendering method, apparatus, device, and readable storage medium. Background Technology

[0002] The development of information technology has driven the rapid growth of the entertainment industry, with an increasing number of applications running on mobile phones, such as game apps, movie apps, and shopping apps. However, using some mobile versions of applications on a mobile phone can have certain limitations. Therefore, using the mobile versions of these applications on a personal computer can broaden the ways to use mobile applications.

[0003] The relevant technology involves creating a renderer on a personal computer for a mobile version of the application, creating and binding vertex shaders and fragment shaders within the renderer, linking the vertex shaders and fragment shaders in the renderer to form a rendering pipeline, and rendering the mobile version of the application according to the rendering pipeline in the renderer so that the mobile version of the application can be used on the personal computer. Subsequently, when the use of the mobile version of the application on the personal computer is stopped, the rendering pipeline in the renderer is disconnected and the renderer is deleted.

[0004] In the process of researching and practicing related technologies, the inventors of this application discovered that when creating a rendering program for a mobile version of an application on a personal computer, the related technologies require a cumbersome process of creating and binding vertex shaders and fragment shaders, and linking them to form a rendering pipeline. This results in a long application startup time. Furthermore, since the vertex shader and fragment shader programs need to be provided in the form of source code, this can easily lead to the leakage of shader source code and lacks security. Summary of the Invention

[0005] This application provides an application screen rendering method, apparatus, device, and readable storage medium, which can simplify the rendering process, improve the rendering efficiency of application screens, and eliminate the need to provide shader programs in source code form, thereby enhancing the security of shader programs.

[0006] To solve the above-mentioned technical problems, this application provides the following technical solution:

[0007] This application provides an application screen rendering method, including:

[0008] Create a renderer container corresponding to the target mobile application, wherein the target mobile application is a mobile application in the simulator;

[0009] Obtain shader runtime data of a binary language type pre-stored for the target mobile application, and load the shader runtime data of the binary language type into the renderer container;

[0010] The shader runtime data of the binary language type includes binary program data obtained by linking and compiling the native shader program, and binary mapping data representing the syntax variable mapping relationship between the mobile shader program of the target mobile application and the native shader program. The native shader program is obtained by syntax translation based on the mobile shader program.

[0011] Based on the binary program data and binary mapping data in the rendering program container, the corresponding target shader program is executed to render the screen of the target mobile application in the simulator.

[0012] Accordingly, embodiments of this application provide an application screen rendering apparatus, including:

[0013] A creation unit is used to create a rendering program container corresponding to the target mobile application, wherein the target mobile application is a mobile application in the simulator;

[0014] The acquisition unit is used to acquire shader runtime data of a binary language type pre-stored for the target mobile application, and load the shader runtime data of the binary language type into the rendering program container;

[0015] The shader runtime data of the binary language type includes binary program data obtained by linking and compiling the native shader program, and binary mapping data representing the syntax variable mapping relationship between the mobile shader program of the target mobile application and the native shader program. The native shader program is obtained by syntax translation based on the mobile shader program.

[0016] An execution unit is configured to execute a corresponding target shader program based on the binary program data and the binary mapping data in the rendering program container, so as to render the screen of the target mobile application in the simulator.

[0017] In some embodiments, the acquiring unit is further configured to:

[0018] The runtime data to be parsed corresponding to the target mobile application is obtained from the storage space. The runtime data to be parsed includes at least a feature header, a data hash value, and candidate runtime data.

[0019] When the feature header matches the preset feature header for the running data to be parsed, a hash verification is performed on the candidate running data based on the data hash value;

[0020] When the hash verification of the candidate running data based on the data hash value passes, the candidate running data is determined to be shader running data of binary language type.

[0021] In some embodiments, the acquiring unit is further configured to:

[0022] The binary configuration parameters, binary program data, and binary mapping data are determined from the candidate runtime data;

[0023] Obtain the target configuration parameters of the local image processing unit, and verify the binary configuration parameters according to the target configuration parameters to obtain the verification result;

[0024] When the verification result shows that the binary configuration parameters are consistent with the target configuration parameters, the binary program data and binary mapping data are determined as shader runtime data of binary language type.

[0025] In some embodiments, the execution unit is further configured to:

[0026] The binary mapping data is deserialized to obtain the main syntax variable location table and the variable mapping table;

[0027] Based on the binary program data, start the corresponding target shader program;

[0028] The target shader program, once started, combines the main syntax variable location table and variable mapping table to render the screen of the target mobile application in the simulator.

[0029] In some embodiments, the execution unit is further configured to:

[0030] Based on the variable inverse mapping table in the variable mapping table, determine the target mobile terminal variable mapped to the real-time target local terminal variable in the binary program data;

[0031] Based on the target variable location information associated with the target mobile variable in the main syntax variable location table, the shader variable information of the target shader is adjusted to obtain the shader variable information of the target shader.

[0032] The target shader program, once started, combines the shader variable information of the target shader to render the screen of the target mobile application in the simulator.

[0033] In some embodiments, the execution unit is further configured to:

[0034] Send the target mobile terminal variables to the simulator;

[0035] When it is detected that the simulator calls the variable location interface to send a location query request for the target mobile terminal variable, the target local terminal variable mapped by the target mobile terminal variable is determined according to the variable positive mapping table in the variable mapping table;

[0036] Query the target variable location information corresponding to the target local variable from the main syntax variable location table;

[0037] Adjust the shader variable information of the target shader based on the target variable position information.

[0038] In some embodiments, the application rendering apparatus further includes a pre-storage unit for:

[0039] According to the target syntax rules, the mobile shader program of the target mobile application is translated into a native shader program.

[0040] Based on the syntax variable mapping relationship between the local shader program and the mobile shader program, binary mapping data is generated;

[0041] Obtain binary program data for the rendering pipeline formed by linking the local shader programs;

[0042] The binary mapping data and the binary program data are stored.

[0043] In some embodiments, the pre-storage unit is further configured to:

[0044] Determine the mobile syntax version corresponding to the mobile shader program of the target mobile application, and determine the target syntax version that matches the mobile syntax version according to the target syntax rules;

[0045] Determine the syntax extension attributes supported by the mobile syntax version in the target syntax version;

[0046] Read the target configuration parameters of the local image processing unit, and fill the syntax constants corresponding to the mobile syntax version according to the target configuration parameters to obtain the target syntax information corresponding to the target syntax version;

[0047] According to the syntax extension attributes and the target syntax information, the mobile shader program is translated into a native shader program corresponding to the target syntax version.

[0048] In some embodiments, the pre-storage unit is further configured to:

[0049] Obtain the syntax variable information corresponding to the local shader program;

[0050] Fill the preset variable location table with the location information corresponding to each target local variable in the syntax variable information to obtain the main syntax variable location table;

[0051] Based on the syntax variable information, determine the syntax variable mapping relationship between the local shader program and the mobile shader program, and generate a positive variable mapping table and a negative variable mapping table based on the syntax variable mapping relationship;

[0052] Binary mapping data is generated based on the main syntax variable position table, the variable forward mapping table, and the variable reverse mapping table.

[0053] In some embodiments, the pre-storage unit is further configured to:

[0054] Based on the binary mapping data and the binary program data, generate shader runtime data for binary language type;

[0055] The target configuration parameters, the binary language type, and the shader runtime data are bound together to obtain candidate runtime data;

[0056] Obtain the data hash value, data length, and feature header corresponding to the candidate running data;

[0057] The target running data is obtained by combining the feature header, the data length, the data hash value, and the candidate running data in that order, and then the target running data is stored.

[0058] In some embodiments, the application screen rendering apparatus further includes a notification unit for:

[0059] A notification message is generated and sent to the simulator. The notification message is used to instruct the shader running data that supports binary language types to run the target mobile application.

[0060] The creation unit is further configured to: when it detects that the simulator requests to run the target mobile application through the target shader program of the binary language type, create a rendering program container corresponding to the target mobile application.

[0061] In some embodiments, the application rendering apparatus further includes a download unit for:

[0062] Read the target configuration parameters and operating system parameters of the local image processing unit, and download the corresponding binary language type shader runtime data from the data sharing terminal according to the target configuration parameters and the operating system parameters;

[0063] The data sharing terminal stores at least binary language type shader runtime data uploaded by other devices for the target mobile application.

[0064] The downloaded shader runtime data for the binary language type is stored.

[0065] Furthermore, this application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described application screen rendering method.

[0066] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a computer program adapted for loading by a processor to execute the above-described application screen rendering method.

[0067] Furthermore, this application also provides a computer program product, which includes a computer program that can be stored in a storage medium. The processor of a computer device reads the computer program from the storage medium and executes the computer program to implement the above-described application screen rendering method.

[0068] This application embodiment can create a renderer container corresponding to a target mobile application, where the target mobile application is a mobile application in an simulator; obtain shader runtime data of a binary language type pre-stored for the target mobile application, and load the binary language type shader runtime data into the renderer container; wherein, the binary language type shader runtime data includes binary program data obtained by linking and compiling the native shader program, and binary mapping data representing the syntax variable mapping relationship between the mobile shader program of the target mobile application and the native shader program, the native shader program being obtained by syntax translation based on the mobile shader program; based on the binary program data and binary mapping data in the renderer container, execute the corresponding target shader program to render the screen of the target mobile application in the simulator.

[0069] Based on this, when the emulator triggers the launch of the target mobile application, the local end first creates a rendering program container for loading shader program data. Then, it obtains the shader runtime data of the binary language type pre-stored for the target mobile application and loads the binary language type shader runtime data into the rendering program container. It should be noted that the binary language type shader runtime data refers to the binary program data obtained by translating the mobile shader program of the target mobile application into the local shader program and then linking and compiling it, as well as the binary mapping data of the grammatical variable mapping relationship of the mobile shader program of the target mobile application before and after grammatical translation. Finally, based on the binary language type shader runtime data, the corresponding shader program is directly run on the personal computer to render the screen of the target mobile application in the emulator.

[0070] Therefore, compared to existing technologies that require creating and binding vertex and fragment shaders and linking them to form a rendering pipeline when creating a rendering program, this application obtains pre-stored shader runtime data in a binary language type and directly loads this binary language type shader runtime data into the rendering program container. Since binary language is machine language, the compiled code can be run directly without further interpretation or conversion. Therefore, the shader program corresponding to the shader runtime data can be run directly to render the screen of the target mobile application. This simplifies the rendering process, improves the rendering efficiency of the application screen, and avoids the leakage of shader source code in high-level language form by storing shader runtime data in a binary language type, thus improving the security of the shader program.

[0071] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

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

[0073] Figure 1 This is a scene diagram of the application screen rendering system provided in the embodiments of this application;

[0074] Figure 2This is a flowchart illustrating the steps of the application screen rendering method provided in the embodiments of this application;

[0075] Figure 3 This is a schematic diagram of another step in the application screen rendering method provided in the embodiments of this application;

[0076] Figure 4 A flowchart illustrating the rendering process of a mobile application on a personal computer, as provided in an embodiment of this application.

[0077] Figure 5 This is a flowchart of application screen rendering based on instruction stream provided in an embodiment of this application;

[0078] Figure 6 A flowchart illustrating the translation process between the mobile shader program and the native shader program provided in this application embodiment;

[0079] Figure 7 A flowchart illustrating the binary representation of the syntax variable mapping relationship provided in this application embodiment;

[0080] Figure 8 An example diagram illustrating the synchronization response of the binary shader program acquisition interface between the mobile terminal and the local terminal provided in this application embodiment;

[0081] Figure 9 A flowchart illustrating the interaction of syntax variable information in the instruction stream during the application screen rendering process provided in this embodiment of the application.

[0082] Figure 10 This is a schematic diagram of the structure of the application screen rendering device provided in the embodiments of this application;

[0083] Figure 11 This is a schematic diagram of the terminal structure provided in the embodiments of this application;

[0084] Figure 12 This is a schematic diagram of the server structure provided in an embodiment of this application. Detailed Implementation

[0085] To enable those skilled in the art to better understand the solutions of this application, 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.

[0086] It is understood that in the specific embodiments of this application, data related to shader runtime data, mobile shader programs, native shader programs, binary program data, binary mapping data, etc. are involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the target is required, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0087] Furthermore, when this application embodiment needs to obtain related data such as shader runtime data, mobile shader program, native shader program, binary program data, and binary mapping data, it will obtain separate permission or separate consent for the related data such as shader runtime data, mobile shader program, native shader program, binary program data, and binary mapping data through pop-up windows or redirection to a confirmation page. After clearly obtaining separate permission or separate consent for the related data such as shader runtime data, mobile shader program, native shader program, binary program data, and binary mapping data, it will then obtain the necessary shader runtime data, mobile shader program, native shader program, binary program data, and binary mapping data for enabling the application embodiment to operate normally.

[0088] It should be noted that while some processes described in the specification, claims, and accompanying drawings contain multiple steps that appear in a specific order, it should be clearly understood that these steps may not be performed in the order they appear herein, or may be performed in parallel. The step numbers are merely used to distinguish different steps and do not represent any particular order of execution. Furthermore, descriptions such as "first," "second," or "objective" in this document are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

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

[0090] This application provides an application rendering method, apparatus, device, and readable storage medium. When a target mobile application is launched via an emulator, a rendering program container is first created locally to load shader program data. Then, pre-stored binary language type shader runtime data for the target mobile application is obtained, and this binary language type shader runtime data is loaded into the rendering program container. It should be noted that this binary language type shader runtime data refers to the binary program data obtained after linking and compiling the local shader program translated from the mobile shader program of the target mobile application, as well as the binary mapping data of the syntax variable mapping relationship of the mobile shader program of the target mobile application before and after translation. Finally, the corresponding shader program is directly run based on the binary language type shader runtime data to render the screen of the target mobile application in the emulator. Please refer to the following specific embodiments for details.

[0091] The application screen rendering methods of the various embodiments of this application can be executed by a computer device, which can be a server or a terminal or other similar device.

[0092] Terminals can be personal computers (such as tablets, laptops, desktop computers, etc.), smart home appliances, in-vehicle terminals, intelligent voice interaction devices, aircraft, etc.

[0093] A server can be a computer system that provides certain services to terminals. Compared to ordinary terminals, servers have higher requirements in terms of stability, security, and performance. For example, a server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0094] The application screen rendering method in this application embodiment can be implemented by the terminal, while the server provides corresponding business data services to the terminal. Alternatively, the application screen rendering method can also be implemented by the server, with the terminal displaying the application screen data obtained from processing the server's data. Furthermore, the application screen rendering method can also be implemented partly on the terminal and partly on the server, thus achieving a joint implementation by both the terminal and the server.

[0095] See Figure 1 This is a scene diagram of the application screen rendering system provided in the embodiments of this application. The system includes a terminal 110 and a server 120.

[0096] The terminal 110 can have the target mobile application installed, and the corresponding application services can be run through the target mobile application. The server 120 can be the business server corresponding to the target mobile application.

[0097] Taking a personal computer as an example, the personal computer creates an emulator using virtualization technology. When the target mobile application is launched on the emulator, the local end of the personal computer executes the steps of the application screen rendering method. Specifically, a rendering program container corresponding to the target mobile application can be created, where the target mobile application is the mobile application in the emulator; pre-stored binary language type shader runtime data for the target mobile application is obtained, and the binary language type shader runtime data is loaded into the rendering program container; the binary language type shader runtime data includes binary program data obtained by linking and compiling the local shader program, and binary mapping data representing the syntax variable mapping relationship between the mobile shader program of the target mobile application and the local shader program, which is obtained by syntax translation based on the mobile shader program; based on the binary program data and binary mapping data in the rendering program container, the corresponding target shader program is executed to render the screen of the target mobile application in the emulator.

[0098] Based on the above, this application can obtain pre-stored shader runtime data in a binary language type and directly load this binary language type shader runtime data into the rendering program container so that the shader program can be directly run to render the screen of the target mobile application. In this way, the rendering process can be simplified, the rendering efficiency of the application screen can be improved, and since the shader runtime data is stored in a binary language type, the leakage of shader source code is avoided, thus improving the security of the shader program.

[0099] It should be noted that the above are just examples and can be applied to other application rendering scenarios, which will not be elaborated on here.

[0100] To facilitate understanding, each step of the application rendering method will be described in detail below. It should be noted that the order of the following embodiments is not intended to limit the preferred order of the embodiments.

[0101] See Figure 2 , Figure 2 This is a flowchart illustrating the steps of the application screen rendering method provided in this application embodiment. In this application embodiment, the application screen rendering method can be performed by... Figure 1 The process is executed by terminal 110. To better illustrate the embodiments of this application, we will take a personal computer as an example. The specific process is as follows:

[0102] 101. Create the rendering container corresponding to the target mobile application.

[0103] Currently, many service providers have developed mobile versions of their applications for mobile devices (such as smartphones, smartwatches, and other computer devices). For example, mobile versions of games and short video applications have been developed for smartphones. However, while users can conveniently use these mobile applications anytime, the hardware limitations of mobile devices may hinder user operation and restrict rendering performance. For instance, a mobile device might limit the operation and rendering effects of a game application. To address this, virtualization technology has been introduced, enabling the running of mobile applications on a PC. Thus, when a user's device allows, they can use the mobile version of the application on their personal computer.

[0104] To facilitate understanding, virtualization technology will be described below. Virtualization technology is primarily implemented using mobile emulators on personal computer devices. It can be understood as a simulated environment created through virtualization. The core of the emulator is to create a virtual target device environment on the host device, distinct from the host device. This helps developers test application compatibility within the simulated target device environment and provides users with a way to use applications from that environment on the host device without needing the target device itself. For example, it allows users to use Android mobile applications on desktop operating systems such as Windows and macOS.

[0105] When running a mobile application on a personal computer using virtualization technology, a renderer is created for the mobile version of the application. Within this renderer, vertex and fragment shaders are created and bound. These vertex and fragment shaders are then linked to form a rendering pipeline, which is used to render the mobile version of the application on the personal computer. However, this process involves a cumbersome workflow of creating and binding vertex and fragment shaders and linking them to form a rendering pipeline, resulting in longer application startup times. Furthermore, because the vertex and fragment shaders are provided as source code, this can easily lead to the leakage of shader source code, reducing the security of the shader program.

[0106] Based on this, in order to simplify the rendering process, this application embodiment obtains pre-stored shader runtime data in a binary language type and directly loads this binary language type shader runtime data into the rendering program container, so that the shader program can be directly run to render the screen of the target mobile application, thereby improving the rendering efficiency of the application screen. Furthermore, to prevent the leakage of shader source code, the shader runtime data is stored in a binary language type, thereby enhancing the security of the shader program.

[0107] This application embodiment utilizes virtualization technology to abstract and simulate an emulator environment on a personal computer. This emulator environment can be a virtual environment obtained by simulating a mobile terminal (mobile phone, smartwatch, smart wearable device, etc.), used to run mobile versions of applications on the personal computer. It should be noted that this emulator environment can also be understood as a virtual machine. In addition to the emulator environment, the personal computer also includes another operating environment, namely the personal computer's local operating system. The emulator environment can be used as the mobile terminal, and the local terminal environment as the local terminal.

[0108] The target mobile application refers to applications developed for mobile terminals, such as game applications, short video applications, online shopping applications, and live streaming applications developed for mobile operating environments. Furthermore, the target mobile application is a mobile application running on an emulator; specifically, the mobile version of the application can run in the emulator environment, while the local client on the personal computer provides data support for the operation of the mobile version of the application.

[0109] The rendering container can be a container used to load data related to the shader program. In the computer field, a container can be an application-specific container that packages software and all its dependencies (such as code, runtime environment, system tools, system libraries, etc.) into a single unit. By loading the shader program's data into this container, the shaders can be run based on the shader runtime data within the container to render the target mobile application's screen. It's important to understand that the execution process of the target mobile application can be viewed as the shader rendering process.

[0110] In this embodiment, after abstracting and simulating an operating environment for a mobile terminal on a personal computer using virtualization technology, the personal computer can be considered to include at least two operating environments, specifically an emulator environment for the mobile terminal and a local operating environment. The emulator environment can be understood as a simulation environment for the mobile terminal, used to run the target mobile application. When the personal computer detects that the target mobile application is to be launched in the emulator environment, it can create a renderer container on the local side so that the shader-related runtime data of the target mobile application can be loaded into the renderer container, and the screen rendering of the target mobile application can be performed based on the runtime data in the renderer container.

[0111] It's important to note that running mobile applications using virtualization technology involves data interaction. Specifically, rendering the target mobile application's screen involves command interaction between the mobile device (i.e., the emulator environment) and the local device (i.e., the local operating environment). The local device executes the application's screen rendering process based on the mobile device's commands. To avoid complex and cumbersome screen rendering processes, the local device can support loading binary shader program data in the rendering program container, thereby skipping processes such as program loading, binding, and linking.

[0112] In some implementations, to avoid cumbersome and complex rendering processes, a notification message indicating that the local machine supports shader runtime data in binary language types can be sent to the simulator environment. This allows the simulator environment to request the local machine to run the corresponding target mobile application directly using the shader program data in the binary language type. For example, before step 101, the process may further include: generating a notification message and sending the notification message to the simulator, the notification message indicating that the target mobile application is run using shader runtime data in a binary language type; then step 101 may include: when a request is detected from the simulator to run the target mobile application using the target shader program in the binary language type, creating a renderer container corresponding to the target mobile application.

[0113] The binary language type can be binary machine language, represented by 0s and 1s. Specifically, machine language is a set of binary code instructions that a computer can directly recognize and execute. It is the lowest-level computer language, using binary numbers (0s and 1s) to represent instructions and data. Each computer's central processing unit (CPU) has its own specific set of machine language instructions. These instructions directly control the operation of computer hardware, such as data transmission, arithmetic and logical operations, and control transfer.

[0114] It's important to note that because the language types supported by the native operating environment of a personal computer may differ from the shader language types used by the mobile operating environment, the native environment needs to undergo a cumbersome process of translating, loading, binding, linking, and compiling the mobile shader program. Therefore, to avoid this cumbersome process, the target mobile application's mobile shader program can be pre-converted into data in a language type directly supported by the native environment, such as binary language shader data, and this binary language data can be pre-stored for later loading and use. Based on this, the native environment can directly load the target shader program in a binary language type to run the target mobile application and notify the emulator environment.

[0115] Subsequently, when a user launches the target mobile application in the simulator environment, the simulator environment calls the local binary program interface to send a runtime request for the target mobile application. This can be understood as a loading request for the "target shader program in binary language type." At this time, the local machine uses this binary program interface to create a corresponding renderer container for the target mobile application in the simulator environment. This allows for the subsequent loading of shader-related data in binary language type corresponding to the target mobile application into the renderer container based on a simplified instruction flow, in order to execute the rendering of the target mobile application's screen. This eliminates the need for the cumbersome process of creating and binding vertex and fragment shaders and linking them to form a rendering pipeline, thus simplifying the rendering process.

[0116] Using the above method, when the target mobile application is launched in the simulator environment, a renderer container can be created for the target mobile application so that the shader runtime data of binary language type can be directly loaded into the renderer container to perform screen rendering of the target mobile application.

[0117] 102. Obtain the shader runtime data of the binary language type pre-stored for the target mobile application, and load the shader runtime data of the binary language type into the renderer container.

[0118] In this embodiment, after creating a corresponding renderer container for the target mobile application, pre-stored binary language type shader runtime data for the target mobile application can be obtained and loaded into the renderer container. Specifically, to ensure that correct, complete, and target-app-corresponding binary language type shader runtime data is loaded into the renderer container, the shader-related data needs to be verified. Only after successful verification is the data loaded into the renderer container, ensuring the accuracy of the binary language type shader runtime data and enabling the target mobile application's screen to be rendered.

[0119] Specifically, the shader runtime data can be binary runtime data related to the target mobile application's shader program running on the local machine. It describes how a "model" is rendered, representing a rendering logic. In detail, since the target mobile application can only run in its corresponding operating environment, when running on a personal computer's operating environment using virtualization technology, the mobile shader program (using the mobile's shading language) needs to be translated into a native shader program (using the local graphics programming high-level shading language). The differences in syntax variables between the two, as well as the binary language type program data of the native shader program at runtime, are then obtained to generate the shader runtime data.

[0120] The binary language type shader runtime data includes binary program data obtained by linking and compiling the native shader program, and binary mapping data representing the syntax variable mapping relationship between the mobile shader program and the native shader program of the target mobile application. The native shader program is obtained by syntax translation based on the mobile shader program.

[0121] It's important to note that for real-time data streaming applications (such as games and live streaming apps), this can be understood as a real-time rendering process, specifically rendered by the target mobile application's shader program. Therefore, a mobile shader program can be the mobile version of the target mobile application's shader program, for example, a mobile phone version of the shader program; while a native shader program can be the corresponding shader program of the mobile shader program on the local device. The syntax of mobile shader programs and native shader programs differs, requiring translation and conversion between them.

[0122] Since mobile shader programs and native shader programs use different shader languages, which can be understood as different syntax descriptions, it is necessary to obtain the syntax differences between the mobile shader program and the native shader program. Specifically, this can be achieved by obtaining the differences in syntax variables between the two programs. These syntax variable differences can be understood as the different expressions of the same semantic variable in the mobile shader program and the native shader program. For this same semantic variable, the syntax variable mapping relationship between the mobile shader program and the native shader program can be obtained, as well as the position information of each variable in the shader. This syntax variable mapping relationship and the position information of each variable in the shader can be described in binary form to obtain binary mapping data.

[0123] In addition, in order to obtain the binary language type program data of the native shader program that can be run directly, the native shader program needs to be linked and compiled to obtain the binary program data. This skips the compilation process of the native shader program in the high-level language and allows the native shader to be run directly with the final binary program data.

[0124] In some implementations, to avoid the cumbersome process of creating and binding vertex and fragment shaders and linking them to form a rendering pipeline, the mobile shader program can be translated into a native shader program before rendering. The native shader program and the syntax variable mappings before and after translation can be pre-stored in binary form. For example, before step 102, the following may also be included:

[0125] (1) Translate the mobile shader program of the target mobile application into a native shader program according to the target syntax rules;

[0126] (2) Generate binary mapping data based on the syntax variable mapping relationship between the local shader program and the mobile shader program;

[0127] (3) Obtain the binary program data of the rendering pipeline formed by linking the local shader programs;

[0128] (4) Store binary mapping data and binary program data.

[0129] The target syntax rule may include syntax version correspondence information between mobile shader programs and native shader programs, indicating the syntax version correspondence between different shader languages. It can be understood that mobile shader programs and native shader programs use different shader languages, and different shader languages ​​correspond to different language versions during conversion.

[0130] For example, the mobile shader program uses an embedded shading language (ESSL), while the native shader program uses a high-level shading language for graphics programming (OpenGL Shading Language, GLSL). A shading language can have multiple versions; for instance, the embedded shading language versions include ESSL100, ESSL300, and ESSL310, while the high-level shading language versions include GLSL330, GLSL430, and GLSL450. Specifically, ESSL100 corresponds to GLSL330, ESSL300 corresponds to GLSL430, and ESSL310 corresponds to GLSL450. Based on the version correspondence information between different shading languages, the target syntax rules are constructed.

[0131] The binary mapping data may include a description of the syntax variable mapping relationship between the mobile shader program and the native shader program, representing the differences in syntax variables between the two programs. It also includes binary data of a variable location table describing the location information of each syntax variable. Specifically, since the mobile shader program and the native shader program use different shader languages, for any given semantic variable (uniform), the syntax variable mapping relationship between the two programs can be obtained and described in binary form.

[0132] The binary program data can be program data in binary form obtained after linking and compiling the native shader program. It can be understood as the basic shader data in binary form that can be directly read and run on the native side.

[0133] To avoid the tedious and complex shader building process during image rendering, when a personal computer runs a target mobile application via virtualization technology for the first time or at any other time, it can process and generate binary shader-related data based on the instructions of the emulator environment, and store this binary shader-related data at the appropriate time. Specifically, when it is detected that the emulator environment starts the target mobile application for the first time or at a target time (such as the first launch time after the target mobile application is updated, or other scenarios that require storing binary shader-related data), the mobile shader program of the target mobile application is translated into a native shader program according to the target syntax rules to obtain the shader program of the high-level shading language of image programming; then, the syntactic variable differences between the mobile shader program and the native shader program are determined, and binary mapping data is generated; furthermore, the native shader program may include vertex shader programs and fragment shader programs, which are linked to form a rendering pipeline, and the corresponding programs of the rendering pipeline are compiled to obtain binary program data; finally, the binary program data and binary mapping data are stored. In this way, shader runtime data of binary language types that can be directly run locally can be stored in advance, so that the shader runtime data of the binary language type can be directly loaded later, avoiding the tedious and complicated shader building process during the rendering process.

[0134] In some implementations, the target syntax version, syntax extension attributes, and target syntax information supported by the mobile shader program of the target mobile application can be determined first, so as to translate the mobile shader program into a native shader program based on the target syntax version, syntax extension attributes, and target syntax information. For example, step (1) may include: determining the mobile syntax version corresponding to the mobile shader program of the target mobile application, and determining the target syntax version that matches the mobile syntax version according to the target syntax rules; determining the syntax extension attributes supported by the mobile syntax version in the target syntax version; reading the target configuration parameters of the local image processing unit, and filling the syntax constants corresponding to the mobile syntax version according to the target configuration parameters to obtain the target syntax information corresponding to the target syntax version; translating the mobile shader program into a native shader program corresponding to the target syntax version according to the syntax extension attributes and target syntax information.

[0135] The mobile syntax version can be a colorized language version for mobile applications, such as ESSL100, ESSL300, ESSL310, etc.

[0136] The target syntax version can be a version of the high-level shading language for image programming used by the native shader program, such as GLSL330, GLSL430, GLSL450, etc.

[0137] The syntax extension attribute can be the syntax extension attribute function supported by the mobile syntax version after being converted to the target syntax version. Specifically, it can also be understood as the syntax extension attribute supported by the mobile shader program of the mobile syntax version after being converted to the native shader program of the target syntax version.

[0138] The image processing unit can be a graphics processing unit (GPU) hardware unit on a personal computer. This means that the image processing unit has corresponding characteristic parameters that reflect hardware parameters, including key GPU parameters such as computing power, memory size, memory bandwidth, power consumption control, and inter-card interconnection speed. Based on these hardware parameters, characteristic parameters can be determined, such as the number of frames buffered per second, the shader rendering rate, and the model of the image processing unit. Based on this information, target configuration parameters are generated for use in the syntax constant filling process or subsequent validation processes.

[0139] The target syntax information can be the syntax information corresponding to the target syntax version (GLSL), which reflects the limitations or characteristics of a personal computer's graphics card in handling uniform buffers and shader storage buffers. These graphics card characteristics may be reflected in the GLSL syntax information in some way, such as limiting the scope of syntax usage for certain buffer-related operations or providing syntax structures optimized for a specific graphics card. For example, if the graphics card supports a limited maximum number of uniform buffer bindings, the GLSL syntax information may include limits or optimization suggestions on the number of uniform buffers used to ensure that shader programs running on that graphics card can correctly and efficiently utilize graphics card resources, avoiding performance problems or errors caused by unreasonable buffer usage.

[0140] Specifically, the process of translating a mobile shader program into a native shader program is as follows: First, the mobile syntax version of the target mobile application's mobile shader program is detected. Then, according to the syntax version correspondence of different shader languages ​​in the target syntax rules, the target syntax version matching the mobile syntax version is determined. For example, taking a game application as an example, the game platform may release some cool skins and special effects that require a new version to use and display. Therefore, before translating the mobile shader program into a native shader program, the syntax version of the mobile shader program needs to be determined first. It should be noted that during game rendering, assuming there are two "skins" or "effects" with different syntax versions, different syntax versions of "skins" may appear during the rendering process. In this case, using binary language types, only the translation of these effects and skins needs to be performed once, and the variable information of the shader program (such as variables and their positions) needs to be serialized and saved. Subsequently, the model rendering of different versions of "skins" or "effects" for the same application screen can be directly executed based on the variable information.

[0141] Next, the syntax extension attributes supported by the mobile syntax version in the target syntax version are determined. Then, based on the target configuration parameters of the image processing unit, the syntax constants corresponding to the mobile syntax version (ESSL syntax version) are populated to obtain the syntax information of the high-level shading language syntax version for graphics programming. This target syntax information can limit the scope of syntax usage for buffer-related operations during rendering, such as the amount of buffer space rendered per unit time. Finally, according to the syntax extension attributes and the target syntax information, the mobile shader program is translated into a native shader program corresponding to the target syntax version. Thus, the mobile shader program can be translated into a native shader program of a syntax version of the high-level shading language for graphics programming that is supported by the personal computer's native end, so that the binary program data corresponding to this native shader program can be stored subsequently, and the data can be directly loaded to run the corresponding target shader program.

[0142] In some implementations, the syntax variable mapping information between the mobile shader program and the native shader program may include syntax variable information and the position information of each target native variable, and binary mapping data is generated based on the syntax variable information and the position information of each target native variable. For example, step (2) may include: obtaining the syntax variable information corresponding to the native shader program; filling the position information corresponding to each target native variable in the syntax variable information into a preset variable position table to obtain a main syntax variable position table; determining the syntax variable mapping relationship between the native shader program and the mobile shader program based on the syntax variable information, and generating a variable forward mapping table and a variable reverse mapping table based on the syntax variable mapping relationship; generating binary mapping data based on the main syntax variable position table, the variable forward mapping table, and the variable reverse mapping table.

[0143] The syntax variable information can be the variable information of the native shader program translated into a high-level shading language for graphics programming. It includes one or more native variables, including but not limited to defined uniform variables, varying variables used to pass data between vertex shaders and fragment shaders, vertex attribute variables, interface blocks, etc.

[0144] It's important to note that the `uniform` variable is a modifier for syntactic variables, used to define the access scope of shader variables. It does not define the type of the variable's own structure (such as `int`, `float`, `vector`, etc.). Vertex shaders and fragment shaders are designed on different hardware units, and variables enable data access between different shader programs. It's worth noting that the variable's value will not change until the entire shader execution is complete. It can be combined with variables of any basic type, and `uniform` variables can also be used to store environmental data passed from external programs (such as point light positions, model transformation matrices, etc.).

[0145] Vertex attribute variables are used in vertex shaders and can only be combined with floating-point, vector, or matrix variables. Vertex attribute variables can be used to store model vertex, normal, color, texture, and other data passed from the program, and they can access the data buffer.

[0146] Varying variables act as messengers between the vertex shader and the fragment shader. Typically, the variable is modified in the vertex shader and then used in the fragment shader.

[0147] The main syntax variable location table is used to record the location information of each target local variable. The corresponding data parameters are manipulated through this location information, such as modifying the data parameters corresponding to the location information to modify the shader data.

[0148] Specifically, the syntax variable mapping relationship includes a forward mapping from mobile syntax variables in the mobile shader program to local syntax variables in the native shader program, and a reverse mapping from local syntax variables in the native shader program to mobile syntax variables in the mobile shader program. Therefore, the forward variable mapping table contains the forward mapping relationship between mobile syntax variables and native syntax variables, and the reverse variable mapping table contains the reverse mapping relationship between native syntax variables and mobile syntax variables.

[0149] Specifically, the process of assembling this binary mapping data is as follows: First, the corresponding syntax variable information is obtained from the native shader program. This syntax variable information includes one or more target native variables, and the location information corresponding to each target native variable is obtained. Then, recursively, the location information corresponding to each target native variable is filled into the preset variable location table to obtain the main syntax variable location table. It should be noted that the recursive method can traverse the data structures related to native syntax variables (uniforms). For example, there are multiple native syntax variables (uniforms) in the shader program, and there may be nested or hierarchical structures (such as uniform variables in a structure). The recursive algorithm can start from the outermost layer and go deep into each internal layer in turn to accurately determine the location of each uniform variable in memory. Therefore, by recursively traversing, it is ensured that no native syntax variable is missed, and complex data structure relationships can be handled correctly, providing a foundation for quickly and accurately accessing these variables in the subsequent graphics rendering process.

[0150] Furthermore, based on the syntax variable information, the local syntax variables corresponding to the local shader program are determined, and the mobile syntax variables mapped to these local syntax variables in the mobile shader program are also determined. Based on the inverse mapping relationship between the local and mobile syntax variables, a variable inverse mapping table is generated, and based on the forward mapping relationship between the mobile and local syntax variables, a variable forward mapping table is generated. Finally, using binary serialization, the main syntax variable position table, variable forward mapping table, and variable inverse mapping table are saved to obtain binary mapping data. This binary serialization can be understood as the process of converting complex data structures (such as objects, structs, etc.) into byte streams. For example, in vertex data (vertex position, color, texture coordinates, etc.), binary serialization can convert this vertex data structure into a byte sequence, allowing for subsequent storage of the binary mapped data and reducing storage space (such as cache, memory, etc.).

[0151] In some implementations, in order to subsequently verify the integrity of the binary program data and binary mapping data associated with the local shader program, verification index information can be bound to the binary program data and binary mapping data so that the binary program data and binary mapping data can be verified according to the verification index information. For example, step (4) may include: generating shader runtime data of binary language type according to binary mapping data and binary program data; binding the target configuration parameters, binary language type and shader runtime data to obtain candidate runtime data; obtaining the data hash value, data length and feature header corresponding to the candidate runtime data; combining them in the order of feature header, data length, data hash value and candidate runtime data to obtain target runtime data, and storing the target runtime data.

[0152] To ensure that complete shader runtime data of the binary language type can be obtained subsequently, verification index information needs to be set for the shader runtime data of this binary language type. The verification index information includes, but is not limited to, the target configuration parameters of the image processing unit, the binary version corresponding to the binary language type, the data hash, the data length, and the feature header, etc. By binding these verification index information with the shader runtime data, the binary language type shader runtime data can be verified according to these verification index information to ensure data integrity.

[0153] Specifically, the storage process for binary mapping data and binary program data is as follows: First, the binary mapping data and binary program data are combined, such as through overlay, concatenation, or binding, to obtain shader runtime data of the binary language type. Then, the target configuration parameters corresponding to the personal computer's graphics processing unit (GPU) are obtained, such as the graphics card model, serial number, and configuration, as well as the binary version number corresponding to the binary language type. This information is then bound to the shader runtime data to obtain candidate runtime data. Subsequently, when this candidate runtime data is obtained, the target configuration information can be used to verify the shader runtime data to determine whether the shader runtime data supports the GPU.

[0154] Furthermore, a corresponding data hash is calculated for the candidate running data. For example, a Message-Digest Algorithm (MD5) or a Secure Hash Algorithm 256 (SHA256) can be used to calculate the hash value of the candidate running data. A corresponding data length is also set, which describes the bit sequence in which the candidate running data appears; this can be understood as the candidate running data's position within the overall data set. Additionally, a feature header is defined for the candidate running data. This header can be a numerical value indicating the data type contained in the candidate running data, or a predefined code, flag, etc., used to identify the candidate running data. Finally, these data are combined according to the feature header, data length, data hash value, and the specific order format of the candidate running data to obtain the target running data, which is then stored.

[0155] Based on this, the mobile shader program corresponding to the target mobile application in the simulator environment can be translated into a native shader program. The mapping relationship between the mobile syntax variables of the mobile shader program and the native syntax variables of the native shader program is determined, along with a master syntax variable location table containing the location information of each native syntax variable. Binary mapping data is generated based on this mapping relationship and the master syntax variable location table, and the binary program data obtained after linking and compiling the native shader program is acquired. Thus, binary language-type shader runtime data can be obtained. Furthermore, verification index information is bound to this shader runtime data to obtain target runtime data. This pre-built target runtime data can be stored. This target runtime data describes the shader state and / or variable information of the native shader program during runtime, representing the binary data required by the native shader during runtime. The target runtime data can be directly loaded and used after subsequent parsing and verification, avoiding the cumbersome and complex processes of translating between the mobile and native shader programs, loading, binding, linking, and compiling the native shader program, thereby improving the efficiency of subsequent application rendering.

[0156] In this embodiment, to avoid complex and cumbersome processes during application rendering, binary language shader runtime data can be obtained through sharing. Specifically, different personal computers can share the binary language shader runtime data associated with the target mobile application. After generating the binary language shader runtime data, the personal computer can upload it to a data sharing platform for access by any computer device or a computer device with sharing permissions.

[0157] In some implementations, after generating binary language-type shader runtime data based on binary mapping data and binary program data, this binary language-type shader runtime data can be associated with the target configuration parameters and operating system parameters of the image processing unit on the personal computer. After the association is completed, the associated binary language-type shader runtime data is uploaded to the data sharing terminal. Alternatively, after obtaining the target runtime data by combining the feature header, data length, data hash value, and candidate runtime data in that order, the target runtime data can be associated with the target configuration parameters and operating system parameters of the image processing unit on the personal computer. After the association is completed, the associated target runtime data is uploaded to the data sharing terminal.

[0158] In some implementations, to avoid the cumbersome process of creating and binding vertex and fragment shaders and linking them to form a rendering pipeline, binary shader-related data can be downloaded from a data sharing terminal before rendering for pre-storage. For example, before step 102, the process may further include: reading the target configuration parameters and operating system parameters of the local image processing unit, and downloading the corresponding binary language type shader runtime data from the data sharing terminal based on the target configuration parameters and operating system parameters; wherein the data sharing terminal stores at least binary language type shader runtime data uploaded by other devices for the target mobile application; and storing the downloaded binary language type shader runtime data.

[0159] Here, the target configuration parameter refers to the configuration parameters of the graphics card of this personal computer, and the operating system parameter refers to the version number of the operating environment (such as Win7, Win10, etc.). To obtain shader runtime data conforming to the local personal computer's binary language type from the data sharing terminal, the target configuration parameters and operating system parameters of the image processing unit of this personal computer can be read first. Then, from the binary language type shader runtime data already stored on the data sharing terminal, the shader runtime data of the binary language type shared by other devices is searched according to the target configuration parameters and operating system parameters, and the found target shader runtime data is downloaded. Finally, the downloaded target shader runtime data is stored. It should be noted that when storing the target shader runtime data, it can be bound to the verification index information as described above, and stored only after the binding is completed.

[0160] Furthermore, after obtaining the target shader runtime data in binary language type, this data can be directly loaded into an already created renderer container for immediate use. It should be noted that when the data sharing end stores target runtime data uploaded from other devices, the same principle applies; this target runtime data can be directly stored or parsed and used. In this way, by sharing shader runtime data in binary language type, the cumbersome process of creating and binding vertex and fragment shaders and linking them to form a rendering pipeline is avoided, improving the efficiency of subsequent application rendering.

[0161] In this embodiment of the application, after creating a corresponding rendering program container for the target mobile application, the target running data pre-stored for the target mobile application can be obtained, and the target running data can be parsed and its integrity verified. After the verification is passed, the binary language type shader running data is loaded into the rendering program container to ensure the accuracy of the binary language type shader running data, so that the screen of the target mobile application can be rendered.

[0162] In some implementations, runtime data corresponding to the target mobile application can be obtained. After parsing, it is verified based on the feature header and hash method to determine the candidate runtime data that passes the verification as shader runtime data of binary language type. For example, "obtaining shader runtime data of binary language type pre-stored for the target mobile application" in step 102 may include:

[0163] (102.1) Obtain the runtime data to be parsed corresponding to the target mobile application from the storage space. The runtime data to be parsed includes at least the feature header, data hash value and candidate runtime data;

[0164] (102.2) When the feature header is consistent with the preset feature header for the running data to be parsed, perform hash verification on the candidate running data based on the data hash value;

[0165] (102.3) When the hash verification of the candidate running data based on the data hash value passes, the candidate running data is determined to be shader running data of binary language type.

[0166] Specifically, the process retrieves the runtime data to be parsed for the target mobile application from the local personal computer's storage. This runtime data is then parsed to obtain a feature header, a data hash value, and candidate runtime data. A pre-defined feature header is then determined for the runtime data to be parsed. This pre-defined feature header is compared with the parsed feature header. If the pre-defined feature header matches the parsed feature header, a hash check is performed on the candidate runtime data based on the data hash value. Specifically, a hash value to be checked for the candidate runtime data is calculated and compared with the parsed data hash value. If the hash value to be checked matches the parsed data hash value, the hash check on the candidate runtime data based on the data hash value has passed. Finally, when the hash check on the candidate runtime data based on the data hash value passes, the candidate runtime data is determined to be shader runtime data of a binary language type.

[0167] It should be noted that if the preset feature header is inconsistent with the parsed feature header, and / or if the hash verification of the candidate running data based on the data hash value fails, it indicates that the data is incomplete, and the running data that fails the verification can be rejected and loaded into the rendering program container. Furthermore, the mobile shader program of the target mobile application can be directly translated into the native shader program, and the syntax variable mapping information and variable position information between the mobile shader program and the native shader program can be obtained to generate binary mapping data. In addition, the native shader program is linked and compiled to obtain binary program data, and the binary mapping data and binary program data are loaded into the rendering program container.

[0168] In some implementations, candidate runtime data consists of binary configuration parameters, binary program data, and binary mapping data. Based on the binary configuration parameters, the matching between the binary program data and the binary mapping data and the image processing unit of the personal computer is verified. If a match is found, the binary program data and binary mapping data are determined as shader runtime data of a binary language type. For example, step (102.3), "determining candidate runtime data as shader runtime data of a binary language type," may include: determining binary configuration parameters, binary program data, and binary mapping data from the candidate runtime data; obtaining the target configuration parameters of the local image processing unit, and verifying the binary configuration parameters based on the target configuration parameters to obtain a verification result; when the verification result shows that the binary configuration parameters match the target configuration parameters, the binary program data and binary mapping data are determined as shader runtime data of a binary language type.

[0169] Specifically, after obtaining candidate runtime data, it can be parsed to obtain binary mechanism configuration parameters, binary program data, and binary mapping data. The binary mechanism configuration parameters can be understood as the configuration parameters of the image processing unit supported by the current binary program data and binary mapping data. Based on the binary configuration parameters, it is determined whether the binary program data and binary mapping data are compatible with the personal computer's image processing unit. Therefore, the target configuration parameters of the personal computer's image processing unit are obtained and compared with the binary configuration parameters. If the binary configuration parameters match the target configuration parameters (e.g., the graphics card model represented by the binary configuration parameters matches the graphics card model in the target configuration parameters), then the binary program data and binary mapping data are determined to be shader runtime data of a binary language type. It should be noted that the rendering process is primarily implemented based on the PC's (local) graphics card; therefore, shader-related parameters (such as the graphics card configuration parameters recorded in the binary configuration parameters) also need to be consistent with the actual configuration parameters of the graphics card to ensure that the graphics card can support the binary program data and binary mapping data.

[0170] The above methods can be used to obtain the target runtime data pre-stored for the target mobile application, and to parse and verify the data integrity of the target runtime data. After the verification is passed, the binary language type shader runtime data is loaded into the rendering program container to ensure the accuracy and integrity of the binary language type shader runtime data, so that the screen of the target mobile application can be rendered.

[0171] 103. Based on the binary program data and binary mapping data in the renderer container, execute the corresponding target shader program to render the screen of the target mobile application in the simulator.

[0172] In this embodiment, loading binary language type shader runtime data into the renderer container can be understood as loading binary program data and binary mapping data into the renderer container. The binary program data and binary mapping data are binary data that a personal computer can directly recognize and use. They represent binary data that supports the execution of native shaders, or can be understood as the state data of the native shader program during runtime. Based on the binary program data and binary mapping data in the renderer container, the native shader program is executed to render the screen of the target mobile application in the simulator. In this way, there is no need to go through the cumbersome process of creating and binding vertex shaders and fragment shaders and linking them to form a rendering pipeline. The shader program is run based on the directly loaded binary program data and binary mapping data, which improves the rendering efficiency of the application screen.

[0173] The target shader program can be a native shader program, which may include a native vertex shader program and a fragment shader program. Based on directly loaded binary program data and binary mapping data, the native vertex shader program and fragment shader program are run sequentially to render the screen of the target mobile application in the simulator.

[0174] In some implementations, the binary mapping data can be deserialized to extract the main syntax variable location table and the variable mapping table. The target shader program is then executed based on the binary program data, the main syntax variable location table, and the variable mapping table to render the screen of the target mobile application in the simulator. For example, step 103 may include:

[0175] (103.1) The binary mapping data is deserialized to obtain the main syntax variable location table and variable mapping table;

[0176] (103.2) Start the corresponding target shader program based on the binary program data;

[0177] (103.3) The target shader program is started and combined with the main syntax variable location table and variable mapping table to render the screen of the target mobile application in the simulator.

[0178] Specifically, since the main syntax variable location table, variable forward mapping table, and variable reverse mapping table are stored in binary serialization, after obtaining the binary mapping data, it can be deserialized to obtain the main syntax variable location table and variable mapping table, which includes both forward and reverse mapping tables. Then, based on the binary program data, the corresponding target shader program is started; for example, the local vertex shader and fragment shader can be started sequentially or simultaneously. Finally, the started target shader (program) renders the target mobile application's screen in the simulator based on the main syntax variable location table, variable forward mapping table, and variable reverse mapping table. In this way, the screen of the target mobile application in the simulator is rendered directly based on the binary mapping data and binary program data in binary form, eliminating the need for cumbersome processes and improving rendering efficiency.

[0179] In some implementations, the rendering process involves instruction stream interaction between the simulator environment and the local device. The local device uses this instruction stream interaction to pass shader variable information so that the shader can render the target mobile application's screen in the simulator according to relevant rendering parameters. For example, step (103.3) may include:

[0180] (103.3.1) Based on the variable inverse mapping table in the variable mapping table, determine the target mobile terminal variable mapped to the real-time target local terminal variable in the binary program data;

[0181] (103.3.2) Based on the target variable position information associated with the target mobile variable in the main syntax variable position table, adjust the shader variable information of the target shader to obtain the target shader;

[0182] (103.3.3) The target shader program is started and combined with the shader variable information of the target shader to render the screen of the target mobile application in the simulator.

[0183] Specifically, when the PC detects that the emulator is calling the local binary shader program interface to send a variable retrieval request, the PC determines at least one target local variable that needs to be used based on the binary program data. It then queries the variable inverse mapping table for the target mobile variable mapped to that target local variable, and sends each retrieved target mobile variable to the emulator. Furthermore, it retrieves the target variable location information associated with each target mobile variable from the main syntax variable location table, and adjusts the shader variable information of the target shader based on this target variable location information. Finally, by combining the launched target shader program with the shader variable information, the PC determines the state of the target shader (such as structure, shape, etc., which are not limited here), and combines this with rendering parameters (such as lighting, vertex positions, vertex texture coordinates, and other vertex data, as well as material properties) to render the target mobile application's screen in the emulator. It should be noted that the target mobile variables, target variable location information, and shader variable information can be understood as shader-related data, which are not limited here.

[0184] In some implementations, since the local end transmits shader variable information based on instruction stream interaction, the target mobile variable can be sent to the simulator environment. When the simulator requests the target variable location information associated with the target mobile variable, the target variable location information is then sent to the simulator to adjust the shader variable information. For example, step (103.3.2) may include: sending the target mobile variable to the simulator; when a request for a location query for the target mobile variable is detected by the simulator calling the variable location interface, determining the target local variable mapped to the target mobile variable based on the variable positive mapping table in the variable mapping table; querying the target variable location information corresponding to the target local variable from the main syntax variable location table; and adjusting the shader variable information of the target shader based on the target variable location information.

[0185] The target shader can include a vertex shader and a fragment shader. It's important to note that the vertex shader is responsible for determining the shape and position of the graphics, while the fragment shader is responsible for assigning color and other visual attributes to each pixel on the graphics surface. Only when both work together can complete and realistic graphics rendering be achieved. For example, in a 3D game scene, the vertex shader transforms the vertices of the 3D model to the correct positions, while the fragment shader calculates the appropriate color for each pixel on the model's surface based on factors such as scene lighting and materials, thus presenting a three-dimensional and realistic game screen.

[0186] Specifically, after obtaining the target mobile variable, it can be sent to the simulator environment. Then, if a request for a location query for the target mobile variable is detected by the simulator calling the variable location interface, the target local variable mapped to the target mobile variable is determined according to the variable positive mapping table in the variable mapping table. Next, the target variable location information corresponding to the target local variable is retrieved from the main syntax variable location table. Finally, this target variable location information is sent to the simulator environment to adjust the shader variable information of the target shader based on the target variable location information in the simulator environment. Thus, for a given variable, the location information corresponding to that variable is determined. By changing the data parameters of the target shader at the corresponding location, the variable data of the target shader is modified. Subsequently, the target shader will output results based on different input variables (such as lighting, position, and other rendering parameters), thereby rendering the screen of the target mobile application.

[0187] Using the above methods, the shader program can be run based on directly loaded binary program data and binary mapping data to execute the local shader program and render the screen of the target mobile application in the simulator. This eliminates the need for the cumbersome process of creating and binding vertex shaders and fragment shaders and linking them to form a rendering pipeline, thus improving the efficiency of application screen rendering.

[0188] As can be seen from the overall description of the embodiments of this application, the embodiments of this application can create a rendering program container corresponding to a target mobile application, where the target mobile application is a mobile application in an simulator; obtain shader runtime data of a binary language type pre-stored for the target mobile application, and load the shader runtime data of the binary language type into the rendering program container; wherein, the shader runtime data of the binary language type includes binary program data obtained by linking and compiling the native shader program, and binary mapping data representing the syntax variable mapping relationship between the mobile shader program of the target mobile application and the native shader program, the native shader program being obtained by syntax translation based on the mobile shader program; based on the binary program data and binary mapping data in the rendering program container, execute the corresponding target shader program to render the screen of the target mobile application in the simulator.

[0189] Based on this, when the emulator triggers the launch of the target mobile application, the local side first creates a rendering program container for loading shader program data. Then, it obtains the shader runtime data of the binary language type pre-stored for the target mobile application and loads the shader runtime data of the binary language type into the rendering program container. It should be noted that the shader runtime data of the binary language type refers to the binary program data obtained by translating the mobile shader program of the target mobile application into the local shader program and then linking and compiling it, as well as the binary mapping data of the grammatical variable mapping relationship of the mobile shader program of the target mobile application before and after the grammatical translation. Finally, based on the shader runtime data of the binary language type, the corresponding shader program is run directly on the personal computer to render the screen of the target mobile application in the emulator. Therefore, compared to existing technologies that require creating and binding vertex and fragment shaders and linking them to form a rendering pipeline when creating a rendering program, this application obtains pre-stored shader runtime data in a binary language type and directly loads this binary language type shader runtime data into the rendering program container. Since binary language is machine language, the compiled code can be run directly without further interpretation or conversion. Therefore, the shader program corresponding to the shader runtime data can be run directly to render the screen of the target mobile application. This simplifies the rendering process, improves the rendering efficiency of the application screen, and avoids the leakage of shader source code in high-level language form by storing shader runtime data in a binary language type, thus improving the security of the shader program.

[0190] Based on the methods described in the above embodiments, the following examples will provide further detailed explanations.

[0191] Figure 3 This is a schematic diagram of another step in the application screen rendering method provided in this application embodiment. For ease of understanding, this application embodiment combines... Figure 3 Describe it.

[0192] In this embodiment of the application, the application screen rendering method can be provided by Figure 1 The application is executed on terminal 110. To better illustrate the embodiments of this application, a personal computer is used as an example for description. The specific process of the application screen rendering method is as follows:

[0193] 201. Translate the mobile shader program of the target mobile application into a native shader program according to the target syntax rules.

[0194] In this embodiment, to simplify the rendering process, pre-stored shader runtime data in a binary language type is acquired and directly loaded into the rendering program container. This allows the shader program to be run directly to render the target mobile application's screen, thereby improving the rendering efficiency of the application screen. Furthermore, to prevent the leakage of shader source code, the shader runtime data is stored in a binary language type, thus enhancing the security of the shader program.

[0195] To obtain the relevant data for a native shader program that can be run directly, the native shader program needs to be linked and compiled to obtain binary program data, which is used to describe the runtime state data of the native shader program.

[0196] Specifically, the mobile syntax version of the target mobile application's mobile shader program is detected, and a target syntax version matching the mobile syntax version is determined according to the syntax version correspondence of different shading languages ​​in the target syntax rules. Then, the syntax extension attributes supported by the mobile syntax version in the target syntax version are determined. Next, based on the target configuration parameters of the image processing unit, the syntax constants corresponding to the mobile syntax version (ESSL syntax version) are filled in to obtain the syntax information of the high-level shading language syntax version for graphics programming. This target syntax information can limit the scope of syntax usage for buffer-related operations during rendering, such as the amount of buffer space rendered per unit time. Finally, according to the syntax extension attributes and the target syntax information, the mobile shader program is translated into a native shader program corresponding to the target syntax version. Thus, the mobile shader program can be translated into a native shader program with a syntax version of a high-level shading language for graphics programming that is supported by the personal computer's native end, so that the binary program data corresponding to the native shader program can be stored for later direct loading to run the corresponding target shader program.

[0197] 202. Generate binary mapping data based on the syntax variable mapping relationship between the local shader program and the mobile shader program.

[0198] In this embodiment, since the mobile shader program and the native shader program use different shader languages, which can be understood as different syntax descriptions, it is necessary to obtain the syntax differences between the mobile shader program and the native shader program. Specifically, the syntax variable differences between the two can be obtained, and these syntax variable differences can be understood as different expressions of the same semantic variable between the mobile shader program and the native shader program. For the same semantic variable, the syntax variable mapping relationship between the mobile shader program and the native shader program can be obtained, as well as the position information of each variable of the shader can be obtained. This syntax variable mapping relationship and the position information of each variable of the shader can be described in binary form to obtain binary mapping data.

[0199] Specifically, first, the corresponding syntax variable information is obtained from the local shader program. This syntax variable information includes one or more target local variables, and the position information corresponding to each target local variable is obtained. Then, following a recursive approach, the position information corresponding to each target local variable is filled into a preset variable position table to obtain the main syntax variable position table. Further, based on this syntax variable information, the local syntax variables corresponding to the local shader program are determined, and the mobile syntax variables in the mobile shader program that are mapped to these local syntax variables are determined. Based on the inverse mapping relationship between local and mobile syntax variables, an inverse variable mapping table is generated, and based on the forward mapping relationship between mobile and local syntax variables, a forward variable mapping table is generated. Finally, following a binary serialization method, the main syntax variable position table, the forward variable mapping table, and the inverse variable mapping table are saved to obtain binary mapping data.

[0200] 203. Obtain the binary program data for the rendering pipeline formed by linking local shader programs.

[0201] In this embodiment of the application, the local shader program includes a vertex shader program and a fragment shader program. The vertex shader program and the fragment shader program need to be linked to form a rendering pipeline, and the program corresponding to the rendering pipeline is compiled to obtain binary program data.

[0202] 204. Store binary mapping data and binary program data.

[0203] In this embodiment of the application, in order to subsequently verify the integrity of the binary program data and binary mapping data associated with the local shader program, the verification index information can be bound to the binary program data and binary mapping data so that the binary program data and binary mapping data can be verified according to the verification index information.

[0204] Specifically, firstly, the binary mapping data and binary program data are combined, such as through overlay, concatenation, or binding, to obtain shader runtime data of the binary language type. Then, the target configuration parameters corresponding to the personal computer's graphics processing unit (GPU) are obtained, such as the graphics card model, serial number, and configuration, as well as the binary version number corresponding to the binary language type. This information is then bound to the shader runtime data to obtain candidate runtime data. Subsequently, when this candidate runtime data is obtained, the target configuration information can be used to verify the shader runtime data to determine whether the shader runtime data supports the GPU. Furthermore, a corresponding data hash is calculated for the candidate running data. For example, a Message-Digest Algorithm (MD5) or a Secure Hash Algorithm 256 (SHA256) can be used to calculate the hash value of the candidate running data. A corresponding data length is also set, which describes the bit sequence in which the candidate running data appears; this can be understood as the candidate running data's position within the overall data set. Additionally, a feature header is defined for the candidate running data. This header can be a numerical value indicating the data type contained in the candidate running data, or a predefined code, flag, etc., used to identify the candidate running data. Finally, these data are combined according to the feature header, data length, data hash value, and the specific order format of the candidate running data to obtain the target running data, which is then stored.

[0205] 205. Create the rendering container corresponding to the target mobile application.

[0206] In this embodiment, after abstracting and simulating an operating environment for a mobile terminal on a personal computer using virtualization technology, the personal computer can be considered to include at least two operating environments: a simulator environment for the mobile terminal and a local operating environment. The simulator environment can be understood as a simulation environment for the mobile terminal, used to run the target mobile application. When the personal computer detects that the target mobile application needs to be launched in the simulator environment, it can create a renderer container on the local side so that the shader-related data of the target mobile application can be loaded into the renderer container subsequently.

[0207] 206. Obtain the shader runtime data of the binary language type pre-stored for the target mobile application, and load the shader runtime data of the binary language type into the renderer container.

[0208] In this embodiment, after creating a corresponding renderer container for the target mobile application, pre-stored binary language type shader runtime data for the target mobile application can be obtained and loaded into the renderer container. Specifically, to ensure that correct, complete, and target-app-corresponding binary language type shader runtime data is loaded into the renderer container, the shader-related data needs to be verified. Only after successful verification is the data loaded into the renderer container, ensuring the accuracy of the binary language type shader runtime data and enabling the target mobile application's screen to be rendered.

[0209] Specifically, the system retrieves the runtime data to be parsed for the target mobile application from the storage space of the local personal computer. This runtime data is then parsed to obtain a feature header, a data hash value, and candidate runtime data. A pre-defined feature header is then determined for the runtime data to be parsed. This pre-defined feature header is compared with the parsed feature header. If the pre-defined feature header matches the parsed feature header, a hash verification is further performed on the candidate runtime data based on the data hash value. Specifically, the hash value to be verified corresponding to the candidate runtime data is calculated and compared with the parsed data hash value. If the hash value to be verified matches the parsed data hash value, the hash verification of the candidate runtime data based on the data hash value has passed.

[0210] Furthermore, when the hash verification of the candidate running data based on the data hash value passes, the candidate running data is parsed to obtain binary configuration parameters, binary program data, and binary mapping data. These binary configuration parameters can be understood as the configuration parameters of the image processing unit supported by the current binary program data and binary mapping data. Based on the binary configuration parameters, it is determined whether the binary program data and binary mapping data are compatible with the personal computer's image processing unit. Therefore, the target configuration parameters of the personal computer's image processing unit are obtained and compared with the binary configuration parameters. If the binary configuration parameters match the target configuration parameters (e.g., the graphics card model represented by the binary configuration parameters matches the graphics card model in the target configuration parameters), then the binary program data and binary mapping data are determined to be shader running data of a binary language type. It should be noted that the rendering process is primarily implemented based on the PC's (local) graphics card; therefore, shader-related parameters (such as the graphics card configuration parameters recorded in the binary configuration parameters) also need to be consistent with the actual configuration parameters of the graphics card to ensure that the graphics card can support the binary program data and binary mapping data.

[0211] 207. Based on the binary program data and binary mapping data in the renderer container, execute the corresponding target shader program to render the screen of the target mobile application in the simulator.

[0212] In this embodiment, loading binary language type shader runtime data into the renderer container can be understood as loading binary program data and binary mapping data into the renderer container. The binary program data and binary mapping data are binary data that a personal computer can directly recognize and use. They represent binary data that supports the execution of native shaders, or can be understood as the state data of the native shader program during runtime. Based on the binary program data and binary mapping data in the renderer container, the native shader program is executed to render the screen of the target mobile application in the simulator. In this way, there is no need to go through the cumbersome process of creating and binding vertex shaders and fragment shaders and linking them to form a rendering pipeline. The shader program is run based on the directly loaded binary program data and binary mapping data, which improves the rendering efficiency of the application screen.

[0213] To facilitate understanding of the embodiments of this application, specific application scenario examples will be used to describe the embodiments of this application. Specifically, the application scenario example will be described by performing the above steps 201-207.

[0214] It should be noted that this application rendering method is suitable for rendering scenarios where mobile versions of applications (such as smartphones and smartwatches) run on PC devices using virtualization technology. Examples include mobile game applications, short video applications, and e-commerce applications. Specifically, when the target mobile application is launched, a rendering program container is created to load shader program data. Pre-stored binary language type shader runtime data is obtained and directly loaded into the rendering program container so that the shader program can directly run to render the target mobile application's screen. This simplifies the rendering process, improves application rendering efficiency, and, because the shader runtime data is stored in binary language type, it avoids the leakage of shader source code, enhancing the security of the shader program. The following is a detailed description of this application rendering method using an example of such a scenario:

[0215] I. A brief introduction to the scene rendering examples of this application is as follows:

[0216] With the development of mobile information technology, many business service providers have developed mobile applications for mobile devices (such as mobile phones), including mobile game applications and short video applications. However, while users can conveniently use these mobile applications anytime on their phones, the hardware characteristics of mobile devices may hinder user operation and limit rendering. For example, mobile devices may restrict the operation and rendering effects of game applications. Therefore, virtualization technology can be used to enable mobile applications to run on PC devices.

[0217] Mobile emulators used on PCs are virtualization-based simulation environments. The core of an emulator is creating a virtual target device environment on the host device, distinct from the host device. This allows developers to test application compatibility within the simulated target device environment and provides users with a way to use applications on the host device without needing the target device itself. For example, it allows users to use mobile applications on desktop operating systems like Windows and macOS. In this case, the host device is a PC, and the target device is a mobile phone.

[0218] When running a mobile application on a PC using virtualization technology, a renderer is created for the mobile version of the application. Vertex shaders and fragment shaders are created and bound in the renderer. The vertex shaders and fragment shaders in the renderer are linked to form a rendering pipeline. The mobile version of the application is rendered according to the rendering pipeline in the renderer so that it can be used on a personal computer. Afterwards, when the use of the mobile version of the application on the personal computer is stopped, the rendering pipeline in the renderer is disconnected and the renderer is deleted.

[0219] For example, Figure 4 The rendering flowchart of the mobile application on a personal computer provided in the embodiments of this application is combined with Figure 4 As shown, the rendering process involving shaders when running mobile applications on a personal computer using virtualization technology is as follows:

[0220] (A.1) Create Program. When the mobile application running in virtualization technology calls the "glCreateProgram" interface, the PC creates a program. This program is equivalent to the program used by the rendering pipeline and is a container for shader objects.

[0221] (A.2) Load Shader: First, check if the shader has been written. If not, proceed with the following three steps:

[0222] (A.2.1) Write the shader source code.

[0223] (A.2.2) Create Shader. When the mobile application calls the "glCreateShader" interface, a shader object is created. The shader object can include a vertex shader (GL_VERTEX_SHADER) and a fragment shader (GL_FRAGMENT_SHADER), abbreviated as vs and fs shaders.

[0224] (A.2.3) Initialize the shader object source code. When the mobile application calls the "glShaderSource" interface, the PC side provides the shader source code in the shader object.

[0225] (A.2.4) Compile Shader source code. When the mobile application calls the "glCompileShader" interface, the PC side compiles the source code in the shader object.

[0226] (A.2.5) Create the shader object.

[0227] (A.3) Attach Shader. When the mobile application calls the "glAttachShader" interface, the PC side binds the vs and fs shaders to the Program object.

[0228] (A.4) Linking the shader program: When the mobile application calls the "glLinkProgram" interface, the PC side links the vs shader and fs shader in the Program object, so that the output of the vs shader becomes the input of the fs shader, thus forming a rendering pipeline.

[0229] (A.5) Run the shader program (Use Program). When the mobile application calls the "glUseProgram" interface, the PC runs the shader program and begins rendering the content of the Program object. That is, the vs and fs shader programs bound to the Program object are executed sequentially.

[0230] (A.6) Detach Shader. When the mobile application calls the "glDetachShader" interface, it does the opposite of the "glAttachShader" interface, unbinding the vs and fs shaders from the Program object.

[0231] (A.7) Delete Shader. When the mobile application calls the "glDeleteShader" interface, it performs the opposite function of the "glCreateShader" interface and is used to delete the Shader object.

[0232] (A.8) Delete Program. When the mobile application calls the "glDeleteProgram" interface, it performs the opposite function of the "glCreateProgram" interface and is used to delete the Program object.

[0233] As can be seen from the above process, the relevant technologies require a cumbersome process of creating and binding vertex shaders and fragment shaders, and linking them to form a rendering pipeline. This results in a long application startup time. Furthermore, since the vertex shader and fragment shader programs need to be provided in source code form, this can easily lead to the leakage of shader source code and reduce the security of the shader program.

[0234] To address the aforementioned issues with related technologies, this application's rendering scenario is based on an instruction-stream architecture, using OpenGL as the backend on the computer device, i.e., the local end, simulating the operating environment of a mobile device to run the "GL_OES_get_program_binary" function.

[0235] Figure 5 This application provides a flowchart of application screen rendering based on instruction streams in its embodiments, combined with... Figure 5 As shown, the scene rendered in this application is as follows:

[0236] (B.1) Create Program: When the mobile application calls the "glCreateProgram" interface, Program is equivalent to the program used by the rendering pipeline, which is a container for shader objects.

[0237] (B.2) Loading Program Binary Shader Runtime Data. When the mobile application calls the glProgramBinary interface, binary data is loaded into the shader program object. This binary data can be understood as the offline binary serialized data after the shader is compiled and linked.

[0238] (B.3) Run the shader program (Use Program). When the mobile application calls the "glUseProgram" interface, it starts rendering the content of the Program object, that is, the vs and fs shader programs bound to the Program object are executed one after the other.

[0239] (B.4) Delete Program: When the mobile application calls the "glDeleteProgram" interface, it is the opposite of the "glCreateProgram" interface and is used to delete the Program object.

[0240] In game engines, the default terminal (such as a personal computer, PC) supports obtaining the binary shader program "GL_OES_get_program_binary" to run and using the shader loading process.

[0241] II. The specific implementation process of this application's scene rendering example is as follows:

[0242] (1) Translate the Android ESSL shader program into the PC GLSL shader program.

[0243] Figure 6 This is a flowchart illustrating the translation process between the mobile shader program and the native shader program provided in this embodiment of the application. (In conjunction with...) Figure 6 As shown, the mobile shader program of the target mobile application is translated (transferred) into a native shader program. The translation process is as follows:

[0244] (1.1) When a mobile device calls the shader object initialization interface, the PC (native or backend) uses this interface to detect the ESSL syntax version corresponding to the original mobile shader program and determines the GLSL syntax version of the translated native shader program based on the original ESSL syntax version. For example, ESSL100 corresponds to a native shader program with GLSL330; similarly, ESSL300 corresponds to GLSL430, and ESSL310 corresponds to GLSL450. These are just examples.

[0245] (1.2) Determine the ESSL syntax extensions to be supported based on the different ESSL syntax versions. For example, ESSL310 needs to support syntax extensions such as "GL_OES_texture_buffer" and "GL_OES_shader_image_atomic".

[0246] (1.3) Based on the characteristics of the main graphics card on the PC device, fill in the global ESSL constant information to obtain the GLSL syntax information. For example, fill in the constants of "maximum number of buffer bindings" (GL_MAX_UNIFORM_BUFFER_BINDINGS) and "maximum number of bindings in the shader cache" (GL_MAX_SHADER_STORAGE_BUFFER_BINDINGS) in the global ESSL constants, and so on.

[0247] (1.4) Based on the GLSL syntax version, ESSL syntax extension, and the filled GLSL syntax information, the PC side calls the shader translation module through the shader program translation interface (glShaderSource) to complete the corresponding syntax conversion of the mobile shader program and obtain the local shader program.

[0248] (1.5) Based on the translation results, obtain the translated syntax variable information. The syntax variable information may include defined uniform variables, variables used to pass data between vertex shaders and fragment shaders, vertex count variables, interface blocks, etc.

[0249] (2) Map the syntax variables of the two programs before and after translation one by one, and serialize the mapping relationship into binary.

[0250] Figure 7 This is a flowchart illustrating the binary representation of the syntax variable mapping relationship provided in the embodiments of this application. (In conjunction with...) Figure 7 As shown, the binary transformation process of this syntax variable mapping relationship is as follows:

[0251] (2.1) When the Android client calls the program linking interface (glLinkProgram) for the shaders, the PC client executes the shader program linking, such as linking the vertex shader program and the fragment shader program to create a rendering pipeline for the shaders. Specifically, based on the previously obtained syntax variable information (uniform, varying, attribute, interfaceblock), the location table is filled with the position corresponding to each uniform variable using a recursive method to obtain the host variable location table, referred to as the "host uniform loc table".

[0252] (2.2) Based on the obtained grammatical variable information, the name forward mapping table (hereinafter referred to as uniform name table) and the name reverse mapping table (hereinafter referred to as uniform name reverse table) for uniform variables between the mobile shader program and the native shader program before and after translation are further filled in using a recursive method.

[0253] (2.3) Serialize and save the above three tables, “host uniform loc&&uniform name&&uniform name reverse”, using a certain binary serialization method, such as using data serialization format (Protocol Buffers).

[0254] (3) Binary the PC GLSL shader program.

[0255] After obtaining the GLSL syntax information and the binary serialization information of the syntax variable mapping translated by "ESSL->GLSL", the PC further needs to obtain the binary serialization information of the GLSL shader program after linking and compilation, for example, by obtaining it from the PC's backend driver (such as the driver corresponding to the graphics card) through binary retrieval (PROGRAM_BINARY_RETRIEVABLE_HINT).

[0256] (4) After the mobile terminal (Android terminal) obtains the above binary serialized data, it stores it in a certain format.

[0257] Figure 8 This is an example diagram illustrating the synchronization response of the binary shader program acquisition interface between the mobile terminal and the local terminal, as provided in an embodiment of this application. (Combined with...) Figure 8 As shown, the storage process for this binary serialized data is as follows:

[0258] (4.1) The PC (local or backend) has obtained the binary serialization information of the “ESSL->GLSL” translation mapping and the binary serialization information of the GLSL shader program after linking and compilation. At this time, it needs to be returned to the mobile terminal (e.g., Android terminal) in a certain data format.

[0259] (4.2) The entire data is stored in the format of “feature header (length 2) + data Len (length 4) + data (Binary data hash (length 8) + Binary data)”. The “feature header and Binary data hash” are used to verify the integrity of the binary serialized data and prevent inconsistencies in the data content before and after storage. It should be noted that “Binary data” refers to the binary serialized information.

[0260] (4.3) For binary serialization information, the binary serialization data and GLSL shader program binary data are stored in the following format: "Binary Ver + Binary VENDOR + host uniform loc && uniform name && uniform name reverse". Binary Ver is used for functional expansion to maintain the scalability of the binary serialization information of the "ESSL->GLSL" translation mapping. For example, new tables can be added later to store "attribute" variable information. Binary VENDOR is used to verify the validity of the GLSL shader program binary data to prevent the binary serialization information from becoming unsuitable due to changes in PC hardware graphics cards.

[0261] (5) The PC parses the binary data sent from the Android client according to the corresponding format, first loads and parses the binary program data of the GLSL shader program, and deserializes the binary mapping data. Based on the three tables of deserialization, the PC returns the correct syntax variable information to the mobile client.

[0262] Figure 9 This is a flowchart illustrating the interaction of syntax variable information in the instruction flow during the application screen rendering process provided in this embodiment. (Combined with...) Figure 9 As shown, during the application rendering process, the mobile terminal (simulated Android terminal, front-end) on the personal computer interacts with the local terminal (back-end) for syntax variable information. The specific process is as follows:

[0263] (5.1) When the mobile terminal calls the "glProgramBinary" interface of the local terminal, the PC terminal (local terminal) first verifies the stored data according to the "feature header and Binary data hash", then loads and parses the binary data corresponding to the GLSL shader program, and further deserializes the "host uniform loc&&uniform name&&uniform namereverse" binary mapping data to restore the corresponding three table structures.

[0264] (5.2) When the mobile terminal calls the “glGetActiveUniform” interface to obtain uniform information, the PC terminal (local terminal) returns the corresponding uniform variable name information of the mobile terminal based on the information in the uniform name reverse table.

[0265] (5.3) When the mobile device calls the "glGetUniformLocation" interface to query the location information of the corresponding uniform variable based on the uniform variable name information, the PC device queries the uniform variable name table to obtain the PC device uniform variable name, and then queries the "host uniform loc table" using the PC device uniform variable name to return the corresponding location information to the mobile device. In this way, the data of the corresponding uniform variable can be modified according to the "location information" to change the shader data, thereby drawing the corresponding content during the rendering process.

[0266] By executing the above application rendering scene example, the following effects can be achieved: The process is simple; only binary data needs to be loaded into the shader program object for use. The shader object is no longer explicitly required in the process, reducing the burden on developers. Secondly, loading and parsing are fast; the binary form of the shader program does not require compilation and linking and is directly loaded into the graphics card driver for processing. Furthermore, the source code is protected; the binary form of the shader program does not contain readable source code.

[0267] As described above, in this embodiment of the application, when the emulator triggers the launch of the target mobile application, a rendering program container for loading shader program data is first created on the local end. Then, the shader runtime data of the binary language type pre-stored for the target mobile application is obtained, and the shader runtime data of the binary language type is loaded into the rendering program container. It should be noted that the shader runtime data of the binary language type refers to the binary program data obtained by translating the mobile shader program of the target mobile application and linking and compiling the local shader program, as well as the binary mapping data of the grammatical variable mapping relationship of the mobile shader program of the target mobile application before and after grammatical translation. Finally, the corresponding shader program is run directly on the personal computer based on the shader runtime data of the binary language type to render the screen of the target mobile application in the emulator. Therefore, compared to existing technologies that require creating and binding vertex and fragment shaders and linking them to form a rendering pipeline when creating a rendering program, this application obtains pre-stored shader runtime data in a binary language type and directly loads this binary language type shader runtime data into the rendering program container. Since binary language is machine language, the compiled code can be run directly without further interpretation or conversion. Therefore, the shader program corresponding to the shader runtime data can be run directly to render the screen of the target mobile application. This simplifies the rendering process, improves the rendering efficiency of the application screen, and avoids the leakage of shader source code in high-level language form by storing shader runtime data in a binary language type, thus improving the security of the shader program.

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

[0269] To facilitate better implementation of the application screen rendering method provided in this application embodiment, this application embodiment also provides an apparatus based on the above application screen rendering method. The meanings of the terms used are the same as in the above application screen rendering method, and specific implementation details can be found in the description of the method embodiment.

[0270] Please see Figure 10 , Figure 10 This is a schematic diagram of the application rendering apparatus provided in an embodiment of this application. The application rendering apparatus is integrated into the computer device of this application, such as... Figure 1 On the terminal 110, the application screen rendering device may include a creation unit 401, an acquisition unit 402, and an execution unit 403.

[0271] Creation unit 401 is used to create a rendering program container corresponding to the target mobile application, which is the mobile application in the simulator;

[0272] The acquisition unit 402 is used to acquire the shader runtime data of the binary language type that is pre-stored for the target mobile application, and load the shader runtime data of the binary language type into the renderer container;

[0273] Among them, the shader runtime data of binary language type includes binary program data obtained by linking and compiling the native shader program, and binary mapping data representing the syntax variable mapping relationship between the mobile shader program of the target mobile application and the native shader program. The native shader program is obtained by syntax translation based on the mobile shader program.

[0274] The execution unit 403 is used to execute the corresponding target shader program based on the binary program data and binary mapping data in the renderer container in order to render the screen of the target mobile application in the simulator.

[0275] In some embodiments, the acquisition unit 402 is further configured to:

[0276] Retrieve the runtime data to be parsed corresponding to the target mobile application from the storage space. The runtime data to be parsed includes at least the feature header, data hash value, and candidate runtime data.

[0277] When the feature header matches the preset feature header for the running data to be parsed, a hash check is performed on the candidate running data based on the data hash value;

[0278] When the hash verification of the candidate running data based on the data hash value passes, the candidate running data is determined to be shader running data of binary language type.

[0279] In some embodiments, the acquisition unit 402 is further configured to:

[0280] Determine binary configuration parameters, binary program data, and binary mapping data from candidate runtime data;

[0281] Obtain the target configuration parameters of the local image processing unit, and verify the binary configuration parameters according to the target configuration parameters to obtain the verification result;

[0282] When the verification result shows that the binary configuration parameters are consistent with the target configuration parameters, the binary program data and binary mapping data are determined as shader runtime data of binary language type.

[0283] In some embodiments, the execution unit 403 is further configured to:

[0284] The binary mapping data is deserialized to obtain the main syntax variable location table and variable mapping table;

[0285] Start the corresponding target shader program based on the binary program data;

[0286] The target shader program, which is started, combines the main syntax variable location table and variable mapping table to render the screen of the target mobile application in the simulator.

[0287] In some embodiments, the execution unit 403 is further configured to:

[0288] Based on the variable inverse mapping table in the variable mapping table, determine the target mobile terminal variable mapped to the real-time target local terminal variable in the binary program data;

[0289] Based on the target variable position information associated with the target mobile variable in the main syntax variable position table, adjust the shader variable information of the target shader to obtain the target shader;

[0290] The target shader program, combined with the shader variable information of the target shader, renders the screen of the target mobile application in the simulator.

[0291] In some embodiments, the execution unit 403 is further configured to:

[0292] Send the target mobile device variables to the simulator;

[0293] When it is detected that the simulator calls the variable location interface to send a location query request for the target mobile terminal variable, the target local terminal variable mapped to the target mobile terminal variable is determined according to the variable positive mapping table in the variable mapping table;

[0294] Retrieve the target variable location information corresponding to the target local variable from the main syntax variable location table;

[0295] Adjust the shader variable information of the target shader based on the target variable location information.

[0296] In some implementations, the application rendering apparatus further includes a pre-storage unit for:

[0297] According to the target syntax rules, translate the mobile shader program of the target mobile application into the native shader program.

[0298] Generate binary mapping data based on the syntax variable mapping relationship between the local shader program and the mobile shader program;

[0299] Obtain binary program data for the rendering pipeline formed by linking local shader programs;

[0300] Store binary mapping data and binary program data.

[0301] In some implementations, the pre-storage unit is also used for:

[0302] Determine the mobile syntax version corresponding to the mobile shader program of the target mobile application, and determine the target syntax version that matches the mobile syntax version according to the target syntax rules;

[0303] Determine the syntax extension attributes supported by the mobile syntax version in the target syntax version;

[0304] Read the target configuration parameters of the local image processing unit, and fill in the syntax constants corresponding to the mobile syntax version according to the target configuration parameters to obtain the target syntax information corresponding to the target syntax version;

[0305] Based on the syntax extension attributes and target syntax information, the mobile shader program is translated into the native shader program corresponding to the target syntax version.

[0306] In some implementations, the pre-storage unit is also used for:

[0307] Obtain the syntax variable information corresponding to the local shader program;

[0308] Fill the preset variable location table with the location information corresponding to each target local variable in the syntax variable information to obtain the main syntax variable location table;

[0309] Based on the syntax variable information, determine the syntax variable mapping relationship between the local shader program and the mobile shader program, and generate a positive variable mapping table and a negative variable mapping table based on the syntax variable mapping relationship;

[0310] Generate binary mapping data based on the main syntax variable position table, variable forward mapping table, and variable reverse mapping table.

[0311] In some implementations, the pre-storage unit is also used for:

[0312] Generate shader runtime data for binary language types based on binary mapping data and binary program data;

[0313] The target configuration parameters, binary language type, and shader runtime data are bound together to obtain candidate runtime data;

[0314] Obtain the data hash value, data length, and feature header corresponding to the candidate running data;

[0315] The target running data is obtained by combining the feature header, data length, data hash value, and candidate running data in that order, and then stored.

[0316] In some implementations, the application rendering apparatus further includes a notification unit for:

[0317] A notification message is generated and sent to the simulator. The notification message is used to instruct the shader running data that supports binary language types to run the target mobile application.

[0318] The creation unit is also used to: create a renderer container corresponding to the target mobile application when a simulator request is detected to run the target mobile application through a target shader program of a binary language type.

[0319] In some implementations, the application rendering apparatus further includes a download unit for:

[0320] Read the target configuration parameters and operating system parameters of the local image processing unit, and download the corresponding binary language type shader runtime data from the data sharing end according to the target configuration parameters and operating system parameters;

[0321] Among them, the data sharing terminal stores at least the shader runtime data of binary language type uploaded by other devices for the target mobile application;

[0322] Store the downloaded binary language type shader runtime data.

[0323] As described above, in this embodiment of the application, when the emulator triggers the launch of the target mobile application, a rendering program container for loading shader program data is first created on the local end. Then, the shader runtime data of the binary language type pre-stored for the target mobile application is obtained, and the shader runtime data of the binary language type is loaded into the rendering program container. It should be noted that the shader runtime data of the binary language type refers to the binary program data obtained by translating the mobile shader program of the target mobile application and linking and compiling the local shader program, as well as the binary mapping data of the grammatical variable mapping relationship of the mobile shader program of the target mobile application before and after grammatical translation. Finally, the corresponding shader program is directly run based on the shader runtime data of the binary language type to realize the rendering of the screen of the target mobile application in the emulator. Therefore, compared to existing technologies that require creating and binding vertex and fragment shaders and linking them to form a rendering pipeline when creating a rendering program, this application obtains pre-stored shader runtime data in a binary language type and directly loads this binary language type shader runtime data into the rendering program container. Since binary language is machine language, the compiled code can be run directly without further interpretation or conversion. Therefore, the shader program corresponding to the shader runtime data can be run directly to render the screen of the target mobile application. This simplifies the rendering process, improves the rendering efficiency of the application screen, and avoids the leakage of shader source code in high-level language form by storing shader runtime data in a binary language type, thus improving the security of the shader program.

[0324] The specific implementation of each of the above units can be found in the previous embodiments, and will not be repeated here.

[0325] See Figure 11 , Figure 11 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. It includes a structural block of the portion of the terminal 110 that implements the embodiment of this application. The terminal can be... Figure 1 The terminal 110 shown specifically includes: a radio frequency (RF) circuit 510, a memory 515, an input unit 530, a display unit 540, a sensor 550, an audio circuit 560, a wireless fidelity (WiFi) module 570, a processor 580, and a power supply 590, among other components. Those skilled in the art will understand that the structure of the terminal 110 shown does not constitute a limitation on a mobile phone or computer, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0326] The RF circuit 510 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 580; in addition, it transmits uplink data to the base station.

[0327] The memory 515 can be used to store software programs and modules. The processor 580 executes various terminal functions and renders application screens by running the software programs and modules stored in the memory 515.

[0328] The input unit 530 can be used to receive input numeric or character information, and to generate key signal inputs related to the terminal's settings and function control. Specifically, the input unit 530 may include a touch panel 531 and other input devices 532.

[0329] The display unit 540 can be used to display input or provided information, as well as various menus of the terminal. The display unit 540 may include a display panel 541.

[0330] Audio circuit 560, speaker 561, and microphone 562 provide an audio interface.

[0331] In this embodiment, the processor 580 included in the terminal 110 can execute the application screen rendering method of the previous embodiment.

[0332] See Figure 12 , Figure 12 This is a schematic diagram of the server structure provided in an embodiment of this application, which includes a structural block of the server 120 implementing this embodiment. The server can be... Figure 1 The server 120 shown can vary significantly due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 622 (e.g., one or more processors) and memory 632, and one or more storage media 630 (e.g., one or more mass storage devices) for storing application programs 642 or data 644. The memory 632 and storage media 630 may be temporary or persistent storage. The program stored in the storage media 630 may include one or more modules (not shown in the figure), each module including a series of instruction operations on the server 120. Furthermore, the CPU 622 may be configured to communicate with the storage media 630 and execute the series of instruction operations in the storage media 630 on the server 120.

[0333] Server 120 may also include one or more power supplies 626, one or more wired or wireless network interfaces 650, one or more input / output interfaces 658, and / or one or more operating systems 641, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0334] The central processing unit 622 in server 120 can be used to execute the application screen rendering method of the present application embodiments.

[0335] This application also provides a computer-readable storage medium for storing a computer program for executing the application screen rendering methods of the foregoing embodiments.

[0336] This application also provides a computer program product, which includes a computer program. The processor of a computer device reads and executes the computer program, causing the computer device to perform the application screen rendering method described above.

[0337] Furthermore, the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.

[0338] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0339] It should be understood that in the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

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

[0341] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

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

[0344] It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

[0345] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0346] The above is a detailed description of the embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for rendering application images, characterized in that, include: Create a renderer container corresponding to the target mobile application, wherein the target mobile application is a mobile application in the simulator; Obtain shader runtime data of a binary language type pre-stored for the target mobile application, and load the shader runtime data of the binary language type into the renderer container; The shader runtime data of the binary language type includes binary program data obtained by linking and compiling the native shader program, and binary mapping data representing the syntax variable mapping relationship between the mobile shader program of the target mobile application and the native shader program. The native shader program is obtained by syntax translation based on the mobile shader program. Based on the binary program data and the binary mapping data in the rendering program container, the corresponding target shader program is executed to render the screen of the target mobile application in the simulator; The step of executing the corresponding target shader program based on the binary program data and the binary mapping data in the rendering program container to render the screen of the target mobile application in the simulator includes: The binary mapping data is deserialized to obtain the main syntax variable location table and the variable mapping table; Based on the binary program data, start the corresponding target shader program; Based on the variable inverse mapping table in the variable mapping table, determine the target mobile terminal variable mapped to the real-time target local terminal variable in the binary program data; Based on the target variable location information associated with the target mobile variable in the main syntax variable location table, the shader variable information of the target shader is adjusted to obtain the shader variable information of the target shader. The target shader program, once started, combines the shader variable information of the target shader to render the screen of the target mobile application in the simulator.

2. The method according to claim 1, characterized in that, The step of obtaining shader runtime data for the target mobile application, which is pre-stored in binary language type, includes: The runtime data to be parsed corresponding to the target mobile application is obtained from the storage space. The runtime data to be parsed includes at least a feature header, a data hash value, and candidate runtime data. When the feature header matches the preset feature header for the running data to be parsed, a hash verification is performed on the candidate running data based on the data hash value; When the hash verification of the candidate running data based on the data hash value passes, the candidate running data is determined to be shader running data of binary language type.

3. The method according to claim 2, characterized in that, The step of determining the candidate runtime data as shader runtime data of binary language type includes: The binary configuration parameters, binary program data, and binary mapping data are determined from the candidate runtime data; Obtain the target configuration parameters of the local image processing unit, and verify the binary configuration parameters according to the target configuration parameters to obtain the verification result; When the verification result shows that the binary configuration parameters are consistent with the target configuration parameters, the binary program data and binary mapping data are determined as shader runtime data of binary language type.

4. The method according to claim 1, characterized in that, The step of adjusting the shader variable information of the target shader according to the target variable position information associated with the target mobile variable in the main syntax variable position table includes: Send the target mobile terminal variables to the simulator; When it is detected that the simulator calls the variable location interface to send a location query request for the target mobile terminal variable, the target local terminal variable mapped by the target mobile terminal variable is determined according to the variable positive mapping table in the variable mapping table; Query the target variable location information corresponding to the target local variable from the main syntax variable location table; Adjust the shader variable information of the target shader based on the target variable position information.

5. The method according to any one of claims 1 to 4, characterized in that, Before acquiring the shader runtime data for the binary language type pre-stored for the target mobile application, the method further includes: According to the target syntax rules, the mobile shader program of the target mobile application is translated into a native shader program. Based on the syntax variable mapping relationship between the local shader program and the mobile shader program, binary mapping data is generated; Obtain binary program data for the rendering pipeline formed by linking the local shader programs; The binary mapping data and the binary program data are stored.

6. The method according to claim 5, characterized in that, The step of translating the mobile shader program of the target mobile application into a native shader program according to the target syntax rules includes: Determine the mobile syntax version corresponding to the mobile shader program of the target mobile application, and determine the target syntax version that matches the mobile syntax version according to the target syntax rules; Determine the syntax extension attributes supported by the mobile syntax version in the target syntax version; Read the target configuration parameters of the local image processing unit, and fill the syntax constants corresponding to the mobile syntax version according to the target configuration parameters to obtain the target syntax information corresponding to the target syntax version; According to the syntax extension attributes and the target syntax information, the mobile shader program is translated into a native shader program corresponding to the target syntax version.

7. The method according to claim 5 or 6, characterized in that, The step of generating binary mapping data based on the syntax variable mapping relationship between the local shader program and the mobile shader program includes: Obtain the syntax variable information corresponding to the local shader program; Fill the preset variable location table with the location information corresponding to each target local variable in the syntax variable information to obtain the main syntax variable location table; Based on the syntax variable information, determine the syntax variable mapping relationship between the local shader program and the mobile shader program, and generate a positive variable mapping table and a negative variable mapping table based on the syntax variable mapping relationship; Binary mapping data is generated based on the main syntax variable position table, the variable forward mapping table, and the variable reverse mapping table.

8. The method according to any one of claims 5 to 7, characterized in that, The storage of the binary mapping data and the binary program data includes: Based on the binary mapping data and the binary program data, generate shader runtime data for binary language type; The target configuration parameters, the binary language type, and the shader runtime data are bound together to obtain candidate runtime data; Obtain the data hash value, data length, and feature header corresponding to the candidate running data; The target running data is obtained by combining the feature header, the data length, the data hash value, and the candidate running data in that order, and then the target running data is stored.

9. The method according to any one of claims 5 to 8, characterized in that, Before creating the rendering container corresponding to the target mobile application, the method further includes: A notification message is generated and sent to the simulator. The notification message is used to instruct the shader running data that supports binary language types to run the target mobile application. The creation of the rendering application container corresponding to the target mobile application includes: When the simulator detects a request to run the target mobile application through the target shader program of the binary language type, a renderer container corresponding to the target mobile application is created.

10. The method according to any one of claims 1 to 4, characterized in that, Before acquiring the shader runtime data for the binary language type pre-stored for the target mobile application, the method further includes: Read the target configuration parameters and operating system parameters of the local image processing unit, and download the corresponding binary language type shader runtime data from the data sharing terminal according to the target configuration parameters and the operating system parameters; The data sharing terminal stores at least binary language type shader runtime data uploaded by other devices for the target mobile application. The downloaded shader runtime data for the binary language type is stored.

11. An application screen rendering device, characterized in that, include: A creation unit is used to create a rendering program container corresponding to the target mobile application, wherein the target mobile application is a mobile application in the simulator; The acquisition unit is used to acquire shader runtime data of a binary language type pre-stored for the target mobile application, and load the shader runtime data of the binary language type into the rendering program container; The shader runtime data of the binary language type includes binary program data obtained by linking and compiling the native shader program, and binary mapping data representing the syntax variable mapping relationship between the mobile shader program of the target mobile application and the native shader program. The native shader program is obtained by syntax translation based on the mobile shader program. An execution unit is configured to execute a corresponding target shader program based on the binary program data and the binary mapping data in the rendering program container, so as to render the screen of the target mobile application in the simulator. The execution unit is further configured to: deserialize the binary mapping data to obtain a main syntax variable location table and a variable mapping table; start the corresponding target shader program according to the binary program data; determine the target mobile variable mapped to the real-time target local variable in the binary program data according to the variable inverse mapping table in the variable mapping table; adjust the shader variable information of the target shader according to the target variable location information associated with the target mobile variable in the main syntax variable location table; and render the screen of the target mobile application in the simulator by combining the started target shader program with the shader variable information of the target shader.

12. A computer device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the application screen rendering method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for loading by a processor to execute the application screen rendering method according to any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the application screen rendering method according to any one of claims 1 to 10.

Images