Compilation methods, electronic devices, and computer-readable storage media

Abstract

This application relates to the field of terminal technology, and provides a compilation method, an electronic device, and a computer-readable storage medium. The method includes: obtaining L types of shader source code, where the L types of shader source code are the source code corresponding to the shaders of L applications, and L is an integer greater than 1; determining common source code from the L types of shader source code, where the common source code is the part shared by the L types of shader source code; compiling the common source code to obtain N types of common executable code, where the N types of common executable code are used to adapt to N types of runtime environments, and N is a positive integer; and sending target common executable code to a second device, where the target common executable code is one of the N types of common executable code adapted to the runtime environment of the second device. This method can reduce the probability of frame drops and stuttering during image rendering, which is beneficial for optimizing image rendering performance.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to compilation methods, electronic devices, and computer-readable storage media. Background Technology

[0002] With the development of image processing technology, shaders are commonly used in game development, graphic design, film and animation production for image rendering and visual effects. A shader is a small program that runs on a graphics processing unit (GPU) and controls various stages of the image rendering process, such as calculations for color, texture coordinates, and lighting.

[0003] For applications that require image rendering (such as games and video applications), the software installation packages downloaded from app stores typically include shader source code. Once these applications are installed on the user's device, they can be launched normally. However, since shader source code cannot run directly on the GPU hardware, the user's device needs to compile the shader source code into executable machine code (or executable instructions) for the GPU to perform image rendering.

[0004] However, as certain scenarios (such as games and animations) place increasingly higher demands on smoothness, image clarity, and realism, the compilation of complex and time-consuming shader source code can lead to frame drops and stuttering during the rendering process. For example, a game application that requires a frame rate of 60 frames per second has an average rendering time of only 16.6 milliseconds (ms) per frame. However, the compilation of shader source code can sometimes take tens to hundreds of milliseconds. This time-consuming compilation process often results in frame drops and stuttering during game execution. Summary of the Invention

[0005] To this end, this application provides a compilation method, an electronic device, and a computer-readable storage medium that can reduce the probability of frame drops and stuttering during screen rendering, thereby improving screen rendering performance.

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

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

[0008] Obtain L types of shader source code, where L is an integer greater than 1, representing the source code corresponding to the shaders of L applications. Identify common source code from the L types of shader source code, representing the common parts shared by all L types of shader source code. Compile the common source code to obtain N types of common executable code, which are used to adapt to N different runtime environments, where N is a positive integer. Send the target common executable code to the second device, where the target common executable code is one of the N common executable codes adapted to the runtime environment of the second device.

[0009] The first device can refer to a server. The compilation method can be executed by the server, or by a module applied to the server (such as a processor, chip, or chip system), or by a logic module or software that can implement all or part of the server's functions.

[0010] In the rendering process, one approach is to compile and render simultaneously, which often results in frame drops and stuttering. In this application, the first device can identify common source code from L shader source codes and compile it. Finally, it sends the target common executable code adapted to the second device's runtime environment to the second device. When performing rendering operations, the second device can directly call the common executable code without compiling the common source code, thereby reducing the amount of compilation during image rendering, lowering the probability of frame drops and stuttering, and optimizing rendering performance.

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

[0012] In some scenarios, in addition to determining the common source code from L shader source codes, the first device can also determine M private source codes from the L shader source codes, and compile these M private source codes to obtain K private executable codes. The first device can send the target private executable code adapted to the second device's runtime environment to the second device, so that the second device can directly call the target common executable code and the target private executable code to perform image rendering during the rendering process, avoiding the compilation of complex and time-consuming shader source codes, thereby further reducing the probability of frame drops and stuttering during the rendering process and optimizing the rendering performance.

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

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

[0015] In one possible implementation, obtaining L shader source codes from at least one terminal device includes: obtaining L shader source codes from the shaders of at least one terminal device, wherein the shaders are running in debug mode.

[0016] In some scenarios, terminal devices can obtain shader source code through their own shaders. For example, when an application is running, the terminal device can set the shader's running mode to debug mode to obtain L shader source codes without designing a dedicated source code inspection module, which can reduce the cost of obtaining source code.

[0017] In one possible implementation, the first device includes a acquisition module for acquiring shader source code. Acquiring L types of shader source code from the shader of at least one terminal device includes: acquiring L types of shader source code from the shader of at least one terminal device through the acquisition module, wherein the shader is running in debug mode.

[0018] In some scenarios, the first device can obtain L shader source codes from the shader of at least one terminal device through the acquisition module. This eliminates the need for manual collection of L shader source codes and the need to design a dedicated source code detection module. This source code acquisition method is efficient, convenient, and low-cost.

[0019] In one possible implementation, the first device includes a acquisition module for acquiring shader source code. Acquiring L types of shader source code from at least one terminal device includes: acquiring L types of shader source code from at least one terminal device through the acquisition module.

[0020] In some scenarios, compared to manually collecting the source code of L shaders, the first device can automatically obtain the source code of L shaders from at least one terminal device through the acquisition module, which is simple, efficient and low-cost.

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

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

[0023] In one possible implementation, determining common source code from L shader source codes includes: determining common source code from L shader source codes based on a first parameter, the first parameter including usage frequency information.

[0024] In some scenarios, in order to ensure that the common source code determined from the L shader source codes is widely available, this application uses a first parameter (e.g., frequency information) to filter out the shader source codes that are called (or used) frequently from the L shader source codes as common source codes, so that the common executable code obtained by compiling the common source code can be called by a variety of applications, thereby reducing the probability of more applications experiencing frame drops and stuttering during the rendering process.

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

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

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

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

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

[0030] In some scenarios, the first device can send the target private executable code and the software installation package of the first application to the second device based on the second request information, so as to avoid forcibly sending data when the user does not need it and affecting the user experience.

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

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

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

[0034] In some scenarios, the first device can send the target publicly executable code to the second device based on the first request information, so as to avoid forcibly sending data when the user does not need it and affecting the user experience.

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

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

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

[0038] Since different devices may have different operating environments, the second device can report a third parameter to the first device through the first request information, so that the first device can determine the target common executable code that is compatible with the operating environment of the second device from N kinds of common executable code according to the third parameter, and avoid erroneously sending executable code that does not match the operating environment of the device.

[0039] In one possible implementation, 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.

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

[0041] Secondly, another compilation method is provided for application to the second device, which includes:

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

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

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

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

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

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

[0048] Since different devices may have different operating environments, the second device can report a third parameter to the first device through the first request information, so that the first device can determine the target common executable code that is compatible with the operating environment of the second device from N kinds of common executable code according to the third parameter, and avoid erroneously sending executable code that does not match the operating environment of the device.

[0049] In one possible implementation, the method further includes: sending a second request message for requesting the download of a software installation package of a first application, wherein the first application is one of L applications; and receiving the software installation package of the first application and the target private executable code.

[0050] In some scenarios, the first device can send the target private executable code and the software installation package of the first application to the second device based on the second request information, so as to avoid forcibly sending data when the user does not need it and affecting the user experience.

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

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

[0053] In one possible implementation, 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.

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

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

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

[0057] In some cases, users can trigger installation or update commands on the app store's display interface according to their needs to avoid automatic installation or updates consuming excessive network bandwidth, causing additional data usage and system lag.

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

[0059] In some cases, users can trigger an update command on the first application's display interface according to their needs, in order to avoid automatic application updates consuming a lot of network traffic, causing additional data consumption and system lag.

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

[0061] In some scenarios, when a user triggers an update from the display interface of an application (e.g., the first application), the updated application may not have updated the previously stored private executable code. To ensure that the updated application can update the previously stored private executable code in a timely manner, even though the user triggers the update from the application's display interface, the second device still instructs the application market to generate a second request message according to the first operation instruction. This controls the application market to execute the update of the first application and download the corresponding target private executable code, thereby avoiding a mismatch between the application update and the private executable code update that could affect the screen rendering performance.

[0062] Thirdly, embodiments of this application provide an electronic device including a processor and a memory. The memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, causing the electronic device to perform the methods described in the first aspect and various possible implementations of the first aspect.

[0063] Fourthly, embodiments of this application provide an electronic device including a processor and a memory. The memory stores a computer program, and the processor retrieves and runs the computer program from the memory, causing the electronic device to perform the methods described in the second aspect and various possible implementations of the second aspect.

[0064] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the methods described in the first aspect and various possible implementations of the first aspect.

[0065] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the methods described in the second aspect and various possible implementations of the second aspect.

[0066] In a seventh aspect, embodiments of this application provide a computer program product, which includes computer program code that, when executed by a terminal device, causes the terminal device to perform the methods described in the first aspect and various possible implementations of the first aspect.

[0067] Eighthly, embodiments of this application provide a computer program product comprising: computer program code, which, when executed by a terminal device, causes the terminal device to perform the methods described in the second aspect and various possible implementations of the second aspect.

[0068] Ninthly, embodiments of this application provide a chip system including a processing circuit and a storage medium storing computer program instructions; when the computer program instructions are executed by the processing circuit, they implement the methods described in the first aspect and various possible implementations of the first aspect.

[0069] In a tenth aspect, embodiments of this application provide a chip system including a processing circuit and a storage medium storing computer program instructions; when the computer program instructions are executed by the processing circuit, they implement the methods described in the second aspect and various possible implementations of the second aspect.

[0070] Optionally, the processing circuitry in the above-mentioned chip system can be replaced by a processor, and the storage medium can be replaced by a memory. Optionally, the chip system may also include a communication interface for enabling communication between the chip system and a receiving device.

[0071] The beneficial effects of the technical solutions in the third to tenth aspects of this application can be the same as the beneficial effects of the technical solutions in the first or second aspects, and will not be repeated here. Attached Figure Description

[0072] Figure 1 This is a schematic diagram of an image rendering scene provided in an embodiment of this application;

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

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

[0075] Figure 4 This application provides a schematic diagram of the software architecture of a terminal device.

[0076] Figures 5A to 5B These are schematic diagrams illustrating two application scenarios provided in the embodiments of this application;

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

[0078] Figures 7A to 7C These are schematic diagrams illustrating three application scenarios provided in the embodiments of this application;

[0079] Figures 8A to 8B These are schematic diagrams illustrating two more application scenarios provided in the embodiments of this application;

[0080] Figure 9 This application provides an embodiment of an interaction diagram between a first device and a second device.

[0081] Figure 10 This application provides another schematic diagram illustrating the interaction between a first device and a second device.

[0082] Figure 11 A schematic diagram illustrating the process of an application market performing an update operation, provided as an embodiment of this application;

[0083] Figures 12A to 12D This is a schematic diagram of an application installation scenario provided in an embodiment of this application;

[0084] Figures 13A to 13D This is a schematic diagram of an application update scenario provided in an embodiment of this application;

[0085] Figures 14A to 14D This is a schematic diagram illustrating another application update scenario provided in the embodiments of this application;

[0086] Figures 15A to 15D This is a schematic diagram illustrating a scenario where updates are not performed temporarily, as provided in an embodiment of this application.

[0087] Figures 16A to 16D This is a schematic diagram of an update setting scenario provided in an embodiment of this application;

[0088] Figures 17A to 17D This is a schematic diagram illustrating another application update scenario provided in the embodiments of this application;

[0089] Figures 18A to 18D This is a schematic diagram of an accelerated package download scenario provided in an embodiment of this application;

[0090] Figure 19 This is a schematic diagram of the structure of an electronic device 1900 provided in an embodiment of this application. Detailed Implementation

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

[0092] In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. In the description of this application, "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. "At least one" means one or more, and "more" means two or more. The terms "first" and "second," etc., in the specification and claims of this application are used to distinguish different objects or to distinguish different treatments of the same object, not to describe a specific order of objects. For example, "first terminal" and "second terminal," etc., are used to distinguish different terminal devices, not to describe a specific order of terminal devices. Those skilled in the art will understand that the words "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply difference.

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

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

[0095] 1. Shader

[0096] Shaders are used to implement image rendering, replacing editable programs in a fixed rendering pipeline. Shaders are typically small programs that execute on a graphics processing unit (GPU) to control different aspects of graphics, such as color, lighting, texture mapping, and projection. During image rendering, shaders are used to process the geometry of the scene and calculate the final color or attributes for each pixel or vertex. Shaders generally consist of two types: vertex shaders and fragment shaders. Vertex shaders are primarily responsible for calculations related to the geometric relationships of vertices, such as calculating the final position, color, and normals of each vertex; they can also perform coordinate transformations, lighting calculations, and vertex animations. Fragment shaders, also known as pixel shaders, are primarily responsible for calculations such as fragment color; for example, fragment shaders can process each pixel to calculate its final color; they can also perform texture sampling, lighting calculations, and shadow calculations to generate the final image.

[0097] 2. Shader source code

[0098] Shader source code is the source code written by software developers when writing software to implement image rendering. This shader source code is usually packaged into the software installation package and ultimately installed on the terminal device through app stores or other channels (such as browsers).

[0099] 3. Shader compilation

[0100] Since shader source code itself cannot run directly on specific hardware (such as GPUs) or operating systems, but needs to be compiled into executable instructions (shader bins) to run on hardware; therefore, shader compilation is the process of converting shader source code into machine code programs that can be executed on specific hardware (such as GPUs) or operating systems; these executable machine code programs can also be called executable code, executable programs, or executable instructions (shader bins).

[0101] 4. GPU

[0102] A GPU, also known as a graphics processing unit, is a microprocessor specifically designed for performing image and graphics-related computations in personal computers, workstations, game consoles, and some mobile devices (such as tablets and smartphones). GPUs reduce the reliance of graphics cards on the CPU and perform some of the tasks that were originally handled by the CPU, especially in 3D graphics processing. Core technologies employed by GPUs include hardware T&L (geometry transformation and lighting processing), cubic environment mapping and vertex blending, texture compression and bump mapping, and dual-texture four-pixel 256-bit rendering engines.

[0103] The following is combined with Figure 1 The image rendering scene shown illustrates the technical problem that this application needs to solve.

[0104] like Figure 1 As shown, a terminal device has applications such as games and videos installed. When a user launches these applications, the terminal device executes code related to image rendering. Before executing the image rendering function, the terminal device first checks whether a compiled shader bin file is stored in its internal file system or memory. If so, it means the application has already run on the terminal device, and the terminal device can read the compiled shader bin file from the file system or memory for image rendering. If not, it means the application is running on the terminal device for the first time. In this case, the terminal device can pass the shader source code to the shader through the system interface and trigger the shader to compile the shader source code into a shader bin file. Finally, the shader's caching function is used to cache the compiled shader bin file in the file system or memory so that the terminal device can read the compiled shader from the file system or memory. Image rendering is performed using bin files. Therefore, in scenarios where application software runs for the first time on a terminal device, the pre-compiled shaderbin file does not exist in the terminal device's file system or memory because the application software is performing image rendering for the first time. In this case, the terminal device needs to trigger real-time compilation of the shader source code during image rendering. However, this complex and time-consuming compilation of shader source code can lead to frame drops and stuttering during image rendering. To address this, this application proposes a compilation method that reduces the probability of frame drops and stuttering during image rendering, thus optimizing image rendering performance.

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

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

[0107] To better understand the embodiments of this application, the following is combined with... Figure 2 This application describes a hardware structure for an electronic device 100; the electronic device 100 may refer to a first device (or a second device).

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

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

[0110] The processor 110 can generate operation control signals based on the instruction opcode and timing signals to control the instruction fetching and execution.

[0111] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 may be a cache memory. This memory can store instructions or data that the processor 110 has used or that are used frequently. If the processor 110 needs to use the instruction or data, it can directly retrieve it from this memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0112] In some embodiments, the processor 110 may include one or more interfaces. These interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal serial bus (USB) interface, etc. The processor 110 can connect to modules such as wireless communication modules and displays through at least one of these interfaces.

[0113] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0114] USB connector 130 is a USB standard-compliant interface used to connect electronic device 100 and peripheral devices. Charging management module 140 receives charging input from a charger, which can be either a wireless or wired charger. Power management module 141 connects to battery 142, and charging management module 140 connects to processor 110. Power management module 141 receives input from battery 142 and / or charging management module 140 to power processor 110, internal memory 121, display screen 170, and wireless communication module 160, etc. In some embodiments, power management module 141 and charging management module 140 may also be housed in the same device.

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

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

[0117] The wireless communication module 160 can provide wireless communication solutions for use on electronic devices 100, including wireless local area networks (WLAN) (such as Wi-Fi networks), Bluetooth (BT), and near field communication (NFC) technologies.

[0118] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other terminal devices via wireless communication technology. This wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), etc.

[0119] Electronic device 100 can implement display functions through GPU, display screen 170, and application processor. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0120] The external storage 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 storage interface 120 to perform data storage functions. For example, it can save images, videos, and other files to the external memory card, or transfer images, videos, and other files from the electronic device 100 to the external memory card.

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

[0122] Electronic device 100 can display image data such as game screens and movie animations on display screen 170.

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

[0124] It should be noted that in some scenarios, such as when electronic device 100 is a terminal device, most applications running on the terminal device require screen display; therefore, electronic device 100 needs to include a display screen 170. This display screen 170 can display various images in conjunction with the image rendering process of each application. In other scenarios, such as when electronic device 100 is a server, which mainly provides computing services, such as compiling shader source code, and does not require screen display, the server may not need to include a display screen 170. Another example is in scenarios where a server connects to a physical terminal (see below). Figure 8A Since the applications run on physical terminals with displays, the server primarily provides computing power (e.g., compilation services), therefore, the server may not need a display screen. Of course, in some scenarios, the server can also have a display screen, for example, see below. Figure 8BThe server is equipped with various virtual terminals that are used to run applications that require screen display, such as games and videos. In this case, the server needs to be equipped with a 170-degree display screen.

[0125] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also include... Figure 2 More or fewer components, or combining some components, or splitting some components, or different component arrangements. Figure 2 The components can be implemented in hardware, software, or a combination of both.

[0126] Furthermore, it should be noted that the software system of the aforementioned electronic device 100 can adopt a layered architecture or a service architecture, etc. This embodiment of the invention uses the layered architecture of the Android operating system as an example to exemplify the software architecture of the electronic device 100. It should be understood that the solution provided in this application can also be applied to other types of operating systems such as HarmonyOS, Apple operating systems, and Windows operating systems.

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

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

[0129] The application framework layer (FWK) provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions. For example... Figure 3As shown, the application framework layer can include a graphics manager, video codec, window manager, resource manager, notification manager, and content manager. The graphics manager is responsible for calling interfaces in the graphics library to complete drawing, rendering, and compositing the interface; the video codec is responsible for video encoding and decoding; the window manager manages all windows in the system; the resource manager manages system resources and provides various resources to the application, such as images and video files; the notification manager manages notification messages in the phone's top status bar; and the content provider stores and retrieves data (such as videos and images) and makes this data accessible to the application.

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

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

[0132] The core library primarily provides basic Java class library functionalities, such as libraries for fundamental data structures, mathematics, I / O, tools, databases, and networking. It also provides APIs for users to develop Android applications.

[0133] The Hardware Abstraction Layer (HAL) runs in user space, encapsulates kernel-level drivers, and provides calling interfaces to the upper layers. The HAL includes modules such as the display module and the Bluetooth module.

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

[0135] The following uses Figure 2 and Figure 3 Taking the second device in the structure shown as a terminal device as an example, combined with... Figure 4 The illustrated software architecture diagram of the terminal device serves as an example to illustrate the overall process of the terminal device executing the above compilation method.

[0136] When a user opens a game application at the application layer, the game application runs on the terminal device's operating system (OS). During graphics rendering, the game application generates a rendering request and sends it to the graphics manager. The graphics manager generates shader source instructions based on the rendering request and sends them to the shader module in the system library. Upon receiving the shader source, the shader module checks if a compiled shader bin file exists in the file system module. If so, it generates an image rendering instruction stream (e.g., scene drawing instructions, interface drawing instructions, etc.) based on the shader bin file. The shader module sends the image rendering instruction stream to the GPU driver. The GPU driver generates a rendering driver instruction stream based on the image rendering instruction stream and sends it to the GPU. The GPU instructs the display driver to push frames to the display screen based on the rendering driver instruction stream, thus rendering the game screen.

[0137] It should be noted that the software architecture of electronic device 100 is not limited to Figures 2 to 4 The hardware and software system architecture shown can be adapted to specific application scenarios in practical applications. Figures 2 to 4 The hardware and software system architecture shown may be modified, but this application does not limit it.

[0138] The above provides a detailed description of the hardware and software system architecture of the electronic device 100 to which this application applies. Below, we will further discuss... Figure 5A and Figure 5B Two application scenario architectures applicable to this application are introduced.

[0139] Figure 5AThis paper illustrates an application scenario where a terminal device obtains a public shader bin file (also known as public executable code) and a private shader bin file (also known as private executable code) from a cloud server. In some scenarios, the terminal device (i.e., an example of a second device) can send a download request X to the cloud server (i.e., an example of a first device). This download request X is used to request the download of the software installation package of application 1 (i.e., an example of the first application) (or the software installation package of application 2). After receiving the download request X, the cloud server sends the software installation package A and the private shader bin file A (or sends the software installation package B and the private shader bin file B) to the terminal device. After receiving the software installation package A and the private shader bin file A (or receiving the software installation package B and the private shader bin file B), the terminal device can store the private shader bin file A (or the private shader bin file B) in the OS's file system module so that the shader module can call it when performing image rendering functions.

[0140] In other scenarios, the terminal device can also send a download request Y to the cloud server to request the download of a public shader bin file. After receiving the download request Y, the cloud server sends the public shader bin file to the terminal device. After receiving the public shader bin file, the terminal device can store the public shader bin file in the aforementioned file system module so that the shader module can call it when performing image rendering functions.

[0141] When application 1 (or application 2) calls the shader module during image rendering, the terminal device will trigger the shader module located in the operating system to check if the file system module has a pre-compiled shader bin file (e.g., private shader bin file A). For example, if the shader module finds a pre-compiled shader bin file in the file system module, the shader module can directly read the public shader bin file and private shader bin file A from the file system module to perform image rendering (or trigger the shader module to read the public shader bin file and private shader bin file B from the file system module to perform image rendering) without triggering a compilation action.

[0142] Figure 5BThis illustrates an application scenario where a terminal device (an example of a second device) interacts with a cloud server (an example of a first device). This scenario is applicable to software installation scenarios (e.g., the installation and updating of applications within an app store, and updates of applications outside of app stores). In this scenario, the cloud server and the terminal device can communicate with each other, for example, by sending request messages and software installation packages via a wireless network. The cloud server includes an automated data collection module, a compilation module, and a distribution module. The processing and interaction flow of these modules is as follows:

[0143] The automated acquisition module, also known as the acquisition module, is used to acquire the shader source code of multiple applications (e.g., L shader source codes below) from at least one terminal device, and also to send the acquired shader source code to the compilation module.

[0144] The compilation module is used to determine the public and private source code, and to compile the public and private source code separately. For example, after receiving the shader source code sent by the automated acquisition module, the compilation module determines the public and private source code (e.g., M types of private source code) based on the shader source code; then it compiles the public and private source code separately to obtain public shader bin files (e.g., N types of public executable code below) and private shader bin files (e.g., K types of private executable code below). For details, please refer to the examples below, which will not be elaborated here.

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

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

[0147] When application 1 (or application 2) calls the shader module during image rendering (or when calling the image rendering interface shader module), the terminal device triggers the shader module to check if a pre-compiled shader bin file (e.g., private shader bin file A) exists in the file system module. If it does, the shader module can directly call the public and private shader bin files (e.g., private shader bin file A or private shader bin file B) from the file system module to perform image rendering without triggering a compilation operation. If not, the compilation operation needs to be triggered again. The shader module is a module located in the operating system used to perform image rendering functions. When performing image rendering functions, the shader module usually prioritizes using the pre-compiled shader bin file in the file system module. The compilation operation is only triggered when the file system module does not have a pre-compiled shader bin file. In addition, the operating system also includes a store kit, which is used to provide software distribution-related interfaces and to launch the application market to perform application updates (see the following examples for details, which will not be elaborated here).

[0148] The above describes several application scenarios applicable to this application. The following section provides illustrative examples of the compilation method provided in the embodiments of this application, with reference to the accompanying drawings.

[0149] like Figure 6 The diagram shown is a flowchart of a compilation method 600 provided in an embodiment of this application. Before introducing the method 600 provided in this application, a brief description of the execution entities involved in the embodiments of this application will be given. In this application, the first device can be a server, and the second device can be a terminal device; the above-mentioned compilation method can be executed by the first device (or the second device), or by a module (such as a processor, chip, or chip system, etc.) applied in the first device (or the second device), or by a logic module or software that can implement all or part of the functions of the first device (or the second device).

[0150] The aforementioned first device can be equipped with Figure 2 and Figure 3 The server has a hardware and software architecture, and the second device can be a server with... Figure 2 and Figure 3 Terminal devices with both hardware and software architectures. It should be noted that the first device and the second device can communicate with each other, for example, through a wireless network.

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

[0152] Step 601: The first device obtains L types of shader source code. The L types of shader source code are the source code corresponding to the shaders of L applications, where L is an integer greater than 1.

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

[0154] Because different applications require different image rendering content, the source code corresponding to the shaders of different applications is different. For example, L applications may correspond to L shader source codes.

[0155] The first device obtains the source code of L shaders in the following way:

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

[0157] Wherein, at least one terminal device includes one or more terminal devices; at least one terminal device for running L applications can be understood as L applications running on one terminal, or L applications running on multiple terminals.

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

[0159] Method 2: In some embodiments, the first device obtains L shader source codes from the shader of at least one terminal device, and the shader runs in debug mode.

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

[0161] For example, such as Figure 7CAs shown, the first device is a server, L=6, and applications 1 to 6 run on terminal device A. The server and terminal device A can communicate with each other. Terminal device A includes a shader module and a source code detection module. The server includes an automated acquisition module, a compilation module, and a distribution module. The automated acquisition module automatically acquires L shader source codes. The compilation module compiles the shader source codes to obtain executable code. The distribution module sends the executable code to a second device (e.g., a terminal). On the terminal side, during the execution of applications 1 to 6, the source code detection module can acquire the shader source codes corresponding to each of the six applications during image rendering and send the six shader source codes to the server. On the server side, the automated acquisition module can receive the six shader source codes from terminal device A and send them to the compilation module. The compilation module processes the six shader source codes (e.g., extracting public and private source codes) and compiles the processed shader source codes to obtain executable code (e.g., public or private executable code). The compilation module sends the executable code to the distribution module, and the distribution module distributes the executable code to the target terminal.

[0162] It should be noted that the above methods 1 and 2 only take the method of the first device obtaining L shader source code from one terminal device as an example. For the methods of obtaining L shader source code from multiple terminal devices, which are involved in methods 1 and 2, please refer to methods 3 and 4, which will be introduced below. They are similar in principle and will not be described in detail here.

[0163] Method 3: In some embodiments, the first device includes a collection module for acquiring shader source code. The first device acquires L shader source codes from at least one terminal device, including: the first device acquires L shader source codes from at least one terminal device through the collection module.

[0164] The acquisition module is a module on the first device used to acquire shader source code. This acquisition module can be a module in the operating system or a module in the application layer, and this application does not limit it in this way.

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

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

[0167] Method 4: In some implementations, the first device includes a data acquisition module for acquiring shader source code. The first device acquires L types of shader source code from the shader of at least one terminal device, including: the first device acquires L types of shader source code from the shader of at least one terminal device through the data acquisition module, and the shader is running in debug mode.

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

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

[0170] Step 602: The first device determines the common source code from the L shader source codes. The common source code is the part that is common to all L shader source codes.

[0171] Since L shader source codes correspond to L applications, the part of each shader's source code that can be considered public source code can be determined based on the frequency of use of the corresponding application. This frequency can be measured by usage frequency and application call patterns. For example, shader source code from frequently used applications is more likely to be identified as public source code, and vice versa. Furthermore, the more applications that call a particular shader's source code, the more widely it is used, and the higher its probability of being identified as public source code; conversely, the lower its probability of being identified as public source code, the less frequently it is used.

[0172] The frequency of use information is used to represent the frequency with which each application is used among the L applications. This frequency of use information includes, but is not limited to, the number of downloads (also known as the number of downloads) and / or the number of installations (also known as the number of installations). The more downloads (or installations), the higher the frequency of use of the application, and vice versa. The call situation can refer to the situation in which a certain shader source code is called by other applications. For example, how many applications call the first type of shader source code (i.e., an example of L types of shader source code) or how many times it is called by other applications in total.

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

[0174] For example, taking download frequency as the information used for usage, and assuming L = 4 shader source codes, the first shader source code corresponds to application 1 with 100 million downloads, the second shader source code corresponds to application 2 with 80 million downloads, the third shader source code corresponds to application 3 with 250 million downloads, and the fourth shader source code corresponds to application 4 with 4 million downloads. Clearly, applications 1 and 3 have the most users, followed by application 2, and application 4 has the fewest. Therefore, when the first device determines the common source code from the 4 shader source codes, the shader source code shared by the first and third shader source codes is more likely to be identified as the common source code. For example, the first and third shader source codes both include shader source code A, but not shader source code B and shader source code C; while the second shader source code includes shader source code B, and the fourth shader source code includes shader source code C. Considering that applications 1 and 3 are used more frequently, the first device can use shader source code A as the common source code.

[0175] Therefore, in order to ensure that the common source code determined from the L types of shader source code has a wide range, this application uses a first parameter (e.g., frequency information) to filter out the shader source code with high calling (or usage) frequency from the L types 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 a variety of applications, thereby reducing the probability of more applications experiencing frame drops and stuttering during the rendering process.

[0176] For example, in some other embodiments, the first device can determine the common source code from L shader source codes based on the caller's situation; taking L=4 shader source codes as an example, where the first shader source code comes from application 1, ..., and the fourth shader source code comes from application 4; the first shader source code includes shader source code A1, shader source code B1, and shader source code C1; the second shader source code includes shader source code A1, shader source code B2, and shader source code C1; the third shader source code includes shader source code A1, shader source code B3, and shader source code C1; and the fourth shader source code package... The dataset includes shader source code A2, shader source code B4, and shader source code C1. Clearly, applications 1 through 3 all call shader source code A1, indicating that it is likely widely used. Furthermore, applications 1 through 4 also all call shader source code C1, suggesting it is also likely widely used. However, shader source codes B1 through B4 are not called by other applications besides their own, indicating that they may be proprietary source code of their respective applications. Compared to shader source codes B1 through B4, shader source code A1 and shader source code C1 are more likely to be identified as public source code. Since shader source code A1 and shader source code C1 are likely to be called by more applications, the first device can consider shader source code A1 and shader source code C1 as public source code.

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

[0178] Since the source code needs to be compiled to run on the terminal device (i.e., an example of the second device), the first device can compile the public source code after it has determined the public source code.

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

[0180] The aforementioned N can typically be determined based on device parameters. For example, if there are currently 5 different GPU versions, the first device can compile the common source code into common executable code that can run on all 5 different GPU versions. Alternatively, if there are 5 different GPU versions and 4 different OS versions, the first device can compile the common source code into common executable code that can run on 20 (i.e., 5 × 4 = 20) different GPU versions and OS versions.

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

[0182] The second parameter is an example of the device parameters mentioned above. Taking the GPU version number as an example, if there are three GPU versions on the market, namely version 1, version 2, and version 3, then the first device can compile the public source code into N=3 types of public executable code based on versions 1 to 3, namely public executable code 1, public executable code 2, and public executable code 3. These three types of public executable code can run on the three GPU versions (i.e., they are compatible with the runtime environment of the three GPU versions). For example, if the GPU version number installed on the second device is version 1 (or version 2 or version 3), then public executable code 1 (or public executable code 2 or public executable code 3) can run on the GPU of the second device.

[0183] For example, taking the GPU version number and operating system version number as the second parameters, if there are currently two GPU versions on the market, namely GPU version 1 and GPU version 2, and two OS versions, namely OS version 1 and OS version 2, then the first device can compile the public source code into N=4 types of public executable code based on the two GPU versions and two OS versions. These are public executable code 1, public executable code 2, public executable code 3, and public executable code 4. Among them, public executable code 1 is adapted to GPU version 1 and OS version 1. The runtime environments are designed as follows: Common executable code 2 is adapted to a runtime environment built with GPU version 1 and OS version 2; Common executable code 3 is adapted to a runtime environment built with GPU version 2 and OS version 1; and Common executable code 4 is adapted to a runtime environment built with GPU version 2 and OS version 2. These four common executable codes can run in four different runtime environments built with different GPU versions and OS versions. For example, if the second device has GPU version 1 and OS version 1 installed, then common executable code 1 can run on the GPU and OS of the second device.

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

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

[0186] The second device can be a terminal device or a target business server; this application does not limit the specific device to either.

[0187] Because different devices may have different GPU and OS versions, the target public executable code that different devices need to download from the first device may also differ. For example, the second device sends request 1 to the first device (e.g., the first request information below); request 1 includes the GPU and OS versions of the second device; after receiving request 1, the first device can determine the public executable code 1 adapted to the second device's operating environment from N public executable codes based on the GPU and OS versions in 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 its local file system module; when application 1 performs rendering, the shader module of the second device can directly read (or call) the public executable code 1 from the file system module without having to compile the public source code again, thereby reducing the amount of compilation in the image rendering process.

[0188] In summary, one approach to image rendering is to compile and render simultaneously, which often results in frame drops and stuttering. In this application, the first device can identify common source code from L shader source codes and compile it. Finally, it sends the target common executable code adapted to the second device's runtime environment to the second device. The second device can directly call the common executable code during rendering operations without compiling the common source code, thereby reducing the amount of compilation during image rendering, lowering the probability of frame drops and stuttering, and optimizing image rendering performance.

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

[0190] Step 605: The first device receives a first request information from the second device. The first request information is used to request the acquisition of the target public executable code.

[0191] Accordingly, the second device sends a first request message to the first device.

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

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

[0194] In some embodiments, step 604 above can also be implemented via step 6041:

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

[0196] After receiving the first request information, the first device can determine the target common executable code based on the first request information and send the target common executable code to the second device to avoid forcibly sending data when the user has no need for it, thus affecting the user experience.

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

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

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

[0200] In these embodiments, the second device sends a first request to the first device to obtain the target public executable code from the first device. In this way, the second device can directly call the public executable code during image rendering without triggering the compilation of the public source code, thereby reducing the amount of source code compilation, reducing the probability of frame drops and stuttering during image rendering, and optimizing image rendering performance.

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

[0202] Step 6040: The first device determines the target public executable code from N types of public executable code based on the third parameter.

[0203] The third parameter is an example of a device parameter, such as the device model, GPU version number, and operating system version number. Since the N common executable codes are executable codes compiled by the first device based on the device parameters (e.g., GPU version number), the third parameter reported by the second device to the first device helps the first device determine the target common executable code adapted to the second device from the N common executable codes based on the third parameter.

[0204] In some embodiments, the third parameter includes at least one of the GPU version number or the 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 that the first device can determine the target common executable code adapted to the second device's operating environment from N kinds of common executable code based on the GPU version number and / or OS version number, avoiding the erroneous delivery of executable code that does not match the device's operating environment. For details, please refer to the method for determining the target common executable code in step 605 above, which will not be repeated here.

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

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

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

[0208] It should be noted that the M types of private source code are the private source code corresponding to M applications; typically, the M types of private source code are bound one-to-one with the M applications; when a user downloads or updates an application, the private source code is usually sent to the client (e.g., a second device) along with the application's software installation package.

[0209] As described in step 602 above, the first device can determine the public source code from a certain shader source code; while the private source code can be understood as the part of a certain shader source code other than the public source code.

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

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

[0212] The usage frequency information can be referred to in the relevant description in step 602 above, and will not be repeated here. For example, taking the usage frequency information as the download count of each of the L applications as an example, the first device can remove the shader source code corresponding to the application with the fewest download counts based on the download counts of each of the L applications. For example, if the download counts of 5 applications in the L applications are lower than a preset value, the first device can remove the 5 shader source codes corresponding to these 5 applications from the L shader source codes, thus obtaining L-5 shader source codes. That is, the first device removes the common source code part of each shader source code in the L-5 shader source codes, resulting in M ​​= L-5 private source codes after removing the common source code, where "-" is the subtraction operator.

[0213] In this embodiment, the first device removes some private source code corresponding to less frequently used applications from the L types of shader source code according to the first parameter, and retains the private source code corresponding to the M types of commonly used applications (i.e., M types of private source code), which can ensure that the private executable code obtained after compiling the M types of private source code has a high usage rate.

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

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

[0216] Since the first device compiles each of the M types of private source code in the same way, the following explanation will only use the first device compiling one type of private source code as an example to illustrate the process of the first device compiling M types of private source code.

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

[0218] The aforementioned K is typically determined based on device parameters and the number of source codes. For example, if there are 5 different GPU versions, the first device can compile one type of proprietary source code into 5 types of proprietary executable code based on these 5 GPU versions. These 5 types of proprietary executable code can run on GPUs corresponding to different GPU versions. Alternatively, if there are M types of proprietary source code, the first device can compile M types of proprietary source code into K = 5 * M types of proprietary executable code based on the 5 GPU versions. Another example: if there are 4 different GPU versions and 3 different OS versions, the first device can compile one type of proprietary source code into 12 (4 × 3 = 12) types of proprietary executable code based on different GPU and OS versions. These 12 types of proprietary executable code can run on runtime environments built with 12 different GPU and OS versions. Because there are M types of proprietary source code, and each type can be compiled into 12 executable codes, the first device can compile M types of proprietary source code into K = 12 * M types of proprietary executable code based on 4 GPU versions and 3 OS versions.

[0219] In some embodiments, the first device compiles M types of proprietary source code according to a second parameter, the second parameter including at least one of a GPU version number or an OS version number.

[0220] The second parameter is an example of the device parameters mentioned above. Taking the GPU version number as an example, if there are three GPU versions on the market, namely version 1, version 2, and version 3, then the first device can compile one proprietary source code into N=3 proprietary executable codes based on versions 1 to 3, namely proprietary executable code 1, proprietary executable code 2, and proprietary executable code 3. These three proprietary executable codes can run on the three GPU versions (i.e., they are compatible with the runtime environment of the three GPU versions). For example, if the GPU version number installed on the second device is version 1 (or version 2 or version 3), then proprietary executable code 1 (or proprietary executable code 2 or proprietary executable code 3) can run on the GPU of the second device. For example, if there are M proprietary source codes, the first device can compile M proprietary source codes into K=3*M proprietary executable codes based on the three GPU versions.

[0221] For example, taking the GPU version number and OS version number as the second parameters, if there are currently two GPU versions on the market, namely version V1.0 and version V2.0, and two OS versions, namely version OS.1 and version OS.2, then the first device can compile a proprietary source code into N=4 proprietary executable codes based on the two GPU versions and two OS versions. These are proprietary executable code 1, proprietary executable code 2, proprietary executable code 3, and proprietary executable code 4. Among them, proprietary executable code 1 is compatible with version V1.0 and version OS.1. The runtime environments are as follows: private executable code 2 is adapted to the runtime environment built on version V1.0 and version OS.2; private executable code 3 is adapted to the runtime environment built on version V2.0 and version OS.1; and private executable code 4 is adapted to the runtime environment built on version V2.0 and version OS.2. These four types of private executable code can run in runtime environments composed of four different GPU versions and OS versions. For example, if the second device has GPU version 1 and OS version 1 installed, then private executable code 1 can run on the GPU and OS of the second device. For example, if there are M types of private source code, the first device can compile the M types of private source code into K = 4 * M types of private executable code based on 2 GPU version numbers and 2 OS version numbers.

[0222] In this embodiment, 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 used in multiple running environments, the first device can compile the private source code according to parameters such as the GPU version number to meet the requirements of private executable code in different running environments.

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

[0224] For example, in some scenarios, a user triggers a download (or update) operation for an application on a second device. In this case, the second device needs to send a request to the first device, requesting the first device to distribute the application's software installation package or the download address of the application's software installation package. After receiving the request from the second device (e.g., the second request message below), the first device can send the application's software installation package along with its corresponding target private executable code to the second device, or send the download address of the target private executable code along with the application's software installation package, so that the second device can obtain the target private executable code based on the download address. 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 the file system module, and delete the old private executable code and release storage space.

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

[0226] In summary, in addition to identifying the common source code from L types of shader source code, the first device can also identify M types of private source code from the L types of shader source code, and compile these M types of private source code to obtain K types of private executable code. The first device can send the target private executable code adapted to the second device's runtime environment 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 during the rendering process, avoiding the compilation of complex and time-consuming shader source code, thereby further reducing the probability of frame drops and stuttering during the rendering process and optimizing the rendering performance.

[0227] Prior to step 1003 above, method 600 further includes step 1004:

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

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

[0230] Since the K types of proprietary executable code are executable codes compiled by the first device from the M types of proprietary source code, the first device can determine the N types of proprietary executable code corresponding to the first application from the K types of proprietary executable code based on the first application identifier. These N types of proprietary executable code are compiled by the first device based on device parameters (e.g., GPU version number). Therefore, the first device can determine the target proprietary executable code adapted to the second device's operating environment from the N types of proprietary executable code based on the second device parameters (i.e., an example of device parameters). The second device's operating environment can be determined based on the second device parameters. For example, if the first application corresponds to N = 2 types of proprietary executable code, where the first type of proprietary executable code is compiled by the first device from the proprietary source code of the first application based on GPU version A, and the second type of proprietary executable code is compiled by the first device from the proprietary source code of the first application based on GPU version B, and the second device parameter is GPU version A, then the first device can determine the first type of proprietary executable code as the target proprietary executable code from the 2 types of proprietary executable code based on GPU version A.

[0231] In some embodiments, step 1003 above can also be implemented via step 1005:

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

[0233] After receiving the second request information, the first device can determine the target private executable code (see the relevant description in step 1004) and the software installation package of the first application based on the second request information. For example, the first device can obtain the software installation package of the first application and the corresponding target private executable code based on the first application identifier, and send (or download) the target private executable code and the software installation package of the first application together to the second device. Alternatively, the first device can obtain the download address of the software installation package of the first application and the download address of the corresponding target private executable code based on the first application identifier, and send the download address to the second device so that the second device can obtain the software installation package of the first application and the corresponding target private executable code based on the download address. This method of sending the target private executable code and the software installation package of the first application to the second device based on the second request information can avoid forcibly sending data when the user has no need for it, thus affecting the user experience.

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

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

[0236] The third parameter is an example of a device parameter, which includes at least one of the following: the GPU version number or the OS version number of the second device. It should be noted that the third parameter may also include other parameters (such as device model, device system upgrade time, etc.), but this application does not limit this.

[0237] In some scenarios, the first device can quickly determine N types of private executable code for the first application from K types of private executable code based on the first application identifier. The N types of private executable code for the first application are executable code 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) adapted to the second device from the N types of private executable code based on the reported third parameter. For details, please refer to step 1004 regarding the method by which the first device determines the target private executable code based on the second device parameters (i.e., the third parameter here), which will not be repeated here.

[0238] Once the first device has identified the target private executable code, it can either directly send the target private executable code to the second device, or send a download address for the target private executable code so that the second device can obtain the target private executable code based on that download address.

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

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

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

[0242] For example, the first operation command can be an operation command obtained by the second device from the display interface of the app market, or it can be an operation command obtained by the second device from the display interface of the first application. The app market, also known as an app store, is used to provide users with various software download, installation and update services, so that users can easily view information such as installed applications, applications to be updated and download history. In addition, the app market will also display detailed information, version descriptions and update content of the applications to help users understand the changes and new features of the applications.

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

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

[0245] The first operation instruction is an installation instruction or an update instruction. For example, a user can select the application to be installed from the application market on the second device and trigger the installation operation. At this time, the second device can obtain the installation instruction from the display interface of the application market and download the software installation package of the first application and the corresponding private executable code from the first device (e.g., a server) according to the installation instruction.

[0246] For example, a user can select an application that needs to be updated in the app store of a second device and trigger the update operation. At this time, the second device can obtain the update instruction from the display interface of the app store, and download the software upgrade package (also known as the software acceleration package) and the corresponding private executable code of the first application from the first device according to the update instruction.

[0247] For method 1, users can trigger installation or update commands on the app store's display interface according to their needs, in order to avoid automatic installation or updates of apps consuming a lot of network traffic and causing additional data consumption.

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

[0249] Since the first application is already installed on the second device, when a new version of the first application needs to be updated, the user can trigger an update operation on the first application's display interface. Correspondingly, the second device can receive the update instruction from the first application's display interface. For example, the user can trigger an update operation on the first application. In this case, the second device can update the first application through an app store or through the first application's own server. When the second device updates the first application through an app store, the app store can obtain the software upgrade package and corresponding private executable code from the first device and store the private executable code in its local file system module. When the first application updates through its own server, since its server does not have the corresponding private executable code, the second device needs to instruct the app store to download the corresponding private executable code from the first device so that the second device can update the private executable code of the upgraded first application in a timely manner. It should be noted that when updating the private executable code, the second device can delete the private executable code of the first application from its local storage before the upgrade.

[0250] As the examples above illustrate, users can trigger installation or update commands on the app store's display interface according to their needs, thus avoiding situations where automatic installation or updates of applications consume excessive network traffic, leading to additional data consumption and system lag.

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

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

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

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

[0255] In some scenarios, when a user triggers an update from the application's (e.g., the first application) display interface, the updated application may not have updated the previously stored private executable code. Therefore, to ensure that the updated application can update the previously stored private executable code in a timely manner, when the user triggers an update from the application's display interface, the second device will instruct the application market to generate second request information according to the first operation instruction. This controls the application market to execute the update of the first application and the download of the corresponding target private executable code, thus avoiding a mismatch between the application update and the private executable code update that could affect screen rendering performance. In other words, regardless of whether the user triggers the first operation instruction from the first application's display interface or the application market's display interface, the second device will launch the application market to execute the operation specified by the first operation instruction (e.g., installation, update, or download). When the second device launches the application market, the application market will generate 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 updates of various application software on the second device through the application market, it can be ensured that the application market obtains the corresponding target private executable code from the first device in a timely manner for downloaded or updated applications.

[0256] The following is combined with Figure 11 Here's a detailed explanation of the process for the second device to launch the app store and perform the update; it should be noted that... Figure 11 In this example, the second device is mobile phone A (i.e., an example of a second device). Mobile phone A includes a storage kit located in the operating system. This storage kit acts as a bridge between various applications (such as game applications) and the app store, responsible for information exchange between them. The second device can obtain the first operation command through the storage kit, and can also initiate operations such as updating the app store through the storage kit. The first application is a game application, and both the game application and the app store run on the operating system of mobile phone A. The process of mobile phone A initiating the update operation through the app store is as follows:

[0257] 1) User-triggered update operation. After launching the game application, the user can trigger an update operation on the game application's display interface. For example, the user can click the "Update or Upgrade" button on the game application's display interface to trigger an update operation on a second device.

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

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

[0260] 4) The storage suite initiates the application market to execute the update task. After receiving the update task request through the application update detection interface, the storage suite sends an update task instruction to the application market to instruct the application market to execute the update task for the game application.

[0261] 5) The app store sends an update request message. After receiving the update task instruction, the app store sends an update request message (i.e., an example of the second request information) to the cloud server. This 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).

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

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

[0264] 8) The app store performs an update operation based on the software update package and the corresponding proprietary executable code. After receiving the software update package and the corresponding proprietary executable code, the app store performs an update operation on the current game application based on the software update package, that is, the app store automatically installs the software update package; in addition, the app store updates the proprietary executable code distributed by the cloud server to the file system module of mobile phone A, and deletes the old version of proprietary executable code previously stored in the file system module.

[0265] The method 600 has been described in detail above. Below, with the example of a cloud server as the first device and a mobile phone as the second device, we will briefly introduce the application of method 600 in different application scenarios.

[0266] Example 1: Application Installation Scenario

[0267] In some embodiments, users can install applications they need from an app store. For example, let's take the example of a user installing the XX game app (i.e., an example of the first application) from an app store. Figure 12A As shown, the phone has applications such as video streaming, an app store, and a browser installed. The user can double-click the app store shortcut icon 1201 on the phone's main screen. At this point, the phone enters the app store's recommended interface 1202. The user can then click the install button 1203 for the game XX on the recommended interface 1202 to trigger the installation process. Figure 12B As shown; after the mobile phone receives the installation instruction corresponding to the installation operation (i.e., an example of the first operation instruction) from the recommendation interface 1202, it responds to the installation instruction and obtains the software installation package of XX game from the cloud server (i.e., an example of the first device), and performs the download and installation operations. For details, please refer to the relevant description of method 1 above; in addition, the user can see the download status 1204 of XX game during the download process, such as Figure 12C As shown; after the app store downloads the software installation package for XX game, it will automatically install the package; after installation, the status of XX game on the recommended screen 1202 will change to open status 1205. Users can launch the XX application by clicking the open status 1205 button, as shown. Figure 12D As shown; at the same time, after installation, as... Figure 13A As shown, a shortcut icon 1301 for the XX game will be generated on the main screen of the phone. Users can launch the XX application by double-clicking the shortcut icon 1301.

[0268] Example 2: Application-side update scenario

[0269] In some embodiments, a user can trigger an application update on the application side; for example, taking a user triggering a self-update from a video application (i.e., an example of the first application) as an example, Figure 13B As shown, users can double-click the shortcut icon 1302 of the video application on the phone's main screen; at this time, the phone enters the video application's user interface 1303, where users can select the video they want to watch; when a new version of the video application is released, the video application can generate an update reminder message on the user interface 1303; for example, such as Figure 13C As shown, when a new version of the video application is released, the video application can generate an update reminder interface 1304 on the user interface 1303; the user can select the "Update Now 1305" option on the update reminder interface 1304 to trigger the video application to perform an automatic update; at this time, an upgrade settings interface 1306 is generated on the user interface 1303, as shown... Figure 13D As shown.

[0270] It should be noted that video applications can perform self-updates in two ways: first, through the video application's own servers; second, through app stores. For the first method, such as... Figure 13D As shown, users can select the "Disallow upgrades using the app store" option on the upgrade settings interface 1306; at this time, the video application will perform a self-update in the background, that is, the video application downloads the software upgrade package from its own application server and automatically installs the software upgrade package; at this time, users can see the background update status indicator 1401 on the user interface 1303, as shown. Figure 14A As shown; since applications (such as video applications) do not have the private executable code corresponding to the new version of the application (such as the 6.1.2.3A version of the video application) on their own servers, the application market needs to monitor the update status of each application in order to update the private executable code previously stored by each application in a timely manner in the case of application-side self-update.

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

[0272] For the second type, such as Figure 14B As shown, users can select the "Always allow upgrades using the app store" option on the upgrade settings interface 1306. At this time, the phone will switch from the video app to... Figure 14C The application update interface 1403 is shown; users can click the update button 1404 for the video application on the application update interface 1403 to trigger the video application update operation, such as... Figure 14C As shown; at this point, the user will see the video application's update button change to a "Download progress 1405" status indicator, as shown. Figure 14DAs shown; at this point, the app store downloads the software upgrade package and corresponding private executable code of the new version of the video application from the cloud server; specifically, the app store can send a request message Y to the cloud server, which requests the cloud server to distribute the software upgrade package and corresponding private executable code of 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 (e.g., GPU version number and / or OS version number); 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 based on the video application identifier and the device parameters of the mobile phone. For details, please refer to the relevant description of step 1006 above, which will not be repeated here.

[0273] Once the cloud server has determined the software upgrade package and corresponding proprietary executable code for the new version of the video application, it can then... Figure 5B The distribution module sends the software upgrade package and the corresponding proprietary executable code to the app store. Upon receiving the software upgrade package and the corresponding proprietary executable code, the app store automatically installs the software upgrade package and updates the old proprietary executable code stored in the local file system module with the corresponding proprietary executable code. After installation, the status of the video application on the application update interface 1403 changes from the update button to the open button 1501. Users can launch the updated video application by clicking the open button 1501. Figure 15A As shown; simultaneously, after installation, a shortcut icon 1502 for the new version of the video application will be generated on the phone's main interface. Users can launch the video application by double-clicking the shortcut icon 1502, as shown. Figure 15B As shown.

[0274] In some other embodiments, such as, Figure 15C As shown, when a user selects the "Do not update 1503" option on the update reminder screen 1304, it indicates that the user may not want to upgrade for the time being; at this time, as Figure 15D As shown, a pause update settings interface 1504 is generated on the user interface 1303. Users can set the desired pause duration or the desired update time on the pause update settings interface 1504; for example, ... Figure 15DAs shown, when a user selects the "Pause Duration 1505" option, they can set the desired pause duration. For example, if the current date is "June 20th, xxxx," the user can choose to pause until "July 5th, xxxx." The maximum pause duration for this "Pause Duration 1505" option is 30 days. When the pause period is reached, the video application will automatically update. The automatic update method can default to the "First Method" (or "Second Method") mentioned above. Alternatively, when a user selects the "Update Time Setting 1506" option, they can set the desired update time period, such as from 18:00 to 20:00 on "July 1st, xxxx." The automatic update method for the video application can also default to the "First Method" (or "Second Method") mentioned above.

[0275] In other embodiments, users can configure video application updates themselves. For example, such as... Figure 16A As shown, users can click the "Personal Center 1601" option on the video application's user interface 1303. At this time, the phone will jump from user interface 1303 to the personal center interface 1602, as follows. Figure 16A As shown; users can select the "Latest Upgrade 1603" option on the personal center interface 1602. At this time, a "Latest Version Information" prompt box 1604 will pop up on the personal center interface 1602, as shown. Figure 16C As shown; users can select either "Upgrade Now 1605" or "Update Settings 1606" on prompt box 1604; if the user selects "Upgrade Now 1605", the personal center interface 1602 will display [the following text is incomplete and likely refers to a different page or format] Figure 13D The same upgrade settings interface 1306; please refer to the following for details. Figure 13D as well as Figures 14A to 14D The relevant descriptions will not be repeated here. If the user selects the "Update Settings 1606" option, then the 1602 option will be generated on the personal center interface. Figure 16D The update settings interface shown is 1607. Users can configure update methods on the "Update Settings Interface 1607". For example, if the user selects the "Automatic Update 1608" option, the video application will automatically update when a new version is released, without prompting the user for immediate updates. If the user selects the "Ask for Update 1609" option, the application will first prompt the user for updates when a new version is released, instead of updating automatically. Figure 16D As shown.

[0276] Implementation 3: App Store Update Scenario

[0277] In some embodiments, users can update their current applications through an app store. For example, ... Figure 12AAs shown, users can double-click the app store shortcut icon 1201 on the phone's main screen to enter the app store's recommended interface 1202; after entering the recommended interface 1202, as... Figure 17A As shown, users can click the "My" option 1701 on the recommended interface 1202 to open the "My" main interface 1702 (see...). Figure 17B At this point, the user can select the "Application Update 1703" option on the "My" main interface 1702, causing the phone to jump from the "My" main interface 1702 to the "Application Update Interface 1403". On the Application Update Interface 1403, the user can select the application to be updated, such as... Figure 17C As shown; for example, a user can click the "Update 1704" button in the video application to trigger the update operation, such as... Figure 17C As shown; at this point, the user can see that the update 1704 button in the video application changes to the "Download progress 1705" status indicator, as shown. Figure 17D As shown; at this time, the application market downloads the software upgrade package and corresponding private executable code of the new version of the video application from the cloud server. For details, please refer to the description of the "second type" automatic update method in Example 2 above, which will not be repeated here. After receiving the software upgrade package and corresponding private executable code from the cloud server, the application market will automatically install the software upgrade package and update the old private executable code stored in the local file system module using the downloaded private executable code; after installation, as... Figure 18A As shown, the status of the video application on the application update interface 1403 changes from the update button to the open button 1801; users can launch the updated video application by clicking the "open button 1801".

[0278] Example 4: Methods for downloading public and private executable code

[0279] In some embodiments, such as Figure 18B As shown, users can select the "Public Accelerator Package Download" option on the "My" main interface (1702); at this time, as... Figure 18C As shown, the app store generates a "Public Accelerator Package Update Method" settings interface 1803 on the "My" main interface 1702; users can select the public acceleration package update method on the settings interface 1803, for example, ... Figure 18CAs shown, if the user selects the "Check for Update 1804" option, the app store will retrieve the public executable code from the cloud server when it detects an app update on the phone (for example, it will call the cloud server interface to query the download address of the public executable code and download it) to ensure that the public executable code stored in the local file system module is consistent with the latest public executable code on the cloud server. If the user selects the "Default Update 1805" option, the app store will retrieve the public executable code from the cloud server according to the time interval set by the system (i.e., the app store will retrieve the public executable code from the cloud server within the preset time period).

[0280] For example, such as Figure 18B As shown, users can select the "Download Private Accelerator Package 1806" option on the "My" main interface 1702. At this time, the app market will jump from the "My" main interface 1702 to... Figure 18D The download interface 1807 for the "Private Accelerator Package" is shown; users can select the private acceleration package corresponding to the application they want to download on this download interface 1807; for example, Figure 18D As shown, users can click the "Download Button 1808" corresponding to the "Video Application". At this time, after receiving the download instruction corresponding to the download operation, the app store will obtain the private executable code corresponding to the video application from the cloud server to ensure that the private executable code of the video application stored in the local file system module is consistent with the private executable code corresponding to the latest video application on the cloud server. Specifically, the app store can send a request message Z to the cloud server. This request message Z is used to request the cloud server to distribute the private executable code corresponding to the new version of the video application. This request message Y includes, but is not limited to, the video application identifier and the device parameters of the mobile phone (e.g., 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 based on the video application identifier (i.e., an example of the first application identifier) ​​and the device parameters of the mobile phone (i.e., an example of the third parameter), and distribute the private executable code (or the download address of the private executable code) to the app store. For details, please refer to the relevant description of step 1006 above, which will not be repeated here.

[0281] The foregoing has detailed examples of the compilation methods provided in this application. It is understood that, in order to achieve the aforementioned functions, electronic devices include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. 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 this application. This application can divide the compilation method into functional units based on the above method examples; for example, each function can be divided into separate functional units, or two or more functions can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application is illustrative and only represents one logical functional division; other division methods may exist in actual implementation.

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

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

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

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

[0286] For example, communication unit 1905 may be a transceiver of electronic device 1900, or communication unit 1905 may be a transceiver circuit of electronic device 1900. Electronic device 1900 may include one or more memories 1902, which store program 1904. Program 1904 may be executed by processor 1901 to generate instructions 1903, causing processor 1901 to execute the method described in the above method embodiments according to instructions 1903. Optionally, memory 1902 may also store data. Optionally, processor 1901 may also read data stored in memory 1902, which may be stored at the same memory address as program 1904, or the data may be stored at a different memory address than program 1904.

[0287] The processor 1901 and memory 1902 can be configured separately or integrated together, for example, integrated on a system-on-chip (SOC) of an electronic device. The specific manner in which the processor 1901 executes the compilation method can be found in the relevant description in the method embodiments.

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

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

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

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

[0292] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process and technical effects of the above-described apparatus and equipment can be referred to the corresponding processes and technical effects in the foregoing method embodiments, and will not be repeated here.

[0293] The systems, apparatuses, and methods disclosed in the embodiments provided in this application can be implemented in other ways. For example, some features of the method embodiments described above may be omitted or not performed. The apparatus embodiments described above are merely illustrative; the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system. Furthermore, the coupling between units or components can be direct or indirect, including electrical, mechanical, or other forms of connection.

[0294] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

[0295] Finally, the above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A compilation method, characterized in that, Applied to a first device, the method includes: L shader source codes are obtained from the shader of at least one terminal device. The shader is running in debug mode. The L shader source codes are the source codes corresponding to the shaders of L applications. The at least one terminal device is used to run the L applications. L is an integer greater than 1. Determine the common source code from the L types of shader source code, where the common source code is the part shared by the L types of shader source code; The public source code is compiled according to different device parameters to obtain N kinds of public executable code. The N kinds of public executable code are used to adapt to N kinds of running environments. N is a positive integer. The device parameters include at least one of device type, graphics processing unit (GPU) version number or operating system (OS) version number. Send target common executable code to the second device, wherein the target common executable code is one of the N types of common executable code adapted to the operating environment of the second device.

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

3. The method according to claim 2, characterized in that, The first device includes a data acquisition module, which is used to acquire shader source code. The acquisition of L shader source codes from the shaders of at least one terminal device includes: The acquisition module obtains the source code of the L shaders from the shaders of the at least one terminal device.

4. The method according to claim 2 or 3, characterized in that, The step of determining M types of private source code from the L types of shader source code includes: The M private source codes are determined from the L shader source codes based on a first parameter, wherein the first parameter includes usage frequency information, and M is less than L.

5. The method according to any one of claims 1 to 4, characterized in that, The step of determining the common source code from the L types of shader source code includes: The common source code is determined from the L shader source codes based on a first parameter, the first parameter including usage frequency information.

6. The method according to claim 2, characterized in that, The compilation of the M types of proprietary source code includes: The M types of private source code are compiled according to the second parameter, which includes at least one of the GPU version number or OS version number.

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

8. The method according to claim 2 or 6, characterized in that, Before sending the target private executable code to the second device, the method further includes: Receive a second request message from the second device, the second request message being used to request the download of the software installation package of a first application, the first application being one of the L applications; Sending the target private executable code to the second device includes: In response to the second request information, the software installation package of the first application and the target private executable code are sent to the second device.

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

10. The method according to any one of claims 1 to 9, characterized in that, Before sending the target publicly executable code to the second device, the method further includes: Receive a first request message from the second device, the first request message being used to request the acquisition of the target public executable code; Sending the target publicly executable code to the second device includes: In response to the first request information, the target public executable code is sent to the second device.

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

12. The method according to claim 10 or 11, characterized in that, The first request information includes a third parameter, which is used to determine the operating environment of the second device; Before sending the target publicly executable code to the second device, the method further includes: The target public executable code is determined from the N types of public executable code based on the third parameter.

13. The method according to claim 9 or 12, characterized in that, 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.

14. A compilation method, characterized in that, Applied to a second device, the method includes: Send a first request message, which is used to request the acquisition of target public executable code. The target public executable code is one of N public executable codes adapted to the operating environment of the second device. The N public executable codes are the compilation results of public source code based on different device parameters. The public source code is the common part of L shader source codes. The L shader source codes are obtained from the shaders of at least one terminal device. The shader runs in debug mode. The L shader source codes are the source codes corresponding to the shaders of L applications. The at least one terminal device is used to run the L applications. L is an integer greater than 1. N is a positive integer. The device parameters include at least one of device type, GPU version number, or OS version number. Receive the target public executable code.

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

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

17. The method according to any one of claims 14 to 16, characterized in that, The method further includes: Send a second request message, which is used to request the download of the software installation package of the first application, wherein the first application is one of the L applications; Receive the software installation package of the first application and the target private executable code.

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

19. The method according to claim 16 or 18, characterized in that, 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.

20. The method according to claim 17 or 18, characterized in that, Before sending the second request information, the method further includes: Receive a first operation instruction, which is used to trigger the download of the software installation package of the first application; The second request information is generated based on the first operation instruction.

21. The method according to claim 20, characterized in that, The receiving of the first operation instruction includes: The first operation instruction is received from the display interface of the application market, which runs on the second device. The first operation instruction is an installation instruction or an update instruction.

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

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

24. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program from the memory, causing the electronic device to perform the method of any one of claims 1 to 13, or causing the electronic device to perform the method of any one of claims 14 to 23.

25. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1 to 13, or causes the processor to perform the method of any one of claims 14 to 23.

26. A chip system, characterized in that, The chip system includes a memory and a processor, the processor being configured to execute a computer program stored in the memory to implement the method as described in any one of claims 1 to 13, or to implement the method as described in any one of claims 14 to 23.

Images