Compiling method, electronic equipment and computer readable storage medium

Abstract

The invention relates to the technical field of terminals, and provides a compiling method, electronic equipment and a computer readable storage medium, the method comprises the following steps: obtaining L types of shader source codes, the L types of shader source codes are source codes corresponding to shaders of L applications, and L is an integer greater than 1; determining a public source code from the L shader source codes, wherein the public source code is a common part in the L shader source codes; the public source code is compiled to obtain N kinds of public executable codes, the N kinds of public executable codes are used for adapting to N kinds of operation environments, and N is a positive integer; and sending a target public executable code to a second device, wherein the target public executable code is one of the N public executable codes matched with the operating environment of the second device. According to the method, the probability of frame loss and jamming in the picture rendering process can be reduced, and the picture rendering performance can be optimized.

Description

Technical Field

[0001] The present application relates to the field of terminal technology, and in particular to a compilation method, an electronic device, and a computer-readable storage medium. Background Art

[0002] With the development of image processing technology, shaders are commonly used for image rendering and visual effects in game development, graphic design, film and animation production, and other fields. They are small programs that run on the graphics processing unit (GPU) and are used to control various stages of the image rendering process, such as color, texture coordinates, and lighting calculations.

[0003] For some applications that require image rendering (such as games and videos), when users download the software installation packages of these applications from the application market, these software installation packages usually include shader source code (shadersource); when these applications are installed on the terminal device, users can open these applications normally. Because shader source code cannot be run directly on GPU hardware, when these applications are running, the terminal device needs to compile the shader source code into machine code programs (i.e., executable code or executable instructions) that can be executed on the GPU. Only then can the shader realize the image rendering function.

[0004] However, as some scenarios (such as games, animations, etc.) have increasingly higher requirements for picture smoothness, picture clarity, and picture realism, complex and time-consuming shader source code compilation may cause frame drops and stuttering during the picture rendering process; for example, a game application that requires a frame rate of 60 frames (that is, running 60 frames per second) has an average drawing time of only 16.6 milliseconds (ms) per frame, while the compilation of shader source code sometimes takes tens to hundreds of milliseconds. This time-consuming compilation process often causes frame drops and stuttering during the game. Summary of the Invention

[0005] To this end, the present application provides a compilation method, an electronic device, and a computer-readable storage medium, which can reduce the probability of frame loss and freezes during the picture rendering process, and is conducive to optimizing the picture rendering performance.

[0006] To achieve the above objectives, this application adopts the following technical solutions:

[0007] In a first aspect, a compilation method is provided, applied to a first device, the method comprising:

[0008] Obtain L types of shader source code, where the L types of shader source code are source code corresponding to L applied shaders, where L is an integer greater than 1; determine common source code from the L types of shader source code, where the common source code is a common portion of the L types of shader source code; compile the common source code to obtain N types of public executable codes, where the N types of public executable codes are used to adapt to N types of operating environments, where N is a positive integer; and send a target public executable code to a second device, where the target public executable code is one of the N types of public executable codes that is adapted to the operating environment of the second device.

[0009] Among them, the first device may refer to a server, and the compilation method may be executed by the server, or by a module applied in the server (such as a processor, chip, or chip system, etc.), or by a logic module or software that can realize all or part of the server functions.

[0010] During the image rendering process, one processing method is to compile and render at the same time, which often results in frame drops and lags. In this application, the first device can determine the common source code from L types of shader source code and compile the common source code; finally, the target common executable code adapted to the operating environment of the second device is sent to the second device. When performing the rendering operation, the second device can directly call the common executable code without compiling the common source code part, thereby reducing the amount of compilation in the image rendering process, reducing the probability of frame drops and lags during the image rendering process, and optimizing the image rendering performance.

[0011] In one possible implementation, the above method also includes: determining M types of private source codes from L types of shader source codes, where the M types of private source codes are the parts of the L types of shader source codes excluding the public source codes, and M is a positive integer less than or equal to L; compiling the M types of private source codes respectively to obtain K types of private executable codes, where the K types of private executable codes are used to adapt to N types of operating environments, K=M*N, where K is a positive integer; and sending a target private executable code to the second device, where the target private executable code is one of the K types of private executable codes that is adapted to the operating environment of the second device.

[0012] In some scenarios, in addition to determining the public source code from L types of shader source code, the first device can also determine M types of private source code from the L types of shader source code, and compile these M types of private source code to obtain K types of private executable code; the first device can send the target private executable code adapted to the operating environment of the second device to the second device, so that the second device can directly call the target public executable code and the target private executable code for image rendering during the rendering process, avoiding complex and time-consuming shader source code compilation, thereby further reducing the probability of frame loss and freezes during the picture rendering process, and optimizing the picture rendering performance.

[0013] In a possible implementation, obtaining L types of shader source code includes: obtaining the L types of shader source code from at least one terminal device, where the at least one terminal device is used to run L applications.

[0014] Since L applications are running on the terminal device, it is beneficial for the terminal device to detect the corresponding shader source code during the image rendering process of each application. Therefore, the first device can obtain L types of shader source code through at least one terminal device.

[0015] In a possible implementation, obtaining L types of shader source codes from at least one terminal device includes: obtaining L types of shader source codes from a shader of at least one terminal device, where the operating mode of the shader is a debug mode.

[0016] In some scenarios, the terminal device can obtain the shader source code through its own shader; for example, when the application is running, the terminal device can set the shader's operating mode to debug mode to obtain L types of shader source code without designing a dedicated source code detection module, which can reduce the cost of obtaining the source code.

[0017] In one possible implementation, the first device includes an acquisition module, which is used to obtain shader source code, and obtain L types of shader source code from the shader of at least one terminal device, including: obtaining L types of shader source code from the shader of at least one terminal device through the acquisition module, and the operating mode of the shader is debug mode.

[0018] In some scenarios, the first device obtains L types of shader source code from the shader of at least one terminal device through the acquisition module. There is no need to manually collect L types of shader source code or design a special source code detection module. This source code acquisition method is efficient, convenient and low-cost.

[0019] In a possible implementation, the first device includes an acquisition module, which is used to obtain shader source code. Obtaining L types of shader source code from at least one terminal device includes: obtaining L types of shader source code from at least one terminal device through the acquisition module.

[0020] In some scenarios, compared with manually collecting L types of shader source codes, the first device automatically obtains L types of shader source codes from at least one terminal device through the acquisition module, which is simple, efficient and low-cost.

[0021] In a possible implementation, determining M private source codes from L shader source codes includes: determining the M private source codes from the L shader source codes according to a first parameter, where the first parameter includes usage frequency information, and M is less than L.

[0022] In some scenarios, in order to improve the utilization rate of private executable code, the first device can eliminate private source codes corresponding to some infrequently used applications from the L types of shader source codes according to the first parameter, and retain the private source codes corresponding to the M commonly used applications (i.e., M types of private source codes) to ensure that the private executable code obtained after compiling the M types of private source codes has a higher utilization rate.

[0023] In a possible implementation, determining the common source code from the L types of shader source code includes: determining the common source code from the L types of shader source code according to a first parameter, where the first parameter includes usage frequency information.

[0024] In some scenarios, in order to ensure that the common source code determined from L types of shader source codes is universal, the present application uses a first parameter (for example, usage frequency information) to filter out shader source codes with high calling (or usage) frequencies from the L types of shader source codes as common source codes, so that the common executable code compiled from the subsequent common source codes can be called by multiple applications, thereby reducing the probability of frame drops and freezes in more applications during the screen rendering process.

[0025] In a possible implementation, compiling the M types of private source code separately includes: compiling the M types of private source code separately according to a second parameter, where the second parameter includes at least one of a GPU version number or an OS version number.

[0026] Since different GPU version numbers and / or OS version numbers can build different operating environments, in order to compile private source code into private executable code that can be applied to multiple operating environments, the first device can compile the private source code according to the GPU version number and / or OS version number to meet the requirements for private executable code in different operating environments.

[0027] In a possible implementation, compiling the public source code includes compiling the public source code according to a second parameter, where the second parameter includes at least one of a GPU version number or an OS version number.

[0028] Since different GPU version numbers and / or OS version numbers can build different operating environments, the first device can compile the public source code into public executable code that can adapt to different operating environments according to the GPU version number and / or OS version number, thereby meeting the demand for public executable code in different operating environments.

[0029] In one possible implementation, before sending the target private executable code to the second device, the above method also includes: receiving a second request message from the second device, the second request message being used to request downloading of a software installation package of a first application, where the first application is one of L applications; sending the target private executable code to the second device, including: sending the software installation package of the first application and the corresponding target private executable code to the second device in response to the second request message.

[0030] In some scenarios, the first device can send the target private executable code and the software installation package of the first application to the second device according to the second request information, so as to avoid forcibly sending data and affecting the user experience when the user has no demand.

[0031] In one possible implementation, the second request information includes a third parameter and a first application identifier, and the third parameter is used to determine the operating environment of the second device. Before sending the software installation package of the first application and the corresponding target private executable code to the second device, the above method also includes: determining the target private executable code from K types of private executable codes based on the third parameter and the first application identifier.

[0032] Since the K types of private executable codes are executable codes corresponding to M applications and can adapt to N types of operating environments, the first device can quickly determine the N types of private executable codes corresponding to the first application from the K types of private executable codes based on the first application identifier, and quickly determine the target private executable code that is adapted to the operating environment of the second device from the N types of private executable codes based on the third parameter.

[0033] In one possible implementation, before sending the target public executable code to the second device, the above method also includes: receiving first request information from the second device, the first request information being used to request acquisition of the target public executable code; sending the target public executable code to the second device, including: sending the target public executable code to the second device in response to the first request information.

[0034] In some scenarios, the first device may send the target public executable code to the second device based on the first request information, so as to avoid forcibly sending data and affecting the user experience when the user has no demand.

[0035] In a possible implementation, receiving the first request information from the second device includes: receiving the first request information from the second device within a preset time period.

[0036] In some scenarios, the first device can receive the first request information from the second device within a preset time period (for example, at a certain interval), and periodically send the target public executable code to the second device to ensure that the public executable code currently stored on the second device is consistent with the latest public executable code of the first device.

[0037] In one possible implementation, the first request information includes a third parameter, which is used to determine the operating environment of the second device; before sending the target public executable code to the second device, the method also includes: determining the target public executable code from N public executable codes based on the third parameter.

[0038] Since the operating environments of different devices may be different, the second device can report the third parameter to the first device through the first request information, so that the first device can determine the target public executable code that is adapted to the operating environment of the second device from N types of public executable codes based on the third parameter, thereby avoiding the erroneous issuance of executable code that does not match the device operating environment.

[0039] In a possible implementation, the third parameter includes at least one of a GPU version number of the second device or an OS version number of the second device.

[0040] Since the K types of private executable codes are private executable codes compiled by the first device according to parameters such as the GPU version number, the third parameter helps the first device quickly determine the target private executable code adapted to the second device from the K types of private executable codes.

[0041] In a second aspect, another compilation method is provided, which is applied to a second device, and the method includes:

[0042] Send a first request message, where the first request message is used to request acquisition of a target public executable code, where the target public executable code is one of N public executable codes that is adapted to the operating environment of the second device, where the N public executable codes are compiled results of a public source code, where the public source code is a common part of L shader source codes, where the L shader source codes are source codes corresponding to shaders of L applications, where L is an integer greater than 1, and N is a positive integer; and receive the target public executable code.

[0043] Among them, the second device may refer to a terminal device, and the compilation method may be executed by the terminal device, or by a module applied in the terminal device (such as a processor, chip, or chip system, etc.), or by a logic module or software that can realize all or part of the functions of the terminal device.

[0044] In the above method, the second device can send a first request message to the first device to obtain the target public executable code from the first device, so that the second device can directly call the public executable code when rendering the image without triggering the compilation of the public source code, thereby reducing the amount of source code compilation, reducing the probability of frame loss and freezes during the screen rendering process, and optimizing the screen rendering performance.

[0045] In a possible implementation manner, sending the first request information includes: sending the first request information within a preset time period.

[0046] In some scenarios, the second device can send a first request message to the first device within a preset time period (for example, at a certain interval) and receive the target public executable code from the first device, thereby ensuring that the local public executable code is always consistent with the latest public executable code of the first device.

[0047] In a possible implementation, the first request information includes a third parameter, and the third parameter is used to determine the operating environment of the second device and is also used to determine the target public executable code.

[0048] Since the operating environments of different devices may be different, the second device can report the third parameter to the first device through the first request information, so that the first device can determine the target public executable code that is adapted to the operating environment of the second device from N types of public executable codes based on the third parameter, thereby avoiding the erroneous issuance of executable code that does not match the device operating environment.

[0049] In a possible implementation, the method further includes: sending a second request message, the second request message being used to request downloading of a software installation package of a first application, where the first application is one of the L applications; and receiving the software installation package of the first application and the target private executable code.

[0050] In some scenarios, the first device can send the target private executable code and the software installation package of the first application to the second device according to the second request information, so as to avoid forcibly sending data and affecting the user experience when the user has no demand.

[0051] In a possible implementation, the second request information includes a third parameter and a first application identifier, the third parameter is used to determine the operating environment of the second device, and the third parameter and the first application identifier are used to determine the target private executable code.

[0052] Since the K types of private executable codes are executable codes corresponding to M applications and can adapt to N types of operating environments, the first device can quickly determine the N types of private executable codes corresponding to the first application from the K types of private executable codes based on the first application identifier, and quickly determine the target private executable code that is adapted to the operating environment of the second device from the N types of private executable codes based on the third parameter.

[0053] In a possible implementation, the third parameter includes at least one of a GPU version number of the second device or an OS version number of the second device.

[0054] Since the K types of private executable codes are executable codes compiled by the first device according to device parameters (such as GPU version number, etc.), the third parameter helps the first device quickly determine the target private executable code adapted to the second device from the K types of private executable codes.

[0055] In a possible implementation, before sending the second request information, the method further includes: receiving a first operation instruction, where the first operation instruction is used to trigger downloading of a software installation package of the first application; and generating the second request information according to the first operation instruction.

[0056] In a possible implementation, receiving the first operation instruction includes: receiving the first operation instruction from a display interface of an application market, where the application market runs on the second device, and the first operation instruction is an installation instruction or an update instruction.

[0057] In some cases, users can trigger installation instructions or update instructions on the display interface of the application market according to their needs to avoid automatic installation or automatic update of applications occupying a large amount of network traffic, causing additional traffic consumption and local lag.

[0058] In a possible implementation, receiving the first operation instruction includes: receiving the first operation instruction from a display interface of the first application, where the first operation instruction is an update instruction.

[0059] In some cases, users can trigger an update instruction on the display interface of the first application according to their needs to avoid automatically updating the application to occupy a large amount of network traffic, causing additional traffic consumption and local lag.

[0060] In a possible implementation, before generating the second request information according to the first operation instruction, the method further includes: instructing the application market to generate the second request information according to the first operation instruction, and the application market runs on the second device.

[0061] In some scenarios, when a user triggers an update from the display interface of an application (for example, a first application), the updated application may not update the previously stored private executable code. In order to ensure that the updated application can timely update the previously stored private executable code, at this time, although the user triggers the update from the display interface of the application, the second device still instructs the application market to generate a second request information according to the first operation instruction to control the application market to execute the update of the first application and the download of the corresponding target private executable code, thereby avoiding the situation where the application update and the private executable code update do not match and affect the screen rendering performance.

[0062] In a third aspect, an embodiment of the present application provides an electronic device, which includes a processor and a memory, the memory being used to store computer programs, and the processor being used to call and run the computer programs from the memory, so that the electronic device executes the method described in the first aspect and various possible implementations of the first aspect.

[0063] In a fourth aspect, an embodiment of the present application provides an electronic device, which includes a processor and a memory, the memory being used to store computer programs, and the processor being used to call and run the computer programs from the memory, so that the electronic device executes the method described in the second aspect and various possible implementations of the second aspect.

[0064] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the processor executes the method described in the first aspect and various possible implementations of the first aspect.

[0065] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the processor executes the method described in the second aspect and various possible implementations of the second aspect.

[0066] In the seventh aspect, an embodiment of the present application provides a computer program product, which includes: computer program code, which, when run by a terminal device, enables the terminal device to execute the method described in the first aspect and various possible implementations of the first aspect.

[0067] In an eighth aspect, an embodiment of the present application provides a computer program product, which includes: a computer program code, which, when executed by a terminal device, enables the terminal device to execute the method described in the second aspect and various possible implementations of the second aspect.

[0068] In the ninth aspect, an embodiment of the present application provides a chip system, which includes a processing circuit and a storage medium, in which computer program instructions are stored; when the computer program instructions are executed by the processing circuit, the method described in the first aspect and various possible implementations of the first aspect is implemented.

[0069] In the tenth aspect, an embodiment of the present application provides a chip system, which includes a processing circuit and a storage medium, in which computer program instructions are stored; when the computer program instructions are executed by the processing circuit, the method described in the second aspect and various possible implementations of the second aspect is implemented.

[0070] Optionally, the processing circuit in the above chip system can be replaced by a processor, and the storage medium can be replaced by a memory. Optionally, the chip system can also include a communication interface, which is used to realize communication between the chip system and the receiving device.

[0071] The beneficial effects of the technical solutions in the third to tenth aspects of the present application may be the same as the beneficial effects of the technical solutions in the first or second aspects, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] Figure 1 A schematic diagram of an image rendering scene provided in an embodiment of the present application;

[0073] Figure 2 A schematic diagram of the hardware structure of an electronic device 100 provided in an embodiment of the present application;

[0074] Figure 3 A schematic diagram of the software architecture of an electronic device 100 provided in an embodiment of the present application;

[0075] Figure 4 A schematic diagram of the software architecture of a terminal device provided in an embodiment of the present application;

[0076] Figures 5A to 5B Schematic diagrams of two application scenarios provided in the embodiments of this application;

[0077] Figure 6 A flowchart of a compilation method 600 provided in an embodiment of the present application;

[0078] 7A to 7C Schematic diagrams of three application scenarios provided in the embodiments of this application;

[0079] Figures 8A to 8B Two more application scenario schematic diagrams provided for the embodiments of the present application;

[0080] Figure 9 A schematic diagram of interaction between a first device and a second device provided in an embodiment of the present application;

[0081] Figure 10 A schematic diagram of interaction between a first device and a second device provided in another embodiment of the present application;

[0082] Figure 11 A schematic diagram of a process for executing an update operation in an application market provided in an embodiment of the present application;

[0083] 12A to 12D A schematic diagram of an application installation scenario provided in an embodiment of the present application;

[0084] 13A to 13D A schematic diagram of an application update scenario provided in an embodiment of the present application;

[0085] 14A to 14D A schematic diagram of another application update scenario provided in an embodiment of the present application;

[0086] 15A to 15D A schematic diagram of a temporary update scenario provided in an embodiment of the present application;

[0087] 16A to 16D A schematic diagram of an update setting scenario provided in an embodiment of the present application;

[0088] 17A to 17D A schematic diagram of another application update scenario provided in an embodiment of the present application;

[0089] 18A to 18D A schematic diagram of an acceleration package download scenario provided in an embodiment of the present application;

[0090] Figure 19 A schematic structural diagram of an electronic device 1900 provided in an embodiment of the present application. DETAILED DESCRIPTION

[0091] In order to clearly describe the technical solutions of the embodiments of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in combination with the drawings in the embodiments of the present application; it should be noted that the embodiments described in the present application are only part of the embodiments of the present application, not all of the embodiments.

[0092] In the description of this application, unless otherwise specified, " / " represents "or." For example, A / B can represent either A or B. In the description of this application, "and / or" is simply a term used to describe an association relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exists simultaneously, or B exists alone. "At least one" refers to one or more, and "more than one" refers to two or more. In the specification and claims of this application, the terms "first" and "second" are used to distinguish different objects or to distinguish different processing of the same object, rather than to describe a specific order of objects. For example, "first terminal" and "second terminal" are used to distinguish different terminal devices, rather than to describe a specific order of terminal devices. Those skilled in the art will understand that terms such as "first" and "second" do not limit quantity or execution order, and that terms such as "first" and "second" do not necessarily imply differences.

[0093] It should be noted that, in this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described in this application as "exemplary" or "for example" should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0094] To facilitate understanding of this application, some technical terms involved in this application are explained below.

[0095] 1. Shader

[0096] Shaders are editable programs used to implement image rendering, replacing the fixed rendering pipeline. Shaders are typically small programs executed on the graphics processing unit (GPU) that control various aspects of graphics, such as color, lighting, texture mapping, and projection. During the image rendering process, shaders are used to process the geometry in the scene and calculate the final color or attributes for each pixel or vertex. Shaders typically come in two types: vertex shaders and fragment shaders. Vertex shaders primarily perform operations on vertex geometry, such as calculating the final position, color, and normal of each vertex. They can also perform coordinate transformations, lighting calculations, and vertex animation. Fragment shaders, also known as pixel shaders, primarily perform calculations such as fragment color. For example, they process each pixel to calculate its final color. They can also perform texture sampling, lighting calculations, and shadow calculations to generate the final image.

[0097] 2. Shader source code

[0098] Shader source code is the code that software developers use to implement image rendering when writing software source code. This shader source code is usually packaged into a software installation package and ultimately installed on a terminal device through an app store or other channels (such as a browser).

[0099] 3. Shader compilation

[0100] Since the shader source code itself cannot be run directly on specific hardware (such as GPU, etc.) or operating system, but needs to be compiled into executable instructions (shader bin) before it can be run on the hardware; therefore, shader compilation is to convert the shader source code into a machine code program that can be executed on specific hardware (such as GPU, etc.) or operating system; the executable machine code program can also be called executable code or executable program or executable instructions (shader bin).

[0101] 4. GPU

[0102] A GPU, also known as a graphics processing unit, visual processor, or display chip, is a microprocessor specifically designed to perform image and graphics-related operations on personal computers, workstations, game consoles, and some mobile devices (such as tablets and smartphones). The GPU reduces graphics card reliance on the CPU and performs some of the tasks previously performed by the CPU. This is particularly true when processing 3D graphics. The core technologies employed by the GPU include hardware T&L (geometry transformation and lighting processing), cubic environment material mapping and vertex blending, texture compression and bump mapping, and a dual-texture four-pixel 256-bit rendering engine.

[0103] The following combination Figure 1 The image rendering scene shown leads to the technical problem that needs to be solved by this application.

[0104] like Figure 1 As shown, a terminal device has game, video and other application software installed; when the user starts the game, video and other application software, the terminal device will execute the relevant code for image rendering; before executing the image rendering function, the terminal device first detects whether the compiled shader bin file is stored in the internal file system or memory; if so, it means that the application software has been run on the terminal device before, and at this time, the terminal device can read the compiled shader bin file from the file system or memory for image rendering; if not, it means that the application software is running on the terminal device for the first time; at this time, the terminal device can pass the shader source code to the shader through the system interface, and trigger the shader to compile the shader source code into a shader bin file; finally, use the shader's cache function to cache the compiled shader bin file in the file system or memory, so that the terminal device can read the compiled shader from the file system or memory. bin file for image rendering; it can be seen that when the application software is running on the terminal device for the first time, since the application software performs the image rendering function for the first time, the compiled shaderbin file does not exist in the file system or memory of the terminal device; at this time, when the terminal device performs image rendering, it needs to trigger the shader to compile the shader source code in real time; and the complex and time-consuming shader source code compilation may cause frame loss and jamming during the image rendering process. To this end, the present application proposes a compilation method, which can reduce the probability of frame loss and jamming during the image rendering process, which is conducive to optimizing the image rendering performance.

[0105] In this compilation method, the server (i.e., an example of the first device) can first obtain the common source code from the shader source code of multiple applications, and then compile the common source code to obtain the common executable code; finally, the common executable code is sent to the terminal device (i.e., an example of the second device) to reduce the amount of tasks of the terminal device for compiling the shader source code during the image rendering process, thereby reducing the probability of frame loss and freezes during the image rendering process.

[0106] It should be noted that the above compilation method can be executed by a first device (or a second device). In some scenarios, the first device may refer to a server, such as a business processing server, a computing server, or a data server; the second device may refer to a terminal device (or user equipment (UE)); wherein the terminal device may be a mobile phone, a watch, a car machine, a smart screen, a smart TV (TV), a tablet computer (Pad), a wearable device, a virtual reality (VR) device, an augmented reality (AR) device, a projector, an in-car playback system, and the like. The embodiments of this application do not impose any restrictions on the specific type of the terminal device.

[0107] In order to better understand the embodiments of the present application, Figure 2 A hardware structure of an electronic device 100 applicable to the present application is introduced; the electronic device 100 may refer to a first device (or a second device).

[0108] The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) connector 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, and a display screen 170, etc.

[0109] The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), a controller, a digital signal processor (DSP), a baseband processor, etc. The different processing units may be independent devices or integrated into one or more processors.

[0110] The processor 110 can generate an operation control signal according to the instruction operation code and the timing signal to complete the control of instruction fetching and execution.

[0111] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 may be a cache memory. This memory can store instructions or data that have been used or are frequently used by processor 110. When processor 110 needs to use the instruction or data, it can directly access it from this memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0112] In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal serial bus (USB) interface, etc. The processor 110 may be connected to a wireless communication module, a display, or other modules through at least one of the above interfaces.

[0113] It is understood that the interface connection relationship between the modules illustrated in the embodiments of the present application is merely an illustrative illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection methods from the above embodiments, or a combination of multiple interface connection methods.

[0114] The USB connector 130 is an interface that complies with USB standard specifications and can be used to connect the electronic device 100 and peripheral devices. The charging management module 140 is used to receive charging input from a charger. The charger can be a wireless charger or a wired charger. The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, the internal memory 121, the display screen 170 and the wireless communication module 160. In other embodiments, the power management module 141 and the charging management module 140 can also be set in the same device.

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

[0116] The mobile communication module 150 can provide solutions for wireless communications, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. In some embodiments, at least some functional modules of the mobile communication module 150 may be provided in the same device as at least some modules of the processor 110.

[0117] The wireless communication module 160 can provide wireless communication solutions applied to the electronic device 100, including wireless local area networks (WLAN) (such as Wi-Fi networks), Bluetooth (BT), near field communication (NFC), etc.

[0118] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, so that electronic device 100 can communicate with a network and other terminal devices via wireless communication technologies. The wireless communication technologies may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), etc.

[0119] The electronic device 100 can implement display functions through a GPU, a display screen 170 , and an application processor, etc. The processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

[0120] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 via the external memory interface 120 to implement data storage functions. For example, files such as pictures and videos can be saved on the external memory card or transferred from the electronic device 100 to the external memory card.

[0121] The internal memory 121 can be used to store computer executable program code, which includes instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area can store an operating system, at least one application required for a function (for example, games or videos, etc.), etc. The data storage area can store data created during the use of the electronic device 100 (for example, contact information, external device information to be connected, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional methods or data processing of the electronic device 100 by running instructions stored in the internal memory 121, and / or instructions stored in a memory provided in the processor.

[0122] The electronic device 100 can display image data such as game images, film and television animations, etc. through the display screen 170.

[0123] Display screen 170 is used to display interface information such as the application market, game screens, and video playback. Display screen 170 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like. In some embodiments, electronic device 100 may include one or more display screens 170. In some embodiments, the display screens may be foldable or scrollable.

[0124] It should be noted that in some scenarios, for example, the electronic device 100 is a terminal device. Since most applications running on the terminal device have screen display requirements, the electronic device 100 needs to be equipped with a display screen 170. The display screen 170 can display various images in conjunction with the image rendering process of each application. In other scenarios, for example, the electronic device 100 is a server. The server mainly provides computing services, such as compiling shader source code, etc., and has no screen display requirements. In this case, the server may not have a display screen 170. For example, in the scenario where the server is connected to a physical terminal (see below), Figure 8A ), since each application runs on a physical terminal with a display screen, the server mainly provides computing power (for example, providing compilation services, etc.), so the server may not have a display screen 170. Of course, in some other scenarios, the server may also have a display screen 170, for example, refer to the following Figure 8BVarious virtual terminals are deployed on the server. These virtual terminals are used to run application software that requires screen display, such as games and videos. At this time, the server needs to have a display screen 170.

[0125] It is understood that the structure shown in the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may also include Figure 2 More or fewer components, or combining some components, or splitting some components, or a different arrangement of components. Figure 2 The components in the present invention may be implemented in hardware, software, or a combination of software and hardware.

[0126] In addition, it should be noted that the software system of the electronic device 100 can adopt a layered architecture or a service architecture. In the embodiment of the present invention, the Android operating system with a layered architecture is used as an example to illustrate the software architecture of the electronic device 100. It should be understood that the solution provided in this application can also be applied to other types of operating systems such as the Harmony system, Apple operating system, and Windows operating system.

[0127] Figure 3 FIG. 1 shows a schematic diagram of the software architecture of the electronic device 100 provided in an embodiment of the present application. Figure 3 As shown, the layered architecture of electronic device 100 divides the software into several layers, each with a clear role and division of labor. Layers communicate with each other via software interfaces. In some embodiments, the software architecture, from top to bottom, consists of the application (APP) layer, the application framework (FWK) layer, the Android runtime (ART) and system libraries, the hardware abstraction layer (HAL), and the kernel layer.

[0128] The application layer, also known as the application layer, can include a series of application packages. For example, application layer packages may include games, videos, reading, application market, and settings. When these application packages are run, they can access the various service modules provided by the application framework layer through the application programming interface (API) and execute corresponding intelligent services.

[0129] The application framework layer (framework, FWK) provides application programming interface (application programming interface, API) and programming framework for the application layer. The application framework layer includes some predefined functions. Figure 3As shown, the application framework layer may include a graphics manager, video codec, window manager, resource manager, notification manager, content manager, etc. The graphics manager is responsible for calling interfaces in the graphics library to complete drawing, rendering, and compositing interfaces. The video codec is responsible for video encoding and decoding. The window manager manages all system windows. The resource manager is responsible for managing system resources and providing various resources to applications, such as images and video files. The notification manager is responsible for managing prompt messages in the status bar at the top of the phone. The content provider is used to store and retrieve data (such as videos, images, etc.) and make this data accessible to applications.

[0130] The system library (also known as the native C / C++ library) can include multiple functional modules, such as a surface manager, media libraries, a 3D graphics processing library, a 2D graphics engine, a file system module (also known as a file system), and a shader module. The surface manager manages the display subsystem and provides fusion of 2D and 3D layers for multiple applications. The media library supports playback and recording of a variety of common audio and video formats, as well as static image files. The media library supports a variety of audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG. The 3D graphics processing library implements 3D graphics drawing, image rendering, compositing, and layer processing. The 2D graphics engine is a drawing engine for 2D image drawing. The file system module caches shader bin files. The shader module (also known as a shader) implements the shader's image rendering functions, such as performing vertex, color, and texture calculations.

[0131] The Android runtime consists of the core libraries and the Android runtime. The Android runtime is responsible for converting source code into machine code. It primarily utilizes ahead-of-time (AOT) and just-in-time (JIT) compilation technologies.

[0132] The core library is mainly used to provide basic Java class library functions, such as basic data structures, mathematics, IO, tools, databases, networks, etc. The core library provides an API for users to develop Android applications.

[0133] The hardware abstraction layer runs in user space, encapsulates kernel layer drivers, and provides a calling interface to the upper layer; the hardware abstraction layer includes: display module, Bluetooth module, etc.

[0134] The kernel layer is the layer between hardware and software. This kernel layer includes but is not limited to GPU drivers, CPU drivers, display drivers, Bluetooth drivers, etc., which drive the GPU, CPU, display, and Bluetooth of the hardware layer.

[0135] The following has Figure 2 and Figure 3 The second device of the structure shown is a terminal device as an example, combined with Figure 4 The software architecture diagram of the terminal device shown is exemplary, illustrating the overall process of the terminal device executing the above compilation method.

[0136] When a user opens a game application at the application layer, the game application runs on the operating system (OS) of the terminal device; when the game application performs graphics rendering, the game application can generate a rendering request and send the rendering request to the graphics manager; the graphics manager can generate a shader source instruction based on the rendering request, and send the shader source instruction to the shader module of the system library; after receiving the shader source, the shader module detects whether there is a compiled shader bin file in the file system module. If so, it generates an image rendering instruction stream (for example, scene drawing instructions, interface drawing instructions, etc.) according to the shader bin file; the shader module sends the image rendering instruction stream to the GPU driver; the GPU driver generates a rendering driver instruction stream based on the image rendering instruction stream, and sends the rendering driver instruction stream to the GPU; the GPU instructs the display driver to push frames to the display screen according to the rendering driver instruction stream, thereby realizing the rendering of the game screen.

[0137] It should be noted that the software architecture of the electronic device 100 is not limited to Figures 2 to 4 The hardware and software system structure shown in the figure can be adjusted according to the specific application scenario in actual application. Figures 2 to 4 The software and hardware system structures shown in the figure may be modified, and this application does not limit this.

[0138] The above describes in detail the hardware and software system structure of the electronic device 100 applicable to this application. Figure 5A and Figure 5B Two application scenario architectures suitable for this application are introduced.

[0139] Figure 5AAn application scenario is shown in which a terminal device obtains a public shader bin file (also called public executable code) and a private shader bin file (also called private executable code) from a cloud server. In some scenarios, the terminal device (i.e., an example of a second device) may send a download request X to the cloud server (i.e., an example of a first device). The download request X is used to request downloading of a software installation package of application 1 (i.e., an example of the first application) (or a software installation package of application 2). After receiving the download request X, the cloud server sends software installation package A and private shader bin file A (or software installation package B and private shader bin file B) to the terminal device. After receiving the software installation package A and private shader bin file A (or software installation package B and private shader bin file B), the terminal device may store private shader bin file A (or private shader bin file B) in a file system module of an OS, so that the shader module can call it when performing an image rendering function.

[0140] In other scenarios, the terminal device can also send a download request Y to the cloud server, which is used to request the download of a public shader bin file; after receiving the download request Y, the cloud server sends the public shader bin file to the terminal device; after receiving the public shader bin file, the terminal device can store the public shader bin file in the above-mentioned file system module, so that the shader module can call it when executing the image rendering function.

[0141] When application 1 (or application 2) calls the shader module during image rendering, the terminal device will trigger the shader module located in the operating system to check whether the file system module has a compiled shader bin file (for example, private shader bin file A, etc.); for example, if the shader module detects that there is a compiled shader bin file in the file system module, the shader module can directly read the public shader bin file and private shader bin file A from the file system module to perform image rendering (or trigger the shader module to read the public shader bin file and private shader bin file B from the file system module to perform image rendering) without triggering a compilation action.

[0142] Figure 5BThe following illustrates an application scenario in which a terminal device (i.e., an example of a second device) interacts with a cloud server (i.e., an example of a first device). This application scenario is applicable to software installation scenarios (e.g., the installation and update of applications within an application market, as well as application updates outside of an application market, as described below). In this application scenario, the cloud server and the terminal device can communicate with each other, for example, by sending request messages and software installation packages over a wireless network. The cloud server includes an automated acquisition module, a compilation module, and a distribution module. The processing and interaction processes of these modules are as follows:

[0143] The automated collection module, also referred to as the collection module, is used to collect shader source codes of multiple applications (eg, the L types of shader source codes mentioned below) from at least one terminal device, and is also used to send the collected shader source codes to the compilation module.

[0144] A compilation module is used to determine public source code and private source code, and to compile the public source code and private source code separately. For example, after receiving the shader source code sent by the automated acquisition module, the compilation module determines the public source code and private source code (for example, M types of private source code) based on the shader source code; then, the public source code and private source code are compiled separately to obtain a public shader bin file (for example, N types of public executable code described below) and a private shader bin file (for example, K types of private executable code described below). For details, please refer to the embodiments below and will not be repeated here.

[0145] The distribution module is used to provide public shader bin files, software installation packages, and corresponding private shader bin files to terminal devices.

[0146] On the terminal side, the terminal device can download the software installation package A of application 1 (or application 2) and the corresponding private shader bin file A (or private shader bin file B) and public shader bin file from the cloud server through the application market; wherein, the application market is an application software installed on the terminal device, used to download software installation packages and shader bin files of different applications from the cloud server; after the download is completed, the terminal device can call the system interface to store the shader bin file (for example, private shader bin file A, private shader bin file B and public shader bin file) in the file system module, wherein the file system module is a module running in the operating system of the terminal device, used to store public shader bin files and various private shader bin files.

[0147] When application 1 (or application 2) calls the shader module during the image rendering process (or when calling the image rendering interface shader module), the terminal device will trigger the shader module to check whether there is a compiled shader bin file (for example, private shader bin file A, etc.) in the file system module; if so, the shader module can directly call the public shader bin file and the private shader bin file (for example, private shader bin file A or private shader bin file B) from the file system module to perform image rendering without triggering the compilation action; if not, the compilation operation needs to be re-triggered; wherein, the shader module is a module located in the operating system for performing image rendering functions; when performing image rendering functions, the shader module usually gives priority to using the compiled shader bin file in the file system module; the compilation operation is triggered only when the file system module does not have a compiled shader bin file; in addition, the operating system also includes a storage kit (store kit), which is used to provide software distribution related interfaces and to launch the application market to perform application updates (for details, please refer to the embodiments below, which will not be repeated here).

[0148] Several application scenarios applicable to the present application are introduced above. The compilation method provided in the embodiments of the present application is illustrated below with reference to the accompanying drawings.

[0149] like Figure 6 As shown, it is a flow chart of a compilation method 600 provided in an embodiment of the present application. Before introducing the method 600 provided in the present application, a brief description of the execution subject involved in the embodiment of the present application is first given. In the present application, the first device can be a server and the second device can be a terminal device; the above compilation method can be executed by the first device (or second device), or it can be executed by a module (such as a processor, chip, or chip system, etc.) applied to the first device (or second device), and it can also be implemented by a logic module or software that can realize all or part of the functions of the first device (or second device).

[0150] The first device may be a Figure 2 and Figure 3 The second device can be a server with a hardware and software architecture. Figure 2 and Figure 3 It should be noted that the first device and the second device can communicate with each other, for example, they can communicate with each other via a wireless network.

[0151] The above method 600 includes steps 601 to 604, which are described in detail below.

[0152] In step 601 , a first device obtains L shader source codes, where the L shader source codes are source codes corresponding to L applied shaders, and L is an integer greater than 1.

[0153] Among them, the first device usually refers to a server; the server usually has strong computing power and can compile executable code (or executable instructions) with higher execution efficiency. For example, it can be a business server, computing server, cloud server, etc.; the shader source code usually refers to the source code written by developers to implement image rendering; for example, for some application software that requires image rendering (such as games, videos and other applications), developers need to write source code to implement the image rendering function when writing the source code of these application software (in other words, they need to write shader source code).

[0154] Since different applications need to implement different image rendering content, the source codes corresponding to the shaders of different applications are different. For example, L applications may correspond to L types of shader source codes.

[0155] The first device obtains L shader source codes as follows:

[0156] Mode 1: In some embodiments, the first device obtains L shader source codes from at least one terminal device, where the at least one terminal device is used to run L applications.

[0157] The at least one terminal device includes one or more terminal devices; at least one terminal device being used to run L applications can be understood as L applications running on one terminal, or L applications running on multiple terminals.

[0158] For example, Figure 7AAs shown, the first device is a server, L=6, and applications 1 to 6 are running on terminal device A; the server and terminal device A can communicate with each other; terminal device A includes a shader module and a source code detection module, wherein the shader module is used to implement image rendering, and the source code detection module is used to obtain the shader source code corresponding to each of applications 1 to 6 (i.e., an example of L applications) (i.e., L=6 types of shader source code); the source code detection module collects the shader source code corresponding to each of the six applications during the image rendering process of applications 1 to 6, and sends the six shader source codes to the server. After receiving the six shader source codes from terminal device A, the server processes the six shader source codes (e.g., extracts public source code and private source code, etc.), compiles the processed shader source codes to obtain executable code (e.g., public executable code or private executable code), and finally sends the executable code to the device in need (e.g., the second device). In this scenario, since L applications are running on the terminal device, it is beneficial for the terminal device to detect the corresponding shader source code during the image rendering process of each application. Therefore, the first device can obtain L types of shader source code through at least one terminal device.

[0159] Mode 2: In some embodiments, the first device obtains L shader source codes from a shader of at least one terminal device, and the operating mode of the shader is a debug mode.

[0160] It should be noted that the terminal device A does not need to design a special source code detection module to obtain the shader source code corresponding to each of the applications 1 to 6; for example, Figure 7B As shown, terminal device A can collect the shader source code corresponding to application 1 to application 6 (i.e., L = 6 shader source codes) through the shader module when the shader module is in debugging mode; and send these 6 shader source codes to the server, and use the existing shader module to obtain the shader source code, without the need to design a special source code detection module, which can reduce the cost of obtaining the source code.

[0161] For example, Figure 7CAs shown, the first device is a server, L=6, and applications 1 to 6 are running on terminal device A. The server and terminal device A can communicate with each other. Terminal device A includes a shader module and a source code detection module. The server includes an automated acquisition module, a compilation module, and a distribution module. The automated acquisition module is used to automatically obtain L types of shader source code. The compilation module compiles the shader source code to obtain executable code. The distribution module is used to send the executable code to a second device (e.g., a terminal). On the terminal side, while applications 1 to 6 are running, the source code detection module can collect the shader source code corresponding to each of the six applications during image rendering and send the six shader source codes to the server. On the server side, the automated acquisition module receives the six shader source codes from terminal device A and sends them to the compilation module. The compilation module processes the six shader source codes (e.g., extracts public and private source code), compiles the processed shader source codes to obtain executable code (e.g., public or private executable code). The compilation module sends the executable code to the distribution module, which then sends the executable code to the target terminal.

[0162] It should be noted that the above-mentioned method 1 and method 2 only take the method in which the first device obtains L types of shader source codes from one terminal device as an example. For the method in which the first device obtains L types of shader source codes from multiple terminal devices involved in method 1 and method 2, you can refer to method 3 and method 4 to be introduced below. Their principles are similar and will not be repeated here one by one.

[0163] Method 3: In some embodiments, the first device includes an acquisition module, which is used to obtain shader source code. The first device obtains L types of shader source code from at least one terminal device, including: the first device obtains L types of shader source code from at least one terminal device through the acquisition module.

[0164] Among them, the acquisition module is a module on the first device for obtaining the shader source code. The acquisition module can be a module in the operating system or a module in the application layer, which is not limited in this application.

[0165] It should be noted that in some scenarios, the acquisition module may also be called an automatic acquisition module, an automated acquisition module, a source code acquisition module, etc. This application does not limit the name of the acquisition module in actual applications.

[0166] For example, Figure 8AAs shown, the first device is a server, and terminal devices 1 to n are n physical terminal devices (for example, terminal device 1 is a watch, terminal device 2 is a mobile phone, ..., terminal device n is a tablet); the server and the n terminal devices can communicate with each other; applications 1 to m (i.e., an example of L applications) run on these n terminal devices (i.e., an example of at least one terminal device), for example, application 1 and application 2 run on terminal device 1, application 3 runs on terminal device 2, ..., application m runs on terminal n; terminal devices 1 to n each include a shader module and a source code detection module, wherein the shader module is used to implement image rendering, and the source code detection module is used to obtain the shader source code corresponding to each of applications 1 to m (i.e., an example of L shader source codes); the server includes an automatic acquisition module, a compilation module, and a distribution module. For understanding each module, please refer to Figure 7C The server shown is not described here in detail. For the terminal side, during the operation of application 1 to application m, the source code detection module can collect the shader source code corresponding to each of the m applications (i.e., L=m types of shader source code) during the execution of image rendering, and send the m types of shader source code to the server. For the server side, the automated collection module can receive m types of shader source code from terminal device 1 to terminal device n (for example, receiving the shader source code corresponding to application 1 and the shader source code corresponding to application 2 from terminal device 1), and send the m types of shader source code to the compilation module; the compilation module processes the m types of shader source code (for example, extracting public source code and private source code, etc.), and compiles the processed shader source code to obtain executable code (for example, public executable code or private executable code); the compilation module can send the executable code to the distribution module; the distribution module sends the executable code to the device in need. It can be seen that compared with manually collecting L types of shader source code, the first device automatically obtains L types of shader source code from at least one terminal device through the collection module, which is simple, efficient, and low-cost.

[0167] Method 4: In some implementations, the first device includes an acquisition module, which is used to obtain shader source code. The first device obtains L types of shader source code from the shader of at least one terminal device, including: the first device obtains L types of shader source code from the shader of at least one terminal device through the acquisition module, and the operating mode of the shader is debug mode.

[0168] In some scenarios, developers do not need to design a special source code detection module on terminal device 1 to terminal device n to obtain the shader source code corresponding to different applications; for example, Figure 8BAs shown, terminal devices 1 to n can set their respective shader modules to debug mode, and then use their respective shader modules to collect shader source codes corresponding to m applications (for example, application 1 to application m) running on their own operating systems, and finally obtain m types of shader source codes; the cloud server can obtain these m types of shader source codes from terminal devices 1 to n, without the need to manually collect m types of shader source codes or design a special source code detection module. This source code acquisition method is efficient, convenient, and low-cost.

[0169] For example, Figure 8B As shown, the first device can be a cloud server, and terminal devices 1 to n are n virtual terminals on the cloud server. The cloud server can use an automated acquisition module to obtain shader source code corresponding to applications running on these virtual terminals from the n virtual terminals. Terminal devices 1 to n each include a shader module. The cloud server includes an automated acquisition module, a compilation module, and a distribution module. On the terminal side, the shader module of each virtual terminal runs in debug mode and can be used to obtain shader source code. For example, the shader module of each virtual terminal can collect the shader source code corresponding to each application during image rendering and send the shader source code to the cloud server. On the cloud server side, the automated acquisition module can receive m types of shader source codes from n virtual terminals (for example, receiving the shader source code corresponding to application 1 from terminal device 1, receiving the shader source code corresponding to application 2 from terminal device 2, etc.), and send the m types of shader source codes to the compilation module; the compilation module processes the m types of shader source codes (for example, extracting public source code and private source code, etc.), and compiles the processed shader source codes to obtain executable code (for example, public executable code or private executable code); the compilation module can send the executable code to the distribution module; the distribution module can distribute the executable code to the terminal in need.

[0170] Step 602: The first device determines a common source code from L types of shader source codes, where the common source code is a common portion among the L types of shader source codes.

[0171] Since L types of shader source code correspond to L applications, which portion of each shader source code can be used as public source code can be determined based on the extent to which the application corresponding to the shader source code is used. This extent can be measured by some usage frequency information and call status. For example, the probability of determining a shader source code as public source code is high for applications with high usage frequency, and vice versa. For another example, if a certain shader source code is called by more applications, it means that the shader source code is more widely used, and the probability of determining it as public source code is high. If it is called by fewer applications, the probability of determining it as public source code is low.

[0172] Among them, the usage frequency information is used to indicate the frequency with which each application among the L applications is used, and the usage frequency information includes but is not limited to the number of downloads (also referred to as download volume) and / or the number of installations (also referred to as installation volume); wherein, the more downloads (or installations), the higher the frequency of application use, and vice versa; the calling situation may refer to the situation where a certain shader source code is called by other applications, for example, how many applications call the first shader source code (i.e., an example of L shader source codes) or how many times in total it is called by other applications, etc.

[0173] In some embodiments, the first device determines a common source code from L types of shader source codes, including: determining the common source code from the L types of shader source codes according to a first parameter, wherein the first parameter includes usage frequency information.

[0174] For example, taking the usage frequency information as the number of downloads, and L=4 types of shader source codes as an example, the number of downloads of application 1 corresponding to the first shader source code is 100 million times, the number of downloads of application 2 corresponding to the second shader source code is 80 million times, the number of downloads of application 3 corresponding to the third shader source code is 250 million times, and the number of downloads of application 4 corresponding to the fourth shader source code is 4 million times; obviously, more users use application 1 and application 3, followed by application 2, and the least application 4; at this time, when the first device determines the common source code from the four shader source codes, the probability of the shader source code shared by the first shader source code and the third shader source code being determined as the common source code is higher; for example, the first shader source code and the third shader source code both include shader source code A, but do not include shader source code B and shader source code C; while the second shader source code includes shader source code B, and the fourth shader source code both include shader source code C; considering that application 1 and application 3 are used by more users, the first device can use shader source code A as the common source code.

[0175] It can be seen that in order to ensure that the common source code determined from the L types of shader source codes is universal, the present application uses a first parameter (for example, usage frequency information) to filter out shader source codes with high calling (or usage) frequencies from the L types of shader source codes as common source codes, so that the common executable code compiled from the subsequent common source codes can be called by multiple applications, thereby reducing the probability of frame drops and freezes in more applications during the screen rendering process.

[0176] For another example, in some other embodiments, the first device may determine the common source code from L types of shader source codes according to the caller situation; still taking L=4 types of shader source codes as an example, wherein the first type of shader source code comes from application 1, ..., and the fourth type of shader source code comes from application 4; the first type of shader source code includes shader source code A1, shader source code B1, and shader source code C1; the second type of shader source code includes shader source code A1, shader source code B2, and shader source code C1; the third type of shader source code includes shader source code A1, shader source code B3, and shader source code C1; and the fourth type of shader source code package The following examples include shader source code A2, shader source code B4, and shader source code C1. Applications 1 through 3 all call shader source code A1, indicating that shader source code A1 may be widely used. Furthermore, applications 1 through 4 also call shader source code C1, indicating that shader source code C1 may be widely used. However, shader source code B1 through B4 are not called by any other application besides their own application, indicating that shader source code B1 through B4 may be private source code to the application itself. Compared to shader source code B1 through B4, shader source code A1 and shader source code C1 are more likely to be public source code. Since shader source code A1 and shader source code C1 may be called by more applications, the first device may designate shader source code A1 and shader source code C1 as public source code.

[0177] In step 603 , the first device compiles the public source code to obtain N types of public executable codes, where the N types of public executable codes are used to adapt to N types of operating environments, where N is a positive integer.

[0178] Since the source code needs to be compiled when it is run on the terminal device (ie, an example of the second device), the first device can compile the public source code after determining the public source code.

[0179] Because the device parameters of terminal devices are different, the executable code compiled from the source code is different. Therefore, in some embodiments, the first device can compile the public source code into executable code adapted to the operating environment of different devices based on different device parameters. The device parameters may include, but are not limited to, at least one of the device type (e.g., mobile phone, tablet, or watch), GPU version number, or OS version number; the GPU version number may also be referred to as the GPU model or GPU version, for example, the GPU version number is XXX 000; the operating system version number may also be referred to as the operating system model or operating system version, for example, the operating system version number is XX01.

[0180] The above-mentioned N can generally be determined based on device parameters. For example, if there are currently five GPU version numbers, the first device can compile the public source code into public executable code that can run on the five different GPU versions based on the different GPU version numbers. For another example, if there are currently five GPU version numbers and four OS version numbers, the first device can compile the public source code into public executable code that can run on 20 (i.e., 5×4=20) different GPU versions and OS versions based on the different GPU and OS version numbers.

[0181] In some embodiments, the first device compiles the public source code, including: compiling the public source code according to a second parameter, where the second parameter includes at least one of a GPU version number or an OS version number.

[0182] The second parameter is an example of the above-mentioned device parameter. Taking the second parameter as an example of a GPU version number, if there are three GPU version numbers currently on the market, namely version 1, version 2, and version 3, the first device can compile the public source code into N=3 types of public executable codes according to versions 1 to 3, namely public executable code 1, public executable code 2, and public executable code 3; these three types of public executable codes can run on the three GPU versions (i.e., adapt to the operating environments of the three GPU versions); for example, if the GPU version number installed on the second device is version 1 (or version 2 or version 3), then public executable code 1 (or public executable code 2 or public executable code 3) can run on the GPU of the second device.

[0183] For another example, taking the second parameter as the GPU version number and the operating system version number, if there are currently two GPU version numbers on the market, namely GPU version 1 and GPU version 2, and two OS version numbers, namely OS version 1 and OS version 2, then the first device can compile the public source code into N=4 public executable codes according to the two GPU version numbers and the two OS version numbers, namely public executable code 1, public executable code 2, public executable code 3 and public executable code 4, wherein public executable code 1 is adapted to the combination of GPU version 1 and OS version 1. The public executable code 2 is adapted to the operating environment built by GPU version 1 and OS version 2, the public executable code 3 is adapted to the operating environment built by GPU version 2 and OS version 1, and the public executable code 4 is adapted to the operating environment built by GPU version 2 and OS version 2; these four public executable codes can run in the operating environments built by four different GPU versions and OS versions; for example, if the GPU version installed on the second device is version 1 and the OS version number is OS version 1, then public executable code 1 can run on the GPU and OS of the second device.

[0184] Since different GPU version numbers and / or OS version numbers can build different operating environments, the first device can compile the public source code into public executable code that can adapt to different operating environments according to the GPU version number and / or OS version number, thereby meeting the demand for public executable code in different operating environments.

[0185] Step 604: The first device sends a target public executable code to the second device. The target public executable code is one of the N types of public executable codes that is adapted to the operating environment of the second device.

[0186] The second device may be a terminal device or a target service server, which is not limited in this application.

[0187] Since the GPU version number and OS version number on different devices may be different, the target public executable code that different devices need to download from the first device may be different. For example, the second device sends a request 1 (for example, the first request information below) to the first device; the request 1 includes the GPU version number and OS version number of the second device; after the first device receives the request 1, it can determine the public executable code 1 that is adapted to the operating environment of the second device from N types of public executable codes based on the GPU version number and OS version number in the request 1, and send the public executable code 1 to the second device; after the terminal device receives the public executable code 1, it can store the public executable code 1 in the local file system module; when the application 1 performs the rendering function, the shader module of the second device can directly read (or call) the public executable code 1 from the file system module without the need to compile the public source code, thereby reducing the amount of compilation in the image rendering process.

[0188] In summary, during the image rendering process, one processing method is to compile and render at the same time, which often results in frame drops and freezes. In this application, the first device can determine the common source code from L types of shader source code and compile the common source code; finally, the target common executable code adapted to the operating environment of the second device is sent to the second device. When performing the rendering operation, the second device can directly call the common executable code without compiling the common source code part, thereby reducing the amount of compilation in the image rendering process, reducing the probability of frame drops and freezes in the image rendering process, and optimizing the image rendering performance.

[0189] like Figure 9 As shown, before the above step 604, the above method 600 further includes step 605:

[0190] Step 605: The first device receives first request information from the second device, where the first request information is used to request to obtain the target public executable code.

[0191] Correspondingly, the second device sends first request information to the first device.

[0192] The first request information includes but is not limited to a second device identifier and a second device parameter, wherein the second device identifier can be a string of characters (for example, XXX0002, etc.) used to uniquely identify the second device; the second device parameters include but are not limited to a GPU version number and / or an OS version number.

[0193] Since the N types of public executable codes on the first device correspond to different operating environments, the first device needs to determine the target public executable code from the N types of public executable codes based on the second device parameters reported by the second device; for example, the second device parameters include GPU version number A and operating system version number B; if public executable code 1 is the public executable code obtained by the first device after compiling the public source code according to version number A and version number B, then the first device can determine public executable code 1 as the target public executable code from the N types of public executable codes based on version number A and version number B.

[0194] In some embodiments, the above step 604 may also be implemented through step 6041:

[0195] Step 6041: The first device sends the target public executable code to the second device in response to the first request information.

[0196] After receiving the first request information, the first device can determine the target public executable code according to the first request information and send the target public executable code to the second device, thereby avoiding forcibly sending data and affecting the user experience when the user has no demand.

[0197] Optionally, the second device may send the first request information within a preset time period; correspondingly, the first device may receive the first request information from the second device within the preset time period.

[0198] Among them, the preset time period can be set by the starting time and the interval time. For example, starting from time T1, every interval time T, the second device sends a request message (for example, the first request message) to the first device once; correspondingly, starting from time T1, every interval time T, the first device receives a request message from the second device once.

[0199] For example, in some scheduled task (or periodic task) scenarios, the second device can periodically send a first request message to the first device to obtain the target public executable code from the first device, thereby ensuring that the currently stored public executable code is consistent with the latest public executable code of the first device.

[0200] In these embodiments, the second device sends a first request message to the first device to obtain the target public executable code from the first device, so that the second device can directly call the public executable code when rendering the image without triggering the compilation of the public source code, thereby reducing the amount of source code compilation, reducing the probability of frame loss and freezes during the screen rendering process, and optimizing the screen rendering performance.

[0201] In an optional implementation, the first request information includes a third parameter, and the third parameter is used to determine the operating environment of the second device; before step 604, the method 600 further includes step 6040:

[0202] Step 6040: The first device determines a target public executable code from N types of public executable codes according to the third parameter.

[0203] The third parameter is an example of a device parameter, such as a device model, GPU version number, and operating system version number. Since the N types of public executable codes are executable codes compiled by the first device based on the device parameters (e.g., GPU version number), the third parameter reported by the second device to the first device facilitates the first device in determining, based on the third parameter, a target public executable code that is compatible with the second device from among the N types of public executable codes.

[0204] In some embodiments, the third parameter includes at least one of a GPU version number of the second device or an OS version number of the second device. The second device may report its own GPU version number and / or its own OS version number to the first device through the first request information, so that the first device can determine the target public executable code adapted to the operating environment of the second device from the N types of public executable codes based on the GPU version number and / or the OS version number, thereby avoiding the erroneous issuance of executable code that does not match the device operating environment. For details, please refer to the method for determining the target public executable code in step 605 above, which will not be repeated here.

[0205] In some embodiments, in addition to determining the public source code and compiling the public source code, the first device may also determine the private source code and compile the private source code.

[0206] like Figure 10 As shown, the above method 600 further includes steps 1001 to 1003:

[0207] Step 1001: A first device determines M types of private source codes from L types of shader source codes, where the M types of private source codes are parts of the L types of shader source codes excluding the public source codes, and M is a positive integer less than or equal to L.

[0208] It should be noted that the M types of private source codes are the private source codes corresponding to the M applications; usually, the M types of private source codes are bound to the M applications one by one; when a user downloads or updates an application, the private source code is usually sent to the client (for example, the second device) together with the software installation package of the application.

[0209] According to the description of step 602 above, the first device can determine the public source code from a certain shader source code; and the private source code can be understood as the portion of a certain shader source code other than the public source code.

[0210] In some embodiments, the first device can determine M=L private source codes from L shader source codes, that is, the first device removes the public source code portion from each shader source code in the L shader source codes to obtain L private source codes without the public source code.

[0211] In some other embodiments, the first device may determine M types of private source codes from L types of shader source codes according to a first parameter, wherein the first parameter includes usage frequency information, and M is less than L.

[0212] The usage frequency information can refer to the relevant description in the above step 602, which will not be repeated here. For example, taking the usage frequency information as the number of downloads corresponding to L applications as an example, the first device can remove the shader source code corresponding to the application with a small number of downloads based on the number of downloads of each of the L applications. For example, the number of downloads of 5 applications among the L applications is lower than the preset value. At this time, the first device can remove the 5 shader source codes corresponding to these 5 applications from the L shader source codes, thus obtaining L-5 shader source codes, that is, the first device removes the public source code portion of each shader source code in the L-5 shader source codes, and obtains M=L-5 private source codes without the public source codes, wherein "-" is a subtraction operator.

[0213] In this embodiment, the first device removes private source codes corresponding to some infrequently used applications from the L types of shader source codes based on the first parameter, and retains the private source codes corresponding to the M types of commonly used applications (i.e., M types of private source codes), thereby ensuring that the private executable codes obtained after compiling the M types of private source codes have a higher usage rate.

[0214] Step 1002: The first device compiles M types of private source codes respectively to obtain K types of private executable codes, where the K types of private executable codes are used to adapt to N types of operating environments, where K=M*N, and K is a positive integer.

[0215] Among them, "*" is the multiplication operator, and "M" in K=M*N represents M types of private source code, which also represents M applications; "N" means that each private source code can be compiled into N types of private executable code, which can also be understood as each application can correspond to N types of private executable code; N is usually determined by device parameters (for example, the second device parameter above); for example, if the device parameters include 5 GPU version numbers, then each private source code can be compiled into N=5 types of private executable code; these 5 types of private executable code can run on the GPUs corresponding to these 5 GPU version numbers.

[0216] Since the first device compiles each of the M private source codes in the same manner, the following only takes the first device compiling one private source code as an example to illustrate the process of the first device compiling the M private source codes.

[0217] Since the compilation of private source code is similar to that of public source code, the first device also needs to compile the private source code into executable code adapted to different device operating environments according to different device parameters; wherein, the device parameters can refer to the relevant description in step 603 above and will not be repeated here.

[0218] The above-mentioned K can generally be determined based on device parameters and the number of source code. For example, if there are currently five GPU version numbers, the first device can compile one private source code into five private executable codes based on the five GPU version numbers. These five private executable codes can run on GPUs corresponding to different GPU versions. For example, if there are M types of private source code, the first device can compile the M types of private source code into K = 5 * M types of private executable codes based on the five GPU version numbers. For another example, if there are currently four GPU version numbers and three OS version numbers, the first device can compile one private source code into 12 (i.e., 4 × 3 = 12) types of private executable codes based on different GPU and OS version numbers. These 12 types of private executable codes can run on the operating environments established by the 12 GPU and OS versions. Because there are M types of private source code, each type of private source code can be compiled into 12 types of executable code. Therefore, the first device can compile the M types of private source code into K = 12 * M types of private executable codes based on the four GPU version numbers and the three OS version numbers.

[0219] In some embodiments, the first device compiles the M types of private source codes respectively according to a second parameter, where the second parameter includes at least one of a GPU version number or an OS version number.

[0220] The second parameter is an example of the above-mentioned device parameter. Taking the second parameter as an example of a GPU version number, if there are three GPU version numbers currently on the market, namely version 1, version 2, and version 3, the first device can compile a private source code into N=3 types of private executable codes according to versions 1 to 3, namely private executable code 1, private executable code 2, and private executable code 3; these three types of private executable codes can run on three GPU versions (i.e., adapt to the operating environments of three GPU versions); for example, if the GPU version number installed on the second device is version 1 (or version 2 or version 3), private executable code 1 (or private executable code 2 or private executable code 3) can run on the GPU of the second device; for example, if there are M types of private source codes, the first device can compile the M types of private source codes into K=3*M types of private executable codes according to the three GPU version numbers.

[0221] For another example, taking the second parameter as the GPU version number and the OS version number, if there are 2 GPU version numbers on the market, namely version V1.0 and version V2.0, and 2 OS version numbers, namely version OS.1 and version OS.2, then the first device can compile a private source code into N=4 private executable codes according to the 2 GPU version numbers and the 2 OS version numbers, namely private executable code 1, private executable code 2, private executable code 3 and private executable code 4, wherein private executable code 1 is adapted to build version V1.0 and version OS.1. The first device can compile M private source code into K = 4 * M private executable codes based on two GPU versions and two OS versions.

[0222] In this embodiment, since different GPU version numbers and / or OS version numbers can build different operating environments, in order to compile the private source code into private executable code that can be applied to multiple operating environments, the first device can compile the private source code according to parameters such as the GPU version number to meet the requirements for private executable code in different operating environments.

[0223] Step 1003: The first device sends a target private executable code to the second device, where the target private executable code is one of the K types of private executable codes that is adapted to the operating environment of the second device.

[0224] For example, in some scenarios, the user triggers a download operation (or update operation) of an application on the second device. At this time, the second device needs to send a request message to the first device to request the first device to send the software installation package of the application or the download address of the software installation package of the application; after the first device receives the request message (for example, the second request message below) sent by the second device, it can send the corresponding target private executable code to the second device at the same time as sending the software installation package of the application to the second device, or send the download address of the corresponding target private executable code to the second device at the same time as sending the software installation package of the application to the second device, so that the second device can obtain the target private executable code according to the download address of the target private executable code. Optionally, after receiving the software installation package and the corresponding target private executable code, the second device can call the system interface to save the software installation package and the corresponding target private executable code in the file system module, delete the old private executable code, and release storage space.

[0225] In some other scenarios, if the second device has already installed an application X, the first device may periodically send the latest private executable code corresponding to application X (i.e., an example of the target private executable code) to the second device to ensure that the private executable code of application X stored on the second device is consistent with the latest private executable code on the first device.

[0226] In summary, in addition to determining the public source code from L types of shader source code, the first device can also determine M types of private source code from the L types of shader source code, and compile these M types of private source code to obtain K types of private executable code; the first device can send the target private executable code adapted to the operating environment of the second device to the second device, so that the second device can directly call the target public executable code and the target private executable code for image rendering during the rendering process, avoiding complex and time-consuming shader source code compilation, thereby further reducing the probability of frame loss and freezes during the picture rendering process, and optimizing the picture rendering performance.

[0227] Before step 1003, the method 600 further includes step 1004:

[0228] Step 1004: The first device receives second request information from the second device. Accordingly, the second device sends a second request message to the first device. The second request information is used to request downloading of a software installation package of a first application, where the first application is one of the L applications.

[0229] Among them, the second request information includes but is not limited to the first application identifier, the second device identifier and the second device parameters, wherein the first application identifier can be a string of characters (for example, XXX01, etc.) used to uniquely identify the first application; the first application identifier can be used to determine the software installation package of the first application and the corresponding private executable code; the second device identifier and the second device parameters here can refer to the relevant description of the second device identifier and the second device parameters in step 605 above, and will not be repeated here.

[0230] Since the K types of private executable codes are executable codes obtained by the first device after compiling the M types of private source codes, the first device can determine the N types of private executable codes corresponding to the first application from the K types of private executable codes based on the first application identifier; and the N types of private executable codes are compiled by the first device based on device parameters (such as a GPU version number, etc.), therefore, the first device can determine the target private executable code adapted to the second device operating environment from the N types of private executable codes based on the second device parameter (i.e., an example of the device parameter), wherein the second device operating environment can be determined based on the second device parameter; for example, the first application corresponds to N=2 types of private executable codes, wherein the first type of private executable code is obtained by compiling the private source code of the first application by the first device based on GPU version A; the second type of private executable code is obtained by compiling the private source code of the first application by the first device based on GPU version B; if the second device parameter is GPU version A, the first device can determine the first type of private executable code as the target private executable code from the two types of private executable codes based on GPU version A.

[0231] In some embodiments, the above step 1003 may also be implemented through step 1005:

[0232] Step 1005: The first device sends the software installation package of the first application and the corresponding target private executable code to the second device in response to the second request information.

[0233] After the first device receives the second request information, it can determine the target private executable code (for details, refer to the relevant description of step 1004) and the software installation package of the first application based on the second request information. For example, the first device can obtain the software installation package of the first application and the corresponding target private executable code based on the first application identifier, and send (or distribute) the target private executable code and the software installation package of the first application together to the second device. For another example, the first device can obtain the download address of the software installation package of the first application and the download address of the corresponding target private executable code based on the first application identifier, and send the download address to the second device so that the second device can obtain the software installation package of the first application and the corresponding target private executable code based on the download address. This method of distributing the target private executable code and the software installation package of the first application to the second device based on the second request information can avoid forcibly distributing data when the user does not have any demand, thereby affecting the user experience.

[0234] In some embodiments, the second request information includes a third parameter and a first application identifier, where the third parameter is used to determine the operating environment of the second device. Before step 1005, the method 600 further includes step 1006:

[0235] Step 1006: The first device determines a target private executable code from the K types of private executable codes according to the third parameter and the first application identifier.

[0236] The third parameter is an example of a device parameter, and includes at least one of the GPU version number of the second device or the OS version number of the second device. It should be noted that the third parameter may also include other parameters (e.g., device model, device system upgrade time, etc.), which are not limited in this application.

[0237] In some scenarios, the first device can quickly determine N types of private executable codes of the first application from K types of private executable codes based on the first application identifier; and the N types of private executable codes of the first application are executable codes compiled by the first device according to device parameters (for example, GPU version number, etc.); therefore, the first device can quickly determine the target private executable code (or the download address of the target private executable code) adapted to the second device from the N types of private executable codes based on the reported third parameter. For details, please refer to step 1004 about the method in which the first device determines the target private executable code based on the second device parameter (that is, the third parameter here), which will not be repeated here.

[0238] After determining the target private executable code, the first device may directly send the target private executable code to the second device, or send the download address of the target private executable code so that the second device can obtain the target private executable code according to the download address.

[0239] In a possible implementation, before the second device sends the second request information, the method 600 further includes:

[0240] Step 1007: The second device receives a first operation instruction, where the first operation instruction is used to trigger downloading of a software installation package of the first application.

[0241] Among them, the first operation instruction may refer to an operation instruction triggered by the user on an application interface of the second device. The first operation instruction may be an installation instruction or a download instruction, or may refer to an update instruction; wherein, the installation instruction is used to trigger the second device to perform download and installation operations; the download instruction is used to trigger the second device to perform a download operation; and the update instruction is used to trigger the second device to perform an update operation.

[0242] For example, the first operation instruction may be an operation instruction obtained by the second device from the display interface of the application market, or an operation instruction obtained by the second device from the display interface of the first application; wherein, the application market, which may also be referred to as an application store, is used to provide users with various software download, installation and update services to facilitate users to view information such as installed applications, applications to be updated, and download history; in addition, the application market will also display detailed application information, version descriptions, and update content, etc., to help users understand changes in the application and new features.

[0243] In some embodiments, step 1007 can also be implemented in the following two ways:

[0244] Method 1: The second device receives a first operation instruction from a display interface of an application market, the application market runs on the second device, and the first operation instruction is an installation instruction or an update instruction.

[0245] Among them, the first operation instruction is an installation instruction or an update instruction. For example, the user can select the application to be installed in the application market of the second device and trigger the installation operation; at this time, the second device can obtain the installation instruction from the display interface of the application market, and download the software installation package of the first application and the corresponding private executable code from the first device (for example, the server) according to the installation instruction.

[0246] For another example, the user can select the application that needs to be updated in the application market of the second device and trigger the update operation; at this time, the second device can obtain the update instruction from the display interface of the application market, and download the software upgrade package (also called software acceleration package) of the first application and the corresponding private executable code from the first device according to the update instruction.

[0247] For method 1, users can trigger installation instructions or update instructions on the display interface of the application market according to their needs to avoid automatically installing or updating applications that occupy a large amount of network traffic and cause additional traffic consumption.

[0248] Method 2: The second device receives a first operation instruction from the display interface of the first application, where the first operation instruction is an update instruction.

[0249] Since the first application has been installed on the second device, when a new version of the first application needs to be updated, the user can trigger the update operation on the display interface of the first application; accordingly, the second device can receive the update instruction from the display interface of the first application; for example, the user can trigger the operation of updating the first application on the first application. At this time, the second device can update the first application through the application market, or update the first application through the first application's own server; when the second device updates the first application through the application market, the application market can obtain the software upgrade package of the first application and the corresponding private executable code from the first device, and store the private executable code in the local file system module; and when the first application updates the first application through its own server, since its own server does not have the private executable code corresponding to the first application, the second device needs to instruct the application market to download the private executable code corresponding to the first application from the first device, so that the second device can promptly update the private executable code corresponding to the upgraded first application; it should be noted that when the second device updates the private executable code, it can delete the private executable code corresponding to the first application before the upgrade from the local.

[0250] From the above examples, it can be seen that users can trigger installation instructions or update instructions on the display interface of the application market according to their needs to avoid automatic installation or automatic update of applications occupying a large amount of network traffic, causing additional traffic consumption and local lag.

[0251] Step 1008: The second device generates second request information according to the first operation instruction.

[0252] After receiving the first operation instruction, the second device may generate second request information according to the content indicated by the first operation instruction. For a description of the second request information, please refer to the relevant description of step 1004 above and will not be repeated here.

[0253] In a possible implementation, before step 1008, the method 600 further includes step 1009;

[0254] Step 1009: The second device instructs the application market to generate second request information according to the first operation instruction, and the application market runs on the second device.

[0255] Because in some scenarios, when a user triggers an update from the display interface of an application (e.g., a first application), it may happen that the updated application does not update the previously stored private executable code; therefore, in order to ensure that the updated application can update the previously stored private executable code in a timely manner, when the user triggers an update from the display interface of the application, the second device will instruct the application market to generate a second request message according to the first operation instruction to control the application market to execute the update of the first application and the download of the corresponding target private executable code, so as to avoid the situation where the application update and the private executable code update do not match and affect the screen rendering performance. It can also be understood that regardless of whether the user triggers the first operation instruction on the display interface of the first application or on the display interface of the application market, the second device will launch the application market to execute the operation specified by the first operation instruction (e.g., installation operation, update operation or download operation, etc.); when the second device launches the application market, the application market will generate a second request message according to the first operation instruction to download or update the application (e.g., the first application) through the application market. By managing the installation or update of each application software on the second device through the application market, it can be ensured that the application market can obtain the corresponding target private executable code from the first device for the downloaded or updated application in a timely manner.

[0256] The following combination Figure 11 The following describes in detail the process of the second device launching the application market to perform the update operation; it should be noted that, Figure 11 In the example, the second device is mobile phone A (i.e., an example of the second device). Mobile phone A includes a storage kit located in the operating system. The storage kit acts as a bridge between various applications (e.g., game applications) and the application market, responsible for information exchange between the two parties. The second device can obtain the first operation instruction through the storage kit and use the storage kit to launch the application market to perform operations such as updates. The first application is a game application, and the game application and the application market run on the operating system of mobile phone A. The process for mobile phone A to launch the application market to perform an update operation is as follows:

[0257] 1) User-triggered update operation. After the user launches the game application, the user can trigger the update operation on the display interface of the game application. For example, the user can click an "update or upgrade" button on the display interface of the game application to trigger the second device to perform the update operation.

[0258] 2) The game application obtains an update instruction (ie, an example of the first operation instruction). When the user triggers the update operation, the game application obtains the update instruction corresponding to the update operation from the display interface.

[0259] 3) The game application submits an update task request. After receiving the update instruction, the game application sends an update task request to the checkAppUpdate interface of the storage suite.

[0260] 4) The storage suite launches the application market to execute the update task. After receiving the update task request by detecting the application update interface, the storage suite sends an update task instruction to the application market to instruct the application market to execute the update task of the game application.

[0261] 5) The application market sends an update request message. After receiving the update task instruction, the application market sends an update request message (i.e., an example of the second request information) to the cloud server. The update request message includes, but is not limited to, the game application identifier (i.e., an example of the first application identifier) ​​and the GPU version number (and / or OS version number).

[0262] 6) The cloud server determines the software upgrade package and the corresponding private executable code. After receiving the update request message, the cloud server determines the software upgrade package corresponding to the game application from the software upgrade packages of the multiple applications based on the game application identifier. Furthermore, the cloud server determines the N types of private executable code corresponding to the game application from the M types of private executable code based on the game application identifier. Furthermore, the cloud server determines the private executable code adapted for mobile phone A (i.e., an example of the target executable code) from the N types of private executable code based on the GPU version number (and / or OS version number).

[0263] 7) The cloud server sends the software upgrade package and the corresponding private executable code. After the cloud server determines the software upgrade package and the corresponding private executable code for the game application, it sends the software upgrade package and the corresponding private executable code to the application market.

[0264] 8) The App Market performs an update operation based on the software upgrade package and the corresponding private executable code. After receiving the software upgrade package and the corresponding private executable code, the App Market performs an update operation on the current game application based on the software upgrade package, i.e., the App Market automatically installs the software upgrade package. Furthermore, the App Market updates the private executable code sent by the cloud server to the file system module of mobile phone A and deletes the old version of the private executable code previously stored in the file system module.

[0265] The method 600 is introduced in detail above. Now, in combination with the interface embodiment, taking the first device as a cloud server and the second device as a mobile phone as an example, the application of the method 600 in different application scenarios is briefly introduced.

[0266] Example 1: Application installation scenario

[0267] In some embodiments, the user can install the application that needs to be used through the application market. For example, take the example of a user installing XX game application (i.e., an example of the first application) from the application market. Figure 12A As shown, the mobile phone has installed applications such as video, application market, and browser; the user can double-click the application market shortcut icon 1201 on the main interface of the mobile phone; at this time, the mobile phone enters the application market recommendation interface 1202, and the user can click the installation button 1203 of XX game on the recommendation interface 1202 to trigger the installation operation of XX game, such as Figure 12B As shown; after the mobile phone receives the installation instruction corresponding to the installation operation (i.e., an example of the first operation instruction) from the recommendation interface 1202, it responds to the installation instruction and obtains the software installation package of the XX game from the cloud server (i.e., an example of the first device), and performs the download and installation operations. For details, please refer to the relevant description of the above method 1; in addition, the user can see the download status 1204 of the XX game during the download process, as shown in FIG. Figure 12C When the application market downloads the software installation package of the XX game, the software installation package will be automatically installed; after the installation is complete, the status of the XX game on the recommendation interface 1202 changes to the open state 1205, and the user can start the XX application by clicking the open state 1205 button, such as Figure 12D As shown; at the same time, after the installation is complete, as shown Figure 13A As shown, a shortcut icon 1301 of the XX game is generated on the main interface of the mobile phone, and the user can start the XX application by double-clicking the shortcut icon 1301.

[0268] Example 2: Application-side update scenario

[0269] In some embodiments, the user can trigger an application update on the application side; for example, taking the example of a user triggering a self-update from a video application (ie, an example of a first application), as shown in FIG. Figure 13B As shown, the user can double-click the shortcut icon 1302 of the video application on the main interface of the mobile phone; at this time, the mobile phone enters the user interface 1303 of the video application, and the user can select the video to be watched on the user interface 1303; when a new version of the video application is released, the video application can generate an update reminder message on the user interface 1303; for example, Figure 13C As shown, when a new version of the video application is released, the video application can generate an update reminder interface 1304 on the user interface 1303; the user can select the "Update Now 1305" option on the update reminder interface 1304 to trigger the video application to self-update; at this time, an upgrade setting interface 1306 is generated on the user interface 1303, as shown in FIG. Figure 13D shown.

[0270] It should be noted that there are two ways for video applications to perform self-updates: the first is to perform updates through the video application's own server; the second is to perform self-updates through the application market; for the first method, such as Figure 13D As shown, the user can select the option "Do not allow the use of the application market for upgrades 1307" on the upgrade setting interface 1306; at this time, the video application will self-update in the background, that is, the video application downloads the software upgrade package from its own application server and automatically installs the software upgrade package; at this time, the user can see the status indicator 1401 of the background updating on the user interface 1303, as shown in FIG. Figure 14A As shown; since the application (for example, video application, etc.) does not have the private executable code corresponding to the new version of the application (for example, version 6.1.2.3A of the video application) on its own server, for the case of self-update on the application side, the application market needs to monitor the update status of each application in order to timely update the private executable code previously stored by each application.

[0271] For example, when the application market detects an update to a video application, the application market can download the private executable code corresponding to the new version of the video application from the cloud server (i.e., an example of the first device). Specifically, the application market can send a request message X to the cloud server, where the request message X is used to request the cloud server to issue the private executable code corresponding to the new version of the video application. The request message X includes, but is not limited to, a video application identifier and device parameters of the mobile phone (e.g., a GPU version number and / or an OS version number). The cloud server can determine the private executable code corresponding to the video application (i.e., an example of the target private executable code) or the download address of the private executable code based on the video application identifier (i.e., an example of the first application identifier) ​​and the device parameters of the mobile phone (i.e., an example of the third parameter). For details, please refer to the relevant description of step 1006 above, which will not be repeated here.

[0272] For the second type, Figure 14B As shown, the user can select the option "Always allow using the application market for upgrades 1402" on the upgrade setting interface 1306. At this time, the mobile phone will jump from the video application to Figure 14C The application update interface 1403 shown; the user can click the update button 1404 of the video application on the application update interface 1403 to trigger the update operation of the video application, such as Figure 14C At this time, the user can see that the update button of the video application has changed to the status indicator of "download progress 1405", as shown. Figure 14DAs shown; at this time, the application market downloads the software upgrade package of the new version of the video application and the corresponding private executable code from the cloud server; specifically, the application market can send a request message Y to the cloud server, and the request message Y is used to request the cloud server to send the software upgrade package of the new version of the video application and the corresponding private executable code, and the request message Y includes but is not limited to the video application identifier and the device parameters of the mobile phone (for example, the GPU version number and / or the OS version number); the cloud server can determine the software upgrade package of the new version of the video application (or the download address of the software upgrade package) and the corresponding private executable code (or the download address of the private executable code) based on the video application identifier and the device parameters of the mobile phone. For details, please refer to the relevant description of step 1006 above, which will not be repeated here.

[0273] After the cloud server has determined the software upgrade package of the new version of the video application and the corresponding private executable code, it can be Figure 5B The distribution module sends the software upgrade package and the corresponding private executable code to the application market; after receiving the software upgrade package and the corresponding private executable code, the application market will automatically install the software upgrade package and update the old private executable code stored in the local file system module with the corresponding private executable code; after the installation is completed, the status of the video application on the application update interface 1403 changes from the update button to the open button 1501; the user can start the updated video application by clicking the open button 1501, as shown in FIG. Figure 15A At the same time, after the installation is complete, the main interface of the phone will generate a new version of the video application shortcut icon 1502, the user can double-click the shortcut icon 1502 to start the video application, such as Figure 15B shown.

[0274] In some other embodiments, for example, Figure 15C As shown, when the user selects the "Do not update 1503" option on the update reminder interface 1304, it means that the user may not want to upgrade temporarily; at this time, Figure 15D As shown, a pause update setting interface 1504 is generated on the user interface 1303, and the user can set the desired pause duration or set the desired update time on the pause update setting interface 1504; for example, Figure 15DAs shown, when the user selects the "Pause duration 1505" option, the user can set how long the pause should be. For example, if the current date is "June 20, xxxx", the user can choose to pause until "July 5, xxxx"; the maximum pause duration that can be set for the "Pause duration 1505" option is 30 days; when the pause time limit is reached, the video application will automatically update; the automatic update method can default to the "first" (or "second") method mentioned above. For another example, when the user selects the "Update time setting 1506" option, the user can set the time period in which the update should be performed. For example, the automatic update can be set between "18:00 and 20:00 on July 1, xxxx"; the automatic update method of the video application can default to the "first" (or "second") method mentioned above.

[0275] In other embodiments, users can set the update of the video application themselves. Figure 16A As shown, the user can click the "Personal Center 1601" option on the user interface 1303 of the video application. At this time, the mobile phone jumps from the user interface 1303 to the personal center interface 1602, as shown in FIG. Figure 16A As shown; the user can select the "Latest Upgrade 1603" option on the personal center interface 1602, at this time, the "Latest Version Information" prompt box 1604 will pop up on the personal center interface 1602, as shown Figure 16C As shown; the user can select the "upgrade now 1605" option on the prompt box 1604, or select the "update settings 1606" option; if the user selects the "upgrade now 1605" option, the personal center interface 1602 will appear and Figure 13D The same upgrade settings interface 1306; please refer to Figure 13D as well as 14A to 14D If the user selects the "Update Settings 1606" option, the personal center interface 1602 will generate Figure 16D The update setting interface 1607 shown in the figure; the user can set the update method on the "update setting interface 1607", for example, if the user selects the "automatic update 1608" option, the next time a new version of the video application is released, it will be automatically updated without asking the user whether to update immediately; if the user selects the "ask whether to update 1609" option, the next time a new version of the video application is released, the user will be asked whether to update first, and will not be automatically updated. Figure 16D shown.

[0276] Implementation 3: Application Market Update Scenario

[0277] In some embodiments, users can update the current application through the application market. Figure 12AAs shown, the user can double-click the application market shortcut icon 1201 on the main interface of the mobile phone to enter the application market recommendation interface 1202; after the mobile phone enters the recommendation interface 1202, as shown in FIG. Figure 17A As shown, the user can click the "My" option 1701 on the recommendation interface 1202 to open the "My" main interface 1702 (see Figure 17B ); At this time, the user can select the "Application Update 1703" option on the "My" main interface 1702, so that the mobile phone jumps from the "My" main interface 1702 to the "Application Update Interface 1403", and the user can select the application to be updated on the Application Update Interface 1403, such as Figure 17C As shown; for example, the user can click the "Update 1704" button of the video application to trigger the update operation, such as Figure 17C At this time, the user can see that the update button 1704 of the video application has changed to a status indicator of "download progress 1705", as shown. Figure 17D As shown; at this time, the application market downloads the software upgrade package of the new version of the video application and the corresponding private executable code from the cloud server. For details, please refer to the relevant description of the "second" automatic update method in the second embodiment above, which will not be repeated here. After the application market receives the software upgrade package and the corresponding private executable code issued by the cloud server, it will automatically install the software upgrade package and use the issued private executable code to update the old private executable code stored in the local file system module; after the installation is completed, as shown Figure 18A As shown, the status of the video application on the application update interface 1403 changes from an update button to an open button 1801; the user can start the updated video application by clicking the "open button 1801".

[0278] Example 4: Downloading methods of public executable code and private executable code

[0279] In some embodiments, as Figure 18B As shown, the user can select the "Public Acceleration Package Download 1802" option on the "My" main interface 1702; at this time, as shown in FIG. Figure 18C As shown, the application market generates a "public acceleration package update method" setting interface 1803 on the "My" main interface 1702; the user can select the public acceleration package update method on the setting interface 1803, for example, Figure 18CAs shown, if the user selects the "Check for updates 1804" option, the App Market will obtain the public executable code from the cloud server when it detects that there is an application update on the phone (for example, it will call the cloud server interface to query the download address of the public executable code to download the public executable code) to ensure that the public executable code stored in the local file system module is consistent with the latest public executable code on the cloud server. If the user selects the "Default update 1805" option, the App Market will obtain the public executable code from the cloud server according to the system-set time interval (that is, the App Market will obtain the public executable code from the cloud server within the preset time period).

[0280] For example, Figure 18B As shown, the user can select the "Private Acceleration Package Download 1806" option on the "My" main interface 1702. At this time, the application market jumps from the "My" main interface 1702 to Figure 18D The "Private Acceleration Package" download interface 1807 is shown; the user can select the private acceleration package corresponding to the application to be downloaded on the download interface 1807; for example, Figure 18D As shown, the user can click the "download button 1808" corresponding to the "video application"; at this time, after the application market receives the download instruction corresponding to the download operation, it will obtain the private executable code corresponding to the video application from the cloud server to ensure that the private executable code of the video application stored in the local file system module is consistent with the private executable code corresponding to the latest video application on the cloud server; specifically, the application market can send a request message Z to the cloud server, and the request message Z is used to request the cloud server to issue the private executable code corresponding to the new version of the video application. The request message Y includes but is not limited to the video application identifier and the device parameters of the mobile phone (for example, the GPU version number and / or the OS version number); the cloud server can determine the private executable code corresponding to the new version of the video application (or the download address of the private executable code) based on the video application identifier (i.e., an example of the first application identifier) ​​and the device parameters of the mobile phone (i.e., an example of the third parameter), and issue the private executable code (or the download address of the private executable code) to the application market. For details, please refer to the relevant description of step 1006 above, which will not be repeated here.

[0281] The above details examples of the compilation method provided by this application. It is understood that, in order to implement the aforementioned functions, the electronic device includes hardware structures and / or software modules corresponding to the respective functions. Those skilled in the art will readily appreciate that, in conjunction with the units and algorithmic steps of the various examples described in the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application. This application may divide the compilation method into functional units based on the aforementioned method examples. For example, each function may be divided into separate functional units, or two or more functions may be integrated into a single unit. The integrated units may be implemented in either hardware or software functional units. It should be noted that the division of units in this application is illustrative and represents only one logical functional division; other divisions may be used in actual implementation.

[0282] Figure 19 A schematic structural diagram of an electronic device provided by the present application is shown. Figure 19 The dashed line indicates that the unit or module is optional. The electronic device 1900 can be used to implement the method described in the above method embodiment. The electronic device 1900 can be a server, a terminal device, or a chip (system).

[0283] The electronic device 1900 includes one or more processors 1901, which can support the electronic device 1900 to implement Figure 6 The method in the corresponding method embodiment. Processor 1901 can be a general-purpose processor or a special-purpose processor. For example, processor 1901 can be a central processing unit (CPU). The CPU can be used to control electronic device 1900, execute software programs, and process data of software programs. Electronic device 1900 can also include a communication unit 1905 to implement signal input (reception) and output (transmission).

[0284] The electronic device 1900 may be a chip (system) including a memory and a processor, wherein the processor is configured to execute a computer program stored in the memory to implement the methods shown in the above embodiments.

[0285] The communication unit 1905 may be an input and / or output circuit of the chip (system), or the communication unit 1905 may be a communication interface of the chip (system), and the chip (system) may be a component of the electronic device 1900 .

[0286] For another example, the communication unit 1905 may be a transceiver of the electronic device 1900, or the communication unit 1905 may be a transceiver circuit of the electronic device 1900. The electronic device 1900 may include one or more memories 1902, on which a program 1904 is stored. The program 1904 can be executed by the processor 1901 to generate instructions 1903, so that the processor 1901 performs the method described in the above method embodiment according to the instructions 1903. Optionally, data may also be stored in the memory 1902. Optionally, the processor 1901 may also read data stored in the memory 1902. The data may be stored at the same storage address as the program 1904, or the data may be stored at a different storage address than the program 1904.

[0287] The processor 1901 and the memory 1902 may be provided separately or integrated together, for example, integrated on a system on chip (SOC) of an electronic device. The specific manner in which the processor 1901 executes the compilation method may refer to the relevant description in the method embodiment.

[0288] It should be understood that each step of the above method embodiment can be completed by hardware logic circuits or software instructions in the processor 1901. The processor 1901 can be a CPU, a digital signal processor (DSP), a field programmable gate array (FPGA), or other programmable logic devices, such as discrete gates, transistor logic devices, or discrete hardware components.

[0289] The present application also provides a computer program product that, when executed by a processor 1901, implements any method embodiment of the present application. The computer program product may be stored in a memory 1902, for example, a program 1904. The program 1904 undergoes preprocessing, compilation, assembly, and linking to be converted into an executable object file that can be executed by the processor 1901.

[0290] The present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a computer, implements any method embodiment of the present application. The computer program may be a high-level language program or an executable target program.

[0291] The computer-readable storage medium is, for example, memory 1902. Memory 1902 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM).

[0292] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and equipment and the technical effects produced can refer to the corresponding processes and technical effects in the aforementioned method embodiments, and will not be repeated here.

[0293] In several embodiments provided in this application, the disclosed systems, devices, and methods can be implemented in other ways. For example, some features of the method embodiments described above can be ignored or not executed. The device embodiments described above are merely schematic, and the splitting of units is only a logical function splitting. There may be other splitting methods in actual implementation, and multiple units or components may be combined or integrated into another system. In addition, the coupling between the units or the coupling between the components may be direct coupling or indirect coupling, and the above coupling includes electrical, mechanical or other forms of connection.

[0294] The above embodiments are intended only to illustrate the technical solutions of the present application and are not intended to limit the same. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they may still modify the technical solutions described in the above embodiments or replace some of the technical features therein with equivalents, and that such modifications or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present application and are therefore intended to be included within the scope of protection of the present application.

[0295] Finally, the above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be covered by the scope of protection of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection of the claims.

Claims

1. A compilation method, characterized in that: Applied to a first device, the method includes: Obtain L shader source codes, where the L shader source codes are source codes corresponding to L applied shaders, and L is an integer greater than 1; Determine a common source code from the L shader source codes, where the common source code is a common part among the L shader source codes; Compiling the public source code to obtain N public executable codes, wherein the N public executable codes are used to adapt to N operating environments, where N is a positive integer; A target public executable code is sent to the second device, where the target public executable code is one of the N public executable codes that is adapted to the operating environment of the second device.

2. The method according to claim 1, characterized in that The method further comprises: Determining M types of private source codes from the L types of shader source codes, where the M types of private source codes are parts of the L types of shader source codes excluding the public source codes, and M is a positive integer less than or equal to L; Compiling the M types of private source codes respectively to obtain K types of private executable codes, wherein the K types of private executable codes are used to adapt to the N types of operating environments, where K=M*N, and K is a positive integer; Sending a target private executable code to the second device, where the target private executable code is one of the K types of private executable codes that is adapted to the operating environment of the second device.

3. The method according to claim 1 or 2, characterized in that The obtaining of L shader source codes includes: The L shader source codes are obtained from at least one terminal device, where the at least one terminal device is used to run the L applications.

4. The method according to claim 3, characterized in that The obtaining of the L types of shader source codes from at least one terminal device includes: The L types of shader source codes are obtained from a shader of the at least one terminal device, where the operating mode of the shader is a debug mode.

5. The method according to claim 4, characterized in that The first device includes an acquisition module, the acquisition module is used to obtain shader source code, and the obtaining of the L types of shader source code from the shader of at least one terminal device includes: The L types of shader source codes are obtained from the shader of the at least one terminal device through the acquisition module, and the operating mode of the shader is a debugging mode.

6. The method according to claim 3, characterized in that The first device includes an acquisition module, the acquisition module is used to obtain shader source code, and the obtaining of the L types of shader source code from at least one terminal device includes: The L types of shader source codes are obtained from the at least one terminal device through the acquisition module.

7. The method according to any one of claims 2 to 6, characterized in that The determining of M types of private source codes from the L types of shader source codes includes: M types of private source codes are determined from the L types of shader source codes according to a first parameter, where the first parameter includes usage frequency information, and the M type is smaller than the L type.

8. The method according to any one of claims 1 to 7, characterized in that Determining a common source code from the L types of shader source codes includes: A common source code is determined from the L types of shader source codes according to a first parameter, where the first parameter includes usage frequency information.

9. The method according to any one of claims 2 to 8, characterized in that Compiling the M types of private source codes separately includes: The M types of private source codes are respectively compiled according to a second parameter, where the second parameter includes at least one of a GPU version number or an OS version number.

10. The method according to any one of claims 1 to 9, characterized in that The compiling of the public source code includes: The public source code is compiled according to a second parameter, where the second parameter includes at least one of a graphics processing unit (GPU) version number or an operating system (OS) version number.

11. The method according to any one of claims 2 to 10, characterized in that Before sending the target private executable code to the second device, the method further includes: receiving a second request message from the second device, where the second request message is used to request downloading a software installation package of a first application, where the first application is one of the L applications; The sending the target private executable code to the second device includes: In response to the second request information, the software installation package of the first application and the target private executable code are sent to the second device.

12. The method according to claim 11, characterized in that The second request information includes a third parameter and a first application identifier, the third parameter being used to determine an operating environment of the second device. Before sending the software installation package of the first application and the target private executable code to the second device, the method further includes: The target private executable code is determined from the K types of private executable codes according to the third parameter and the first application identifier.

13. The method according to any one of claims 1 to 12, characterized in that Before sending the target public executable code to the second device, the method further includes: receiving first request information from the second device, where the first request information is used to request acquisition of the target public executable code; The sending the target public executable code to the second device includes: In response to the first request information, the target public executable code is sent to the second device.

14. The method according to claim 13, characterized in that The receiving first request information from the second device includes: Within a preset time period, the first request information is received from the second device.

15. The method according to claim 13 or 14, characterized in that The first request information includes a third parameter, and the third parameter is used to determine the operating environment of the second device; Before sending the target public executable code to the second device, the method further includes: The target public executable code is determined from the N types of public executable codes according to the third parameter.

16. The method according to claim 12 or 15, characterized in that The third parameter includes: at least one of a GPU version number of the second device or an OS version number of the second device.

17. A compilation method, characterized in that: Applied to the second device, the method includes: Sending a first request message, where the first request message is used to request acquisition of a target public executable code, where the target public executable code is one of N public executable codes that is adapted to the operating environment of the second device, where the N public executable codes are compiled results of public source code, where the public source code is a common portion of L shader source codes, where the L shader source codes are source code corresponding to shaders of L applications, where L is an integer greater than 1, and N is a positive integer; The target public executable code is received.

18. The method according to claim 17, characterized in that The sending of the first request information includes: The first request information is sent within a preset time period.

19. The method according to claim 17 or 18, characterized in that The first request information includes a third parameter, and the third parameter is used to determine the operating environment of the second device and is also used to determine the target public executable code.

20. The method according to any one of claims 17 to 19, characterized in that The method further comprises: Sending a second request message, where the second request message is used to request downloading a software installation package of a first application, where the first application is one of the L applications; Receive a software installation package of the first application and the target private executable code.

21. The method according to claim 20, characterized in that The second request information includes a third parameter and a first application identifier, the third parameter is used to determine the operating environment of the second device, and the third parameter and the first application identifier are used to determine the target private executable code.

22. The method according to claim 19 or 21, characterized in that The third parameter includes: at least one of a GPU version number of the second device or an OS version number of the second device.

23. The method according to any one of claims 20 to 22, characterized in that Before sending the second request information, the method further includes: receiving a first operation instruction, where the first operation instruction is used to trigger downloading of a software installation package of the first application; The second request information is generated according to the first operation instruction.

24. The method according to claim 23, wherein The receiving of the first operation instruction includes: The first operation instruction is received from a display interface of an application market, where the application market runs on the second device, and the first operation instruction is an installation instruction or an update instruction.

25. The method according to claim 24, characterized in that The receiving of the first operation instruction includes: The first operation instruction is received from the display interface of the first application, where the first operation instruction is an update instruction.

26. The method according to any one of claims 23 to 25, characterized in that Before generating the second request information according to the first operation instruction, the method further includes: The application market is instructed to generate the second request information according to the first operation instruction, and the application market runs on the second device.

27. An electronic device, characterized in that: The electronic device includes a processor and a memory, the memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, so that the electronic device executes the method described in any one of claims 1 to 16, or the electronic device executes the method described in any one of claims 17 to 26.

28. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, enables the processor to execute the method according to any one of claims 1 to 16, or enables the processor to execute the method according to any one of claims 17 to 26.

29. A chip system, characterized in that: The chip system includes a memory and a processor, and the processor is configured to execute a computer program stored in the memory to implement the method as claimed in any one of claims 1 to 16, or to implement the method as claimed in any one of claims 17 to 26.

Images