A method and system for constructing an application installation package, an electronic device, and a storage medium

Abstract

The application discloses a kind of application installation package construction method, system, electronic equipment and storage medium, and the technical field belongs to software engineering technical field.The application installation package construction method: determine current environment, module requirement information is determined according to the current environment;Wherein, the module requirement information is the information for describing whether function module needs to be integrated in application installation package;The function module includes first type function module and second type function module, the first type function module is the function module needing to be integrated in application installation package, and the second type function module is the function module not needing to be integrated in application installation package;First control operation and second control operation are executed, and intermediate code file is obtained;The intermediate code file and corresponding resource file are packed, and application installation package is obtained;The application can construct application installation package in the case where useless code is avoided to remain.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and in particular to a method, system, electronic device, and storage medium for constructing an application installation package. Background Technology

[0002] In software project development, multiple environments are typically deployed for development and testing purposes, such as a development environment (dev), a testing environment (test), a pre-production environment (pre), and a production environment (product). Different functional modules need to be built into corresponding application installers for different environments. Traditional solutions use conditional compilation to build application installers. However, most functional modules require references to their internal code when called. If the source code references this internal code, the module must be added as a compiler dependency during compilation; otherwise, compilation will fail, and the application installer cannot be generated.

[0003] To avoid compilation failures, the code of the corresponding module is usually accessed through reflection. However, the above method leaves useless reflection code in the application installation package, which not only affects runtime performance but may also cause crashes, stutters and other exceptions due to the useless code.

[0004] Therefore, how to build application installation packages while avoiding useless code residues is a technical problem that needs to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide a method, system, electronic device, and storage medium for building application installation packages, which can build application installation packages while avoiding useless code residue.

[0006] To address the aforementioned technical problems, this application provides a method for constructing an application installation package, comprising: Determine the current environment, and determine the module requirement information based on the current environment; wherein, the module requirement information is information used to describe whether the functional module needs to be integrated into the application installation package; the functional module includes a first type of functional module and a second type of functional module, the first type of functional module is the functional module that needs to be integrated into the application installation package, and the second type of functional module is the functional module that does not need to be integrated into the application installation package; Execute the first and second control operations to obtain the intermediate code file; The intermediate code files and corresponding resource files are packaged to obtain the application installation package; The first control operation includes: adding dependency declarations of the first type of functional modules to the configuration information according to the module requirement information, and removing dependency declarations of the second type of functional modules from the configuration information; generating a compilation path according to the configuration information, and performing a compilation operation according to the compilation path to obtain the intermediate code file; The second control operation is either a source code modification operation or an instrumentation control operation. The source code modification operation includes: before performing the compilation operation according to the compilation path, removing content related to the second type of functional module from the source code based on the module requirement information; The instrumentation control operation includes: determining an instrumentation strategy based on the module requirement information, and performing instrumentation operations on the intermediate code file according to the instrumentation strategy before packaging the intermediate code file and the corresponding resource file; the instrumentation strategy includes: allowing the code corresponding to the first type of functional module to participate in the instrumentation operation, and prohibiting the code corresponding to the second type of functional module from participating in the instrumentation operation.

[0007] Optionally, before performing the second control operation, the method further includes: The source code modification operation or the instrumentation control operation is set as the second control operation according to the environment configuration.

[0008] Optionally, if the second control operation is the source code modification operation, then the intermediate code file and the corresponding resource file are packaged, including: Package the intermediate code files and corresponding resource files obtained from the compilation operation; If the second control operation is the instrumentation control operation, then the intermediate code file and the corresponding resource file are packaged, including: Package the instrumented intermediate code files and corresponding resource files.

[0009] Optionally, based on the module requirement information, remove content from the source code related to the second type of functional module, including: In the source code file, remove the code and dependency import statements related to the second type of functional module based on the module requirement information.

[0010] Optionally, perform compilation operations according to the compilation path, including: Generate the corresponding dependency tree based on the configuration information; By traversing the dependency tree, it can be determined whether the second type of functional module is directly or indirectly introduced. If not, then perform the compilation operation according to the specified compilation path.

[0011] Optionally, after obtaining the application installation package, it may also include: Use static scanning tools to determine whether the code, dependencies, and instrumentation code of the second type of functional module do not appear in the application installation package; If so, the application installation package is deemed to have passed verification; If not, the application installation package is determined to have failed verification, and a corresponding verification analysis report is output.

[0012] Optionally, determine the current environment, including: The script reads the current environment; the current environment includes, but is not limited to, a development environment, a testing environment, a pre-production environment, or a production environment.

[0013] This application also provides a system for building application installation packages, including: An environment perception module is used to determine the current environment and determine module requirement information based on the current environment; wherein, the module requirement information is information describing whether the functional module needs to be integrated into the application installation package; the functional modules include a first type of functional modules and a second type of functional modules, the first type of functional modules being functional modules that need to be integrated into the application installation package, and the second type of functional modules being functional modules that do not need to be integrated into the application installation package; A dual-cooperative control module is used to execute the first and second control operations to obtain intermediate code files; The packaging output module packages the intermediate code files and corresponding resource files to obtain the application installation package; The first control operation includes: adding dependency declarations of the first type of functional modules to the configuration information according to the module requirement information, and removing dependency declarations of the second type of functional modules from the configuration information; generating a compilation path according to the configuration information, and performing a compilation operation according to the compilation path to obtain the intermediate code file; The second control operation is either a source code modification operation or an instrumentation control operation. The source code modification operation includes: before performing the compilation operation according to the compilation path, removing content related to the second type of functional module from the source code based on the module requirement information; The instrumentation control operation includes: determining an instrumentation strategy based on the module requirement information, and performing instrumentation operations on the intermediate code file according to the instrumentation strategy before packaging the intermediate code file and the corresponding resource file; the instrumentation strategy includes: allowing the code corresponding to the first type of functional module to participate in the instrumentation operation, and prohibiting the code corresponding to the second type of functional module from participating in the instrumentation operation.

[0014] This application also provides a storage medium on which a computer program is stored, wherein the computer program, when executed, implements the steps of the above-described application installation package construction method.

[0015] This application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor, when calling the computer program in the memory, implements the steps of the above-described application installation package construction method.

[0016] This application provides a method for building an application installation package. This method determines module requirement information based on the current environment, thereby identifying a first type of functional modules that need to be integrated into the application installation package and a second type of functional modules that do not need to be integrated. Based on the module requirement information, this application can perform a first control operation and a second control operation to obtain intermediate code files without irrelevant functional modules, and then perform a packaging operation to obtain the application installation package. Specifically, by performing the first control operation, dependency declarations of the first type of functional modules can be added to the configuration information according to the module requirement information, and dependency declarations of the second type of functional modules can be removed from the configuration information; this application performs a compilation operation according to the compilation path corresponding to the configuration information to obtain intermediate code files without irrelevant functional modules. The second control operation includes source code modification operations or instrumentation strategy modification operations; by performing source code modification operations, content related to the second type of functional modules in the source code can be removed during the pre-compilation stage; by performing instrumentation strategy modification operations, the code participating in instrumentation is controlled so that the code corresponding to the second type of functional modules participates in the instrumentation operation. The above scheme can eliminate functional modules that do not need to be integrated into the application installation package during the process of building the application installation package, therefore, this application can build the application installation package without leaving useless code residues. This application also provides an application installation package building system, a storage medium, and an electronic device, which have the above-mentioned beneficial effects, and will not be elaborated here. Attached Figure Description

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

[0018] Figure 1 A flowchart illustrating a method for constructing an application installation package as provided in an embodiment of this application; Figure 2 This is a schematic diagram of functional module dependencies provided in an embodiment of this application; Figure 3This is a flowchart illustrating a residue-free decoupling module integration method based on dual-control collaboration, provided in an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] Please see below. Figure 1 , Figure 1 This is a flowchart illustrating a method for constructing an application installation package, as provided in an embodiment of this application.

[0021] Specific steps may include: S101: Determine the current environment and determine the module requirement information based on the current environment.

[0022] This embodiment can be applied to electronic devices with application installation package building capabilities. This step can obtain the current environment. The aforementioned current environment is the build environment configuration for the application package. This step can utilize a script to read the current environment; wherein, the current environment includes, but is not limited to: development environment, testing environment, pre-production environment, or production environment.

[0023] This step allows you to pre-set the mapping between the current environment and module requirement information. Module requirement information describes whether each functional module needs to be integrated into the application installation package. For example, this step can determine which functional modules need to be integrated and which should be removed based on preset environment-module mapping rules, generating the corresponding module requirement information.

[0024] Based on module requirement information, all functional modules can be divided into two categories: Category 1 functional modules and Category 2 functional modules. The aforementioned functional modules include Category 1 and Category 2 functional modules. Category 1 functional modules are those that need to be integrated into the application installation package, while Category 2 functional modules are those that do not need to be integrated into the application installation package.

[0025] S102: Execute the first control operation and the second control operation to obtain the intermediate code file.

[0026] The purpose of this step is to generate an intermediate code file that does not contain irrelevant functional modules by executing the first control operation and the second control operation.

[0027] The process of performing the first control operation includes: adding dependency declarations for the first type of functional modules to the configuration information based on the module requirement information, and removing dependency declarations for the second type of functional modules from the configuration information; generating a compilation path based on the configuration information, and performing compilation operations according to the compilation path to obtain the intermediate code file. The first control operation dynamically maintains dependency declarations in the configuration information based on the module requirement information; for the first type of functional modules to be integrated, dependency declarations are added to the configuration file to ensure that the first type of functional modules can enter the compilation process; for the second type of functional modules to be removed, their dependency declarations can be removed from the configuration file. The above first control operation ensures that the compiler's input (compilation path) only contains necessary modules, preventing the mixing of useless code from the source. A corresponding compilation path can be generated based on the configuration information. This compilation path defines the location of all source code and library files accessible to the compiler. The compiler strictly follows the compilation path to perform compilation operations, generating clean intermediate code files. The above process ensures that the code of the second type of functional modules does not enter the compilation process.

[0028] The second control operation mentioned above can be a source code modification operation or an instrumentation control operation.

[0029] The process of performing the above source code modification operation includes: before performing the compilation operation according to the compilation path, removing the content related to the second type of functional module from the source code according to the module requirement information.

[0030] The process of performing the above instrumentation control operation includes: determining the instrumentation strategy based on the module requirement information, and performing instrumentation operation on the intermediate code file according to the instrumentation strategy before packaging the intermediate code file and the corresponding resource file; the instrumentation strategy includes: allowing the code corresponding to the first type of functional module to participate in the instrumentation operation, and prohibiting the code corresponding to the second type of functional module from participating in the instrumentation operation.

[0031] The source code modification operation is performed before the compilation operation. If the second control operation is a source code modification operation, the implementation process of S102 is as follows: According to the module requirement information, add the dependency declaration of the first type of functional module in the configuration information, and remove the dependency declaration of the second type of functional module in the configuration information; generate a compilation path according to the configuration information, remove the content related to the second type of functional module in the source code according to the module requirement information, and perform the compilation operation according to the compilation path to obtain the intermediate code file.

[0032] The instrumentation control operation is performed after the intermediate code file is compiled and before the application installation package is generated. If the second control operation is an instrumentation control operation, the implementation process of S102 is as follows: According to the module requirement information, add the dependency declaration of the first type of functional module to the configuration information and remove the dependency declaration of the second type of functional module from the configuration information; generate a compilation path according to the configuration information and perform the compilation operation according to the compilation path to obtain the intermediate code file; determine the instrumentation strategy according to the module requirement information, and perform the instrumentation operation on the intermediate code file according to the instrumentation strategy before packaging the intermediate code file and the corresponding resource file.

[0033] S103: Package the intermediate code file and the corresponding resource file to obtain the application installation package.

[0034] This step involves inputting the intermediate code files generated from the compilation process and the filtered resource files into a packaging tool to ultimately generate a redundant application installation package that fully meets the requirements of the current environment.

[0035] If the second control operation is the source code modification operation, then the process of packaging the intermediate code file and the corresponding resource file includes: packaging the intermediate code file and the corresponding resource file obtained from the compilation operation.

[0036] If the second control operation is the instrumentation control operation, then the process of packaging the intermediate code file and the corresponding resource file includes: packaging the instrumented intermediate code file and the corresponding resource file.

[0037] This embodiment determines module requirement information based on the current environment, thereby identifying a first type of functional modules that need to be integrated into the application installation package and a second type of functional modules that do not need to be integrated into the application installation package. Based on the module requirement information, this embodiment can execute a first control operation and a second control operation to obtain intermediate code files without irrelevant functional modules, and then perform a packaging operation to obtain the application installation package. Specifically, by executing the first control operation, dependency declarations of the first type of functional modules can be added to the configuration information according to the module requirement information, and dependency declarations of the second type of functional modules can be removed from the configuration information; this embodiment performs a compilation operation according to the compilation path corresponding to the configuration information to obtain intermediate code files without irrelevant functional modules. The second control operation includes source code modification operation or instrumentation strategy modification operation; by executing the source code modification operation, content related to the second type of functional modules in the source code can be removed during the pre-compilation stage; by executing the instrumentation strategy modification operation, the code participating in instrumentation is controlled so that the code corresponding to the second type of functional modules participates in the instrumentation operation. The above scheme can eliminate functional modules that do not need to be integrated into the application installation package during the process of building the application installation package, so that this embodiment can build the application installation package without the presence of useless code residues.

[0038] As for Figure 1 As further described in the corresponding embodiment, before executing the second control operation, the source code modification operation or the instrumentation control operation can be set as the second control operation according to the environment configuration. This operation allows the source code modification operation or the instrumentation control operation to be selected as the second control operation based on the environment configuration, avoiding the execution of invalid operations and improving the efficiency of application installation package construction.

[0039] As for Figure 1 A further description of the corresponding embodiment: the process of removing content related to the second type of functional module from the source code based on the module requirement information includes: in the source code file, removing code and dependency import statements related to the second type of functional module according to the module requirement information. Specifically, during the pre-compilation stage, this solution performs scanning and cleaning on the source code file, deletes code related to the second type of functional module, and simultaneously removes its corresponding dependency import statements.

[0040] As for Figure 1A further description of the corresponding embodiment: the process of performing the compilation operation according to the compilation path includes: generating a corresponding dependency tree based on the configuration information; determining whether the second type of functional module is directly or indirectly introduced by traversing the dependency tree; if so, terminating the build process and outputting a dependency introduction path diagnostic report to prompt the user of configuration errors that violate module requirements; if not, performing the compilation operation according to the compilation path. The above process enables dependency verification before compilation, ensuring that the second type of functional module marked as not requiring integration and all its transitive dependencies are not mixed into the compilation environment, thereby avoiding the introduction of useless code.

[0041] As for Figure 1 As further described in the corresponding embodiment, after obtaining the application installation package, a static scanning tool can be used to determine whether the code, dependencies, and instrumentation code of the second type of functional module are not present in the application installation package. If so, the application installation package is determined to have passed the verification; if not, the application installation package is determined to have failed the verification, and a corresponding verification analysis report is output. The verification analysis report may include the specific name of the residual module, the residual type (code / dependency / instrumentation code), the physical path in the installation package, the file size, and the complete dependency import tracing chain.

[0042] The process described in the above embodiments is illustrated below through examples in practical applications.

[0043] In software project development, the following environments are typically deployed for development and testing purposes: Development environment (dev): The environment used for research and development, containing a lot of code for logging, monitoring, debugging, and third-party modules; Testing environment (test): The environment used for testing, containing some code for logging, monitoring, debugging, and third-party modules; Pre-production environment (pre): The environment used for testing, usually used for full network testing (final testing before going live); Production environment (product): The environment used by online users, containing only the modules used.

[0044] Project engineering refers to source files written by developers using languages ​​supported by development tools. These files are composed of ordered numbers or letters and represent objective entities and their attributes. Application engineering refers to computer programs designed to perform one or more specific tasks. These programs run in user mode, can interact with the user, and have a visual user interface. The modules mentioned above refer to program modules, which are independent, identifiable program instructions that can be processed as a whole by an assembler, compiler, loader, or translator.

[0045] For the environments described above, the self-developed and third-party modules included in the applications compiled and built from the projects are different. For example, the development environment (dev) and the testing environment (test) might integrate a third-party module to collect runtime information for easier problem localization. However, this module might be restricted by privacy compliance due to the collection of sensitive device information, or it might not be usable in the production environment (product) application due to package size limitations. In this case, the module cannot be compiled and built into the production environment (product) application. Self-developed modules refer to modules written by developers in a language supported by the development tools within the project, whose source code can be directly modified. Third-party modules refer to modules written and packaged in other projects, possessing specific functionalities, whose source code cannot be directly modified. Please see [link to relevant documentation]. Figure 2 , Figure 2 This illustration illustrates a functional module dependency in an embodiment of this application. The main project depends on self-developed module 1, self-developed module 2, third-party module 1, and third-party module 2. The production environment (product) does not depend on self-developed module 1 and third-party module 2, while other environments (dev, test, etc.) depend on these two modules. To address this issue, a conditional compilation scheme is typically used. This involves determining the current environment during compilation to decide whether a module needs to be compiled into the application. For example, code to determine the product environment can be added to the compilation code to decide whether to depend on self-developed module 1 and third-party module 2. However, most modules require their internal code during use. Once the module's code is used, the compilation and build process must depend on that module; otherwise, compilation will fail, and the application will not be generated. Compilation and build refer to the process of compiling the project's source code into object files and packaging them together with configuration files, resource files, etc.

[0046] A common solution to the above compilation failure problem is to use the corresponding module's code via reflection. This approach allows for successful compilation without explicitly depending on the third-party module's code. The specific implementation steps are as follows: Module dependency import: In the build configuration file, the target module is imported according to the environment dependencies. For environments that need the target module, the module code will be compiled and packaged into the final application installation package. For environments that do not need the target module, it will not be compiled and packaged into the final application installation package.

[0047] Environment determination logic: At the application startup or module initialization entry point, the current running environment is determined by reading environment variables, build parameters or configuration files.

[0048] Reflection-based loading control: If the current environment requires integrating the target module (e.g., dev, test, pre environments), the module class object is obtained through reflection, and the constructor or initialization method is called to complete module loading. If the current environment does not require integrating the module (e.g., product environments), reflection calls are skipped, and no module initialization logic is executed. Reflection refers to the technique in computer science for dynamically accessing, inspecting, and modifying the structure and behavior of a program. Its core mechanism implements metadata operations by encapsulating assemblies, modules, and types, enabling the program to parse object information and dynamically call members at runtime.

[0049] Module function call: In subsequent business logic, the module function is called through the interface or dependency injection. If the module is not loaded, an empty implementation is called or a caught exception is thrown.

[0050] The above-described method of using the corresponding module's code via reflection, while avoiding the module code being consistently compiled and packaged into the final application in some scenarios, leaves useless reflection code in the production environment. This not only impacts runtime performance but can also cause various problems (such as crashes and stuttering) due to the useless code. Furthermore, reflection has limitations; some programming languages ​​do not support reflection or have very weak reflection capabilities, making it impossible to use existing technologies. Additionally, if the scenario of using the target module in a project is complex and requires a large amount of reflection code, developers often avoid using existing technologies for project maintenance and instead rely on the target module in all environments for code compilation. In this case, the target module will always be compiled and packaged into the final application. In summary, the main drawbacks of building application installation packages based on reflection technology are as follows: (1) Code residue: Reflection code is always compiled and packaged into the final application. It is not executed only at runtime. The module code and dependencies still exist in the product environment, and the decoupling is not thorough.

[0051] (2) Performance loss: Reflection calls have additional performance overhead, and the class loading and instantiation process will prolong the application startup time.

[0052] (3) Crash risk: If the exception is not caught by reflection call, the application may crash due to problems such as class not being found or method not existing.

[0053] (3) Potential privacy compliance risks: The limitations of reflection mean that all environments must rely on the target module to compile the code, which means that the target module code is always compiled and packaged into the final application. This means that the product environment comes with unnecessary modules, which poses a privacy compliance risk.

[0054] (4) Increased package size: Reflection code is always compiled and packaged into the final application, which will increase the package size. At the same time, the limitations of reflection cause the target module code to always be compiled and packaged into the final application. The module code and dependencies always occupy the installation package space and cannot be removed in the production environment, resulting in redundant package size.

[0055] To overcome the shortcomings of existing technologies, this embodiment provides a residue-free decoupled module integration scheme based on dual-control collaboration. Through a dual collaborative mechanism of pre-compilation dependency control and bytecode instrumentation control, it achieves on-demand module integration in multiple environments and a completely residue-free final product. This embodiment directly excludes unnecessary modules from the compilation path during the pre-compilation stage, cutting off dependencies and code residues at the source. This ensures that the final application in the product environment is completely free of any module code dependencies and reflection code residues, thoroughly avoiding privacy and compliance risks. This embodiment achieves strong binding collaboration between compilation dependency control and bytecode instrumentation control, ensuring complete decoupling between modules and the main project, reducing maintenance and iteration costs. This embodiment eliminates redundant code and dependencies, significantly improving application performance, reducing installation package size, and enhancing application stability and user experience.

[0056] This solution consists of four phases, which are executed sequentially and work in concert: In the pre-compilation dependency control phase, the system determines whether a module needs to be integrated based on the environment information, adds the modules that need to be integrated to the compilation path, and excludes the modules that do not need to be integrated from the compilation path; In the compilation phase, intermediate code without unintegrated modules is generated based on the trimmed compilation path; In the instrumentation execution control phase, the system works in conjunction with dependency control, and instrumentation is performed only when a module is integrated; In the packaging phase, the system outputs the final application package with no code, dependencies, or instrumentation residues of any modules that do not need to be integrated (i.e., the second type of functional modules).

[0057] The above process achieves the first layer of control (i.e., dependency path control) in the pre-compilation dependency control stage. This stage can determine whether a module needs to be integrated based on the environment. If a module needs to be integrated, it is added to the compilation path; otherwise, it is completely excluded.

[0058] The above process implements a second layer of control during the compilation phase (i.e., instrumentation execution control). This phase only performs instrumentation on modules already included in the compilation path; instrumentation is completely disabled for modules not integrated, and no code injection occurs. The compilation phase is strongly bound to pre-compiled dependency control.

[0059] During the pre-compilation dependency control phase, unnecessary modules are removed from the source of the compilation chain, cutting off all possibilities of dependencies and code remnants. The specific implementation steps are as follows: Step A1: Environment Information Reading. When the build script starts, it reads the environment parameters passed in by the build tool to determine the current build environment type.

[0060] Step A2: Module Integration Determination. Based on the preset environment-module mapping rules, determine which modules need to be integrated and which need to be removed.

[0061] Step A3: Compilation path trimming.

[0062] Specifically, for modules that need to be integrated, the dependencies are declared in the build configuration and added to the compilation dependency chain; for modules that do not need to be integrated, the dependency declarations of the module are removed directly in the build script through conditional judgment, completely excluding them from the compilation path so that they do not participate in the subsequent compilation and linking process.

[0063] Step A4: Dependency Tree Verification. This step traverses the generated dependency tree to ensure that no direct or indirect dependencies of the removed modules have been introduced, thus eliminating dependency remnants at the source.

[0064] During the compilation phase, clean intermediate code files containing no irrelevant modules can be generated. The specific implementation steps are as follows: Step B1: Based on the compilation path trimmed during the pre-compilation stage, call the compiler (such as javac, kotlinc, tsc) to compile the modules included in the compilation chain.

[0065] Step B2: During the compilation process, only the source code and resource files related to the integrated modules are processed, and any files of the removed modules are completely ignored.

[0066] Step B3: Output bytecode (.class) or intermediate code (.js / .wasm) files that do not contain the code of the removed modules, ensuring that the intermediate artifacts have no redundant code or dependencies. The ".class", ".js", and ".wasm" files mentioned above are executable file formats.

[0067] The instrumentation execution control phase is strongly bound to the pre-compiled dependency control to avoid instrumentation code residue. The specific implementation steps are as follows: Step C1: Read instrumentation rules. Read the instrumentation control rules that are consistent with the environment-module mapping rules and establish the correspondence between "whether the module is integrated and whether instrumentation is performed".

[0068] Step C2: Instrumentation Task Triggering: If the target module is included in the compilation path (requires an integration environment), a bytecode manipulation framework (such as ASM, AspectJ, etc.) is started to execute the instrumentation logic related to that module (such as data entry, log injection, etc.); if the target module is excluded from the compilation path (no integration environment required), all instrumentation tasks related to that module are directly disabled, and no bytecode injection operations are executed. ASM is a bytecode manipulation framework, and AspectJ is an aspect-oriented framework.

[0069] Step C3: Instrumentation result verification: Scan the processed intermediate code to confirm that instrumentation code of modules not integrated has not been injected, thus eliminating instrumentation residue.

[0070] During the packaging stage, a final application installation package with no residue can be output. The specific steps are as follows: Step D1: Package the intermediate code and resource files after compilation and instrumentation (e.g., Android APK, Web dist). Android APK is the installation package for the native mobile application, and Web dist is the installation package for the front-end application.

[0071] Step D2: During the packaging process, only the code and resources of the integrated modules are included, and all files of the excluded modules are completely excluded.

[0072] Step D3: Final Product Verification: Through static scanning tools, it is verified that the code, dependencies, and instrumentation code of the removed modules do not appear in the final installation package, achieving complete absence of residues.

[0073] The residual-free decoupling module integration method based on dual-control collaboration provided in this application includes the following steps: Step E1: Read the build environment parameters.

[0074] Step E2: Pre-compilation dependency control.

[0075] In this step, it can be determined whether the target module needs to be integrated in the current environment; if so, the module is added to the compilation dependency chain and the dependency is declared; if not, the module is excluded from the compilation path and the dependency declaration is removed.

[0076] Step E3: After the compilation path is trimmed, clean intermediate code is generated based on the trimmed compilation path.

[0077] Step E4: Pile driving execution control.

[0078] In this step, we can first determine whether the target module is included in the compilation path; if so, we will perform module-related instrumentation operations (such as instrumentation and log injection); if not, we will disable module-related instrumentation tasks and not inject any code.

[0079] Step E5: After instrumentation is completed, package the application to generate the final application and verify that there is no module code, dependency or instrumentation residue.

[0080] This embodiment removes unnecessary modules throughout the entire process from pre-compilation to packaging, resulting in a final product free of any code, dependencies, instrumentation, or reflection residue, completely avoiding privacy compliance risks and crashes. The strong binding of pre-compilation dependency control and bytecode instrumentation control in this embodiment achieves complete decoupling between modules and the main project, facilitating iteration and maintenance across multiple environments. This embodiment eliminates redundant code and dependencies, significantly improving application runtime efficiency while drastically reducing the installation package size, achieving performance and package size optimization. The absence of useless code execution avoids stuttering and crashes caused by reflection and redundant logic, improving stability. This solution addresses the issues of code residue, high coupling, and significant compliance and performance risks during module integration in software projects. Through the dual collaboration of pre-compilation dependency control and bytecode instrumentation control, it achieves on-demand module integration, resulting in a deeply decoupled product with no remaining code.

[0081] Please see Figure 3 , Figure 3 The flowchart illustrates a residue-free decoupled module integration method based on dual-control collaboration provided in this application embodiment. After the process begins, build environment parameters are read. In the pre-compilation dependency control phase, it is determined whether the target module needs to be integrated in the current environment. If so, the module is added to the compilation dependency chain, and its dependency is declared; otherwise, the module is excluded from the compilation path, and its dependency declaration is removed. After the compilation path is trimmed, clean intermediate code is generated based on the trimmed compilation path. In the instrumentation execution control phase, it is determined whether the target module is included in the compilation path. If so, module-related instrumentation operations (such as instrumentation points and log injection) are executed; otherwise, module-related instrumentation tasks are disabled, and no code is injected. After instrumentation is completed, the final application is packaged and verified to have no module code, dependencies, or instrumentation residue. The entire process is then complete. In the above process, the pre-compilation dependency control phase and the instrumentation execution control phase involve dual-control collaborative linkage.

[0082] The following will use an Android project as an example to explain the technical solution of the present invention in detail (the dev, test, and pre environments depend on self-developed module 1 and third-party module 2, while the product environment does not depend on self-developed module 1 and third-party module 2).

[0083] The pre-compilation stage is explained below: If it is a production environment (product), then in the Gradle script, exclude the logging module from the compilation path using if(env=='product'){excludemodule:'Module1';exclude module:'ThirdLib2'}, or directly modify the Gradle file through a pre-compilation script (such as a Python script) to remove the dependencies of Module1 and ThirdLib2 from the file.

[0084] Gradle is a project build tool. The line `if(env=='product'){exclude module:'Module1';exclude module:'ThirdLib2'}` is a Gradle scripting language code that means: if the environment variable `env` has the value 'product', then exclude (do not import) the module dependencies named 'Module1' and 'ThirdLib2'. 'Module1' and 'ThirdLib2' are both module names. Python, on the other hand, is an interpreted scripting language.

[0085] For other environments, the dependencies `implementation project(':Module1');implementation project(':ThirdLib2')` are declared and included in the compilation chain. `implementation project(':Module1')` indicates that the dependency path includes the `Module1` module, and `implementation project(':ThirdLib2')` indicates that the dependency path includes the `ThirdLib2` module.

[0086] The compilation phase is explained as follows: If it is a production environment, only the core business modules are compiled, generating class files that do not contain Module1 and ThirdLib2; class files represent bytecode files generated after the source code is compiled.

[0087] In other environments, the core business module, Module1, and ThirdLib2 modules are compiled.

[0088] The following is an explanation of the stake driving stage: If it is a production environment (product), the instrumentation task will determine if the target module has not been integrated, or if the current environment is a product, and the instrumentation task of the related code of Module1 and ThirdLib2 modules will be skipped directly.

[0089] In other environments, instrumentation operations are performed on the relevant code of Module1 and ThirdLib2 modules.

[0090] The packaging stage is explained as follows: The application installation package (APK) generated in the production environment does not contain the Module1 and ThirdLib2 modules, and there are no residual code related to the target modules. Application installation packages (APKs) generated in other environments contain complete Module1 and ThirdLib2 modules and instrumentation code.

[0091] The differences in runtime of the application installation package APK are as follows: Production environment: No runtime logic involving any Module1 and ThirdLib2 module related code; Other environments: Normal operation of Module1 and ThirdLib2 module related code and logic.

[0092] This embodiment also provides a decoupling module integration device based on dual-control coordination, including: The environment awareness module is used to read the current build environment information and determine module integration requirements; Dependency trimming modules are used to exclude unnecessary modules from the compilation path during the pre-compilation stage; The compiler execution module is used to generate clean intermediate code based on the trimmed compilation path; The instrumentation control module is used to work in conjunction with dependency control to perform instrumentation operations under conditions. The packaging output module is used to generate the final application package without any module residue.

[0093] The modules communicate and control each other through build scripts or plugin interfaces, jointly completing a dual-control collaborative module integration process. After inputting the build environment parameters, the environment awareness module can read the environment configuration information to determine whether a module needs to be integrated. The dependency trimming module performs the following first layer of control: controlling the compilation path during the pre-compilation stage; if integration is required, it adds the module to the compilation dependency chain; if integration is not required, it completely excludes the module from the compilation path. The compilation execution module compiles based on the trimmed compilation path and source code, generating intermediate code free of irrelevant modules and module-related code. The instrumentation control module performs the following second layer of control: working in conjunction with the dependency trimming module, it executes code instrumentation if a module needs integration, and disables all instrumentation if the module does not need integration. The packaging output module can package the clean intermediate code to generate a final application package without any remnants.

[0094] Taking the example of functional modules Module1 and Module2, and resource files ThirdLib1 and ThirdLib2, the application compilation and build process is explained in detail: In development, testing, or pre-production environments, dependencies are analyzed during the pre-compilation phase, and necessary modules (Module1 and Module2) are added to the compilation path. During the code compilation phase, tools are used to compile the relevant code to obtain class bytecode files. Based on the bytecode files, the required module code is instrumented into the class bytecode. A packaging tool is used to package the class bytecode files into dex (an executable bytecode file format) bytecode files, and the command-line tool apkbuilder is used to generate the application installation package (APK). The application installation package can include the app (application), Module1, Module2, ThirdLib1, ThirdLib2, and the instrumentation code. The runtime module loading process is as follows: after the application starts running, the instrumentation code is called, the target module is loaded, and the business logic code is executed. Code instrumentation refers to injecting a piece of executable code into the final generated application during the compilation phase.

[0095] In the production environment, dependencies are analyzed during the pre-compilation phase, and the necessary module Module2 is added to the compilation path. During the code compilation phase, tools are used to compile the relevant code to obtain class bytecode files. Based on the bytecode files, the code of the dependent modules is instrumented into the class bytecode. A packaging tool is used to package the class bytecode files into dex bytecode files, and the command-line tool apkbuilder is used to generate the application installation package (APK). The application installation package can include app, Module2, and ThirdLib1. The runtime module loading process is as follows: after the application starts running, the business logic code is executed.

[0096] This embodiment excludes unnecessary modules from the compilation path at the source of the compilation chain. Unlike the dynamic loading and runtime control of existing technologies, it eliminates code residue at the root and achieves dependency exclusion in the pre-compilation stage. The instrumentation logic in this embodiment is strongly bound to dependency control, and instrumentation is only performed when a module is integrated, avoiding instrumentation code residue and achieving collaborative control of both dependency and instrumentation. The final product of this embodiment contains no code, dependencies, or instrumentations of unnecessary modules, achieving true and complete decoupling and possessing a completely residue-free characteristic.

[0097] This embodiment can also replace code instrumentation at the bytecode stage with direct modification of source code files at the pre-compilation stage, achieving the same effect as the original solution of dual-control collaboration and no-residual-module integration.

[0098] During the pre-compilation phase, source code modifications can be made (replacing the original bytecode instrumentation). During pre-compilation, conditional modifications to the source code files are executed synchronously with dependency pruning logic: If the target module needs integration: retain the target module's related source code and code using the target module (such as event tracking and logging statements); if the target module does not need integration: by running the pre-compilation script, all code related to that module, dependency import statements, etc., are directly deleted / commented out from the source code files, ensuring that module-related code is completely removed before compilation.

[0099] After inputting the environment parameters, the environment awareness module can read the environment configuration information to determine whether a module needs to be integrated. The dependency trimming module performs the following first layer of control: controlling the compilation path during the pre-compilation stage; adding modules to the dependency chain if integration is required; and completely excluding modules from the compilation path if integration is not needed. The source code modification module performs the following second layer of control: deleting unnecessary code during the pre-compilation stage; retaining relevant code for integrated modules and deleting relevant code for non-integrated modules. The compilation execution module compiles based on the trimmed compilation path and source code, generating intermediate code free of irrelevant modules and module-related code. The packaging output module packages the clean intermediate code, generating a final application package without any remnants.

[0100] The coordination between dependency control and source code modification is explained as follows: The module integration determination result output by the environment-aware module is simultaneously passed to both the dependency trimming module and the source code modification module. The dependency trimming module excludes unnecessary modules from the compilation path; the source code modification module synchronously deletes all code related to the module from the source code. Their collaboration ensures that the module code is completely removed at both the source code level and the compilation path level, leaving no residue in the final output.

[0101] The compilation phase is based directly on the modified clean source code, without the need for additional bytecode instrumentation; the packaging phase outputs the final application package, ensuring that there is no code, dependencies, instrumentation or reflection residue of any unintegrated modules.

[0102] The above process achieves on-demand module integration through dual control collaboration of pre-compiled dependency control and pre-compiled source code modification. This embodiment completely removes unnecessary module code at the source code level, ensuring that the final application package has no code, dependencies, or reflection residues. This embodiment solves the problems of code residues, compliance risks, and performance loss in the prior art.

[0103] This application provides an application installation package building system, which may include: An environment perception module is used to determine the current environment and determine module requirement information based on the current environment; wherein, the module requirement information is information describing whether the functional module needs to be integrated into the application installation package; the functional modules include a first type of functional modules and a second type of functional modules, the first type of functional modules being functional modules that need to be integrated into the application installation package, and the second type of functional modules being functional modules that do not need to be integrated into the application installation package; A dual-cooperative control module is used to execute the first and second control operations to obtain intermediate code files; The packaging output module packages the intermediate code files and corresponding resource files to obtain the application installation package; The first control operation includes: adding dependency declarations of the first type of functional modules to the configuration information according to the module requirement information, and removing dependency declarations of the second type of functional modules from the configuration information; generating a compilation path according to the configuration information, and performing a compilation operation according to the compilation path to obtain the intermediate code file; The second control operation is either a source code modification operation or an instrumentation control operation. The source code modification operation includes: before performing the compilation operation according to the compilation path, removing content related to the second type of functional module from the source code based on the module requirement information; The instrumentation control operation includes: determining an instrumentation strategy based on the module requirement information, and performing instrumentation operations on the intermediate code file according to the instrumentation strategy before packaging the intermediate code file and the corresponding resource file; the instrumentation strategy includes: allowing the code corresponding to the first type of functional module to participate in the instrumentation operation, and prohibiting the code corresponding to the second type of functional module from participating in the instrumentation operation.

[0104] This embodiment determines module requirement information based on the current environment, thereby identifying a first type of functional modules that need to be integrated into the application installation package and a second type of functional modules that do not need to be integrated into the application installation package. Based on the module requirement information, this embodiment can execute a first control operation and a second control operation to obtain intermediate code files without irrelevant functional modules, and then perform a packaging operation to obtain the application installation package. Specifically, by executing the first control operation, dependency declarations of the first type of functional modules can be added to the configuration information according to the module requirement information, and dependency declarations of the second type of functional modules can be removed from the configuration information; this embodiment performs a compilation operation according to the compilation path corresponding to the configuration information to obtain intermediate code files without irrelevant functional modules. The second control operation includes source code modification operation or instrumentation strategy modification operation; by executing the source code modification operation, content related to the second type of functional modules in the source code can be removed during the pre-compilation stage; by executing the instrumentation strategy modification operation, the code participating in instrumentation is controlled so that the code corresponding to the second type of functional modules participates in the instrumentation operation. The above scheme can eliminate functional modules that do not need to be integrated into the application installation package during the process of building the application installation package, so that this embodiment can build the application installation package without the presence of useless code residues.

[0105] Furthermore, it also includes: An operation selection module is used to set the source code modification operation or the instrumentation control operation as the second control operation according to the environment configuration before executing the second control operation.

[0106] Furthermore, if the second control operation is the source code modification operation, the process of the packaging output module packaging the intermediate code file and the corresponding resource file includes: packaging the intermediate code file and the corresponding resource file obtained from the compilation operation; If the second control operation is the instrumentation control operation, the process of the packaging output module packaging the intermediate code file and the corresponding resource file includes: packaging the intermediate code file and the corresponding resource file after the instrumentation operation.

[0107] Furthermore, the process by which the dual collaborative control module removes content related to the second type of functional module from the source code based on the module requirement information includes: removing code and dependency import statements related to the second type of functional module from the source code file based on the module requirement information.

[0108] Furthermore, the process of the dual collaborative control module performing compilation operations according to the compilation path includes: generating a corresponding dependency tree based on the configuration information; determining whether the second type of functional module is directly or indirectly introduced by traversing the dependency tree; if not, performing compilation operations according to the compilation path.

[0109] Furthermore, it also includes: The verification module is used to determine, after obtaining the application installation package, whether the code, dependencies, and instrumentation code of the second type of functional module do not appear in the application installation package using a static scanning tool; if so, the application installation package is determined to have passed the verification; if not, the application installation package is determined to have failed the verification, and a corresponding verification analysis report is output.

[0110] Furthermore, the process by which the environment awareness module determines the current environment includes: reading the current environment using a script; wherein the current environment includes, but is not limited to: development environment, testing environment, pre-production environment, or production environment.

[0111] Since the embodiments of the system part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the system part, and they will not be repeated here.

[0112] This application also provides a storage medium on which a computer program is stored, which, when executed, can perform the steps provided in the above embodiments. The storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0113] This application also provides an electronic device that may include a memory and a processor. The memory stores a computer program, and when the processor calls the computer program in the memory, it can implement the steps provided in the above embodiments. Of course, the electronic device may also include various network interfaces, power supplies, and other components.

[0114] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

[0115] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A method for constructing an application installation package, characterized in that, include: The current environment is determined, and module requirement information is determined based on the current environment. The module requirement information describes whether a functional module needs to be integrated into the application installation package. The functional modules include a first type of functional module and a second type of functional module. The first type of functional module is the functional module that needs to be integrated into the application installation package, and the second type of functional module is the functional module that does not need to be integrated into the application installation package. The current environment is the build environment configuration of the application package, and the current environment includes: a development environment, a testing environment, a pre-production environment, or a production environment. Execute the first and second control operations to obtain the intermediate code file; The intermediate code files and corresponding resource files are packaged to obtain the application installation package; The first control operation is used to dynamically maintain dependency declarations in the configuration information based on module requirement information. The first control operation includes: adding dependency declarations of the first type of functional modules in the configuration information according to the module requirement information, and removing dependency declarations of the second type of functional modules from the configuration information; generating a compilation path according to the configuration information, and performing a compilation operation according to the compilation path to obtain the intermediate code file. The second control operation is either a source code modification operation or an instrumentation control operation. The source code modification operation includes: before performing the compilation operation according to the compilation path, removing code and dependency import statements related to the second type of functional module from the source code file according to the module requirement information; The instrumentation control operation includes: determining an instrumentation strategy based on the module requirement information, and performing instrumentation operations on the intermediate code file according to the instrumentation strategy before packaging the intermediate code file and the corresponding resource file; the instrumentation strategy includes: allowing the code corresponding to the first type of functional module to participate in the instrumentation operation, and prohibiting the code corresponding to the second type of functional module from participating in the instrumentation operation.

2. The method for constructing an application installation package according to claim 1, characterized in that, Before performing the second control operation, the following is also included: The source code modification operation or the instrumentation control operation is set as the second control operation according to the environment configuration.

3. The method for constructing an application installation package according to claim 2, characterized in that, If the second control operation is the source code modification operation, then the intermediate code file and the corresponding resource file are packaged, including: Package the intermediate code files and corresponding resource files obtained from the compilation operation; If the second control operation is the instrumentation control operation, then the intermediate code file and the corresponding resource file are packaged, including: Package the instrumented intermediate code files and corresponding resource files.

4. The method for constructing an application installation package according to claim 1, characterized in that, Perform compilation operations according to the specified compilation path, including: Generate the corresponding dependency tree based on the configuration information; By traversing the dependency tree, it can be determined whether the second type of functional module is directly or indirectly introduced. If not, then perform the compilation operation according to the specified compilation path.

5. The method for constructing an application installation package according to claim 1, characterized in that, After obtaining the application installation package, it also includes: Use static scanning tools to determine whether the code, dependencies, and instrumentation code of the second type of functional module do not appear in the application installation package; If so, the application installation package is deemed to have passed verification; If not, the application installation package is determined to have failed verification, and a corresponding verification analysis report is output.

6. The method for constructing an application installation package according to claim 1, characterized in that, Determine the current environment, including: Use a script to read the current environment.

7. A system for building application installation packages, characterized in that, include: An environment awareness module is used to determine the current environment and, based on the current environment, determine module requirement information. The module requirement information describes whether a functional module needs to be integrated into the application installation package. The functional modules include a first type of functional module and a second type of functional module. The first type of functional module is one that needs to be integrated into the application installation package, and the second type of functional module is one that does not need to be integrated into the application installation package. The current environment is the application package's build environment configuration, which includes: a development environment, a testing environment, a pre-production environment, or a production environment. A dual-cooperative control module is used to execute the first and second control operations to obtain intermediate code files; The packaging output module packages the intermediate code files and corresponding resource files to obtain the application installation package; The first control operation is used to dynamically maintain dependency declarations in the configuration information based on module requirement information. The first control operation includes: adding dependency declarations of the first type of functional modules in the configuration information according to the module requirement information, and removing dependency declarations of the second type of functional modules from the configuration information; generating a compilation path according to the configuration information, and performing a compilation operation according to the compilation path to obtain the intermediate code file. The second control operation is either a source code modification operation or an instrumentation control operation. The source code modification operation includes: before performing the compilation operation according to the compilation path, removing code and dependency import statements related to the second type of functional module from the source code file according to the module requirement information; The instrumentation control operation includes: determining an instrumentation strategy based on the module requirement information, and performing instrumentation operations on the intermediate code file according to the instrumentation strategy before packaging the intermediate code file and the corresponding resource file; the instrumentation strategy includes: allowing the code corresponding to the first type of functional module to participate in the instrumentation operation, and prohibiting the code corresponding to the second type of functional module from participating in the instrumentation operation.

8. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program, and the processor, when calling the computer program in the memory, implements the steps of the method for constructing an application installation package as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium stores computer-executable instructions, which, when loaded and executed by a processor, implement the steps of the application installation package construction method as described in any one of claims 1 to 6.

Images