Compiling method, electronic device and computer readable storage medium

Abstract

Provided are a compiling method, an electronic device, and a computer readable storage medium. The method comprises: acquiring L shader source codes, wherein the L shader source codes are source codes corresponding to shaders of L applications, and L is an integer greater than 1; determining a common source code from among the L shader source codes, the common source code being the part common to the L shader source codes; compiling the common source code to obtain N common executable codes, wherein the N common executable codes are used for adapting to N operating environments, and N is a positive integer; and sending a target common executable code to a second device, the target common executable code being one of the N common executable codes adapted to the operating environment of the second device. The method can reduce the probability of frame loss and stuttering during picture rendering, and is beneficial to optimizing picture rendering performance.

Description

Compilation method, electronic device and computer readable storage medium

[0001] The present application claims priority to the Chinese patent application No. 202410775688.4, filed on June 14, 2024, and entitled "Compilation method, electronic device and computer readable storage medium", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the technical field of terminals, and in particular to a compilation method, an electronic device and a computer readable storage medium. BACKGROUND

[0003] With the development of image processing technology, shaders are commonly used for image rendering and visual effects in fields such as game development, graphic design, film and animation production. It is a small program running on a graphics processing unit (GPU) that controls various stages of the image rendering process, such as color, texture coordinate, lighting, etc.

[0004] For some applications that require picture rendering (such as games, videos, etc.), the user usually downloads the software installation package of these applications from the application market, which usually includes shader source code; when these applications are installed on the terminal device, the user can normally start these applications. Since the shader source code cannot be directly run on the GPU hardware, the terminal device needs to compile the shader source code into machine code programs executable on the GPU (i.e. executable code or executable instructions) during the running process of these applications, so that the shader can realize the function of image rendering.

[0005] However, as the requirements for picture smoothness, picture clarity and picture realism of some scenes (such as games, animations, etc.) become higher and higher, the complex and time-consuming compilation of shader source code may cause frame loss and lag in the picture rendering process; for example, a game application that requires a frame rate of 60 frames (i.e. 60 frames per second) has an average frame rendering time of only 16.6 milliseconds (ms), while the compilation of shader source code sometimes takes tens to hundreds of milliseconds. This time-consuming compilation process often causes picture frame loss and lag during game running. SUMMARY

[0006] 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 lag in the picture rendering process, and is beneficial to optimize the picture rendering performance.

[0007] To achieve the above object, the application adopts the following technical solutions:

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

[0009] obtaining L kinds of shader source codes, the L kinds of shader source codes being source codes corresponding to L applied shaders, L being an integer greater than 1; determining a common source code from the L kinds of shader source codes, the common source code being a part common in the L kinds of shader source codes; compiling the common source code to obtain N kinds of common executable codes, the N kinds of common executable codes being used to adapt to N running environments, N being a positive integer; and sending a target common executable code to a second device, the target common executable code being one of the N kinds of common executable codes adapted to a running environment of the second device.

[0010] The first device can refer to a server, and the compiling method can be executed by the server, or by a module (such as a processor, a chip, or a chip system, etc.) applied to the server, or by a logic module or software capable of realizing all or part of the functions of the server.

[0011] In the picture rendering process, one processing method is to compile while rendering, and this method often causes frame loss and lag. In the present application, the first device can determine the common source code from the L kinds of shader source codes and compile the common source code; finally, the target common executable code adapted to the running environment of the second device is sent to the second device, and the second device can directly call the common executable code when performing the rendering operation, without the need to compile the common source code part, thereby reducing the amount of compilation in the image rendering process, reducing the probability of frame loss and lag in the picture rendering process, and optimizing the picture rendering performance.

[0012] In a possible implementation, the above method further comprises: determining M kinds of private source codes from the L kinds of shader source codes, the M kinds of private source codes being parts of the L kinds of shader source codes other than the common source code, M being a positive integer less than or equal to L; compiling the M kinds of private source codes respectively to obtain K kinds of private executable codes, the K kinds of private executable codes being used to adapt to the N running environments, K = M*N, K being a positive integer; and sending a target private executable code to the second device, the target private executable code being one of the K kinds of private executable codes adapted to the running environment of the second device.

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

[0014] In a possible implementation, the L kinds of shader source codes are obtained by: obtaining the L kinds of shader source codes from at least one terminal device, the at least one terminal device being configured to run the L applications.

[0015] Since the L applications are running on the terminal device, the terminal device can detect the corresponding shader source code in the execution of the image rendering process of each application, and therefore the first device can obtain the L kinds of shader source codes through the at least one terminal device.

[0016] In a possible implementation, the L kinds of shader source codes are obtained from the at least one terminal device, including: obtaining the L kinds of shader source codes from a shader of the at least one terminal device, the running mode of the shader being a debugging mode.

[0017] In some scenarios, the terminal device can obtain the shader source code through the shader of the terminal device; for example, when the application is running, the terminal device can set the running mode of the shader to the debugging mode to obtain the L kinds of shader source codes, without the need to design a special source code detection module, which can reduce the source code acquisition cost.

[0018] In a possible implementation, the first device includes a collection module configured to obtain the shader source code, and the collection module obtains the L kinds of shader source codes from the shader of the at least one terminal device, including: the collection module obtains the L kinds of shader source codes from the shader of the at least one terminal device, the running mode of the shader being a debugging mode.

[0019] In some scenarios, the first device obtains the L kinds of shader source codes from the shader of the at least one terminal device through the collection module, without the need for manual collection of the L kinds of shader source codes or the need to design a special source code detection module, and this source code acquisition method is efficient, convenient and low in cost.

[0020] In a possible implementation, the first device comprises a collection module, and the collection module is configured to obtain the L pieces of shader source code from the at least one terminal device, including: obtaining, by the collection module, the L pieces of shader source code from the at least one terminal device.

[0021] In some scenarios, compared with manually collecting the L pieces of shader source code, the first device automatically obtains the L pieces of shader source code from the at least one terminal device through the collection module, which is simple, efficient and low in cost.

[0022] In a possible implementation, the M pieces of private source code are determined from the L pieces of shader source code according to a first parameter, and the first parameter comprises usage frequency information, and M is less than L.

[0023] In some scenarios, in order to improve the usage rate of the private executable code, the first device can exclude private source code corresponding to some applications that are not frequently used from the L pieces of shader source code according to the first parameter, and retain M pieces of private source code corresponding to frequently used applications (that is, the M pieces of private source code), so as to ensure that the private executable code obtained by compiling the M pieces of private source code has a high usage rate.

[0024] In a possible implementation, the common source code is determined from the L pieces of shader source code according to a first parameter, and the first parameter comprises usage frequency information.

[0025] In some scenarios, in order to ensure that the common source code determined from the L pieces of shader source code is extensive, the application screens, through the first parameter (such as usage frequency information), the shader source code with a high calling (or usage) frequency from the L pieces of shader source code as the common source code, so that the common executable code obtained by compiling the common source code can be called by multiple applications, thereby reducing the probability of frame loss and lag in the picture rendering process of more applications.

[0026] In a possible implementation, the M pieces of private source code are compiled respectively according to a second parameter, and the second parameter comprises at least one of a GPU version number or an OS version number.

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

[0028] In a possible implementation, the compiling of the common source code comprises: compiling the common source code according to a second parameter, the second parameter comprising at least one of a GPU version number or an OS version number.

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

[0030] In a possible implementation, before the target private executable code is sent to the second device, the method further comprises: receiving second request information from the second device, the second request information being used to request to download a software installation package of a first application, the first application being one of the L applications; and sending, to the second device, the target private executable code comprises: in response to the second request information, sending, to the second device, the software installation package of the first application and the corresponding target private executable code.

[0031] In some scenarios, the first device can deliver the target private executable code to the second device together with the software installation package of the first application according to the second request information, thereby avoiding forcibly delivering data to the second device in the case that the user has no demand, and affecting the user experience.

[0032] In a possible implementation, the second request information comprises a third parameter and a first application identifier, the third parameter being used to determine a running environment of the second device, and before the software installation package of the first application and the corresponding target private executable code are sent to the second device, the method further comprises: determining the target private executable code from the K private executable codes according to the third parameter and the first application identifier.

[0033] Since the K private executable codes are executable codes corresponding to the M applications and capable of adapting to the N running environments, the first device can quickly determine the N private executable codes corresponding to the first application from the K private executable codes according to the first application identifier, and quickly determine the target private executable code that adapts to the running environment of the second device from the N private executable codes according to the third parameter.

[0034] In a possible implementation, before the target common executable code is sent to the second device, the method further comprises: receiving first request information from the second device, the first request information being used to request to obtain the target common executable code; and sending, to the second device, the target common executable code comprises: in response to the first request information, sending, to the second device, the target common executable code.

[0035] In some scenarios, the first device can send the target public executable code to the second device according to the first request information, so as to avoid forcibly issuing data and affecting user experience in the case where the user has no demand.

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

[0037] In some scenarios, the first device can receive the first request information from the second device within a preset time period (for example, at intervals), and issue the target public executable code to the second device at intervals, so as to ensure that the public executable code currently stored by the second device is consistent with the latest public executable code of the first device.

[0038] In a possible implementation, the first request information comprises a third parameter, the third parameter being used to determine the running environment of the second device; and before the target public executable code is sent to the second device, the method further comprises: determining the target public executable code from the N public executable codes according to the third parameter.

[0039] Since the running environments of different devices can be different, the second device can report the third parameter to the first device through the first request information, so that the first device determines the target public executable code that is adapted to the running environment of the second device from the N public executable codes according to the third parameter, thereby avoiding issuing an executable code that does not match the running environment of the device by mistake.

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

[0041] Since the K private executable codes are private executable codes compiled by the first device according to the GPU version number and the like, the third parameter is beneficial for the first device to quickly determine the target private executable code that is adapted to the second device from the K private executable codes.

[0042] In a second aspect, another compiling method is provided, and the method is applied to a second device, and the method comprises:

[0043] sending first request information, the first request information being used to request to obtain a target public executable code, the target public executable code being one of N public executable codes that is adapted to a running environment of the second device, the N public executable codes being a compiling result of a public source code, the public source code being a part that is common in L shader source codes, the L shader source codes being source codes corresponding to shaders of L applications, L being an integer greater than 1, and N being a positive integer; and receiving the target public executable code.

[0044] The second device can refer to a terminal device, the compiling method can be executed by the terminal device, or can be executed by a module (for example, a processor, a chip, or a chip system, etc.) applied in the terminal device, and can also be implemented by a logic module or software capable of implementing all or part of the functions of the terminal device.

[0045] In the above method, the second device can send the first request information 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 compilation amount of the source code, reducing the probability of frame loss and lag in the picture rendering process, and optimizing the picture rendering performance.

[0046] In a possible implementation, the sending of the first request information comprises: sending the first request information within a preset time period.

[0047] In some scenarios, the second device can send the first request information to the first device within a preset time period (for example, at intervals), and receive the target public executable code from the first device, so as to ensure that the local public executable code is always consistent with the current latest public executable code of the first device.

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

[0049] Since the running environments of different devices can be different, the second device can report the third parameter to the first device through the first request information, so that the first device determines the target public executable code that matches the running environment of the second device from the N public executable codes according to the third parameter, thereby avoiding the error delivery of the executable code that does not match the running environment of the device.

[0050] In a possible implementation, the above method further comprises: sending second request information, the second request information being used to request to download a software installation package of the first application, the first application being one of the L applications; and receiving the software installation package of the first application and the target private executable code.

[0051] In some scenarios, the first device can deliver the target private executable code and the software installation package of the first application to the second device according to the second request information, thereby avoiding the forced delivery of data in the case where the user has no demand, and affecting the user experience.

[0052] In a possible implementation, the second request information comprises a third parameter and a first application identifier, the third parameter being used to determine the running environment of the second device, and the third parameter and the first application identifier being used to determine the target private executable code.

[0053] Since the K private executable codes are executable codes corresponding to the M applications and adapted to the N running environments, therefore, the first device can quickly determine the N private executable codes corresponding to the first application from the K private executable codes according to the first application identifier, and quickly determine the target private executable code adapted to the running environment of the second device from the N private executable codes according to the third parameter.

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

[0055] Since the K private executable codes are executable codes compiled by the first device according to the device parameters (such as the GPU version number, etc.), therefore, the third parameter is beneficial for the first device to quickly determine the target private executable code adapted to the second device from the K private executable codes.

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

[0057] In a possible implementation, the first operation instruction is received, including: receiving the first operation instruction from a display interface of an application market, the application market running on the second device, and the first operation instruction being an installation instruction or an update instruction.

[0058] In some cases, the user can trigger the installation instruction or the update instruction on the display interface of the application market according to the own demand, so as to avoid the case that automatic installation or automatic update of the application occupies a large amount of network traffic, causes additional traffic consumption, and causes the local to be stuck.

[0059] In a possible implementation, the first operation instruction is received, including: receiving the first operation instruction from a display interface of the first application, and the first operation instruction being an update instruction.

[0060] In some cases, the user can trigger the update instruction on the display interface of the first application according to the own demand, so as to avoid the case that automatic update of the application occupies a large amount of network traffic, causes additional traffic consumption, and causes the local to be stuck.

[0061] In a possible implementation, before the second request information is generated 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, the application market running on the second device.

[0062] In some scenarios, the user triggers the update from the display interface of the application (for example, the first application), and the updated application can not update the previously stored private executable code. In order to ensure that the updated application can update the previously stored private executable code in time, although the user triggers the update from the display interface of the application, the second device still generates the second request information according to the first operation instruction to instruct the application market to control the application market to perform the update of the first application and the download of the corresponding target private executable code, so as to avoid the case that the application update and the private executable code update do not match, and the picture rendering performance is affected.

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

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

[0065] In a fifth aspect, an embodiment of the present application provides a computer readable storage medium, the computer readable storage medium storing a computer program, and 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.

[0066] In a sixth aspect, an embodiment of the present application provides a computer readable storage medium, the computer readable storage medium storing a computer program, and 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.

[0067] In a seventh aspect, an embodiment of the present application provides a computer program product, the computer program product comprising: computer program code, when the computer program code is run by a terminal device, the terminal device executes the method described in the first aspect and various possible implementations of the first aspect.

[0068] In an eighth aspect, an embodiment of the present application provides a computer program product, the computer program product comprising: computer program code, when the computer program code is run by a terminal device, the terminal device executes the method described in the second aspect and various possible implementations of the second aspect.

[0069] In a ninth aspect, an embodiment of the present application provides a chip system, which comprises processing circuitry and a storage medium, and the storage medium stores computer program instructions; the computer program instructions are executed by the processing circuitry to implement the method described in the first aspect and various possible implementations of the first aspect.

[0070] In a tenth aspect, an embodiment of the present application provides a chip system, which comprises processing circuitry and a storage medium, and the storage medium stores computer program instructions; the computer program instructions are executed by the processing circuitry to implement the method described in the second aspect and various possible implementations of the second aspect.

[0071] Optionally, the processing circuitry in the chip system can be replaced by a processor, and the storage medium can be replaced by a memory. Optionally, the chip system can further comprise a communication interface, which is configured to realize communication between the chip system and a receiving device.

[0072] The beneficial effects of the technical solutions in the third aspect to the tenth aspect of the present application can be the same as those of the technical solutions in the first aspect or the second aspect, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0073] FIG. 1 is a schematic diagram of an image rendering scene provided by an embodiment of the present application;

[0074] FIG. 2 is a schematic diagram of a hardware structure of an electronic device 100 provided by an embodiment of the present application;

[0075] FIG. 3 is a schematic diagram of a software architecture of an electronic device 100 provided by an embodiment of the present application;

[0076] FIG. 4 is a schematic diagram of a software architecture of a terminal device provided by an embodiment of the present application;

[0077] FIGS. 5A and 5B are schematic diagrams of two application scenarios provided by an embodiment of the present application;

[0078] FIG. 6 is a flowchart of a compiling method 600 provided by an embodiment of the present application;

[0079] FIGS. 7A to 7C are schematic diagrams of three application scenarios provided by an embodiment of the present application;

[0080] FIGS. 8A and 8B are schematic diagrams of two other application scenarios provided by an embodiment of the present application;

[0081] FIG. 9 is a schematic diagram of interaction between a first device and a second device provided by an embodiment of the present application;

[0082] FIG. 10 is a schematic diagram of interaction between a first device and a second device provided by an embodiment of the present application;

[0083] FIG. 11 is a flow diagram illustrating an example of performing an update operation in an application market according to an embodiment of the present application;

[0084] FIGS. 12A-12D are diagrams illustrating an example of an application installation scenario according to an embodiment of the present application;

[0085] FIGS. 13A-13D are diagrams illustrating an example of an application update scenario according to an embodiment of the present application;

[0086] FIGS. 14A-14D are diagrams illustrating another example of an application update scenario according to an embodiment of the present application;

[0087] FIGS. 15A-15D are diagrams illustrating an example of a scenario in which an application is not updated according to an embodiment of the present application;

[0088] FIGS. 16A-16D are diagrams illustrating an example of an update setting scenario according to an embodiment of the present application;

[0089] FIGS. 17A-17D are diagrams illustrating another example of an application update scenario according to an embodiment of the present application;

[0090] FIGS. 18A-18D are diagrams illustrating an example of an acceleration package download scenario according to an embodiment of the present application;

[0091] FIG. 19 is a diagram illustrating an example of an electronic device 1900 according to an embodiment of the present application. DETAILED DESCRIPTION

[0092] In order to clearly describe the technical solutions of the embodiments of the present application, the technical solutions of the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. It should be noted that the embodiments described in the present application are only some of the embodiments of the present application, not all the embodiments.

[0093] In the description of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B. In the description of the present application, "and / or" is only a description of the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can mean that A exists alone, A and B exist together, and B exists alone. "At least one" means one or more, and "multiple" means two or more. In the specification and claims of the present application, the terms "first" and "second" are used to distinguish different objects or different treatments of the same object, not to describe the specific order of the objects. For example, the first terminal and the second terminal are used to distinguish different terminal devices, not to describe the specific order of the terminal devices. Those skilled in the art can understand that the terms "first", "second", etc. do not limit the quantity and execution order, and the terms "first", "second", etc. do not necessarily mean different.

[0094] It should be noted that the terms "exemplary" and "for example" are used herein to mean "an example of" rather than "an ideal". Any embodiment or design scheme described herein as "exemplary" or "for example" is not necessarily to be construed as preferred or advantageous over other embodiments or design schemes. Rather, the exemplary or for example terms are used herein to enable a clear and unambiguous presentation of the relevant concept, and are only meant to be used in the sense of presenting an example rather than suggesting that other embodiments or design schemes are less desirable or less advantageous. The terms "comprise", "comprising", "include", "including", "have", "has", and the like are meant to be construed as "including but not limited to", unless otherwise noted.

[0095] In order to facilitate the understanding of the present application, some technical terms related to the present application are explained below.

[0096] 1. Shader

[0097] A shader is an editable program used to implement image rendering, which replaces the fixed rendering pipeline. A shader is usually a small program that is executed on a graphics processing unit (GPU) and is used to control different aspects of graphics, such as color, lighting, texture mapping, projection, etc. During image rendering, a shader is used to process the geometry in a scene and calculate the final color or attributes for each pixel or vertex. A shader usually consists of two types: vertex shader and fragment shader. The vertex shader is mainly responsible for the geometric relationship of the vertex, such as calculating the final position, color, normal, etc. of each vertex. In addition, it can also perform coordinate transformation, lighting calculation, vertex animation, etc. The fragment shader, also known as the pixel shader, is mainly responsible for calculating the color of the fragment. For example, the fragment shader can process each pixel to calculate the final color of the pixel. It can also perform texture sampling, lighting calculation, shadow calculation, etc. to generate the final image.

[0098] 2. Shader source

[0099] A shader source is a source code written by a software developer when writing the source code of the software to implement image rendering. The shader source is usually packaged into a software installation package and finally installed on a terminal device through an application market or other channels (such as a browser, etc.).

[0100] 3. Shader compilation

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

[0102] 4. GPU

[0103] GPU, also known as display core, visual processor, display chip, is a kind of microprocessor specially used for image and graphics related operation on personal computer, workstation, game console and some mobile devices (such as tablet computer, smart phone, etc.). GPU makes the display card reduce the dependence on CPU, and performs part of the work originally done by CPU, especially when GPU adopts core technology for 3D graphics processing, such as hardware T&L (geometry conversion and lighting processing), cubic environment material mapping and vertex mixing, texture compression and concave-convex mapping, double texture four-pixel 256-bit rendering engine, etc.

[0104] The technical problem to be solved by the present application will be introduced below in combination with the image rendering scene shown in FIG. 1.

[0105] As shown in FIG. 1, some terminal device is installed with game, video and other application software; when the user starts the game, video and other application software, the terminal device will execute the related code of image rendering; before executing the image rendering function, the terminal device first detects whether the compiled shaderbin file is stored in the internal file system or the memory; if yes, it means that the application software has been previously run on the terminal device, at this time, the terminal device can read the compiled shaderbin file from the file system or the memory for image rendering; if not, it means that the application software is running for the first time on the terminal device; 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 the shaderbin file; finally, use the cache function of the shader to cache the compiled shaderbin file to the file system or the memory, so as to read the compiled shaderbin file from the file system or the memory for image rendering; as can be seen, for the scenario that the application software is running for the first time on the terminal device, since the application software executes the image rendering function for the first time, there is no compiled shaderbin file in the file system or the memory of the terminal device; at this time, the terminal device needs to trigger the shader to compile the shader source code in real time in the process of executing the image rendering; the complex and time-consuming shader source code compilation may cause the phenomenon of frame loss and lag in the process of picture rendering. Therefore, the present application proposes a compilation method, which can reduce the probability of frame loss and lag in the process of picture rendering, and is beneficial to optimize the picture rendering performance.

[0106] In the 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, then compile the common source code to obtain the common executable code; finally, the common executable code is distributed to the terminal device (i.e. an example of the second device), so as to reduce the task amount of the shader source code compilation of the terminal device in the process of executing the image rendering, thereby reducing the probability of frame loss and lag in the process of picture rendering.

[0107] It should be noted that the above compiling method can be performed by the first device (or the second device), and in some scenarios, the first device can refer to a server, such as a business processing server, a computing server, or a data server, etc.; the second device can refer to a terminal device (or a user equipment (UE)). The terminal device can be a mobile phone, a watch, a car machine, a smart screen, a smart television (TV), a tablet computer (Pad), a wearable device, a virtual reality (VR) device, an augmented reality (AR) device, a projector, a vehicle-mounted playback system, etc. The specific type of the terminal device is not limited in the embodiments of the present application.

[0108] In order to better understand the embodiments of the present application, a hardware structure of an electronic device 100 suitable for the present application will be introduced below in combination with FIG. 2; the electronic device 100 can refer to the first device (or the second device).

[0109] The electronic device 100 can include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) joint 130, a charge 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.

[0110] The processor 110 can include one or more processing units, for example: the processor 110 can include an application processor (AP), a modem processor, a graphics processing unit (GPU), a controller, a digital signal processor (DSP), a baseband processor, etc. Different processing units can be independent devices, or can be integrated in one or more processors.

[0111] The processor 110 can generate operation control signals according to instruction operation codes and timing signals, and complete the control of fetching instructions and executing instructions.

[0112] The processor 110 can also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 can be a cache memory. The memory can hold instructions or data that are frequently used or used by the processor 110. If the processor 110 needs to use the instructions or data, the processor 110 can directly call the memory. This avoids repeated access and reduces the waiting time of the processor 110, thereby improving the efficiency of the system.

[0113] In some embodiments, the processor 110 can include one or more interfaces. The interface can 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, and the like. The processor 110 can connect the wireless communication module, the display, and the like through at least one of the above interfaces.

[0114] It can be understood that the interface connection relationship between the modules shown in the embodiments of the present application is only illustrative and does not constitute a structural limitation of the electronic device 100. In other embodiments of the present application, the electronic device 100 can also use different interface connection methods or a combination of multiple interface connection methods in the above embodiments.

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

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

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

[0118] The wireless communication module 160 can provide a solution for wireless communication including wireless local area networks (WLAN) (e.g., a Wifi network), Bluetooth (BT), near field communication (NFC), etc. applied to the electronic device 100.

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

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

[0121] 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 through the external memory interface 120 to implement a data storage function. For example, files such as pictures and videos are saved in the external memory card. Or files such as pictures and videos are transmitted from the electronic device 100 to the external memory card.

[0122] The internal memory 121 can be used to store computer executable program codes including instructions. The internal memory 121 can include a program storage area and a data storage area. The program storage area can store an operating system, at least one application required by a function (such as a game or a video application, etc.), and the like. The data storage area can store data created during use of the electronic device 100 (such as contact information, external device information to be connected, etc.), and the like. In addition, the internal memory 121 can include a high-speed random access memory, and can further include a non-volatile memory such as at least one of a magnetic disk storage device, a flash memory device, a universal flash storage (UFS), and the like. The processor 110 executes various function 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 disposed in the processor.

[0123] The electronic device 100 can display image data such as a game screen, a video animation, etc. through the display screen 170.

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

[0125] It should be noted that in some scenarios, for example, the electronic device 100 is a terminal device, since most of the applications running on the terminal device have a picture display requirement, the electronic device 100 needs to be equipped with a display screen 170; the display screen 170 can display various image screens in cooperation 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 picture display requirement, at this time, the server can not be equipped with a display screen 170; for example, in a scenario where the server is connected with a physical terminal (which can be referred to as FIG. 8A below), since each application runs on a physical terminal with a display screen, the server mainly provides computing power (such as providing a compilation service, etc.) here, and therefore the server can not be equipped with a display screen 170. Of course, in some other scenarios, the server can also be equipped with a display screen 170, for example, referring to FIG. 8B below, various virtual terminals are deployed on the server, and these virtual terminals are used to run application software requiring picture display such as games and videos, at this time, the server needs to be equipped with a display screen 170.

[0126] It can be understood that the structure shown in the embodiments 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 can also include more or fewer components than Figure 2, or combine certain components, or split certain components, or different component arrangements. The components in Figure 2 can be implemented in hardware, software or a combination of software and hardware.

[0127] In addition, it should be noted that the software system of the electronic device 100 described above can adopt a layered architecture or a service architecture, and the embodiments of the present application take the Android operating system with a layered architecture as an example to illustrate the software architecture of the electronic device 100. It should be understood that the scheme provided by the present application can also be applied to other types of operating systems such as Harmony system, Apple operating system, Windows operating system, etc.

[0128] Figure 3 shows a software architecture diagram of the electronic device 100 provided by the embodiments of the present application. As shown in Figure 3, the layered architecture of the electronic device 100 divides the software into several layers, each layer has a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the software architecture from top to bottom is the application (application, APP) layer, the application framework (framework, FWK) layer, the Android runtime (ART) and system library, the hardware abstraction layer (hardware abstract layer, HAL) and the kernel layer.

[0129] The application layer, also known as the application layer, can include a series of application packages. For example, the application layer package can include games, videos, reading, application market and settings, etc. When the above application package is running, each service module provided by the application programming interface (application programming interface, API) of the application framework layer can be accessed, and the corresponding intelligent business can be executed.

[0130] The application framework layer (FWK) provides an application programming interface (API) and a programming framework for applications in the application layer. The application framework layer includes some pre-defined functions. As shown in FIG. 3, the application framework layer can include a graphics manager, a video codec, a window manager, a resource manager, a notification manager, a content manager, and the like. Among them, the graphics manager is responsible for calling interfaces in a graphics library to complete drawing, rendering, and synthesizing an interface, the video codec is responsible for video encoding and decoding, the window manager manages all windows in the system, the resource manager is responsible for managing system resources and providing various resources, such as pictures, video files, and the like, for applications; the notification manager is responsible for managing prompt messages on the top status bar of the mobile phone; and the content provider is used to store and obtain data (such as videos, pictures, and the like) and enable the data to be accessed by applications.

[0131] The system library (which can also be referred to as a native C / C++ library) can include a plurality of functional modules, such as a surface manager, media libraries, a three-dimensional graphics processing library, a two-dimensional graphics engine, a file system module (which can also be referred to as a file system), a shader module, and the like; among them, the surface manager is used to manage a display subsystem and provides fusion of two-dimensional and three-dimensional layers for a plurality of applications; the media libraries support playback and recording of a plurality of commonly used audio, video formats, and static image files, and the like; the media libraries can support a plurality of audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, and the like; the three-dimensional graphics processing library is used to implement three-dimensional graphics drawing, image rendering, synthesis, and layer processing, and the like. The two-dimensional graphics engine is a drawing engine for two-dimensional image drawing; the file system module is used to cache a shaderbin file; and the shader module (which can also be referred to as a shader) is used to implement image rendering functions of a shader, such as vertex, color, and texture calculation, and the like.

[0132] The Android runtime includes a core library and an Android runtime. The Android runtime is responsible for converting source code into machine code. The Android runtime mainly includes an ahead of time (AOT) compilation technology and a just in time (JIT) compilation technology.

[0133] The core library is mainly used to provide functions of a basic Java class library, such as libraries of basic data structures, mathematics, IO, tools, databases, networks, and the like. The core library provides an API for a user to develop an Android application.

[0134] The hardware abstraction layer runs in a user space, encapsulates a kernel layer driver, and provides a calling interface to an upper layer. The hardware abstraction layer includes a display module, a Bluetooth module, and the like.

[0135] The kernel layer is a layer between hardware and software. The kernel layer includes, but is not limited to, a GPU driver, a CPU driver, a display driver, a Bluetooth driver, and the like, to drive the GPU, the CPU, the display screen, and the Bluetooth and the like of the hardware layer.

[0136] Next, taking the second device with the structure shown in FIG. 2 and FIG. 3 as an example, and in combination with the software architecture diagram of the terminal device shown in FIG. 4, the overall flow of the terminal device executing the above-mentioned compiling method is exemplarily described.

[0137] When a user opens a game application in the application layer, the game application runs on an operating system (OS) of the terminal device; when the game application performs graphic rendering, the game application can generate a rendering request and send the rendering request to the graphic manager; the graphic manager can generate a shader source instruction according to the rendering request and send the shader source instruction to a shader module of the system library; after the shader module receives the shader source, it detects whether there is a compiled shaderbin file in the file system module, if there is, it generates an image rendering instruction stream (such as a scene drawing instruction, an interface drawing instruction, and the like) according to the shaderbin file; the shader module sends the image rendering instruction stream to the GPU driver; the GPU driver generates a rendering driver instruction stream according to 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 picture.

[0138] It should be noted that the software architecture of the electronic device 100 is not limited to the software and hardware system structure shown in FIG. 2 to FIG. 4, and in actual applications, the software and hardware system structure shown in FIG. 2 to FIG. 4 can be deformed according to specific application scenarios, which is not limited in the present application.

[0139] The above describes in detail the software and hardware system structure of the electronic device 100 applicable to the present application, and then two application scenario architectures applicable to the present application are introduced in combination with FIG. 5A and FIG. 5B.

[0140] FIG. 5A shows an application scenario in which a terminal device obtains a public shaderbin file (may also be referred to as public executable code) and a private shaderbin file (may also be referred to as private executable code) from a cloud server; in some scenarios, the terminal device (an example of a second device) can send a download request X to the cloud server (an example of a first device); the download request X is used to request to download a software installation package of application 1 (an example of a first application) (or a software installation package of application 2); after the cloud server receives the download request X, the cloud server sends the terminal device a software installation package A and a private shaderbin file A (or sends the terminal device a software installation package B and a private shaderbin file B); after the terminal device receives the software installation package A and the private shaderbin file A (or receives the software installation package B and the private shaderbin file B), the terminal device can store the private shaderbin file A (or the private shaderbin file B) to a file system module of an operating system, so as to facilitate the shader module to call when performing an image rendering function.

[0141] In other scenarios, the terminal device can also send a download request Y to the cloud server, the download request Y is used to request to download a public shaderbin file; after the cloud server receives the download request Y, the cloud server sends the terminal device the public shaderbin file; after the terminal device receives the public shaderbin file, the terminal device can store the public shaderbin file to the file system module, so as to facilitate the shader module to call when performing an image rendering function.

[0142] When the application 1 (or the application 2) calls the shader module during the execution of the image rendering process, the terminal device triggers the shader module located in the operating system to check whether the file system module has a compiled shaderbin file (such as the private shaderbin file A); for example, if the shader module checks that the file system module has a compiled shaderbin file, the shader module can directly read the public shaderbin file and the private shaderbin file A from the file system module to perform image rendering (or triggers the shader module to read the public shaderbin file and the private shaderbin file B from the file system module to perform image rendering), without triggering a compilation action.

[0143] FIG. 5B shows 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); the application scenario is applicable to a software installation scenario (e.g., installation and update of an application in an application market, and update of an application outside the application market). In the application scenario, the cloud server and the terminal device can communicate with each other, for example, by sending a request message, a software installation package, and the like through a wireless network; the cloud server includes an automatic collection module, a compiling module, and a distribution module, and the processing and interaction processes of these modules are as follows:

[0144] The automatic collection module, which can also be referred to as a collection module, is configured to collect shader source codes (e.g., L shader source codes described below) of a plurality of applications from at least one terminal device, and to send the collected shader source codes to the compiling module.

[0145] The compiling module is configured to determine public source codes and private source codes, and to compile the public source codes and the private source codes, respectively. For example, after receiving the shader source codes sent by the automatic collection module, the compiling module determines the public source codes and the private source codes (e.g., M private source codes) according to the shader source codes; and then compiles the public source codes and the private source codes, respectively, to obtain public shaderbin files (e.g., N public executable codes described below) and private shaderbin files (e.g., K private executable codes described below); for details, reference can be made to the embodiments described below, and thus no further description is given here.

[0146] The distribution module is configured to provide the terminal device with the public shaderbin files, the software installation package, and the corresponding private shaderbin files, and the like.

[0147] For the terminal side, the terminal device can download the software installation package A of the application 1 (or the application 2), and the corresponding private shaderbin file A (or the private shaderbin file B) and the public shaderbin file from the cloud server through an application market; the application market is an application software installed on the terminal device, and is configured to download the software installation package and the shaderbin files of different applications from the cloud server; after the downloading is completed, the terminal device can store the shaderbin files (e.g., the private shaderbin file A, the private shaderbin file B, and the public shaderbin file) into a file system module by calling a system interface, where the file system module is a module running in the operating system of the terminal device, and is configured to store the public shaderbin files and various private shaderbin files.

[0148] When the application 1 (or the application 2) invokes the shader module in the image rendering process (or when the image rendering interface shader module is invoked), the terminal device triggers the shader module to check whether the file system module has a compiled shader bin file (for example, the private shader bin file A, etc.); if yes, the shader module can directly invoke the public shader bin file and the private shader bin file (for example, the private shader bin file A or the private shader bin file B) from the file system module to perform image rendering, without triggering the compiling action; if not, the compiling operation needs to be triggered again; wherein the shader module is a module in the operating system for performing the image rendering function; when the shader module performs the image rendering function, the compiled shader bin file in the file system module is usually used preferentially; when the file system module does not have the compiled shader bin file, the compiling operation is triggered; in addition, the operating system also includes a store kit, which is used to provide a software distribution related interface, and to pull up the application market to perform the application update (for details, refer to the following embodiments, which are not described here).

[0149] The above introduces several application scenarios suitable for the present application, and the compiling method provided by the embodiments of the present application is exemplarily described below in combination with the drawings.

[0150] As shown in FIG. 6, it is a flowchart of a compiling method 600 provided by the embodiments of the present application. Before introducing the method 600 provided by the present application, the execution subject involved in the embodiments of the present application is briefly described. In the present application, the first device can be a server, and the second device can be a terminal device; the above-mentioned compiling method can be executed by the first device (or the second device), or can be executed by a module (for example, a processor, a chip, or a chip system, etc.) applied in the first device (or the second device), or can be realized by a logic module or software which can realize all or part of the functions of the first device (or the second device).

[0151] The above-mentioned first device can be a server with the software and hardware architecture of FIG. 2 and FIG. 3, and the second device can be a terminal device with the software and hardware architecture of FIG. 2 and FIG. 3. It should be noted that the first device and the second device can communicate with each other, for example, through a wireless network.

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

[0153] In step 601, the first device acquires L kinds of shader source codes, which are the source codes corresponding to the shaders of L applications, and L is an integer greater than 1.

[0154] wherein the first device usually refers to a server; the server usually has strong computing capability, and can compile executable code (or executable instructions) with higher execution efficiency, such as a business server, a computing server, a cloud server, etc.; the shader source code usually refers to source code written by a developer for implementing image rendering; for example, for some application software (such as games, videos, etc.) that needs image rendering, the developer needs to write source code for implementing image rendering function (in other words, needs to write shader source code) when writing the source code of the application software.

[0155] Since different applications need to implement different image rendering contents, the source code corresponding to the shaders of different applications is different, for example, L applications can correspond to L kinds of shader source code.

[0156] The first device obtains the L kinds of shader source code in the following manner:

[0157] Manner 1: In some embodiments, the first device obtains the L kinds of shader source code from at least one terminal device, wherein the at least one terminal device is used to run the L applications.

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

[0159] For example, as shown in FIG. 7A, the first device is a server, L=6, and the application 1 to the application 6 run on a terminal device A; the server and the terminal device A can communicate with each other; the 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 the application 1 to the application 6 (i.e., an example of the L applications), i.e., L=6 kinds of shader source code; the source code detection module collects the shader source code corresponding to each of the six applications during the execution of image rendering of the application 1 to the application 6, respectively, and sends the six kinds of shader source code to the server. After the server receives the six kinds of shader source code from the terminal device A, the server processes the six kinds of shader source code (such as extracting common source code and private source code, etc.), and compiles the processed shader source code to obtain executable code (such as common executable code or private executable code), and finally distributes the executable code to a device in need (such as a second device). In this scenario, since the L applications run on the terminal device, it is beneficial for the terminal device to detect the corresponding shader source code during the execution of image rendering of each application, therefore, the first device can obtain the L kinds of shader source code through the at least one terminal device.

[0160] In some embodiments, the first device obtains L kinds of shader source codes from the shader of the at least one terminal device, and the running mode of the shader is the debugging mode.

[0161] It should be noted that the terminal device A can also not be designed with a special source code detection module to obtain the respective shader source codes of the applications 1 to 6; for example, as shown in FIG. 7B, the terminal device A can collect the respective shader source codes of the applications 1 to 6 (i.e., L = 6 kinds of shader source codes) through the shader module when the shader module is in the debugging mode, and send the six kinds of shader source codes to the server. The shader source codes can be obtained by using the existing shader module without designing a special source code detection module, which can reduce the cost of obtaining the source codes.

[0162] For example, as shown in FIG. 7C, the first device is a server, L = 6, and the applications 1 to 6 run on the terminal device A; the server and the terminal device A can communicate with each other; the terminal device A includes a shader module and a source code detection module; the server includes an automatic collection module, a compilation module, and a distribution module; the automatic collection module is configured to automatically obtain L kinds of shader source codes; the compilation module is configured to compile the shader source codes to obtain executable codes; and the distribution module is configured to send the executable codes to a second device (such as a terminal). For the terminal side, the source code detection module can collect the respective shader source codes of the six applications during the execution of the image rendering process, and send the six kinds of shader source codes to the server. For the server side, the automatic collection module can receive the six kinds of shader source codes from the terminal device A, and send the six kinds of shader source codes to the compilation module; the compilation module processes the six kinds of shader source codes (such as extracting public source codes and private source codes), and compiles the processed shader source codes to obtain executable codes (such as public executable codes or private executable codes); the compilation module sends the executable codes to the distribution module; and the distribution module distributes the executable codes to the target terminal.

[0163] It should be noted that the above-mentioned mode 1 and mode 2 are only examples of the first device obtaining L kinds of shader source codes from one terminal device, and the first device obtaining L kinds of shader source codes from multiple terminal devices according to the mode 1 and mode 2 can refer to the mode 3 and mode 4 to be introduced below, which have similar principles and will not be repeated here.

[0164] In some embodiments, the first device includes a collection module configured to obtain shader source codes, and the first device obtains L kinds of shader source codes from at least one terminal device, including: the first device obtains the L kinds of shader source codes from the at least one terminal device through the collection module.

[0165] The collection module is a module on the first device for obtaining the shader source code. The collection module can be a module in an operating system or a module in an application layer, and the application does not limit the name of the collection module in actual application.

[0166] It should be noted that in some scenarios, the collection module can also be referred to as an automatic collection module or an automated collection module or a source code collection module, and the application does not limit the name of the collection module in actual application.

[0167] For example, as shown in FIG. 8A, the first device is a server, and the terminal device 1 to the terminal device n are n physical terminal devices (for example, the terminal device 1 is a watch, the terminal device 2 is a mobile phone, and the terminal device n is a tablet); the server and the n terminal devices can communicate with each other; the application 1 to the application m (i.e., an example of L applications) run on the n terminal devices (i.e., an example of at least one terminal device), for example, the application 1 and the application 2 run on the terminal device 1, the application 3 runs on the terminal device 2, and the application m runs on the terminal n; the terminal device 1 to the terminal device 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 the application 1 to the application m (i.e., an example of L shader source codes); the server includes an automated collection module, a compilation module, and a distribution module, and the understanding of each module can refer to the server shown in FIG. 7C, which will not be described here. For the terminal side, during the running of the application 1 to the application m, the source code detection module can collect the shader source code corresponding to each of the m applications (i.e., L = m shader source codes) during the execution of the image rendering process, and send the m shader source codes to the server. For the server side, the automated collection module can receive the m shader source codes from the terminal device 1 to the terminal device n (for example, receive the shader source code corresponding to the application 1 and the shader source code corresponding to the application 2 from the terminal device 1), and send the m shader source codes to the compilation module; the compilation module processes the m shader source codes (for example, extracts the public source code and the private source code, etc.), and compiles the processed shader source codes to obtain executable codes (for example, public executable codes or private executable codes); the compilation module can send the executable codes to the distribution module; and the distribution module distributes the executable codes to the devices in need. As can be seen, compared with manually collecting L shader source codes, the first device automatically obtains L shader source codes from at least one terminal device through the collection module, which is simple and efficient and has low cost.

[0168] In some embodiments, the first device comprises a collection module configured to obtain the shader source code, and the first device obtains the L shader source codes from the shaders of the at least one terminal device, including: the first device obtains the L shader source codes from the shaders of the at least one terminal device through the collection module, and the running mode of the shader is the debugging mode.

[0169] In some scenarios, the developer does not need to design a special source code detection module on the terminal device 1 to the terminal device n to obtain the shader source code corresponding to different applications; for example, as shown in FIG. 8B, the terminal device 1 to the terminal device n can set the shader module of each terminal device to the debugging mode, and then collect the shader source code corresponding to the m applications (for example, application 1 to application m) running on the operating system of the terminal device through the shader module of the terminal device, and finally obtain m shader source codes; the cloud server can obtain the m shader source codes from the terminal device 1 to the terminal device n, without the need for manual collection of the m shader source codes or the need for the design of a special source code detection module. This source code collection method is efficient, convenient and low in cost.

[0170] For example, as shown in FIG. 8B, the first device can be a cloud server, and the terminal device 1 to the terminal device n are n virtual terminals on the cloud server; the cloud server can obtain the shader source code corresponding to the applications running on the virtual terminals through an automatic collection module; the terminal device 1 to the terminal device n each comprise a shader module; the cloud server comprises an automatic collection module, a compilation module and a distribution module. For the terminal side, the shader module of each virtual terminal runs in the debugging mode and can be used to obtain the shader source code; for example, the shader module of each virtual terminal can collect the shader source code corresponding to each application in the process of image rendering of each application, and send the shader source code to the cloud server. For the cloud server side, the automatic collection module can receive m shader source codes from the n virtual terminals (for example, receive the shader source code corresponding to the application 1 from the terminal device 1, receive the shader source code corresponding to the application 2 from the terminal device 2, etc.), and send the m shader source codes to the compilation module; the compilation module processes the m shader source codes (for example, extracts the public source code and the private source code, etc.), and compiles the processed shader source codes to obtain executable codes (for example, public executable codes or private executable codes); the compilation module can send the executable codes to the distribution module; and the distribution module can distribute the executable codes to the terminal in need.

[0171] In step 602, the first device determines the public source code from the L shader source codes, and the public source code is the part common to the L shader source codes.

[0172] Since L kinds of shader source codes correspond to L applications, and which part of each kind of shader source code can be used as common source code, can be determined according to the extent to which the application corresponding to the shader source code is used; wherein, the extent can be measured by some usage frequency information and calling situation. For example, the probability of the shader source code corresponding to the application with high usage frequency being determined as common source code is high, and vice versa; for example, if an application calls a kind of shader source code more, it means that the shader source code is more widely used, and the probability of the shader source code being determined as common source code is high, and vice versa.

[0173] Wherein, the usage frequency information is used to represent the frequency of each application in the L applications being used, and the usage frequency information includes but is not limited to the number of downloads (also can be called the download amount) and / or the number of installations (also can be called the installation amount); wherein, the more the number of downloads (or the number of installations) is, the higher the frequency of the application being used is, and vice versa; the calling situation can refer to the situation that a certain shader source code is called by other applications, such as how many applications call the first kind of shader source code (i.e. an example of the L kinds of shader source codes) or how many times the first kind of shader source code is called by other applications.

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

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

[0176] Therefore, in order to ensure that the common source code determined from the L kinds of shader source codes is extensive, the first device screens the shader source codes with high calling (or using) frequency from the L kinds of shader source codes as the common source code according to the first parameter (such as the using frequency information), so that the common executable code compiled from the common source code can be called by multiple applications, thereby reducing the probability of frame loss and lag in the picture rendering process of more applications.

[0177] For example, in some embodiments, the first device can determine the common source code from the L kinds of shader source codes according to the calling party condition. For example, L = 4 kinds of shader source codes, wherein the first kind of shader source code is from application 1, …, and the fourth kind of shader source code is from application 4. The first kind of shader source code includes shader source code A1, shader source code B1 and shader source code C1. The second kind of shader source code includes shader source code A1, shader source code B2 and shader source code C1. The third kind of shader source code includes shader source code A1, shader source code B3 and shader source code C1. The fourth kind of shader source code includes shader source code A2, shader source code B4 and shader source code C1. Obviously, the shader source code A1 is called by the applications 1 to 3, which indicates that the shader source code A1 can be widely used. In addition, the shader source code C1 is called by the applications 1 to 4, which indicates that the shader source code C1 can be widely used. However, the shader source codes B1 to B4 are not called by other applications except the applications themselves, which indicates that the shader source codes B1 to B4 can be private source codes of the applications themselves. Compared with the shader source codes B1 to B4, the shader source codes A1 and C1 are more likely to be determined as the common source code. Since the shader source codes A1 and C1 can be called by more applications, the first device can take the shader source codes A1 and C1 as the common source code.

[0178] In step 603, the first device compiles the common source code to obtain N kinds of common executable codes, and the N kinds of common executable codes are used to adapt to N kinds of running environments, and N is a positive integer.

[0179] Since the source code needs to be compiled when running on the terminal device (which is an example of the second device), the first device can compile the common source code after determining the common source code.

[0180] Since the device parameters of the terminal devices are different, the executable codes compiled from the source code are different, and thus, in some embodiments, the first device can compile the common source code into executable codes adapted to different device running environments according to different device parameters. The device parameters can include, but are not limited to, at least one of a device type (such as a mobile phone, a tablet computer, or a watch, etc.), a GPU version number, or an OS version number. The GPU version number can also be referred to as a GPU model or a GPU version, such as a GPU version number XXX 000. The operating system version number can also be referred to as an operating system model or an operating system version, such as an operating system version number XX01.

[0181] The N can be determined according to the device parameters, for example, if there are 5 GPU version numbers, the first device can compile the common source code into common executable codes that can run on the 5 different GPU versions according to the different GPU version numbers. For another example, if there are 5 GPU version numbers and 4 OS version numbers, the first device can compile the common source code into common executable codes that can run on 20 (5*4=20) different GPU versions and OSs according to the different GPU version numbers and OS version numbers.

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

[0183] The second parameter is an example of the device parameters. Taking the GPU version number as an example, if there are 3 GPU version numbers in the current market, version 1, version 2, and version 3, the first device can compile the common source code into N=3 common executable codes according to the version 1 to version 3, which are common executable code 1, common executable code 2, and common executable code 3. The three common executable codes can run on the three GPU versions (i.e., adapt to the running environments of the three GPU versions). For example, if the GPU version number installed by the second device is version 1 (or version 2 or version 3), the common executable code 1 (or the common executable code 2 or the common executable code 3) can run on the GPU of the second device.

[0184] For example, if there are two GPU version numbers, GPU version 1 and GPU version 2, and two OS version numbers, OS version 1 and OS version 2, in the current market, the first device can compile the common source code into N = 4 kinds of common executable codes, i.e., common executable code 1, common executable code 2, common executable code 3 and common executable code 4, according to the two GPU version numbers and the two OS version numbers, wherein the common executable code 1 is adapted to the running environment built by the GPU version 1 and the OS version 1, the common executable code 2 is adapted to the running environment built by the GPU version 1 and the OS version 2, the common executable code 3 is adapted to the running environment built by the GPU version 2 and the OS version 1, and the common executable code 4 is adapted to the running environment built by the GPU version 2 and the OS version 2; the four kinds of common executable codes can run in the running environments built by the four different GPU versions and OS versions; for example, if the GPU version installed in the second device is version 1 and the OS version number is OS version 1, the common executable code 1 can run on the GPU and the OS of the second device.

[0185] Since different GPU version numbers and / or OS version numbers can build different running environments, the first device can compile the common source code into common executable codes that can adapt to different running environments according to the GPU version number and / or the OS version number, so as to meet the demand for common executable codes in different running environments.

[0186] In step 604, the first device sends the target common executable code to the second device, and the target common executable code is one of the N kinds of common executable codes that adapt to the running environment of the second device.

[0187] The second device can be a terminal device or a target service server, and the present application does not make any limitation.

[0188] Since the GPU version number and the OS version number on different devices can be different, the target public executable code downloaded from the first device can be different for different devices. For example, the second device sends a request 1 (such as the first request information below) to the first device; the request 1 includes the GPU version number and the OS version number of the second device; after receiving the request 1, the first device can determine the public executable code 1 that is suitable for the running environment of the second device from the N kinds of public executable codes according to the GPU version number and the OS version number in the request 1, and send the public executable code 1 to the second device; after receiving the public executable code 1, the terminal device 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 compiling the public source code again, thereby reducing the compilation amount in the image rendering process.

[0189] In summary, in the picture rendering process, one processing method is to compile and render at the same time, and this method often has the phenomenon of frame loss and lag. In this application, the first device can determine the public source code from the L kinds of shader source codes and compile the public source code; finally, the target public executable code suitable for the running environment of the second device is sent to the second device, and the second device can directly call the public executable code when performing the rendering operation without compiling the public source code part, thereby reducing the compilation amount in the image rendering process, reducing the probability of frame loss and lag in the picture rendering process, and optimizing the picture rendering performance.

[0190] As shown in FIG. 9, before the above step 604, the above method 600 further includes a step 605:

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

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

[0193] The first request information includes but is not limited to the second device identifier and the second device parameter, wherein the second device identifier can be a string of characters (such as XXX0002, etc.), which is used to uniquely identify the second device; and the second device parameter includes but is not limited to the GPU version number and / or the OS version number.

[0194] Since the N kinds of common executable codes on the first device correspond to different running environments, the first device needs to determine the target common executable code from the N kinds of common executable codes according to the second device parameters reported by the second device; for example, the second device parameters include a GPU version number A and an operating system version number B; if the common executable code 1 is a common executable code obtained by compiling the common source code according to the version number A and the version number B by the first device, the first device can determine the common executable code 1 as the target common executable code from the N kinds of common executable codes according to the version number A and the version number B.

[0195] In some embodiments, the above step 604 can also be implemented by step 6041:

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

[0197] After the first device receives the first request information, the first device can determine the target common executable code according to the first request information and distribute the target common executable code to the second device, so as to avoid forcibly distributing data and affecting user experience in the case where the user has no demand.

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

[0199] The preset time period can be set by a starting time and an interval time, for example, the second device sends the request information (for example, the first request information) to the first device every interval time T starting from T1; correspondingly, the first device receives the request information from the second device every interval time T starting from T1.

[0200] For example, in some timing task (or periodic task) scenarios, the second device can send the first request information to the first device at a timing to obtain the target common executable code from the first device, so as to ensure that the currently stored common executable code is consistent with the current latest common executable code of the first device.

[0201] In these embodiments, the second device sends the first request information to the first device to obtain the target common executable code from the first device, so that the second device can directly call the common executable code when rendering the image, without triggering the compilation of the common source code, thereby reducing the compilation amount of the source code, reducing the probability of frame loss and lag in the picture rendering process, and optimizing the picture rendering performance.

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

[0203] Step 6040: The first device determines the target common executable code from the N common executable codes according to the third parameter.

[0204] The third parameter is an example of the device parameter, for example, the third parameter can include a device model, a GPU version number, and an operating system version number, etc. Since the N common executable codes are executable codes compiled by the first device according to the device parameter (such as the GPU version number, etc.), the third parameter reported by the second device to the first device is beneficial for the first device to determine the target common executable code that adapts to the second device from the N common executable codes according to the third parameter.

[0205] 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 can report its own GPU version number and / or its own OS version number to the first device through the first request information, so as to facilitate the first device to determine the target common executable code that adapts to the running environment of the second device from the N common executable codes according to the GPU version number and / or the OS version number, and avoid the error of issuing executable codes that do not match the running environment of the device. For details, refer to the determination method of the target common executable code in step 605 above, which will not be described here.

[0206] In some embodiments, in addition to determining the common source code and compiling the common source code, the first device can also determine a private source code and compile the private source code.

[0207] As shown in FIG. 10, the method 600 further includes steps 1001 to 1003:

[0208] Step 1001: The first device determines M private source codes from L shader source codes, the M private source codes being parts of the L shader source codes other than the common source code, and M being a positive integer less than or equal to L.

[0209] It should be noted that the M private source codes are private source codes corresponding to M applications; usually, the M private source codes are one-to-one bound to the M applications; when the user downloads or updates the application, the private source code is usually issued to the client (such as the second device) together with the software installation package of the application.

[0210] According to the description of step 602, the first device can determine the common source code from some shader source code; and the private source code can be understood as the part of some shader source code other than the common source code.

[0211] In some embodiments, the first device can determine M=L private source codes from the L shader source codes, that is, the first device removes the common source code part from each of the L shader source codes to obtain L private source codes without the common source code.

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

[0213] The usage frequency information can refer to the related description in step 602, which will not be repeated here. For example, taking the download times of the L applications as the usage frequency information, the first device can remove the shader source code corresponding to the application with fewer download times according to the download times of the L applications. For example, the download times of 5 applications among the L applications are lower than a preset value, and the first device can remove the 5 shader source codes corresponding to the 5 applications from the L shader source codes, so as to obtain L-5 shader source codes. That is, the first device removes the common source code part from each of the L-5 shader source codes to obtain M=L-5 private source codes without the common source code, wherein “-” is a subtraction operator.

[0214] In this embodiment, the first device removes some private source codes corresponding to less frequently used applications from the L shader source codes according to the first parameter, and retains the private source codes corresponding to M frequently used applications (i.e., M private source codes), which can ensure that the private executable codes obtained by compiling the M private source codes have a high usage rate.

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

[0216] Wherein, “*” is a multiplication operator, K=M*N, “M” represents M kinds of private source code, also represents M applications; “N” represents that each kind of private source code can be compiled into N kinds of private executable code, which can also be understood as that each application can correspond to N kinds of private executable code; N is usually determined by a device parameter (such as the second device parameter in the above); for example, if the device parameter includes 5 GPU version numbers, then each kind of private source code can be compiled into N=5 kinds of private executable code; the 5 kinds of private executable code can run on the GPUs corresponding to the 5 GPU version numbers.

[0217] Since the first device compiles each kind of private source code in the M kinds of private source code in the same way, only the process of compiling one kind of private source code by the first device is taken as an example below to illustrate the process of compiling the M kinds of private source code by the first device.

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

[0219] The above K can usually be determined according to the device parameters and the number of source codes; for example, if there are 5 GPU version numbers, the first device can compile one kind of private source code into 5 kinds of private executable code according to the 5 GPU version numbers; the 5 kinds of private executable code can run on the GPUs corresponding to different GPU versions; for example, if there are M kinds of private source code, the first device can compile the M kinds of private source code into K=5*M kinds of private executable code according to the 5 GPU version numbers. For another example, if there are 4 GPU version numbers and 3 OS version numbers, the first device can compile one kind of private source code into 12 (i.e. 4*3=12) kinds of private executable code according to different GPU version numbers and OS version numbers; the 12 kinds of private executable code can run on the running environment built by the 12 kinds of GPU versions and OS versions; since there are M kinds of private source code, each kind of private source code can be compiled into 12 kinds of executable code, so the first device can compile the M kinds of private source code into K=12*M kinds of private executable code according to the 4 GPU version numbers and the 3 OS version numbers.

[0220] In some embodiments, the first device respectively compiles the M kinds of private source code according to a second parameter, and the second parameter includes at least one of a GPU version number or an OS version number.

[0221] The second parameter is an example of the device parameter. Taking the GPU version number as an example of the second parameter, if there are three GPU version numbers in the current market, version 1, version 2, and version 3, the first device can compile one private source code into N=3 private executable codes, private executable code 1, private executable code 2, and private executable code 3, according to version 1 to version 3. The three private executable codes can run on three GPU versions (i.e., adapt to the running environment 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 private source codes, the first device can compile the M private source codes into K=3*M private executable codes according to the three GPU version numbers.

[0222] For another example, taking the GPU version number and the OS version number as examples of the second parameter, if there are two GPU version numbers, version V1.0 and version V2.0, and two OS version numbers, version OS.1 and version OS.2, in the current market, the first device can compile one private source code into N=4 private executable codes, private executable code 1, private executable code 2, private executable code 3, and private executable code 4, according to the two GPU version numbers and the two OS version numbers. Private executable code 1 is adapted to the running environment built by version V1.0 and version OS.1, private executable code 2 is adapted to the running environment built by version V1.0 and version OS.2, private executable code 3 is adapted to the running environment built by version V2.0 and version OS.1, and private executable code 4 is adapted to the running environment built by version V2.0 and version OS.2. The four private executable codes can run in the running environment formed 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 version OS.1, private executable code 1 can run on the GPU and the OS of the second device. For example, if there are M private source codes, the first device can compile the M private source codes into K=4*M private executable codes according to the two GPU version numbers and the two OS version numbers.

[0223] In this embodiment, because different GPU version numbers and / or OS version numbers can build different running environments, in order to compile private source codes into private executable codes that can be adapted to multiple running environments, the first device can compile the private source codes according to the GPU version number and other parameters to meet the needs of private executable codes in different running environments.

[0224] Step 1003: The first device sends the target private executable code to the second device, the target private executable code being one of the K private executable codes adapted to the running environment of the second device.

[0225] For example, in some scenarios, the user triggers a download operation (or an update operation) of an application on the second device, at this time, the second device needs to send request information to the first device to request the first device to issue a software installation package of the application or a download address of the software installation package of the application; after receiving the request information (for example, the second request information below) sent by the second device, the first device can send the corresponding target private executable code to the second device at the same time of 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 of 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 a system interface to save the software installation package and the corresponding target private executable code in a file system module, and delete the old private executable code and release the storage space.

[0226] In yet some scenarios, the second device has installed an application X, and the first device can also send the latest private executable code (which is an example of the target private executable code) corresponding to the application X to the second device at regular intervals, so as to ensure that the private executable code of the application X stored on the second device is consistent with the latest private executable code on the first device.

[0227] In summary, in addition to determining the public source code from the L shader source codes, the first device can also determine M private source codes from the L shader source codes, and compile the M private source codes to obtain K private executable codes; the first device can send the target private executable code adapted to the running 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 in the rendering process, avoid complex and time-consuming shader source code compilation, and further reduce the probability of frame loss and lag in the picture rendering process, and optimize the picture rendering performance.

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

[0229] Step 1004: The first device receives second request information from the second device, and correspondingly, the second device sends second request information to the first device, the second request information being used to request to download a software installation package of a first application, the first application being one of the L applications.

[0230] The second request information includes but is not limited to the first application identifier, the second device identifier and the second device parameter. The first application identifier can be a string of characters (such as XXX01, etc.) for uniquely identifying 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 parameter can refer to the related description of the second device identifier and the second device parameter in step 605 above, which will not be repeated here.

[0231] Since the K private executable codes are executable codes obtained by the first device from the M private source codes, the first device can determine the N private executable codes corresponding to the first application from the K private executable codes according to the first application identifier. The N private executable codes are obtained by the first device according to the device parameter (such as GPU version number, etc.), so the first device can determine the target private executable code adapted to the second device running environment from the N private executable codes according to the second device parameter (i.e. an example of the device parameter), wherein the second device running environment can be determined according to the second device parameter. For example, the first application corresponds to N=2 private executable codes, wherein the first private executable code is obtained by the first device from the private source code of the first application according to GPU version A, and the second private executable code is obtained by the first device from the private source code of the first application according to GPU version B. If the second device parameter is GPU version A, the first device can determine the first private executable code as the target private executable code from the two private executable codes according to GPU version A.

[0232] In some embodiments, the above step 1003 can also be implemented by step 1005:

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

[0234] After receiving the second request information, the first device can determine the target private executable code (for details, refer to the related description of step 1004) and the software installation package of the first application according to 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 according to the first application identifier, and send (or distribute) the target private executable code and the software installation package of the first application 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 according to the first application identifier, and send the download addresses to the second device, so that the second device obtains the software installation package of the first application and the corresponding target private executable code according to the download addresses. In this way, the target private executable code and the software installation package of the first application are distributed to the second device according to the second request information, which can avoid forcibly distributing data and affecting user experience when the user has no demand.

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

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

[0237] The third parameter is an example of a device parameter, and the third parameter 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 can also include other parameters (such as device model, device system upgrade time, etc.), which are not limited in the present application.

[0238] In some scenarios, the first device can quickly determine the N private executable codes of the first application from the K private executable codes according to the first application identifier; and the N private executable codes of the first application are executable codes compiled by the first device according to device parameters (such as 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) that adapts to the second device from the N private executable codes according to the reported third parameter. For details, refer to the way of determining the target private executable code according to the second device parameter (i.e. the third parameter here) in step 1004, which is not repeated here.

[0239] After determining the target private executable code, the first device can directly distribute the target private executable code to the second device, or distribute the download address of the target private executable code, so that the second device obtains the target private executable code according to the download address.

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

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

[0242] The first operation instruction can be an operation instruction triggered by a user on an application interface of the second device, and the first operation instruction can be an installation instruction or a downloading instruction, or an update instruction. The installation instruction is used to trigger the second device to perform a downloading and installing operation. The downloading instruction is used to trigger the second device to perform a downloading operation. The update instruction is used to trigger the second device to perform an updating operation.

[0243] For example, the first operation instruction can be an operation instruction obtained by the second device from a display interface of an application market, or an operation instruction obtained by the second device from a display interface of the first application. The application market, which can also be referred to as an application store, is used to provide various software downloading, installing, and updating services for a user, to facilitate the user to view installed applications, applications to be updated, and downloading history information, and the like. In addition, the application market also displays detailed information of the application, version description, and update content, to help the user to understand changes of the application and added functions.

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

[0245] Way 1: The second device receives the 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.

[0246] The first operation instruction is an installation instruction or an update instruction. For example, the user can select an application to be installed on the application market of the second device, and trigger an 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 and the corresponding private executable code of the first application from the first device (for example, a server) according to the installation instruction.

[0247] For another example, the user can select an application to be updated on the application market of the second device, and trigger an updating 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 (which can also be referred to as a software acceleration package) and the corresponding private executable code of the first application from the first device according to the update instruction.

[0248] For the mode 1, the user can trigger the installation instruction or the update instruction on the display interface of the application market according to the user's own needs, so as to avoid that the automatic installation or the automatic update of the application occupies a large amount of network traffic and causes additional traffic consumption.

[0249] The mode 2: the second device receives the first operation instruction from the display interface of the first application, and the first operation instruction is an update instruction.

[0250] Since the first application has been installed on the second device, when the first application has a new version to be updated, the user can trigger the update operation on the display interface of the first application; correspondingly, 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 server of the first application; 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; when the first application updates the first application through the server of the first application, since the server of the first application 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 as to update the private executable code corresponding to the first application in time. It should be noted that the second device can delete the private executable code corresponding to the first application before the upgrade from the local when updating the private executable code.

[0251] As can be known from the above examples, the user can trigger the installation instruction or the update instruction on the display interface of the application market according to the user's own needs, so as to avoid that the automatic installation or the automatic update of the application occupies a large amount of network traffic, causes additional traffic consumption, and causes the local to be stuck.

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

[0253] After the second device receives the first operation instruction, the second device can generate the second request information according to the content indicated by the first operation instruction. The description of the second request information can refer to the related description of step 1004 in the above text, and will not be repeated here.

[0254] In a possible implementation, before step 1008, the above method 600 further includes step 1009.

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

[0256] In some scenarios, the updated application may not update the previously stored private executable code after the user triggers the update from the display interface of the application (e.g., the first application). Therefore, to ensure that the updated application can update the previously stored private executable code in time, when the user triggers the update from the display interface of the application, the second device generates second request information according to the first operation instruction to instruct the application market to perform the update of the first application and the download of the corresponding target private executable code, so as to avoid the situation that the application update and the private executable code update do not match, affecting the picture rendering performance. It can also be understood that, whether the user triggers the first operation instruction on the display interface of the first application or triggers the first operation instruction on the display interface of the application market, the second device will pull up the application market to perform the operation (e.g., the installation operation, the update operation, or the download operation) specified by the first operation instruction. When the second device pulls up the application market, the application market generates second request information 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 time.

[0257] The following will be described in detail in combination with FIG. 11. It should be noted that in FIG. 11, the second device is a mobile phone A (i.e., an example of the second device), wherein the mobile phone A includes a store kit located in the operating system, the store kit is a bridge between each application (e.g., a game application) and the application market, and is responsible for the information interaction between the two parties. The second device can obtain the first operation instruction through the store kit and pull up the application market to perform the update operation through the store kit. The first application is a game application, and the game application and the application market run on the operating system of the mobile phone A. The process of the mobile phone A pulling up the application market to perform the update operation is as follows:

[0258] 1) The user triggers the update operation. After starting the game application, the user can trigger the update operation on the display interface of the game application, for example, the user can click the “update or upgrade” button on the display interface of the game application to trigger the second device to perform the update operation.

[0259] 2) The game application obtains the update instruction (i.e., an example of the first operation instruction). After the user triggers the update operation, the game application obtains the update instruction corresponding to the update operation from the display interface.

[0260] 3) The game application submits an update task request. After obtaining the update instruction, the game application sends an update task request to the checkAppUpdate interface of the store kit.

[0261] 4) Storage kit pulls up application market to perform update task. After the storage kit receives the update task request through the application update interface, the storage kit sends an update task instruction to the application market to instruct the application market to perform the update task of the game application.

[0262] 5) Application market sends update request message. After the application market receives 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), the GPU version number (and / or the OS version number).

[0263] 6) Cloud server determines software upgrade package and corresponding private executable code. After the cloud server receives the update request message, the cloud server determines the software upgrade package corresponding to the game application from a plurality of application software upgrade packages according to the game application identifier; in addition, the cloud server determines N kinds of private executable code corresponding to the game application from M kinds of private executable code according to the game application identifier, and determines the private executable code (i.e., an example of the target executable code) suitable for the mobile phone A from the N kinds of private executable code according to the GPU version number (and / or the OS version number).

[0264] 7) Cloud server issues software upgrade package and corresponding private executable code. After the cloud server determines the software upgrade package and the corresponding private executable code of the game application, the cloud server issues the software upgrade package and the corresponding private executable code to the application market.

[0265] 8) Application market performs update operation according to software upgrade package and corresponding private executable code. After the application market receives the software upgrade package and the corresponding private executable code, the application market performs the update operation on the current game application according to the software upgrade package, i.e., the application market automatically installs the software upgrade package; in addition, the application market updates the private executable code issued by the cloud server to the file system module of the mobile phone A, and deletes the old version of the private executable code previously stored in the file system module.

[0266] The method 600 is described in detail above, and the application of the method 600 in different application scenarios is briefly introduced below by taking the first device as the cloud server and the second device as the mobile phone as an example.

[0267] Example 1: Application installation scenario

[0268] In some embodiments, the user can install the application needed to be used through the application market. For example, taking the user installing the XX game application (i.e., an example of the first application) from the application market as an example, as shown in FIG. 12A, the phone is installed with applications such as video, application market, browser, etc. The user can double-click the shortcut icon 1201 of the application market on the main interface of the phone. At this time, the phone enters the recommended interface 1202 of the application market, and the user can click the installation button 1203 of the XX game on the recommended interface 1202 to trigger the installation operation of the XX game, as shown in FIG. 12B. After the phone receives the installation instruction (i.e., an example of the first operation instruction) corresponding to the installation operation from the recommended interface 1202, the phone 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) to perform the downloading and installation operation. For details, please refer to the related description of the above method 1. In addition, the user can see the downloading status 1204 of the XX game during the downloading process, as shown in FIG. 12C. After the application market downloads the software installation package of the XX game, the application market will automatically install the software installation package. After the installation is completed, the state of the XX game on the recommended interface 1202 becomes the opening state 1205, and the user can start the XX application by clicking the opening state 1205 button, as shown in FIG. 12D. At the same time, after the installation is completed, as shown in FIG. 13A, the shortcut icon 1301 of the XX game is generated on the main interface of the phone, and the user can start the XX application by double-clicking the shortcut icon 1301.

[0269] Embodiment two: application side update scenario

[0270] In some embodiments, the user can trigger the application update on the application side. For example, taking the user triggering the self-update from the video application (i.e., an example of the first application) as an example, as shown in FIG. 13B, the user can double-click the shortcut icon 1302 of the video application on the main interface of the phone. At this time, the 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 there is a new version of the video application, the video application can generate an update reminder message on the user interface 1303. For example, as shown in FIG. 13C, when there is a new version of the video application, the video application can generate an update reminder interface 1304 on the user interface 1303. The user can select the "update immediately 1305" option on the update reminder interface 1304 to trigger the video application to perform the self-update. At this time, an upgrade setting interface 1306 is generated on the user interface 1303, as shown in FIG. 13D.

[0271] It should be noted that the video application can have two ways to update itself: the first way is to update through the server of the video application itself; the second way is to update through the application market; for the first way, as shown in FIG. 13D, the user can select the “Do not allow to upgrade 1307 through the application market” option on the upgrade setting interface 1306; at this time, the video application will update itself in the background, that is, the video application downloads the software upgrade package from the application server of the video application itself, and automatically installs the software upgrade package; at this time, the user can see the status identifier 1401 of the background updating on the user interface 1303, as shown in FIG. 14A; since there is no private executable code corresponding to the new version of the application (for example, the 6.1.2.3A version of the video application) on the server of the application (for example, the video application), therefore, for the case of application side update, the application market needs to monitor the update of each application, so as to update the private executable code previously stored by each application in time.

[0272] For example, when the application market monitors the update of the video application, the application market can download the private executable code corresponding to the new version of the video application from the cloud server (that is, an example of the first device); specifically, the application market can send a request message X to the cloud server, the request message X being 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 including but not limited to the video application identifier and the device parameters (for example, the GPU version number and / or the OS version number) of the mobile phone; the cloud server can determine the private executable code (that is, an example of the target private executable code) corresponding to the video application or the download address of the private executable code according to the video application identifier (that is, an example of the first application identifier) and the device parameters (that is, an example of the third parameter) of the mobile phone, which can be referred to the related description of step 1006 above, and will not be described here.

[0273] For the second, as shown in FIG. 14B, the user can select the "Always allow upgrade using application market 1402" option on the upgrade setting interface 1306, at which point the phone will jump from the video application to the application update interface 1403 shown in FIG. 14C; 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, as shown in FIG. 14C; at this point, the user can see that the update button of the video application becomes a status identifier of "download progress 1405", as shown in FIG. 14D; at this point, the application market downloads the software upgrade package and the corresponding private executable code of the new version of the video application from the cloud server; specifically, the application market can send a request message Y to the cloud server, the request message Y being used to request the cloud server to issue the software upgrade package and the corresponding private executable code of the new version of the video application, the request message Y including but not limited to the video application identifier and the device parameters (such as the GPU version number and / or the OS version number) of the phone; the cloud server can determine the software upgrade package (or the download address of the software upgrade package) and the corresponding private executable code (or the download address of the private executable code) of the new version of the video application according to the video application identifier and the device parameters of the phone, which can be referred to the related description of step 1006 above, and will not be described here.

[0274] When the cloud server determines the software upgrade package and the corresponding private executable code of the new version of the video application, it can issue the software upgrade package and the corresponding private executable code to the application market through the distribution module of FIG. 5B; after the application market receives the software upgrade package and the corresponding private executable code, it 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. 15A; at the same time, after the installation is completed, the shortcut icon 1502 of the new version of the video application will be generated on the home screen of the phone, and the user can start the video application by double-clicking the shortcut icon 1502, as shown in FIG. 15B.

[0275] In some embodiments, when the user selects the "not now" option 1503 on the update reminder interface 1304, it indicates that the user may not want to upgrade temporarily; at this time, as shown in FIG. 15D, a pause update setting interface 1504 is generated on the user interface 1303, and the user can set the duration of the pause or set when the user wants to update on the pause update setting interface 1504; for example, as shown in FIG. 15D, when the user selects the "pause duration" option 1505, the user can set how long the pause needs to be, for example, if the current date is "xxxx-06-20", the user can choose to pause until "xxxx-07-05"; the "pause duration" option 1505 can set the maximum pause duration of 30 days; when the pause time limit is reached, the video application will be automatically updated; the automatic update mode can be the "first" (or "second") mode by default. For another example, when the user selects the "update time setting" option 1506, the user can set the time period when the user wants to update, for example, the user can set the automatic update during "xxxx-07-01 18:00-20:00"; the video application automatic update mode can be the "first" (or "second") mode by default.

[0276] In some embodiments, the user can set the update of the video application by himself. For example, as shown in FIG. 16A, the user can click the "personal center" option 1601 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. 16A; the user can select the "latest upgrade" option 1603 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 in FIG. 16C; the user can select the "immediately upgrade" option 1605 or the "update setting" option 1606 on the prompt box 1604; if the user selects the "immediately upgrade" option 1605, the personal center interface 1602 will appear the same upgrade setting interface 1306 as shown in FIG. 13D; for details, please refer to the related description of FIG. 13D and FIG. 14A to FIG. 14D, which will not be repeated here. If the user selects the "update setting" option 1606, the personal center interface 1602 generates the update setting interface 1607 shown in FIG. 16D; the user can set the update mode on the "update setting interface 1607", for example, if the user selects the "automatic update" option 1608, the next time the video application has a new version, it will be automatically updated without asking the user whether to update immediately; if the user selects the "ask whether to update" option 1609, the next time the video application has a new version, it will first ask the user whether to update, and will not be automatically updated, as shown in FIG. 16D.

[0277] Implementation three: application market update scenario

[0278] In some embodiments, the user can update the current application through the application market. For example, as shown in FIG. 12A, the user can double-click the shortcut icon 1201 of the application market on the home interface of the mobile phone, so that the mobile phone enters the recommendation interface 1202 of the application market; after the mobile phone enters the recommendation interface 1202, as shown in FIG. 17A, the user can click the "my" option 1701 on the recommendation interface 1202 to open the "my" main interface 1702 (see FIG. 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, as shown in FIG. 17C; for example, the user can click the "update" 1704 button of the video application to trigger the update operation, as shown in FIG. 17C; at this time, the user can see that the update 1704 button of the video application becomes the status identifier of the "download progress" 1705, as shown in FIG. 17D; at this time, the application market downloads the software upgrade package and the corresponding private executable code of the new version of the video application from the cloud server, which can be referred to the related description of the "second" automatic update method in the above embodiment two, and details are not described here. After the application market receives the software upgrade package and the corresponding private executable code issued by the cloud server, the software upgrade package is automatically installed, and the private executable code is used to update the old private executable code stored in the local file system module; after the installation is completed, as shown in FIG. 18A, the state of the video application on the application update interface 1403 changes from the update button to the open button 1801; the user can start the updated video application by clicking the "open button" 1801.

[0279] Embodiment four: download method of public executable code and private executable code

[0280] In some embodiments, as shown in FIG. 18B, the user can select the "public acceleration package download 1802" option on the "my" main interface 1702; at this time, as shown in FIG. 18C, 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, as shown in FIG. 18C, if the user selects the "detect update 1804" option, when the application market detects that there is an application update on the phone, it will obtain the public executable code from the cloud server (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 application market will obtain the public executable code from the cloud server according to the system set time interval (i.e. the application market will obtain the public executable code from the cloud server within the preset time period).

[0281] For another example, as shown in FIG. 18B, 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 the "private acceleration package" download interface 1807 shown in FIG. 18D; the user can select the private acceleration package corresponding to the application to be downloaded on the download interface 1807; for example, as shown in FIG. 18D, 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 latest private executable code corresponding to the video application on the cloud server; specifically, the application market can send a request message Z to the cloud server, 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 (such as GPU version number and / or OS version number); the cloud server can determine the private executable code (or the download address of the private executable code) corresponding to the new version of the video application according to 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, which can be referred to the related description of step 1006 above, and will not be described here.

[0282] The above describes an example of the compiling method provided in the present application in detail. It can be understood that the electronic device includes hardware structures and / or software modules corresponding to the execution of each function in order to implement the above functions. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is implemented in hardware or computer software driven hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application. The present application can divide the functions of the compiling method into functional units according to the above method examples, for example, each function can be divided into a functional unit, or two or more functions can be integrated into one unit. The integrated unit can be implemented in the form of hardware or software functional unit. It should be noted that the division of units in the present application is illustrative and is only a logical functional division. There can be another division method when actually implemented.

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

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

[0285] The above electronic device 1900 can 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 method shown in each of the above embodiments.

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

[0287] For another example, the communication unit 1905 can be a transceiver of the electronic device 1900, or the communication unit 1905 can be a transceiving circuit of the electronic device 1900. One or more memories 1902 can be included in the electronic device 1900, and the memories 1902 have programs 1904 stored thereon, which can be run by the processor 1901 to generate instructions 1903, so that the processor 1901 performs the methods described in the above method embodiments according to the instructions 1903. Alternatively, the memories 1902 can also store data. Alternatively, the processor 1901 can also read the data stored in the memories 1902, and the data can be stored in the same storage address as the programs 1904, or the data can be stored in different storage addresses from the programs 1904.

[0288] The processor 1901 and the memories 1902 can be separately arranged or integrated together, for example, integrated on a system on chip (SOC) of the electronic device. The processor 1901 performs the specific manners of compiling methods, which can be referred to the related descriptions in the method embodiments.

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

[0290] The present application also provides a computer program product, which is executed by the processor 1901 to implement the method of any method embodiment in the present application. The computer program product can be stored in the memories 1902, for example, the programs 1904, which are finally converted into executable object files that can be executed by the processor 1901 through preprocessing, compiling, assembling, and linking processes.

[0291] The present application also provides a computer readable storage medium, which has a computer program stored thereon, and the computer program is executed by a computer to implement the method of any method embodiment in the present application. The computer program can be a high-level language program or an executable object program.

[0292] The computer readable storage medium is, for example, the memory 1902. The memory 1902 can be a volatile memory or a nonvolatile memory, or the memory 1902 can include both volatile and nonvolatile memory. The nonvolatile memory can be a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically EPROM (EEPROM), or a flash memory, for example. The volatile memory can be a random access memory (RAM), which is used as the external cache. By way of example, and not limitation, many forms of RAM are available, for example, a static RAM (SRAM), a dynamic RAM (DRAM), a synchronous dynamic RAM (SDRAM), a double data rate SDRAM (DDR SDRAM), an enhanced SDRAM (ESDRAM), a synchlink DRAM (SLDRAM), and a direct rambus RAM (DRRAM). The computer readable storage medium can also be other media capable of storing digital information such as, but not limited to, a hard disk, a floppy disk, or a tape.

[0293] 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 apparatuses and the generated technical effects can refer to the corresponding processes and technical effects in the foregoing method embodiments, and will not be described here.

[0294] In several embodiments provided in the present application, the disclosed system, device and method can be implemented in other ways. For example, some features of the above-described method embodiments can be omitted or not performed. The above-described device embodiments are merely illustrative, and the splitting of units is only a logical function splitting, and actual implementation can have another splitting manner, and multiple units or components can be combined or integrated into another system. In addition, the coupling between units or the coupling between components can be direct coupling or indirect coupling, and the above coupling includes electrical, mechanical or other forms of connection.

[0295] The above examples are only used to illustrate the technical solutions of the present application, rather than limit them. Although the present application has been described in detail with reference to the foregoing examples, it should be understood by those of ordinary skill in the art that modifications to the technical solutions described in the foregoing examples, or equivalent replacements of some of the technical features, can still be made without departing from the spirit and scope of the technical solutions of the embodiments of the present application, and all such modifications and replacements should be included in the protection scope of the present application.

[0296] Finally, the above is only a specific implementation of the present application, but the protection scope of the present application is not limited to this. Any change or replacement within the technical scope disclosed by the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method of compiling, characterized by, Applied to a first device, the method comprises: Obtaining L kinds of shader source codes, the L kinds of shader source codes being source codes corresponding to L applications, L being an integer greater than 1; Determining a common source code from the L kinds of shader source codes, the common source code being a part common in the L kinds of shader source codes; Compiling the common source code to obtain N kinds of common executable codes, the N kinds of common executable codes being used to adapt to N running environments, N being a positive integer; Sending a target common executable code to a second device, the target common executable code being one of the N kinds of common executable codes adapted to a running environment of the second device.

2. The method of claim 1, wherein, The method further comprises: Determining M kinds of private source codes from the L kinds of shader source codes, the M kinds of private source codes being parts other than the common source code in the L kinds of shader source codes, M being a positive integer less than or equal to L; Compiling the M kinds of private source codes respectively to obtain K kinds of private executable codes, the K kinds of private executable codes being used to adapt to the N running environments, K=M*N, K being a positive integer; Sending a target private executable code to the second device, the target private executable code being one of the K kinds of private executable codes adapted to the running environment of the second device.

3. The method according to claim 1 or 2, characterized in that, The obtaining of the L kinds of shader source codes comprises: Obtaining the L kinds of shader source codes from at least one terminal device, the at least one terminal device being used to run the L applications.

4. The method of claim 3, wherein, The obtaining of the L kinds of shader source codes from the at least one terminal device comprises: Obtaining the L kinds of shader source codes from a shader of the at least one terminal device, a running mode of the shader being a debugging mode.

5. The method of claim 4, wherein, The first device comprises a collection module used to obtain shader source codes, and the obtaining of the L kinds of shader source codes from the shader of the at least one terminal device comprises: Obtaining the L kinds of shader source codes from the shader of the at least one terminal device through the collection module, a running mode of the shader being a debugging mode.

6. The method of claim 3, wherein, The first device comprises a collection module used to obtain shader source codes, and the obtaining of the L kinds of shader source codes from the at least one terminal device comprises: Obtaining the L kinds of shader source codes from the at least one terminal device through the collection module.

7. The method according to any one of claims 2 to 6, characterized in that, The determining of the M kinds of private source codes from the L kinds of shader source codes comprises: Determining the M kinds of private source codes from the L kinds of shader source codes according to a first parameter, the first parameter comprising usage frequency information, and M being less than L.

8. The method according to any one of claims 1 to 7, characterized in that, The determining of the common source code from the L kinds of shader source codes comprises: Determining the common source code from the L kinds of shader source codes according to a first parameter, the first parameter comprising usage frequency information.

9. The method according to any one of claims 2 to 8, characterized in that, The compiling of the M kinds of private source codes respectively comprises: Compiling the M kinds of private source codes respectively according to a second parameter, the second parameter comprising 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 common source code comprises: compile the common source code according to a second parameter, the second parameter comprising at least one of a graphic 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 the sending the target private executable code to the second device, the method further comprises: receiving second request information from the second device, the second request information being used to request downloading a software installation package of a first application, the first application being one of the L applications; the sending the target private executable code to the second device comprises: in response to the second request information, sending the software installation package of the first application and the target private executable code to the second device.

12. The method of claim 11, wherein, the second request information comprises a third parameter and a first application identifier, the third parameter being used to determine a running environment of the second device, and before the sending the software installation package of the first application and the target private executable code to the second device, the method further comprises: determining the target private executable code from the K 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 the sending the target common executable code to the second device, the method further comprises: receiving first request information from the second device, the first request information being used to request obtaining the target common executable code; the sending the target common executable code to the second device comprises: in response to the first request information, sending the target common executable code to the second device.

14. The method of claim 13, wherein, the receiving the first request information from the second device comprises: receiving the first request information from the second device within a preset time period.

15. The method according to claim 13 or 14, characterized in that, the first request information comprises a third parameter, the third parameter being used to determine a running environment of the second device; before the sending the target common executable code to the second device, the method further comprises: determining the target common executable code from the N common executable codes according to the third parameter.

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

17. A method of compiling, characterized by, applied to a second device, the method comprises: sending first request information, the first request information being used to request obtaining a target common executable code, the target common executable code being one of N common executable codes that is adapted to a running environment of the second device, the N common executable codes being compilation results of a common source code, the common source code being a part that is common in L shader source codes, the L shader source codes being source codes corresponding to shaders of L applications, the L being an integer greater than 1, the N being a positive integer; receiving the target common executable code.

18. The method of claim 17, wherein, the sending the first request information comprises: sending the first request information within a preset time period.

19. The method of claim 17 or 18, wherein, the first request information comprises a third parameter, the third parameter being used to determine the running environment of the second device and used to determine the target common executable code.

20. The method of any one of claims 17-19, wherein, the method further comprises: sending second request information, the second request information being used for requesting to download a software installation package of a first application, the first application being one of the L applications; receiving the software installation package of the first application and the target private executable code.

21. The method of claim 20, wherein, The second request information comprises a third parameter and a first application identifier, the third parameter being used for determining a running environment of the second device, and the third parameter and the first application identifier being used for determining the target private executable code.

22. The method of claim 19 or 21, wherein, The third parameter comprises at least one of a GPU version number of the second device or an OS version number of the second device.

23. The method of any one of claims 20-22, wherein, Before the sending of the second request information, the method further comprises: receiving a first operation instruction, the first operation instruction being used for triggering the downloading of the software installation package of the first application; generating the second request information according to the first operation instruction.

24. The method of claim 23, wherein, The receiving of the first operation instruction comprises: receiving the first operation instruction from a display interface of an application market, the application market being run on the second device, and the first operation instruction being an installation instruction or an update instruction.

25. The method of claim 24, wherein, The receiving of the first operation instruction comprises: receiving the first operation instruction from a display interface of the first application, the first operation instruction being an update instruction.

26. The method of any one of claims 23-25, wherein, Before the generating of the second request information according to the first operation instruction, the method further comprises: generating the second request information according to the first operation instruction, the application market being run on the second device.

27. An electronic device, comprising: The electronic device comprises a processor and a memory, the memory being used for storing a computer program, and the processor being used for calling and running the computer program from the memory, so that the electronic device executes the method in any one of claims 1 to 16, or so that the electronic device executes the method 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, and when the computer program is executed by a processor, the processor executes the method in any one of claims 1 to 16, or the processor executes the method in any one of claims 17 to 26.

29. A chip system, characterized by The chip system comprises a memory and a processor, the processor being configured to execute a computer program stored in the memory, so as to implement the method in any one of claims 1 to 16, or so as to implement the method in any one of claims 17 to 26.

Images