Application installation package generation method, device, equipment, medium and program product
By obtaining the code version identifier, prioritizing the reading of the compilation cache results, and compiling only when necessary, combined with distributed locks and asynchronous uploads, the problem of resource waste caused by repeated compilation during the installation package generation process is solved, thereby improving packaging efficiency and system stability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GUANGZHOU BOGUAN TELECOMM TECH LTD
- Filing Date
- 2026-02-12
- Publication Date
- 2026-06-05
AI Technical Summary
Existing technologies consume a lot of computing resources during the application installation package generation process due to frequent repeated compilation operations, resulting in excessively long packaging times and affecting the efficiency of software version release.
By obtaining the code version identifier corresponding to the packaging request, the compilation artifacts are read first from the pre-stored compilation cache results. The code is only compiled when the cache does not exist. The distributed synchronous lock mechanism and asynchronous upload strategy are used to avoid repeated compilation operations.
It enables the compilation output to be compiled once and reused multiple times, significantly reducing the consumption of computing resources, shortening the packaging time, improving the efficiency of installation package generation, and ensuring system stability and resource utilization efficiency in high-concurrency scenarios.
Smart Images

Figure CN122152349A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer technology, and specifically to methods, apparatus, devices, media, and program products for generating application installation packages. Background Technology
[0002] The process of generating an application installation package typically involves code compilation and resource packaging. Existing packaging technologies usually employ a linear build process when handling packaging requests for a target application. This means that each time a packaging request is received, regardless of whether the code has undergone substantial changes, the entire code compilation process is re-executed to obtain the compiled artifacts, which are then combined with configuration information to generate the installation package. This approach leads to a significant waste of computing resources on repetitive compilation calculations when faced with frequent packaging requests or a large number of repetitive requests, significantly increasing the overall packaging time and severely impacting software release efficiency.
[0003] Therefore, there is an urgent need for a method to generate application installation packages in order to solve the problem of low efficiency in generating installation packages in related technologies. Summary of the Invention
[0004] This disclosure provides a method, apparatus, device, medium, and program product for generating application installation packages, in order to solve the problem of low efficiency in generating installation packages in related technologies.
[0005] In a first aspect, this disclosure provides a method for generating an application installation package, the method comprising:
[0006] In response to receiving a packaging request for the target application, obtain the code version identifier corresponding to the packaging request and the configuration information of the target installation package to be generated;
[0007] Obtain the compilation artifacts corresponding to the code version identifier; the compilation artifacts are obtained by reading from the pre-stored compilation cache results based on the code version identifier, or by compiling the code of the target application if the pre-stored compilation cache results are not read. Based on the compilation artifacts and configuration information, generate the target installation package.
[0008] Secondly, this disclosure provides an apparatus for generating an application installation package, the apparatus comprising: The first acquisition module is used to respond to a packaging request for the target application by acquiring the code version identifier corresponding to the packaging request and the configuration information of the target installation package to be generated. The second acquisition module is used to acquire the compilation artifacts corresponding to the code version identifier. The compilation artifacts are obtained by reading from the pre-stored compilation cache results based on the code version identifier, or by compiling the code of the target application when the pre-stored compilation cache results are not read. The generation module is used to generate the target installation package based on the compilation artifacts and configuration information.
[0009] Thirdly, this disclosure provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the application installation package generation method described in the first aspect or any corresponding embodiment.
[0010] Fourthly, this disclosure provides a computer-readable storage medium storing computer instructions for causing a computer to execute the application installation package generation method described in the first aspect or any corresponding embodiment thereof.
[0011] Fifthly, this disclosure provides a computer program product, including computer instructions for causing a computer to execute the method for generating an application installation package according to the first aspect or any corresponding embodiment described above.
[0012] The application installation package generation method provided in this disclosure obtains the code version identifier corresponding to the packaging request and uses this identifier to obtain the compilation artifacts. It prioritizes reading pre-stored compilation cache results and only executes code compilation if the cache is not present. This technique ensures that for the same code version, regardless of the number of subsequent packaging requests, the time-consuming and computationally intensive compilation steps should, in principle, only be executed once. This method utilizes the code version identifier to achieve one-time compilation and multiple reuse of the compilation artifacts, effectively avoiding repeated compilation operations for the same version of code. This significantly reduces the consumption of computing resources during the application installation package generation process, greatly shortens the total packaging time, and improves overall packaging efficiency. Attached Figure Description
[0013] To more clearly illustrate the technical solutions in the specific embodiments of this disclosure or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0014] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of this disclosure; Figure 2 This is a schematic flowchart of a first method for generating an application installation package according to an embodiment of the present disclosure; Figure 3 This is a schematic diagram of a second process for generating an application installation package according to an embodiment of the present disclosure; Figure 4This is a schematic diagram of the task creation interface of the packaging task management backend according to an embodiment of the present disclosure; Figure 5 This is a flowchart illustrating the compilation and caching mechanism according to an embodiment of this disclosure; Figure 6 This is a flowchart illustrating the asynchronous upload and resource optimization process according to an embodiment of this disclosure; Figure 7 This is a structural block diagram of an application installation package generation apparatus according to an embodiment of the present disclosure; Figure 8 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this disclosure. Detailed Implementation
[0015] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.
[0016] It should be noted that the information (including but not limited to user input information, such as information entered into input boxes), data (including but not limited to data used for analysis, stored data, and displayed data, such as context code, all code of the current project, service pressure corresponding to operations performed on all code of the current project, and code development status of the current project), and signals involved in this disclosure are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, the context code, operations performed on all code of the current project, the corresponding service pressure, and code development status involved in this disclosure were all obtained with full authorization.
[0017] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this disclosure, "a plurality of" means two or more, unless otherwise expressly specified.
[0018] Before providing a detailed description of the embodiments of this disclosure, some of the nouns and terms involved in the embodiments of this disclosure will be explained.
[0019] (1) Windows application: refers to computer software that runs on the Windows operating system.
[0020] (2) CI (Continuous Integration): A software development practice that uses automated scripts to periodically or on demand pull code from a code repository and perform a series of tasks such as compilation, building, and testing.
[0021] (3) CI Runner: The task execution agent in the continuous integration system, responsible for running the physical machine or virtual machine node of the packaging script.
[0022] (4) Commit Hash: A unique identifier (usually a 40-character hexadecimal string) generated for each code commit when using version control systems such as Git.
[0023] (5) EXE / DLL: Executable files and dynamic link libraries in Windows systems. They are the core binary products after compilation.
[0024] (6) InnoSetup: A Windows installer creation tool that uses scripts to define installation logic and package program files into a final installer (such as setup.exe).
[0025] (7) Redis Distributed Lock: A cross-server, cross-process mutual exclusion control mechanism that utilizes the atomic operations of the Redis database (such as SETNX).
[0026] (8) CDN (Content Delivery Network): An intelligent virtual network built on the existing network infrastructure. It relies on edge servers deployed in various locations and uses the central platform's load balancing, content distribution, scheduling and other functional modules to enable users to obtain the content they need from the nearest location.
[0027] (9) Python Signify: A third-party Python library used to digitally sign and verify files to ensure file integrity and trustworthy origin.
[0028] As one optional application scenario of this disclosure embodiment, such as Figure 1 As shown, this method for generating the application installation package can be applied to a computer system that includes at least one terminal device and at least one server. Figure 1 The system is illustrated in the example, which includes a computer 101, a mobile terminal 102, and a server 103, and the terminal devices such as the computer 101 and the mobile terminal 102 are connected to the server 103 through a network 110.
[0029] Specifically, the terminal device can be a desktop computer, laptop, or tablet computer used to initiate packaging requests or configure packaging tasks, or it can be a mobile device such as a smartphone. Server 103 can be an independent physical server used for code compilation, cache management, and installation package generation, or it can be a server cluster or a distributed system, or it can be a cloud server providing cloud services. Network 110 can be a wired or wireless network, examples of which include, but are not limited to, the Internet, corporate intranets, local area networks, wide area networks, mobile communication networks, and combinations thereof.
[0030] In the application software development and release process, generating the application installation package is a crucial step. Typically, when software needs to release a new version or be deployed with a specific configuration, it needs to respond to a packaging request, compile and link the target application's code, generate compiled artifacts, and finally package them into an installation package that users can install.
[0031] However, related technologies often lack effective optimization of the compilation process when handling packaging requests. Even if the code version has not changed, a new packaging request may still require a complete recompile. This repeated compilation process consumes significant computing resources and time, resulting in slow application package generation. Therefore, there is an urgent need for a method to generate application packages that avoids repeated compilation, significantly reduces packaging time, and improves application package generation efficiency.
[0032] According to an embodiment of this disclosure, an embodiment of a method for generating an application installation package is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0033] This embodiment provides a method for generating an application installation package, which can be used in the aforementioned terminal devices, such as laptops and desktop computers. Figure 2 This is a flowchart of a method for generating an application installation package according to an embodiment of this disclosure, such as... Figure 2 As shown, the process includes the following steps: Step S201: In response to receiving a packaging request for the target application, obtain the code version identifier corresponding to the packaging request and the configuration information of the target installation package to be generated.
[0034] The target application refers to a specific software program that needs to be built and released. For example, it could be an online game or an instant messaging software.
[0035] A packaging request is an instruction or signal that triggers the installation package generation process. This request typically carries specific parameters about the task at hand. For example, it could be a signal triggered by a developer clicking the "Start Build" button in the build tool interface, or it could be a timed command-line instruction.
[0036] A code version identifier is a string or number used to uniquely identify the state of source code and to distinguish different code commit records. For example, it can be the "Commit Hash" in the Git version control system (such as a1b2c3d), the version number in SVN (such as Revision 1024), or a manually added tag (such as v1.0.0-release).
[0037] Configuration information refers to the differentiated parameters required when generating the installation package to meet the needs of different environments or channels. For example, configuration information may include: the application's runtime environment (test environment or production environment), the application's channel identifier (such as channel A), a specific application icon file path, or the application name suffix.
[0038] In this step, when an instruction to package a file is received, it is first necessary to clarify which version of the code to package (determined by the code version identifier) and what type of installation package to package (determined by configuration information). Suppose a packaging request is received requesting packaging for "Instant Messaging Software A". After parsing the request, it is confirmed that the current code version identifier is "Hash_123456", and the configuration information shows that this is an installation package for "Official Release to Channel A".
[0039] Step S202: Obtain the compilation artifacts corresponding to the code version identifier; the compilation artifacts are obtained by reading from the pre-stored compilation cache results based on the code version identifier, or by compiling the code of the target application when the pre-stored compilation cache results are not read.
[0040] Compilation artifacts refer to the intermediate or final results that a computer can recognize or execute after the source code of a target application has been processed by build tools such as compilers and linkers. Depending on the type of the target application, its operating environment, and the programming language, the compilation artifacts can take various forms, including but not limited to the following: In a Windows environment, the compilation output includes not only the main program's executable file (e.g., .exe), but may also include dynamic link libraries (e.g., .dll), static library files (e.g., .lib), and program database files (e.g., .pdb) necessary for application operation. In a Unix / Linux environment, the compilation output can be a binary executable file and a shared object file (e.g., .so).
[0041] If the target application has a modular architecture, the compilation artifacts may consist of multiple independent module artifacts. For example, a large application may contain a core logic module, a UI module, and a network communication module. Each module generates an independent binary file after compilation, and the collection of these files together constitutes the compilation artifacts. If the target application depends on a third-party SDK and the SDK requires source code integration, the compilation artifacts may also include a hybrid binary file generated by merging and compiling the business logic code with the third-party SDK code.
[0042] Furthermore, compilation artifacts are not limited to the compiled code logic; they can also include resource files processed during the build phase. Examples include binary serialized data tables, compiled shader code, texture atlases, or other preprocessed binary files.
[0043] Pre-stored compilation cache results refer to copies of compilation artifacts that have been previously generated and stored in a specific location (such as a shared disk or cloud storage). For example, a folder named Cache / CommitID_888 might contain all the files from the last compilation.
[0044] Compilation refers to the process of using a compiler to convert source code into machine code. For example, using Visual Studio's MSBuild tool or Java's Javac command can convert thousands of code files into a program that a computer can run.
[0045] This step uses the code version identifier (such as Hash_123456) obtained in step S201 as an index or keyword to search the cache area.
[0046] Scenario 1 (Cache Hit): If a compilation cache result marked Hash_123456 is found, the file in the cache is directly read as the compilation output for this time, which means that the time-consuming compilation process is skipped.
[0047] Scenario 2 (Cache Miss): If the result identified as Hash_123456 is not found in the cache area, it means that this version of the code has not been compiled. In this case, a compilation process will be performed, that is, the compiler will be called to compile the code of the target application, generating a new compilation artifact, which will be used as the result obtained this time.
[0048] For example, suppose the "Hash_123456" version of "instant messaging software A" was packaged once ten minutes ago and the corresponding cache was saved. When the same "Hash_123456" is passed again through step S201, in step S202, the corresponding .exe and .dll files are read directly from the cache directory of the storage space, without starting the compiler.
[0049] Step S203: Generate the target installation package based on the compilation output and configuration information.
[0050] A target installation package refers to a file that an end user can directly install and use, such as a .msi or .exe installer for Windows, or a .apk file for Android.
[0051] The "generation" action refers to the process of combining the obtained compilation artifacts with configuration information and packaging them into the final delivery form. This typically involves operations such as copying and renaming files, writing configuration files, compression, and converting packaging formats.
[0052] Based on the compilation artifacts obtained in step S202 (which may be reused cache or newly compiled), these artifacts will be processed according to the configuration information obtained in step S201. For example, if the configuration information includes "Channel A", the resource files for Channel A may be selected during packaging.
[0053] For example, using the binary file (compilation product) of "instant messaging software A" quickly read in step S202, combined with the configuration parameters of "channel A", the final installation file is generated by the packaging tool.
[0054] In summary, the application installation package generation method provided in this disclosure obtains the code version identifier corresponding to the packaging request and uses this identifier to obtain the compilation artifacts. It prioritizes reading pre-stored compilation cache results and only executes code compilation if the cache is not present. This technique ensures that for the same code version, regardless of the number of subsequent packaging requests, the time-consuming and computationally intensive compilation steps should, in principle, only be executed once. This method utilizes the code version identifier to achieve one-time compilation and multiple reuse of the compilation artifacts, effectively avoiding repeated compilation operations for the same version of code. This significantly reduces the consumption of computing resources during the application installation package generation process, greatly shortens the total packaging time, and improves overall packaging efficiency.
[0055] This embodiment provides a method for generating an application installation package, which can be used in the aforementioned terminal devices, such as laptops and desktop computers. Figure 3 This is a flowchart of a method for generating an application installation package according to an embodiment of this disclosure, such as... Figure 3As shown, the process includes the following steps: Step S301: In response to receiving a packaging request for the target application, obtain the code version identifier corresponding to the packaging request and the configuration information of the target installation package to be generated. For details, please refer to [link to relevant documentation]. Figure 2 Step S201 of the illustrated embodiment will not be described again here.
[0056] Step S302: Obtain the compilation artifacts corresponding to the code version identifier; the compilation artifacts are obtained by reading from the pre-stored compilation cache results based on the code version identifier, or by compiling the code of the target application when the pre-stored compilation cache results are not read.
[0057] The core logic of this step lies in the cache-first retrieval strategy: First, the code version identifier is used as an index to check if there are any pre-stored compilation cache results.
[0058] Specifically, the code version identifier is used as an index to query whether the corresponding compilation artifact exists in the preset shared storage space; if it exists, the compilation artifact is read from the shared storage space.
[0059] Shared storage space refers to a storage area that can be accessed by multiple packaging machines, such as network attached storage or a local area network shared folder. An index is either a folder name or a database key value.
[0060] If the cache is not read, the compiler must be started to compile the target application's code and generate the required binary file.
[0061] In this embodiment, if compilation is required, the process is implemented in the following way: The code of the target application is compiled, including: acquiring a distributed synchronization lock based on the code version identifier; after successfully acquiring the distributed synchronization lock, performing the compilation operation on the code of the target application, generating a binary file, and digitally signing the binary file to obtain the compilation product.
[0062] Distributed synchronization locks are cross-process, cross-server coordination mechanisms used to ensure that only one task is compiling the same version of code at a time. For example, a key in a Redis database can be used as a lock.
[0063] The action of "acquiring the lock" means attempting to retain this privilege. If multiple packaging tasks (such as packages for channel A and channel B) start simultaneously and all find no cache, they will compete for the lock. The task that acquires the lock (successfully obtains it) becomes the primary builder, responsible for performing time-consuming compilation operations and digital signing (encrypting and marking the binary file with a certificate). The beneficial effect of this mechanism is to prevent dozens of tasks from compiling the same code simultaneously, which could cause server resource crashes.
[0064] Furthermore, the specific logic for acquiring the distributed synchronization lock is as follows: Acquiring a distributed synchronization lock includes: querying whether a lock record exists with the code version identifier as the key value; if no lock record exists, creating the lock record and determining that the acquisition was successful; if a lock record exists, retrying after a preset time interval; if the distributed synchronization lock is still not acquired after the retry, the task is determined to be abnormal; a task abnormality is used to indicate the termination of the generation process of the target installation package for the packaging request.
[0065] A lock record is a piece of data stored in a shared database (such as Redis). Queries are performed using a code version identifier (such as a hash value) as an index.
[0066] If the record is not found (i.e., does not exist), it means no other task is currently compiling, so the record is created (locking) and compilation begins. If the record is found (i.e., exists), it means another task is compiling, and the current task waits for a preset time interval (e.g., 5 seconds) and then checks again (retrying). If the lock is still not acquired after retrying or the cache is not generated, the task is considered abnormal and the process terminates to prevent infinite waiting. The beneficial effect of this mechanism is that it enables intelligent collaboration between tasks; non-primary build tasks will automatically suspend and wait until the output of the primary build task can be reused.
[0067] After compilation is complete, a cache is created for subsequent use: after compiling the code of the target application to obtain the compilation artifacts, the compilation artifacts are stored in a preset shared storage space; an association is established between the compilation artifacts and the code version identifier as a pre-stored compilation cache result.
[0068] Shared storage space refers to a storage location that can be accessed by all packaging servers in the network.
[0069] After compilation, the generated .exe / .dll files are packaged and stored in this shared space, and the storage path corresponding to this version of the code is recorded (i.e., an association is established). This way, subsequent packaging requests for the same code version from other channels can directly hit the cache when executing step S302. The beneficial effect of this step is that it achieves compilation once and reuse multiple times, significantly reducing the time spent on subsequent packaging tasks.
[0070] Step S303: Generate the target installation package based on the compilation artifacts and configuration information.
[0071] To resolve concurrent conflicts, an isolation mechanism is used in the generation process.
[0072] Based on the compilation artifacts and configuration information, the target installation package is generated, including: creating an independent task working directory for the packaging request and copying the compilation artifacts to the task working directory; copying the executable program file and dependency library files of the preset packaging tool to the task working directory to construct an independent tool execution environment for the packaging request in the task working directory; in the independent tool execution environment, calling the copied executable program file of the packaging tool, encapsulating the compilation artifacts and configuration information and performing digital signing to generate the target installation package.
[0073] The task working directory is a temporary folder (e.g., / tmp / job_101) created for the current single packaging task, and is physically isolated from other tasks. The packaging tool is software used to create installation packages (e.g., InnoSetup).
[0074] The beneficial effect of this mechanism is that it completely eliminates file lock conflicts during multi-process concurrent packaging (such as multiple tasks competing for the same global tool configuration file), ensuring stability in high-concurrency scenarios.
[0075] During the generation process, configuration resources are also managed in a refined manner. The configuration information includes the channel identifier and channel configuration file corresponding to the target installation package; it also includes: before generating the target installation package, downloading the corresponding channel configuration file to the task working directory based on the channel identifier; and after generating the target installation package, deleting the channel configuration file from the task working directory.
[0076] Channel configuration files may contain channel-specific icons, splash screens, or SDK configuration files.
[0077] Download the corresponding materials from the resource server to a temporary directory based on the channel identifier (e.g., ID=1001). Delete these files immediately after use (generating the package). This ensures that the package from channel A will never contain icons from channel B, thus saving storage space.
[0078] Step S304: Perform quality verification on the generated target installation package.
[0079] After generating the target installation package, the process also includes: performing integrity verification and digital signature verification on the target installation package; integrity verification includes checking whether the file exists and whether the file name conforms to the preset specifications, and digital signature verification includes verifying whether the signature exists and whether the timestamp is valid; after both integrity verification and digital signature verification pass, the target installation package is deemed to have passed verification.
[0080] Integrity check is to check whether the package is damaged (e.g., 0 bytes in size), and digital signature check is to check whether the package is secure.
[0081] Scan the generated file, confirm that the file name is correct (such as App_v1.0_ChannelA.exe), and then use the verification tool to check whether the signature timestamp of the file is within the valid period. Only when both pass can the package be considered qualified. The beneficial effect of this step is to prevent invalid packages caused by network fluctuations or disk failures from flowing into the market.
[0082] Step S305: Execute asynchronous upload and manage the status of batch tasks.
[0083] The packaging request is used to indicate the generation task including multiple target installation packages, and also includes: after generating the current target installation package, establishing an asynchronous upload task for the current target installation package, and executing the asynchronous upload task to upload the current target installation package to the content distribution network; after establishing the asynchronous upload task, continue to process the packaging request for the next target installation package, so that the asynchronous upload task and the processing of the generation task for the next target installation package are executed in parallel.
[0084] The asynchronous upload task refers to an upload thread that runs independently in the background and does not block the main process. The content distribution network (CDN) is the download server where the installation package is finally released to users.
[0085] After establishing the asynchronous upload task, instead of waiting for the upload to complete, continue to process the packaging request for the next target installation package. Specifically, based on the current channel identifier corresponding to the current target installation package, determine the next channel identifier from multiple channel identifiers; obtain the channel configuration file corresponding to the next channel identifier to execute the generation task for the next target installation package.
[0086] For example, when the package for Channel A is generated, instead of waiting for it to be transmitted, a background process is established to be responsible for the transmission, and the main program immediately continues to process the packaging for Channel B. This makes the upload of Channel A and the generation of Channel B overlap in time (executed in parallel). The beneficial effect of this mechanism is to make the best use of server resources (CPU and network bandwidth work simultaneously), and greatly improve the overall throughput of batch packaging.
[0087] Finally, determine the result of the overall task: obtain the execution results of all established asynchronous upload tasks; after confirming that all asynchronous upload tasks have been executed, determine that the generation task including multiple target installation packages ends; if any asynchronous upload task returns a failure status message, determine that the generation task including multiple target installation packages fails.
[0088] The execution result is the status code of successful or failed upload.
[0089] After all packages are generated and the upload is triggered, all background tasks are monitored. The entire task is only considered complete when all packages have been uploaded. If even one package fails to upload (returning a failure status message), the entire task is marked as failed. This avoids the release chaos caused by partial successes and partial failures.
[0090] In summary, the application installation package generation method provided in this disclosure first achieves multiple reuses of the compilation artifacts for the same code version by obtaining the code version identifier and retrieving the pre-stored compilation cache results. Combined with a distributed synchronization lock mechanism, it effectively avoids repeated building of the same version of code in concurrent scenarios, fundamentally eliminating resource waste caused by redundant computation. Furthermore, by creating an independent task working directory for each packaging request and introducing isolated execution of packaging tool copies and an on-demand download and real-time cleanup mechanism for channel configuration files, it effectively solves the frequent file read / write conflicts and signature mutual exclusion access failures that occur in related technologies during concurrent packaging.
[0091] Furthermore, by establishing asynchronous upload tasks, time-consuming network transmission operations are decoupled from CPU-intensive packaging and generation tasks. This allows the next packaging request to be processed in parallel while the current installation package is being uploaded, achieving overlapping utilization of computing resources and network bandwidth. This effectively avoids resource idleness caused by waiting and greatly improves the throughput and production efficiency of the overall packaging process. Simultaneously, a dual verification mechanism of integrity and digital signature is implemented in conjunction with the generated installation package, significantly improving packaging speed while ensuring the security and reliability of the package body, preventing damaged or tampered installation packages from entering the distribution network.
[0092] To better illustrate the method for generating application installation packages according to embodiments of this disclosure, a preferred embodiment will be provided below. This embodiment is intended to describe the implementation process of this disclosure in detail, but is not intended to limit the scope of protection of this disclosure.
[0093] This disclosure provides a method for generating application installation packages, taking the multi-channel packaging scenario of Windows applications under a large-scale game distribution platform as an example. It aims to solve the problems of low packaging efficiency and insufficient stability caused by repeated compilation and resource competition in the scenario of large-scale packaging of multiple games and multiple channels.
[0094] The specific workflow of this embodiment is as follows: The process begins with the packaging task management backend. Figure 4 This is a schematic diagram of the task creation interface in the packaging task management backend. The visual task creation interface provided by the backend includes a "Main Channel" selection area and a "Branch" input control.
[0095] Users (such as operations or development personnel) first select or specify one or more target channels to be released in the "Main Channels" area (i.e., basic information of the batch channel package), and then enter the specific branch name or commit record (Commit Hash) of the code to be built in the "Branch" input box. After clicking the "Create" button on the interface, the background will officially initiate the batch packaging request.
[0096] The CI system then calls the underlying packaging script, passing in the channel list, code version identifier, and environment parameters (used to distinguish between production and test packages) determined in the aforementioned interface as input parameters. This step achieves a seamless transition from visual configuration to automated scheduling, clearly defining the version target and scope of the packaging task.
[0097] Before proceeding to the creation of specific channel packages, the system first processes the compilation of the core code. Figure 5 This is a flowchart illustrating the compilation and caching mechanisms, such as... Figure 5 As shown, the process mainly includes the following steps: Once the CI task starts and receives the execution command, it first checks the cache folder in the shared directory. This step is based on the incoming code commit hash.
[0098] If a corresponding cache folder is found in the shared directory, the process directly enters the cache reuse branch. The operation is to copy the cache folder from the shared directory to the local machine. At this point, the local machine directly obtains the compiled and signed output, the process ends, and it directly proceeds to the subsequent batch packaging stage.
[0099] If the corresponding cache is not found in the shared directory, proceed to the build branch: First, the code is compiled to build EXE, DLL, and other files.
[0100] After the build is complete, a preprocessing process is executed immediately. For example... Figure 5 As shown, the process consists of three specific sub-steps: Create version identifier: Generate a unique version ID for the current build.
[0101] Signing EXE and DLL files: This means signing the files immediately after the compilation output is generated.
[0102] Copy dependency files: Collect and organize the dependency libraries required for the program to run.
[0103] After preprocessing, the build results are copied to a shared directory, and a new cache folder is created using the hash value of the code commit for that build. This ensures that the results can be reused for subsequent tasks using the same version.
[0104] After obtaining the general compilation artifacts, the process moves to the stage of batch production of channel packages. To ensure stability under high concurrency, this embodiment employs strict isolation measures.
[0105] Working directory isolation: Each CI Runner task is assigned a separate working directory. All operations (file reading and writing, tool execution) are confined to this directory.
[0106] Tool environment isolation: Instead of relying on globally installed tools, the core program of InnoSetup (ISCC.exe) and its dependent libraries (isbunzip.dll, ISCmplr.dll, etc.) are copied to this directory to run, ensuring that the environments do not interfere with each other.
[0107] Digital signature tools also copy themselves and execute them in the working directory to avoid concurrent conflicts.
[0108] Based on the channel configuration, download the channel-specific static resources (such as configuration files, icons, and images) to the working directory as needed. Integrate the resources with the compilation artifacts, call the local ISCC.exe to generate the final installation package, and digitally sign the installation package. Once the installation package is generated, immediately delete the channel-specific resources to prevent misuse of resources between different channels.
[0109] After the installation package is generated, it is not released immediately, but instead undergoes dual verification: Integrity verification: Traverse the directory to check if the file exists, if the filename matches the channel configuration, and if the file format is correct.
[0110] Digital signature verification: Use Python's signify library to verify whether the digital signature of the installation package exists and whether the timestamp is valid.
[0111] If the verification fails, the installation package will be created again and verified once more; if it still fails, the task will be considered a failure.
[0112] The verified installation package proceeds to the release phase. This embodiment uses an asynchronous upload mechanism. Figure 6 This is a flowchart illustrating the process of asynchronous uploading and resource optimization, such as... Figure 6 As shown, this process is embedded in the overall loop logic of batch production of channel packages, as follows: Loop processing logic, such as Figure 6 As shown: Perform a loop operation for each channel. Within the loop, sequentially execute the following steps: read channel configuration and static resources, create channel installation package / signature, and perform checks (including integrity checks and signature checks).
[0113] Parallel splitting logic, such as Figure 6As shown, once the inspection is passed, the process splits: Main thread: Instead of waiting for the upload to complete, it returns directly to the beginning of the loop and continues to process the configuration reading and package creation tasks for the next channel.
[0114] Asynchronous thread: Starts the task of asynchronously uploading the channel package body and uploads the file to the CDN (Content Delivery Network).
[0115] from Figure 6 As can be seen, the CDN upload action is designed as an asynchronous operation independent of the main package creation process, which allows the channel package creation loop to run continuously, while the upload action is executed in parallel in the background.
[0116] In summary, this embodiment achieves "compile once, reuse multiple times" by introducing a compilation result caching mechanism, eliminating the resource waste caused by repeatedly building the same version of code. Simultaneously, by combining resource isolation for concurrent tasks with asynchronous upload strategies, it effectively solves the resource contention problem in high-concurrency environments and achieves full utilization of computing resources and network bandwidth.
[0117] This embodiment also provides an application installation package generation apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0118] This embodiment provides an application installation package generation device, such as... Figure 7 As shown, it includes: The first acquisition module 701 is used to respond to receiving a packaging request for the target application, and to acquire the code version identifier corresponding to the packaging request and the configuration information of the target installation package to be generated; The second acquisition module 702 is used to acquire the compilation artifacts corresponding to the code version identifier; the compilation artifacts are obtained by reading from the pre-stored compilation cache results based on the code version identifier, or by compiling the code of the target application when the pre-stored compilation cache results are not read. Module 703 is used to generate the target installation package based on the compilation artifacts and configuration information.
[0119] In some alternative implementations, the first acquisition module 701 is used for: Using the code version identifier as an index, query the preset shared storage space to see if there is a corresponding compilation artifact; if there is, read the compilation artifact from the shared storage space.
[0120] In some alternative embodiments, the device further includes: The compilation module 704 is used to compile the code of the target application to obtain the compilation product, and then store the compilation product in a preset shared storage space. Establish an association between the compilation artifacts and the code version identifier, so as to serve as a pre-stored compilation cache result.
[0121] In some alternative implementations, compiler module 704 is used for: Acquire a distributed synchronization lock based on the code version identifier; After successfully acquiring the distributed synchronization lock, the code of the target application is compiled to generate a binary file, which is then digitally signed to obtain the compilation artifact.
[0122] In some alternative implementations, compiler module 704 is used for: Check if a lock record exists with the code version identifier as the key. If the lock record does not exist, create the lock record and determine that the acquisition was successful; If a lock record exists, the process will wait for a preset time interval and then retry. If the distributed synchronization lock is still not acquired during the retry, the task is deemed abnormal. A task abnormality is used to indicate the termination of the generation process of the target installation package for the packaging request.
[0123] In some alternative implementations, the generation module 703 is used for: Create a separate task working directory for the packaging request and copy the compiled artifacts to the task working directory; Copy the executable file and dependency library files of the preset packaging tool to the task working directory to create an independent tool execution environment for the packaging request in the task working directory; In the standalone tool execution environment, the executable file of the copied packaging tool is invoked, the compilation artifacts and configuration information are encapsulated and digitally signed, and the target installation package is generated.
[0124] In some optional implementations, the configuration information includes the channel identifier and channel configuration file corresponding to the target installation package; the generation module 703 is further used for: Before generating the target installation package, download the corresponding channel configuration file to the task working directory based on the channel identifier; After generating the target installation package, delete the channel configuration file from the task working directory.
[0125] In some alternative implementations, the generation module 703 is further configured to: Perform integrity and digital signature verification on the target installation package; integrity verification includes checking whether the file exists and whether the file name conforms to the preset specifications, and digital signature verification includes verifying whether the signature exists and whether the timestamp is valid. After both integrity verification and digital signature verification pass, the target installation package is deemed to have passed verification.
[0126] In some alternative implementations, the packaging request is used to instruct a build task containing multiple target installation packages, and the build module 703 is further used to: After generating the current target installation package, create an asynchronous upload task for the current target installation package and execute the asynchronous upload task to upload the current target installation package to the content delivery network; After establishing the asynchronous upload task, continue processing the packaging request for the next target installation package, so that the asynchronous upload task and the processing of the generation task for the next target installation package are executed in parallel.
[0127] In some optional implementations, the packaging request is a batch packaging request containing multiple channel identifiers; the generation module 703 is further configured to: Based on the current channel identifier corresponding to the current target installation package, determine the next channel identifier from multiple channel identifiers; Retrieve the channel configuration file corresponding to the next channel identifier to execute the generation task for the next target installation package.
[0128] In some alternative implementations, the generation module 703 is further configured to: Retrieve the execution results of all established asynchronous upload tasks; Once it is confirmed that all asynchronous upload tasks have been executed, the generation task containing multiple target installation packages is considered complete. If any asynchronous upload task returns a failure status message, the generation task containing multiple target installation packages is determined to have failed.
[0129] The application installation package generation apparatus provided in this disclosure can execute the application installation package generation method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.
[0130] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure.
[0131] The following is a detailed reference. Figure 8The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present disclosure. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 801, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 802 or a program loaded from memory 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the electronic device. The processor 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.
[0132] Typically, the following devices can be connected to I / O interface 805: input devices 806 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 807 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 808 including, for example, magnetic tapes, hard disks, etc.; and communication devices 809. Communication device 809 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.
[0133] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 809, or installed from a memory 808, or installed from a ROM 802. When the computer program is executed by the processor 801, it performs the functions defined in the application installation package generation method of embodiments of this disclosure.
[0134] Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.
[0135] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded over a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the application installation package generation method shown in the above embodiments is implemented.
[0136] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.
[0137] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.
Claims
1. A method for generating an application installation package, characterized in that, The method includes: In response to receiving a packaging request for the target application, the code version identifier corresponding to the packaging request and the configuration information of the target installation package to be generated are obtained; Obtain the compilation artifact corresponding to the code version identifier; the compilation artifact is obtained by reading from the pre-stored compilation cache results based on the code version identifier, or by compiling the code of the target application when the pre-stored compilation cache results are not read. The target installation package is generated based on the compilation output and the configuration information.
2. The method according to claim 1, characterized in that, The step of obtaining the code version identifier from the pre-stored compilation cache results includes: Using the code version identifier as an index, query the preset shared storage space to see if there is a corresponding compilation artifact; if there is, read the compilation artifact from the shared storage space.
3. The method according to claim 1, characterized in that, The method further includes: After obtaining the compilation product by compiling the code of the target application, the compilation product is stored in a preset shared storage space; Establish an association between the compilation artifact and the code version identifier, so as to serve as the pre-stored compilation cache result.
4. The method according to claim 1, characterized in that, Compiling the code of the target application includes: Based on the code version identifier, a distributed synchronization lock is obtained; After successfully acquiring the distributed synchronization lock, the code of the target application is compiled to generate a binary file, and the binary file is digitally signed to obtain the compilation product.
5. The method according to claim 4, characterized in that, The acquisition of the distributed synchronization lock includes: Check if a lock record exists with the code version identifier as the key value; If the lock record does not exist, create the lock record and determine that the acquisition was successful; If the lock record exists, the process will wait for a preset time interval and then retry. If the distributed synchronization lock is still not acquired during the retry, the task is deemed abnormal. The task abnormality is used to indicate the termination of the generation process of the target installation package for the packaging request.
6. The method according to claim 1, characterized in that, The step of generating the target installation package based on the compilation output and the configuration information includes: Create a separate task working directory for the packaging request, and copy the compilation artifacts to the task working directory; The executable file and dependency library files of the preset packaging tool are copied to the task working directory to construct an independent tool execution environment for the packaging request in the task working directory. In the standalone tool execution environment, the copied executable file of the packaging tool is invoked to encapsulate the compilation artifacts and the configuration information and perform digital signing to generate the target installation package.
7. The method according to claim 6, characterized in that, The configuration information includes the channel identifier and channel configuration file corresponding to the target installation package; the method further includes: Before generating the target installation package, the corresponding channel configuration file is downloaded to the task working directory according to the channel identifier; After generating the target installation package, delete the channel configuration file from the task working directory.
8. The method according to claim 1, characterized in that, After generating the target installation package, the method further includes: The target installation package is subjected to integrity verification and digital signature verification; the integrity verification includes checking whether the file exists and whether the file name conforms to the preset specifications, and the digital signature verification includes verifying whether the signature exists and whether the timestamp is valid. After both the integrity verification and the digital signature verification pass, the target installation package is deemed to have passed verification.
9. The method according to claim 1, characterized in that, The packaging request is used to instruct a generation task containing multiple target installation packages, and the method further includes: After generating the current target installation package, an asynchronous upload task is created for the current target installation package, and the asynchronous upload task is executed to upload the current target installation package to the content delivery network; After the asynchronous upload task is established, the packaging request for the next target installation package is processed, so that the asynchronous upload task and the processing of the generation task for the next target installation package are executed in parallel.
10. The method according to claim 9, characterized in that, The packaging request is a batch packaging request containing multiple channel identifiers; the process of continuing to process the packaging request for the next target installation package includes: Based on the current channel identifier corresponding to the current target installation package, determine the next channel identifier from the plurality of channel identifiers; Obtain the channel configuration file corresponding to the next channel identifier to execute the generation task for the next target installation package.
11. The method according to claim 9, characterized in that, The method further includes: Retrieve the execution results of all established asynchronous upload tasks; Once it is confirmed that all the asynchronous upload tasks have been executed, the generation task containing multiple target installation packages is considered complete. If any asynchronous upload task returns a failure status message, then the generation task containing multiple target installation packages is determined to have failed.
12. An apparatus for generating an application installation package, characterized in that, The device includes: The first acquisition module is used to, in response to receiving a packaging request for the target application, acquire the code version identifier corresponding to the packaging request and the configuration information of the target installation package to be generated; The second acquisition module is used to acquire the compilation artifacts corresponding to the code version identifier; the compilation artifacts are obtained by reading from the pre-stored compilation cache results based on the code version identifier, or by compiling the code of the target application when the pre-stored compilation cache results are not read. The generation module is used to generate the target installation package based on the compilation output and the configuration information.
13. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory storing computer instructions, and the processor executing the computer instructions to perform the method for generating an application installation package according to any one of claims 1 to 11.
14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to execute the method for generating an application installation package according to any one of claims 1 to 11.
15. A computer program product, characterized in that, It includes computer instructions for causing a computer to execute the method for generating an application installation package according to any one of claims 1 to 11.