Gradle-based compiling method and device, equipment, medium and program

Abstract

The embodiment of the invention provides a Gradle-based compiling method and device, equipment, a medium and a program, and the method comprises the steps: detecting a module of a project to obtain compiling reference information of a first source code module without source code change in the project, and the compiling reference information comprises an identifier without source code change and information of a binary file; obtaining a dependency relationship tree of each module of the project, and determining a target module which has no source code change and has a dependency type of source code dependency in the dependency relationship tree of each module according to the compiling reference information of the first source code module, according to the binary file of the target module, modifying the source code dependency of the target module in the dependency relationship tree of each module into binary dependency; and compiling each module according to the modified dependency relationship tree of each module. The dependency type of the module is changed from source code dependency to binary dependency, and source code compiling does not need to be performed on the modified module, so that the time required for source code compiling is saved, and the engineering compiling efficiency is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a Gradle-based compilation method, apparatus, device, medium, and program. Background Art

[0002] Software construction generally includes development, compilation, testing, and packaging. In order to improve the efficiency of software construction, you can use construction tools to build. Gradle is an open source automated construction tool that is widely used in the development of Android applications. Gradle supports multiple third-party repositories such as Maven and JCenter, and supports transitive dependency management.

[0003] At present, many projects adopt component-based development methods. A project includes multiple modules. The modules are decoupled from each other, but there may be dependencies between the modules. In the project construction process of the project, if a module depends on the code of other modules (generally depends on other modules); due to the limitations of the default Gradle construction process itself, if the dependency of the module on which the current module depends is source code dependency, it is necessary to first compile the source code of the module on which the current module depends. After all the modules on which the current module depends are compiled and built, the compilation and construction process of the current module is executed. The source code compilation process of the modules on which the current module depends is time-consuming, resulting in low project construction efficiency. Summary of the invention

[0004] The embodiments of the present application provide a compilation method, apparatus, device, medium and program based on Gradle. The method changes the dependency type of the target module in the module's dependency tree from source code dependency to binary dependency, and does not require source code compilation of the target module, thereby saving the time required for source code compilation, shortening the compilation time of the module, and improving the overall construction efficiency of the project.

[0005] In a first aspect, an embodiment of the present application provides a compilation method based on Gradle, the method comprising: detecting modules of a project to obtain compilation reference information of a first source code module in the project in which no source code changes have occurred, the compilation reference information comprising an identifier of the first source code module, an identifier of no source code changes, and information of a binary file, the project comprising multiple modules, and the binary file being a file obtained by compiling the source code of the first source code module; obtaining a dependency tree of each module of the project; determining, based on the compilation reference information of the first source code module, a target module in the dependency tree of each module in which no source code changes have occurred and whose dependency type is a source code dependency; modifying the source code dependency of the target module in the dependency tree of each module to a binary dependency based on the binary file of the target module in the dependency tree of each module; and compiling each module according to the modified dependency tree of each module.

[0006] In the second aspect, an embodiment of the present application provides a compilation device based on Gradle, the device comprising: a source code change detection module, used to detect modules of a project, and obtain compilation reference information of a first source code module in the project in which no source code change has occurred, the compilation reference information comprising an identifier of the first source code module, an identifier of no source code change, and information of a binary file, the project comprising multiple modules, and the binary file is a file obtained by compiling the source code of the first source code module; a dependency acquisition module, used to obtain a dependency tree of each module of the project; a dependency modification module, used to determine, according to the compilation reference information of the first source code module, a target module in the dependency tree of each module in which no source code change has occurred and whose dependency type is a source code dependency; the dependency modification module, further used to modify the source code dependency of the target module in the dependency tree of each module to a binary dependency according to the binary file of the target module in the dependency tree of each module; a compilation module, used to compile each module according to the modified dependency tree of each module.

[0007] In a third aspect, an embodiment of the present application provides a compilation device, comprising: a processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory to execute the method described in the first aspect or each implementation method above.

[0008] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium is used to store a computer program, and the computer program enables a computer to execute the method described in the first aspect or each implementation method above.

[0009] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the method of the first aspect or each implementation method described above.

[0010] The technical solution provided by the embodiment of the present application detects the modules of the project, obtains the compilation reference information of the first source code module in the project where no source code changes have occurred, and the compilation reference information includes the identification of no source code changes and the information of the binary file, the project includes multiple modules, and the binary file is the file obtained by compiling the source code of the first source code module; and obtains the dependency tree of each module of the project, and determines the target module in the dependency tree of each module where no source code changes have occurred and the dependency type is source code dependency according to the compilation reference information of the first source code module, and modifies the source code dependency of the target module in the dependency tree of each module to binary dependency according to the binary file of the target module; and compiles each module according to the modified dependency tree of each module. This method modifies the dependency type of the target module in the dependency tree of the module from source code dependency to binary dependency, and does not need to compile the source code of the target module, thereby saving the time required for source code compilation, shortening the compilation time of the module, and improving the compilation efficiency of the project as a whole. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0012] Figure 1 A schematic diagram of a functional module of the Gradle plug-in provided for this application;

[0013] Figure 2 A flowchart of a Gradle-based compilation method provided in Example 1 of the present application;

[0014] Figure 3 A schematic diagram of the dependency tree of module A;

[0015] Figure 4 Modified dependency tree for module A;

[0016] Figure 5 A flowchart of the Gradle-based compilation method provided in Example 2 of the present application;

[0017] Figure 6 This is a schematic diagram of the folder directory of each module under the root directory of the project;

[0018] Figure 7 A flowchart of the Gradle-based compilation method provided in Example 3 of the present application;

[0019] Figure 8 A flowchart of a Gradle-based compilation method provided in Example 4 of the present application;

[0020] Fig. 9 A schematic diagram of the structure of a Gradle-based compilation device provided in Example 5 of the present application;

[0021] Fig.10 A structural diagram of the compilation device provided in Example 6 of the present application. DETAILED DESCRIPTION

[0022] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0023] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products, or devices.

[0024] In order to facilitate the understanding of the embodiments of the present application, before describing the various embodiments of the present application, some concepts involved in all the embodiments of the present application are first appropriately explained.

[0025] There are two important concepts in Gradle: project and task.

[0026] A Gradle project includes multiple modules, and the project has multiple projects, including a root project and multiple sub-projects. Each module of the project has a project, and the project of the module is called a sub-project.

[0027] Each project (including the root project and sub-projects) contains a build.gradle file. Therefore, it can be understood that each build.gradle file represents a project.

[0028] The build.gradle file is also called the build.gradle script file, which can be a script file based on the Groovy language. The build.gradle file of each module includes the module's dependencies, tasks, and resource information.

[0029] Tasks are defined in the build.gradle file. Each build.gradle file contains one or more tasks. Each task has its own name and unique path. The path is unique among all projects and tasks in the project. Multiple tasks in the build.gradle file are executed in the order or dependency relationship of the configuration.

[0030] After each build.gradle script file is loaded and parsed by the Gradle tool, a corresponding project object will be generated. The project object is an object in memory. The loading and parsing process of the build.gradle script file can also be described as the configuration process of the build.gradle script file. This configuration process is an existing technology and will not be repeated here.

[0031] In the process of building a software engineering project, it is inevitable to publish the files that the module depends on, and the files that the module depends on will be published in a repository. The files that the module depends on include but are not limited to java packages, Android Archive (AAR) packages, and the files that the module depends on may include the source code files of the module, the binary files of the module, etc.

[0032] The warehouse of the Gradle tool can include the following types of warehouses: local warehouse, central warehouse and private warehouse. The central warehouse is usually a remote warehouse. The local warehouse is located on the compilation device or development device and is used to store dependency files downloaded from the central warehouse or remote warehouse. The central warehouse is used to store dependency files of some open source libraries, such as the Maven central warehouse. A private warehouse can be a warehouse customized by an organization or an individual, and a private warehouse can be a remote warehouse.

[0033] The build.gradle file of each module includes the module dependencies. A module can depend on one or more modules, and the modules that the module depends on may depend on other modules. For example, module A depends on module B, and module B depends on module C. Then module A also depends on module C. Then module B is the direct dependency of module A, and module C is a transitive dependency of module A. Through this dependency method, starting from one module, multiple layers of dependencies can be formed, and these dependencies form a dependency link or dependency tree.

[0034] The module dependency types can be divided into the following dependency types according to the type of dependent data: source code dependency and binary dependency.

[0035] Source code dependency is to directly introduce the source code of other modules into the current module, while binary dependency is to introduce the compiled binary files of other modules into the current module. Source code dependency is convenient for debugging and modification, but it will increase the size of the project. Binary dependency is convenient for management and updating, but the source code cannot be modified directly.

[0036] In the existing project compilation process, if a module depends on the code of other modules (generally depends on the code of other modules); due to the limitations of the default Gradle compilation process itself, if the dependency type of the module on which the current module depends is source code dependency, it is necessary to first compile the source code of the module on which the current module depends, and after all the modules on which the current module depends are compiled, the compilation process of the current module is executed. Since the source code compilation process of the module on which the current module depends requires converting the source code file into a binary file, it takes a long time to convert from the source code file to the binary file, which results in a long compilation process of the project and low project compilation efficiency.

[0037] In order to solve the problems of the prior art, an embodiment of the present application provides a compilation method based on Gradle, which can dynamically build the dependencies of the modules included in the project, modify the dependency type of the module from source code dependency to binary dependency, and the modified binary dependency does not need to be compiled, thereby shortening the time consumed in project compilation.

[0038] The method provided in the embodiment of the present application may exist in the form of a Gradle plugin. Figure 1 A schematic diagram of a functional module of the Gradle plug-in provided for this application, such as Figure 1 As shown, the Gradle plug-in includes a plug-in configuration management module, a source code change detection module, a dependency acquisition module, a dependency modification module, a build scheduling module and a binary file management module.

[0039] The plug-in configuration management module is responsible for the configuration and management of plug-in runtime parameters. The main configuration parameters include plug-in enable switch strategy and binary file cache strategy. Among them, the plug-in enable switch strategy is used to control whether the plug-in is started, or to control the plug-in to start when the preset conditions are met. The binary file cache strategy is used to configure the size, address, and replacement strategy of the cached binary file.

[0040] The source code change detection module can exist in the form of a build task. When the compilation is triggered, the task corresponding to the source code change detection module is executed first. It is used to detect source code changes of modules included in the project and record the source code change results.

[0041] The dependency acquisition module can exist in the form of a build task, which is used to find the dependency tree (also called dependency tree) of each module according to the configuration information of each module, and detect whether the source code dependency modules in the dependency tree of each module need to be modified into binary dependency modules according to the source code change results recorded by the source code change detection module, and generate modification information of the dependency tree of each module. The modification information is used to record which modules need to be modified into binary dependency modules.

[0042] The dependency modification module is used to modify the dependency tree of each module determined by the dependency acquisition module, and to modify the source code dependency in the dependency tree into a binary dependency by operating the dependency tree of each module, thereby realizing automatic update of the dependency type or dependency relationship of the module.

[0043] Optionally, the dependency acquisition module and the dependency modification module may also be combined into one functional module: a dependency reconstruction module, which has the functions of both the dependency acquisition module and the dependency modification module.

[0044] The build scheduling module is used to determine and schedule the execution order of the build tasks of the modules included in the project.

[0045] The binary file management module is used to cache and manage the binary files generated in the compilation process according to the binary file cache strategy configured by the plug-in configuration management module, for example, cache binary files, manage the identifiers and addresses of cached binary files, and replace or eliminate cached binary files. For example, at time T1, module A is compiled once to obtain the first binary file of module A, and at time T2, module B is compiled again to obtain the second binary file of module B. Then, at time T2, the first binary file and the second binary file of module A can be cached at the same time, or the second binary file can be used to replace the first binary file.

[0046] The method provided in the embodiment of the present application can be applied to a terminal device for developing or compiling software engineering (hereinafter referred to as the compilation device), which can be a terminal device in various forms such as a mobile phone, a tablet computer, a desktop computer, a portable laptop computer, an intelligent voice interaction device, a smart home appliance, etc.

[0047] After introducing some concepts involved in the embodiments of the present application, the Gradle-based compilation method provided in the embodiments of the present application is specifically described below with reference to the accompanying drawings.

[0048] Figure 2 A flowchart of a Gradle-based compilation method provided in Example 1 of the present application is shown in FIG. Figure 2 As shown, the method provided in this embodiment includes the following steps:

[0049] S101. Detect modules of a project to obtain compilation reference information of a first source code module in the project whose source code has not been changed, wherein the compilation reference information includes an identifier of the first source code module, an identifier of no source code change, and information of a binary file. The project includes multiple modules.

[0050] After the compilation is triggered, this step begins. This step can be Figure 1 The source code change detection module shown is used for detection. The project includes multiple modules, and the source code change detection module detects each module in the project in turn.

[0051] Exemplarily, first check whether the module is a source code module. A source code module means that the module code is source code. A source code module has a separate Git repository information, so a source code module is also called an independent module or an independent source code module. When the module is a source code module, further check whether the module has a source code change. When the module is not a source code module, do not process the module, and continue to check whether the next module is a source code module.

[0052] A module source code change means that the module source code has changed from the last compilation to the current compilation. From the last compilation to the current compilation, the user may have modified the module source code, resulting in a change in the module source code.

[0053] When it is detected that the source code module has not undergone source code changes, it is determined that the source code module is the first source code module, and the first source code module is a source code module that has not undergone source code changes. The binary file information of the first source code module is obtained, and compilation reference information is generated for the first source code module. When it is detected that the source code module has undergone source code changes, it is determined that the module is not the first source code module, and the next module can be detected to see if it is a source code module.

[0054] The binary file is a file obtained by compiling the source code of the first source code module. Figure 1 The binary file management module shown is used to manage the binary file, which is stored locally. The information of the binary file includes the index of the binary file and the address of the binary file. The index of the binary file is used to uniquely identify a binary file, and the address of the binary file is the local storage address of the binary file. The binary file can be found according to the address of the binary file.

[0055] The compilation reference information of the first source code module includes an identifier of the first source code module, an identifier of a source code that has not been changed, and information of a binary file.

[0056] Table 1 is a schematic diagram of the compilation reference information of the source code modules in the project. Referring to Table 1, Table 1 includes three source code modules: module B, module C and module D. Table 1 records the module name, change identifier, binary file index and binary file address of each source code module, wherein the change identifier is used to identify whether the module has changed. When the value of the change identifier is N, it indicates that no source code change has occurred. When the value of the change identifier is Y, it indicates that a source code change has occurred. Table 1 includes not only the compilation reference information of the first source code module, but also the information of the source code module that has undergone source code changes. Modules B and D have not undergone source code changes, but module C has undergone source code changes. For module C that has undergone source code changes, it is not necessary to obtain the binary file information of module C.

[0057] Table 1

[0058]

[0059] It is understandable that Table 1 may also only include the compilation reference information of the first source code module, and does not include the information of the source code module that has undergone source code changes. Accordingly, when it is detected that the module is a source code module, but the module has undergone source code changes, the source code change information of the module is not recorded. After the compilation device obtains the compilation reference information of the first source code module, it stores the compilation reference information of the first source code module in the memory of the compilation device.

[0060] Before this step, the modules of the project have been loaded into the memory. Detecting the modules of the project refers to detecting the modules that have been loaded into the memory.

[0061] S102: Obtain a dependency tree of each module of the project.

[0062] The compilation device may traverse the modules of the project in a preset order to obtain the dependency tree of each module of the project, or may traverse the modules of the project in the compilation order of the modules of the project. This embodiment does not limit the traversal order of the modules.

[0063] The compilation device obtains the dependency tree of each module according to the build.gradle file of each module. Each module may directly or indirectly depend on multiple modules. According to the dependency order between modules, a dependency tree of the project can be formed. The dependency tree of the project represents the dependency relationship between the modules of the project through a tree structure. The dependency tree of the project includes the dependency tree of the module. The dependency tree of the module can be understood as a subtree of the dependency tree of the project. According to the dependency tree of the project, the dependency tree of each module of the project can be obtained.

[0064] Figure 3 A schematic diagram of the dependency tree of module A, such as Figure 3 As shown, with module A as the starting point (i.e., the root node of the dependency tree), the dependency tree includes multiple layers of dependencies, and each layer of dependencies may include multiple different types of dependencies. Exemplarily, it may include online dependencies (online), binary dependencies (binary), lib dependencies (i.e., library dependencies), etc., and lib dependencies are source code dependencies. Figure 3 In the binary module (binary) A and N, it means that the module dependency type is binary dependency, the online module (online) A and Q means that the module dependency type is online dependency, and the dependency type of the library (library) module A is source code dependency.

[0065] Exemplarily, the centralized dependency type can be determined in the following way: lib dependency is determined by referencing keywords, usually starting with lib_xxx characters, and whether the module is a source code dependency is determined based on whether the file name contains lib_xxx characters; binary dependencies are generally determined by whether the dependency path contains aar or jar keywords, and the rest are online dependencies.

[0066] The information of each node in the dependency tree includes the name of the dependent module, the dependency type, and the address of the dependent file.

[0067] Exemplarily, the dependency tree of each module of the project can be obtained in the following way: obtain the project object of the project, obtain the DependencyHandler object by calling the getDependency method provided by the project object, and obtain the dependency tree of each module of the project through the getModuleDependency method provided by the DependencyHandler object.

[0068] Can be Figure 1The dependency reconstruction module shown obtains the dependency tree of each module. The dependency reconstruction module can be used as a task of Gradle. The task corresponding to the dependency reconstruction module is added to the Gradle build task list, that is, the task corresponding to the dependency reconstruction module is used as a task to be executed by the Gradle build, thereby realizing the association of the automatic configuration process of the dependency and the Gradle build process.

[0069] Optionally, the task corresponding to the dependent reconstruction module is added to the Gradle build task list in the following way: the task corresponding to the dependent reconstruction module inherits the DefaultTask class, and the DefaultTask class inherited by the task is added to the Gradle build task list. The DefaultTask class inherited by the task can be understood as a custom DefaultTask. By calling the applyTask method of DefaultTask, the project objects of each module of the project can be obtained.

[0070] S103: According to the compilation reference information of the first source code module, determine the target module in the dependency tree of each module in which no source code change occurs and the dependency type is source code dependency.

[0071] Compare the compilation reference information of the first source code module with the dependency tree of each module. If a module on a node of the dependency tree is a source code dependency and no source code change occurs, determine that the module is a target module, and the target module belongs to the first source code module.

[0072] S104. According to the binary file of the target module in the dependency tree of each module, the source code dependency of the target module in the dependency tree of each module is modified into a binary dependency.

[0073] Step S103 determines the target module that needs to be replaced in binary in the dependency tree of each module. This step modifies the dependency of the target module and changes the dependency type of the target module from source code dependency to binary dependency.

[0074] by Figure 3 As an example, the dependency tree shown in FIG. 1 is used to determine that the dependency tree of module A includes two target modules: module B and module D. Then, the dependency types of module B and module D in the dependency tree of module A are modified to binary dependencies. Figure 4 The dependency tree shown in the reference Figure 4 , Figure 4 Modified dependency tree for module A.

[0075] It can be understood that in the embodiment of the present application, the modification of the dependency tree of each module does not modify the script file of the project, but rather modifies the dependency relationship of each module loaded into the memory of the compilation device. In other words, only the dependency relationship used in the compilation process is modified, and the modified dependency relationship is only valid during the compilation process. After the compilation process is completed, the modified dependency relationship will also become invalid.

[0076] S105. Compile each module according to the modified dependency tree of each module.

[0077] Since the dependency type of the target module in the dependency tree of each module has been changed from source code dependency to binary dependency, when compiling the module, there is no need to compile the source code of the target module. Instead, the binary file corresponding to the binary dependency of the target module is directly used, thereby saving the time required for source code compilation, shortening the compilation time of the module, and improving the overall construction efficiency of the project.

[0078] In this embodiment, the modules of the project are detected to obtain the compilation reference information of the first source code module in which no source code changes have occurred in the project, the compilation reference information includes the identification of the first source code module, the identification of no source code changes and the information of the binary file, the project includes multiple modules, and the binary file is a file obtained by compiling the source code of the first source code module; the dependency tree of each module of the project is obtained, and according to the compilation reference information of the first source code module, the target module in the dependency tree of each module in which no source code changes have occurred and the dependency type is source code dependency is determined, and according to the binary file of the target module, the source code dependency of the target module in the dependency tree of each module is modified to binary dependency; and each module is compiled according to the modified dependency tree of each module. This method saves the time required for source code compilation by modifying the dependency type of the target module in the dependency tree of the module from source code dependency to binary dependency, so that the compilation time of the module is shortened, and the compilation efficiency of the project is improved as a whole.

[0079] On the basis of the first embodiment, the second embodiment of the present application provides a compilation method based on Gradle, which is used to explain the step S101 in the first embodiment in detail. Figure 5 The flowchart of the Gradle-based compilation method provided in Example 2 of the present application is as follows: Figure 5 As shown, the method provided in this embodiment includes the following steps.

[0080] S1011. Obtain the folder path of each module of the project, and obtain the folder of each file of the project according to the folder path of each module of the project.

[0081] After the Gradle compilation is triggered, according to the build task execution order set by the build manager, the task corresponding to the source code change detection module will be started first. This task will detect whether the source code of each module in the project has changed, and record the detection results.

[0082] The project has a root folder, which includes folders for each module of the project. The folders for each module store the source code of each module. The task corresponding to the change detection module can use the File API to traverse the folder paths of each module of the project and obtain the folders of each file of the project.

[0083] S1012. Access each module of the project in the access order, execute a submit query command in the folder of the current module of the project, and obtain a return value of the submit query command.

[0084] In this embodiment, the task corresponding to the source code change detection module determines whether each module is the first source code module in turn according to a preset access order, and the current module refers to the module currently accessed by the task corresponding to the source code change detection module.

[0085] The commit query command is used to query the historical commit records of a file. Exemplarily, the commit query command is the gitlog command. When Git is used for version control, each time a commit is made to the version history library, Git will generate a new version. The git log command can be used to easily view the version history of a file.

[0086] S1013. Determine whether the current module is a source code module according to the return value of the query command submitted.

[0087] Exemplarily, if the return value of the submit query command includes commit information, the module is determined to be a source code module, and if the return value of the submit query command does not include commit information, the module is determined not to be a source code module. The commit information includes the version number of the source code of the module, the commit ID, the commit time, etc. The commit information of the module is uniformly managed by the Git version information system, and the commit ID can be a hash value of the file, a secure hash algorithm (SHA) value, and SHA has multiple different versions of algorithms, and the corresponding SHA value can be a SHA-1 value, a SHA-2 value, or a SHA-3 value.

[0088] Here, judging whether a module is a source code module can also be understood as judging whether a file path is a source code project path.

[0089] Figure 6 This is a schematic diagram of the folder directory of each module in the root directory of the project, refer to Figure 6As shown, usually, the module with the folder name (or module name) lib_xxx is a source code module and has a separate Git repository information. You can determine whether the module is a source code module by executing the 'git log' command using shell syntax in the lib_xxx folder.

[0090] Through steps S1012 and S1013, it can be determined whether a module is a source code module. If the current module is a source code module, step S1014 is executed. If the current module is not a source code module, the process returns to step S1012, that is, the query command is submitted in the folder of the next module according to the access order.

[0091] S1014. Execute a difference query command in the folder of the current module to obtain an execution result of the difference query command.

[0092] The difference query command is used to query whether the source code information of the source code module has changed from the last compilation to the current compilation. Exemplarily, the difference query command is git diff. Git diff compares the differences between two submissions (i.e., versions) by comparing the file digest values ​​between the two submissions. The file digest value can be the hash value of the file. If the file digest values ​​of the two submissions are the same, the two submissions are considered to be the same and there is no difference. If the file digest values ​​of the two submissions are different, the two submissions are considered to be different.

[0093] S1015. Determine whether source code changes occur in the current module based on the execution result of the difference query command.

[0094] Exemplarily, if the return value of the difference query command is empty, it is determined that the source code of the current module has not been changed; if the return value of the difference query command is not empty, it is determined that the source code of the current module has been changed.

[0095] If the source code of the current module has not been changed, step S1016 is executed. If the source code of the current module has been changed, the process returns to step S1012.

[0096] S1016: Determine that the current module is a first source code module, obtain information about a binary file of the first source code module, and generate compilation reference information for the first source code module.

[0097] Through steps S1014 and S1015, it is detected whether a source code module has undergone source code changes. For a first source code module that has not undergone source code changes, binary file information of the first source code module is obtained. Optionally, the binary file information includes an index of the binary file and an address of the binary file.

[0098] Exemplarily, the information of the binary file of the first source code module can be obtained in the following manner: obtain the submission information of the most recent submission from the submission information of the first source code module, the submission information of the most recent submission includes a submission ID and the address of the binary file; use the submission ID of the most recent submission as the index of the binary file of the first source code module, and use the address of the binary file of the most recent submission as the address of the binary file of the first source code module.

[0099] The submission information of the first source code module is included in the return value of the submission query command of the first source code module. The submission information of the first source code module includes multiple submission information of the source code files of the first source code module, and the submission information includes submission ID, submission time, address of binary file, etc.

[0100] Generally, multiple submission information of the first source code module are arranged in order of submission time. Usually, the first line of submission information is the most recent submission information. Therefore, the first line of submission information returned by the first source code module can be used as the most recent submission information.

[0101] Optionally, the submission information of the first source code module and the current time may be compared to obtain the most recent submission, and the binary file corresponding to the submission ID in the most recent submission information is usually the binary file generated during the last compilation.

[0102] If an independent source code module has been modified from the last compilation to the current compilation, when the module modification is submitted, at this time, the binary file managed by the binary file management module is the binary file compiled last time, and the binary file management module does not store the binary file compiled after the modified source code this time. In this case, the correct change identification result cannot be obtained through the git diff command. In this case, the first binary file of the most recent submission of the current module can be determined based on the submission information obtained by the git log command, and the first binary file can be compared with the latest second binary file of the current module provided by the binary file management module. According to the comparison result, it is determined whether the current module has a source code change. If the first binary file and the second binary file are the same, it is determined that the current module has no source code change. If the first binary file and the second binary file are different, it is determined that the current module has a source code change.

[0103] On the basis of the first embodiment, the third embodiment of the present application provides a compilation method based on Gradle, which is used to explain the step S104 in the first embodiment in detail. Figure 7 The flowchart of the Gradle-based compilation method provided in Example 3 of the present application is as follows: Figure 7 As shown, the method provided in this embodiment includes the following steps.

[0104] S1041. Use the project object of each module to create a virtual binary module for the target module according to the binary file information of the target module in the dependency tree of each module.

[0105] For the dependency tree of any module, the target module may or may not exist in the dependency data tree of the module. If the target module exists in the dependency tree of the module, a virtual binary module is generated for each target module in the dependency tree of the module, and the virtual binary module adopts binary dependency.

[0106] The virtual binary module is a virtual module that only exists in the compilation process. The virtual binary module is located in the configuration file of the module in the memory. The configuration file of the module is the build.gradle file of the module. After the compilation process is completed, the virtual binary module disappears. The virtual binary module is relative to the module in the script file of the project. The module in the script file of the project still exists after the compilation is completed.

[0107] Exemplarily, a virtual binary module is created in the following manner: calling the configuration instance of the project object of each module, calling the createArtifact method of the configuration instance, and creating a virtual binary module according to the binary file information of the target module of each module. The virtual binary module is an artifact object.

[0108] S1042. Use the virtual binary module to replace the target module.

[0109] The target module is replaced according to the virtual binary module created for the target module, the target module is a source code module, and the virtual binary module is a binary module, thereby achieving replacement of the source code module with the binary module.

[0110] Exemplarily, the target module can be replaced with the virtual binary module in the following manner: calling the add method of the artifact object, adding the virtual binary module to the dependency tree of each module, and removing the target module from the dependency tree of each module.

[0111] Based on the above embodiments, Embodiment 4 of the present application provides a compilation method based on Gradle, which is used to illustrate the complete compilation process of the project. Figure 8 A flowchart of a Gradle-based compilation method provided in Example 4 of the present application is shown in FIG. Figure 8 As shown, the method provided in this embodiment includes the following steps.

[0112] S201. Build a project object.

[0113] When a compile command is received, the compile process starts. The compile command can be manually triggered by the user. For example, in the process of software application development, a project needs to be compiled. The user can click or touch the compile control on the page. After the compile device detects the user's triggering operation on the compile control, it generates a compile command. Alternatively, the compile command can also be automatically triggered by the compile system.

[0114] After the compilation process starts, the setting.gradle file is searched and the project object of the current project is built. It can be understood that the compilation process is part of the gradle build process. In addition to the compilation operation, the gradle build process also includes the construction of some resource files and other operations.

[0115] The project object is an object in memory. Building a project object means building a project object for the project in the memory of the compilation device. Building a project object includes loading and configuring the project's modules.

[0116] S202: Obtain a module list of the project from the project object of the project.

[0117] A project includes multiple modules. You can get the module list of the project from the project object of the project. The module list includes the module names.

[0118] S203: Detect the modules of the project to obtain compilation reference information of the first source code module in the project where no source code change has occurred.

[0119] The modules of the project may be detected in sequence according to the module list to obtain the compilation reference information of the first source code module in the project in which no source code change occurs.

[0120] S204: Obtain the dependency tree of each module of the project.

[0121] S205 . Determine, according to the compilation reference information of the first source code module, a target module in which no source code change occurs in the dependency tree of each module and the dependency type is source code dependency.

[0122] S206. According to the binary file of the target module in the dependency tree of each module, the source code dependency of the target module in the dependency tree of each module is modified into a binary dependency.

[0123] The specific implementation of steps S203 - 206 refers to the description of the above embodiment and will not be repeated here.

[0124] S207, traverse the module list of the project, obtain the build.gradle file of the current module of the project, and obtain the modified dependency tree of the current module from the build.gradle file of the current module.

[0125] In this embodiment, the dependency tree of each module is modified, which is actually the dependency tree in the build.gradle file of each module created in the memory. In this embodiment, the dependency tree of each module is modified first when the compilation process starts. Therefore, the dependency tree of the build.gradle file read at compile time is the modified dependency tree.

[0126] S208. Determine whether the current module has a source code dependent module based on the modified dependency tree of the current module.

[0127] If the current module has a source code dependent module, execute step S209; if the current module does not have a source code dependent module, execute step S210.

[0128] S209, compile the source code of the source code dependent module of the current module.

[0129] The current module may depend on multiple modules, some of which are source code dependent modules and some of which are not. For the source code dependent modules of the current module, source code compilation is required. After source code compilation, binary files are generated. The compiled binary files are stored in local files according to the binary file management strategy. If the module that the current module depends on is not a source code dependent module, for example, the module that the current module depends on is a binary dependent module, source code compilation is not required, but the binary files of the binary dependent modules are directly used for some other operations.

[0130] It should be noted that the binary dependency module of the current module may be a binary module obtained by modifying the source code module through the method provided in the embodiment of the present application, or it may be a binary module of the project itself. For example, some modules adopt binary dependencies when they are created.

[0131] In addition, the modules that the current module depends on may also depend on other modules, refer to Figure 3 Therefore, module A depends on module B, and module B depends on module C and binary module N. In this case, all modules on the entire dependency chain need to be compiled. After all modules on the dependency tree of the current module are compiled, step S210 is executed, that is, the current module is compiled.

[0132] Taking module A depending on module B, module B depending on module C and binary module N as an example, first determine whether module B is a source code dependent module. If module B is a source code dependent module, then compile the source code of module B. If module B is not a source code dependent module, then do not compile the source code of module B. Then, determine whether module C is a source code dependent module, and perform the corresponding compilation operation based on the determination result. By analogy, determine whether module C is a source code dependent module.

[0133] S210, compile the current module.

[0134] After all modules in the dependency tree of the current module are compiled, the current module is compiled. After the current module is compiled, the next module is compiled.

[0135] Steps S207-S210 are a specific method for compiling the current module according to the modified dependency tree of the current module. For each module in the project, compilation is performed in accordance with the method of S207-S210. After the compilation of the current module is completed, the next module is compiled in accordance with the compilation order until all modules in the project are compiled.

[0136] In order to better implement the Gradle-based compilation method of the embodiment of the present application, the embodiment of the present application also provides a Gradle-based compilation device. Fig. 9 A schematic diagram of the structure of a Gradle-based compilation device provided in Example 5 of the present application is shown in FIG. Fig. 9 As shown, the Gradle-based compilation device 100 may include:

[0137] A source code change detection module 11 is used to detect modules of a project and obtain compilation reference information of a first source code module in which no source code change has occurred in the project, wherein the compilation reference information includes an identifier of the first source code module, an identifier of no source code change, and information of a binary file, wherein the project includes multiple modules, and the binary file is a file obtained by compiling the source code of the first source code module;

[0138] A dependency acquisition module 12, used to acquire a dependency tree of each module of the project;

[0139] A dependency modification module 13, configured to determine, based on the compilation reference information of the first source code module, a target module in the dependency tree of each module in which no source code change has occurred and whose dependency type is source code dependency;

[0140] The dependency modification module 13 is further used to modify the source code dependency of the target module in the dependency tree of each module into a binary dependency according to the binary file of the target module in the dependency tree of each module;

[0141] The compiling module 14 is used to compile the modules according to the modified dependency trees of the modules.

[0142] In a possible implementation, the source code change detection module 11 is specifically used to:

[0143] Detecting source code modules in modules of the project;

[0144] Determining, from the detected source code modules, a module in which no source code change has occurred as the first source code module;

[0145] The binary file information of the first source code module is obtained, and compilation reference information is generated for the first source code module.

[0146] In a possible implementation, the source code change detection module 11 is specifically used to:

[0147] Obtain the folder path of each module of the project, and obtain the folder of each file of the project according to the folder path of each module of the project;

[0148] Access each module of the project in the access order, execute a submit query command in the folder of the current module of the project, and obtain the return value of the query command;

[0149] Determining whether the current module is a source code module according to the return value of the submit query command;

[0150] When the current module is a source code module, executing a difference query command in a folder of the current module to obtain an execution result of the difference query command;

[0151] According to the execution result of the difference query command, determine whether the source code of the current module has been changed;

[0152] If the source code of the current module has not been changed, the current module is determined to be the first source code module.

[0153] In a possible implementation, the source code change detection module 11 is specifically used to:

[0154] If the return value of the submit query command includes submission information, determining that the module is a source code module;

[0155] If the return value of the submit query command does not include the submit information, it is determined that the module is not a source code module.

[0156] In a possible implementation, the source code change detection module 11 is specifically used to:

[0157] If the return value of the difference query command is empty, it is determined that no source code change occurs in the current module;

[0158] If the return value of the difference query command is not empty, it is determined that a source code change has occurred in the current module.

[0159] In a possible implementation, the information of the binary file includes an index of the binary file and an address of the binary file; the source code change detection module 11 is specifically used for:

[0160] Acquire the submission information of the most recent submission from the submission information of the first source code module, wherein the submission information of the most recent submission includes a submission identification ID and an address of a binary file;

[0161] The submission ID of the most recent submission is used as the index of the binary file of the first source code module, and the address of the binary file of the most recent submission is used as the address of the binary file of the first source code module.

[0162] In a possible implementation, the dependency acquisition module 12 is specifically used to:

[0163] Get the project object of the project;

[0164] Get the DependencyHandler object by calling the getDependency method provided by the project object;

[0165] The dependency tree of each module of the project is obtained through the getModuleDependency method provided by the DependencyHandler object.

[0166] In a possible implementation, the dependency modification module 13 is specifically used to:

[0167] Using the project objects of the modules, creating a virtual binary module for the target module according to the binary file information of the target module in the dependency tree of the modules;

[0168] The target module is replaced with the virtual binary module.

[0169] In a possible implementation, the dependency modification module 13 is specifically used to:

[0170] Call the configuration instance of the project object of each module;

[0171] Calling the createArtifact method of the configuration instance to create a virtual binary module according to the binary file information of the target module of each module, wherein the virtual binary module is an artifact object;

[0172] The add method of the artifact object is called to add the virtual binary module to the dependency tree of each module, and remove the target module from the dependency tree of each module.

[0173] In a possible implementation, the compilation reference information of the first source code module is stored in the memory of the compilation device, and the dependency tree of the module is stored in the build.gradle file loaded by each module;

[0174] The dependency modification module 13 is specifically used for:

[0175] According to the binary file of the target module in the dependency tree of each module, the source code dependency of the target module in the dependency tree of each module stored in the build.gradle file loaded by each module is modified to a binary dependency.

[0176] In a possible implementation, a configuration module is further included, which is used to:

[0177] Build the project object of the project;

[0178] Get the module list of the project from the project object of the project;

[0179] The compiling module 14 is specifically used for:

[0180] Traverse the module list of the project, obtain the build.gradle file of the current module of the project, and obtain the modified dependency tree of the current module from the build.gradle file of the current module;

[0181] The current module is compiled according to the modified dependency tree of the current module.

[0182] In a possible implementation, the device 100 is a Gradle plug-in.

[0183] It should be understood that the device embodiment and the method embodiment may correspond to each other, and similar descriptions may refer to the method embodiment. To avoid repetition, they will not be described here.

[0184] The above describes the device 100 of the embodiment of the present application from the perspective of the functional module in conjunction with the accompanying drawings. It should be understood that the functional module can be implemented in hardware form, can be implemented by instructions in software form, and can also be implemented by a combination of hardware and software modules. Specifically, the steps of the method embodiment in the embodiment of the present application can be completed by the hardware integrated logic circuit and / or software form instructions in the processor, and the steps of the method disclosed in the embodiment of the present application can be directly embodied as a hardware decoding processor to perform, or a combination of hardware and software modules in the decoding processor to perform. Optionally, the software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, a register, etc. The storage medium is located in a memory, and the processor reads the information in the memory, and completes the steps in the above method embodiment in conjunction with its hardware.

[0185] The embodiment of the present application also provides a compilation device. Fig.10 A structural diagram of a compilation device provided in Example 6 of the present application, such as Fig.10 As shown, the compiling device 200 may include:

[0186] The memory 21 and the processor 22, the memory 21 is used to store the computer program and transmit the program code to the processor 22. In other words, the processor 22 can call and run the computer program from the memory 21 to implement the method in the embodiment of the present application.

[0187] In some embodiments of the present application, the processor 22 may include but is not limited to: a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0188] In some embodiments of the present application, the memory 21 includes, but is not limited to, volatile memory and / or non-volatile memory. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus random access memory (Direct Rambus RAM, DR RAM).

[0189] In some embodiments of the present application, the computer program may be divided into one or more modules, which are stored in the memory 21 and executed by the processor 22 to complete the method provided by the present application. The one or more modules may be a series of computer program instruction segments capable of completing specific functions, and the instruction segments are used to describe the execution process of the computer program in the compiling device.

[0190] like Fig.10 As shown, the compiling device 200 may further include: a transceiver 23 , which may be connected to the processor 22 or the memory 21 .

[0191] The processor 22 may control the transceiver 23 to communicate with other devices, specifically, to send information or data to other devices, or to receive information or data sent by other devices. The transceiver 23 may include a transmitter and a receiver. The transceiver 23 may further include an antenna, and the number of antennas may be one or more.

[0192] Understandable, although Fig.10Not shown in the figure, the compiling device 200 may also include a positioning module, a Bluetooth module, a display, a controller, an input device, etc., which will not be described in detail here.

[0193] It should be understood that the various components in the compilation device are connected via a bus system, wherein the bus system includes not only a data bus but also a power bus, a control bus and a status signal bus.

[0194] The present application also provides a computer storage medium on which a computer program is stored, and when the computer program is executed by a computer, the computer can perform the method of the above method embodiment. In other words, the present application embodiment also provides a computer program product containing instructions, and when the instructions are executed by a computer, the computer can perform the method of the above method embodiment.

[0195] The present application also provides a computer program product, which includes a computer program, and the computer program is stored in a computer-readable storage medium. The processor of the compilation device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, so that the compilation device executes the corresponding process in the above method embodiment, which will not be repeated here for the sake of brevity.

[0196] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the module is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0197] The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. For example, each functional module in each embodiment of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0198] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A compilation method based on Gradle, characterized in that: include: Detecting modules of a project to obtain compilation reference information of a first source code module in which no source code change has occurred in the project, the compilation reference information including an identifier of the first source code module, an identifier of no source code change, and information of a binary file, the project including multiple modules, and the binary file being a file obtained by compiling the source code of the first source code module; Obtain a dependency tree of each module of the project; Determine, according to the compilation reference information of the first source code module, a target module in which no source code change occurs in the dependency tree of each module and the dependency type is source code dependency; According to the binary file of the target module in the dependency tree of each module, modify the source code dependency of the target module in the dependency tree of each module into a binary dependency; The modules are compiled according to the modified dependency trees of the modules.

2. The method according to claim 1, characterized in that The detecting of the modules of the project to obtain the compilation reference information of the first source code module in the project where no source code change has occurred includes: Detecting source code modules in modules of the project; Determining, from the detected source code modules, a module in which no source code change has occurred as the first source code module; The binary file information of the first source code module is obtained, and compilation reference information is generated for the first source code module.

3. The method according to claim 2, characterized in that The detecting of the source code module in the module of the project includes: Obtain the folder path of each module of the project, and obtain the folder of each file of the project according to the folder path of each module of the project; Access each module of the project in the access order, execute a submit query command in the folder of the current module of the project, and obtain the return value of the query command; Determining whether the current module is a source code module according to the return value of the submit query command; The step of determining, from the detected source code modules, that a module that has not undergone source code changes is the first source code module, includes: When the current module is a source code module, executing a difference query command in a folder of the current module to obtain an execution result of the difference query command; According to the execution result of the difference query command, determine whether the source code of the current module has been changed; If the source code of the current module has not been changed, the current module is determined to be the first source code module.

4. The method according to claim 3, characterized in that The step of judging whether the current module is a source code module according to the return value of the submit query command includes: If the return value of the submit query command includes submission information, determining that the module is a source code module; If the return value of the submit query command does not include the submission information, it is determined that the module is not a source code module; The determining, according to the execution result of the difference query command, whether the source code of the current module has been changed includes: If the return value of the difference query command is empty, it is determined that no source code change occurs in the current module; If the return value of the difference query command is not empty, it is determined that a source code change has occurred in the current module.

5. The method according to claim 3, characterized in that: The information of the binary file includes an index of the binary file and an address of the binary file; The obtaining of information about the binary file of the first source code module includes: Acquire the submission information of the most recent submission from the submission information of the first source code module, wherein the submission information of the most recent submission includes a submission identification ID and an address of a binary file; The submission ID of the most recent submission is used as the index of the binary file of the first source code module, and the address of the binary file of the most recent submission is used as the address of the binary file of the first source code module.

6. The method according to claim 1, characterized in that The obtaining of the dependency tree of each module of the project includes: Get the project object of the project; Get the DependencyHandler object by calling the getDependency method provided by the project object; The dependency tree of each module of the project is obtained through the getModuleDependency method provided by the DependencyHandler object.

7. The method according to claim 1, characterized in that The step of modifying the source code dependency of the target module in the dependency tree of each module into a binary dependency according to the binary file of the target module in the dependency tree of each module comprises: Using the project objects of the modules, creating a virtual binary module for the target module according to the binary file information of the target module in the dependency tree of the modules; The target module is replaced with the virtual binary module.

8. The method according to claim 7, characterized in that The using the project objects of the modules to create a virtual binary module for the target module according to the binary file information of the target module in the dependency tree of the modules includes: Call the configuration instance of the project object of each module; Calling the createArtifact method of the configuration instance to create a virtual binary module according to the binary file information of the target module of each module, wherein the virtual binary module is an artifact object; The step of replacing the target module with the virtual binary module comprises: The add method of the artifact object is called to add the virtual binary module to the dependency tree of each module, and remove the target module from the dependency tree of each module.

9. The method according to any one of claims 1 to 8, characterized in that: The compilation reference information of the first source code module is stored in the memory of the compilation device, and the dependency tree of each module is stored in the build.gradle file loaded by each module; The step of modifying the source code dependency of the target module in the dependency tree of each module into a binary dependency according to the binary file of the target module in the dependency tree of each module comprises: According to the binary file of the target module in the dependency tree of each module, the source code dependency of the target module in the dependency tree of each module stored in the build.gradle file loaded by each module is modified to a binary dependency.

10. The method according to any one of claims 1 to 8, characterized in that: Before testing the modules included in the project, the following steps are also included: Build the project object of the project; Get the module list of the project from the project object of the project; The compiling of the modules according to the modified dependency trees of the modules includes: Traverse the module list of the project, obtain the build.gradle file of the current module of the project, and obtain the modified dependency tree of the current module from the build.gradle file of the current module; The current module is compiled according to the modified dependency tree of the current module.

11. The method according to any one of claims 1 to 8, characterized in that: The method is implemented through a Gradle plug-in.

12. A compilation device based on Gradle, characterized in that: include: a source code change detection module, configured to detect modules of a project and obtain compilation reference information of a first source code module in which no source code change has occurred in the project, wherein the compilation reference information includes an identifier of the first source code module, an identifier of no source code change, and information of a binary file, wherein the project includes multiple modules, and the binary file is a file obtained by compiling the source code of the first source code module; A dependency acquisition module, used to obtain the dependency tree of each module of the project; A dependency modification module, used to determine, based on the compilation reference information of the first source code module, a target module in the dependency tree of each module in which no source code change has occurred and whose dependency type is source code dependency; The dependency modification module is further used to modify the source code dependency of the target module in the dependency tree of each module into a binary dependency according to the binary file of the target module in the dependency tree of each module; A compiling module is used to compile each module according to the modified dependency tree of each module.

13. A compiling device, characterized in that: include: A processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to execute the method according to any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that: Used to store a computer program, wherein the computer program causes a computer to execute the method according to any one of claims 1 to 11.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 11 is implemented.

Images