Data processing method and related device

Abstract

The invention discloses a data processing method and a related device. The embodiment of the invention can be applied to various scenes such as cloud technology, artificial intelligence, intelligent traffic and auxiliary driving. Firstly, a function module set needing to be loaded by a target application and a dependency relationship are obtained, and the function module set is divided into a direct dependency set and an indirect dependency set according to the dependency relationship. Then, an address catalog of the function module set is constructed, query addresses of a loader are identified in the address catalog when the function modules are to be loaded, and meanwhile the query addresses of the function modules with the dependency relation have the incidence relation of the address levels. And finally, in response to a module loading request of a target loading party, according to a target query address of the target loading party in the address directory and a query address having an association relationship with the target query address, querying to obtain a to-be-loaded function module corresponding to the module loading request, and loading the to-be-loaded function module. Therefore, the loading efficiency and precision of the function module are greatly improved through the address catalog marking the incidence relation.

Description

Technical Field

[0001] The present application relates to the field of data processing, and particularly to a data processing method and related devices. Background Art

[0002] In the development work of front-end application projects, in order to implement various functions, different function modules often need to be installed. For example, JavaScript libraries, CSS frameworks, icon fonts, etc. all belong to different function modules. This way of installing function modules is called dependency installation, and these installed function modules can also be recorded as dependencies. Before installing a function module, it is first necessary to load the dependency package (i.e., the function installation file) of the function module.

[0003] During development and design, the same function module may need to be requested for installation when implementing different functions, and different versions of the function module need to be installed. For example, when implementing function a, the first version of function module c needs to be installed, and when implementing function b, the second version of function module c needs to be installed.

[0004] However, in the related art, the dependency relationships in dependency installation cannot be accurately recorded, resulting in the situation that when loading the dependency packages of function modules, non-expected versions of function modules are often loaded, leading to runtime errors and causing runtime problems. Summary of the Invention

[0005] In order to solve the above technical problems, the present application provides a data processing method and related devices, which can accurately record dependency relationships and improve the loading efficiency and accuracy of function modules.

[0006] The embodiments of the present application disclose the following technical solutions:

[0007] On the one hand, the embodiments of the present application provide a data processing method, including:

[0008] Obtaining a set of function modules and dependency relationships that need to be loaded during the operation of a target application, where the dependency relationships are used to identify the relationships between the function modules in the set of function modules and the loaders of the function modules;

[0009] Dividing the set of function modules into a direct dependency set and an indirect dependency set according to the dependency relationships, where the function modules in the direct dependency set are the function modules loaded when the target application runs as a loader, and the function modules in the indirect dependency set are the function modules loaded when any function module in the set of function modules runs as a loader;

[0010] Construct an address directory of the function module set in the target application according to the direct dependency set and the indirect dependency set. The address directory is used to identify the query address of the loading party when the function modules in the function module set are to be loaded. In the address directory, an association relationship is established between the query addresses of the function modules with the dependency relationship through address levels;

[0011] When a module loading request of a target loading party is obtained during the running of the target application, query and load the function module to be loaded corresponding to the module loading request according to the target query address of the target loading party in the address directory and the query addresses associated with the target query address.

[0012] On the other hand, an embodiment of the present application provides a data processing device, and the device includes: an acquisition module, a division module, a construction module, and a query module;

[0013] The acquisition module is used to acquire the function module set and the dependency relationship that need to be loaded during the running of the target application. The dependency relationship is used to identify the relationship between the function modules in the function module set and the loading parties of the function modules;

[0014] The division module is used to divide the function module set into a direct dependency set and an indirect dependency set according to the dependency relationship. The function modules in the direct dependency set are the function modules loaded when the target application runs as a loading party, and the function modules in the indirect dependency set are the function modules loaded when any function module in the function module set runs as a loading party;

[0015] The construction module is used to construct an address directory of the function module set in the target application according to the direct dependency set and the indirect dependency set. The address directory is used to identify the query address of the loading party when the function modules in the function module set are to be loaded. In the address directory, an association relationship is established between the query addresses of the function modules with the dependency relationship through address levels;

[0016] The query module is used to query and load the function module to be loaded corresponding to the module loading request according to the target query address of the target loading party in the address directory and the query addresses associated with the target query address when a module loading request of the target loading party is obtained during the running of the target application.

[0017] On yet another aspect, an embodiment of the present application provides a computer device, and the computer device includes a processor and a memory:

[0018] The memory is used to store a computer program and transmit the computer program to the processor;

[0019] The processor is used to execute the method described in the above aspects according to a computer program.

[0020] In another aspect, an embodiment of the present application provides a computer-readable storage medium for storing a computer program, and the computer program is used to execute the method described in the above aspects.

[0021] In another aspect, an embodiment of the present application provides a computer program product including a computer program, which, when running on a computer device, causes the computer device to execute the method described in the above aspects.

[0022] It can be seen from the above technical solutions that for a target application that needs to load function modules to provide correct services, according to the set of function modules to be loaded and the dependency relationships during the operation of the target application, the set of function modules to be loaded is divided into a direct dependency set and an indirect dependency set. Among them, the function modules in the direct dependency set are the function modules loaded when the target application runs as a loading party, and the function modules in the indirect dependency set are the function modules loaded when any function module in the set of function modules runs as a loading party. By distinguishing function modules from the dimensions of direct dependency and indirect dependency, when constructing an address directory for loading function modules based on dependency relationships, the query addresses of the loading party and the loaded party can be accurately associated in the address directory. Thus, when the loading party needs to load a function module, it can accurately load the required function module based on the association relationship in the address directory, rather than loading other function modules that do not have a dependency relationship with itself. When there are multiple versions of the same function module in the loading environment, the possibility of loading a non-required version of the function module is reduced. Therefore, the loading efficiency and accuracy of function modules are greatly improved through the address directory indicating the association relationship. Description of the Drawings

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0024] Figure 1 It is a schematic diagram of a data processing method provided by an embodiment of the present application;

[0025] Figure 2 It is a flowchart of a data processing method provided by an embodiment of the present application;

[0026] Figure 3A schematic diagram of an address directory with a parent-child relationship provided by an embodiment of the present application;

[0027] Figure 4 A schematic diagram of an address structure provided by an embodiment of the present application;

[0028] Figure 5 A schematic diagram of an address hierarchical structure with a parent-child relationship provided by an embodiment of the present application;

[0029] Figure 6 A schematic diagram of an address directory structure including jump soft links provided by an embodiment of the present application;

[0030] Figure 7 A schematic diagram of an address directory structure including jump soft links in an application scenario provided by an embodiment of the present application;

[0031] Figure 8 A schematic diagram of an address directory structure including jump soft links provided by an embodiment of the present application;

[0032] Figure 9 Another schematic diagram of an address directory structure including jump soft links in an application scenario provided by an embodiment of the present application;

[0033] Figure 10 A schematic diagram of directory level division provided by an embodiment of the present application;

[0034] Figure 11 A flowchart of a method for dependency loading provided by an embodiment of the present application;

[0035] Figure 12 A schematic diagram of a data processing device provided by an embodiment of the present application;

[0036] Figure 13 A structure diagram of a terminal device provided by an embodiment of the present application;

[0037] Figure 14 A structure diagram of a server provided by an embodiment of the present application. Detailed implementation manners

[0038] The embodiments of the present application will be described below with reference to the accompanying drawings.

[0039] Dependency can also be understood as a dependency package, which can refer to a certain functional installation file necessary to ensure the normal operation of an application when the application is running. When an application is running, if one or more dependency packages are missing, the application will not run properly. During the process of front-end application development, it is often necessary to install different functional modules. During the installation of functional modules, it is necessary to first load the dependency packages corresponding to the functional modules. Different dependency packages can be indexed according to the loading path, and after the loading is completed, the installation of the functional modules is carried out. Suppose there are two functional requirements at the same time. When loading the dependency packages of the functional modules, the two functional requirements need to be implemented by the same functional module with different versions. At this time, since the corresponding dependency relationship of the application cannot be accurately determined, the loading of the dependency packages of the functional modules of the expected version cannot be achieved, resulting in a running error and causing a running problem.

[0040] To this end, the embodiments of the present application provide a data processing method and related device, which can divide functional modules through dependency relationships, so that the association relationship of query addresses between different functional modules or between functional modules and target applications can be accurately established during the establishment of the address directory. Through the constructed association relationship between query addresses, it is possible to avoid, to a certain extent, the situation of loading non-required version functional modules when multiple versions of the same functional module are involved during the loading of functional modules, thereby improving the loading efficiency and accuracy of functional modules.

[0041] The data processing method provided by the embodiments of the present application can be implemented by a computer device, which can be a terminal device or a server. Among them, the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Terminal devices include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, etc. The terminal device and the server can be directly or indirectly connected through wired or wireless communication methods, which are not limited in this application. First, several noun terms that may be involved in the following embodiments of the present application are explained. The embodiments of the present application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, intelligent transportation, assisted driving, etc.

[0042] Dependency installation: Dependency installation refers to the need to install and manage various functional modules, such as JavaScript libraries, CSS frameworks, icon fonts, etc., when developing and building front-end applications. These functional modules are usually released in the form of packages and are installed and managed through a package manager.

[0043] npm (Node Package Manager): A popular package manager used to install, manage, and publish Node.js modules. In addition to Node.js modules, npm can also be used to install and manage front-end functional modules, such as JavaScript libraries, CSS frameworks, icon fonts, etc.

[0044] Symbolic Link (also known as soft link): A special file type that can create a link to a query address in the target application or functional module. A symbolic link can be regarded as a pointer that points to the path of the query address, enabling the data of the functional module corresponding to the query address to be accessed and loaded by multiple target loaders.

[0045] Figure 1 Schematic diagram of a data processing method provided by an embodiment of this application, where the aforementioned computer device is a terminal device.

[0046] When developing a front-end target application, it is necessary to install functional modules that can implement various functions of the target application at the same time. The target application includes a set of functional modules and the dependency relationships between the target application and the functional modules. According to different dependency relationships, the set of functional modules can be divided into a direct dependency set and an indirect dependency set. After the division of the dependency relationships is completed, the address directories of each functional module can be constructed. The query addresses of each functional module are marked in the address directory, and there is an address hierarchy association relationship between the query addresses of the functional modules with dependency relationships.

[0047] As Figure 1 shown, an example of an address directory is given in the figure. Under this address directory, there is a first directory level and a second directory level. A folder is set at the first directory level, and all the address situations of the second directory level are included in the folder. The module loading addresses of each functional module are included in the second directory level. When the target loader needs to load a specified functional module, it can accurately load the specified functional module based on the association relationship between the target query address of the target loader in the address directory and the query address of the specified functional module.

[0048] Figure 2 Flowchart of a data processing method provided by an embodiment of this application. This method can be executed by a computer device. In this embodiment, it is described by taking the computer device as a terminal device as an example.

[0049] The method includes:

[0050] S201: Obtain the set of functional modules and the dependency relationships required to be loaded during the operation of the target application.

[0051] During the operation of the target application, different functional modules need to be installed to achieve different functions. The process of installing these functional modules is called dependency installation, and the prerequisite for dependency installation is to accurately load the functional modules required by the target application. The functional modules that the target application needs to load can include, but are not limited to, the following types: JavaScript libraries, CSS frameworks, icon fonts, and identity recognition modules, etc.

[0052] During the operation of the target application in the terminal device, in order to implement the corresponding functions, functional modules need to be loaded. When loading functional modules, first, it is necessary to obtain the set of functional modules and the dependency relationships that the target application needs to load during operation. Since the functions to be implemented are different, the quantity and types of the corresponding required functional modules may be different, may be partially the same, or may be completely the same. One function can correspond to one or more functional modules. It is possible to request to load one functional module at a time, or it is also possible to request to load multiple functional modules simultaneously at one time.

[0053] The above-mentioned set of functional modules can be understood as the sum of the functional modules that the target application needs to load to achieve its own functions. The set of functional modules can include multiple functional modules. The dependency relationship is used to identify the relationship between the functional modules in the set of functional modules and the loading party, that is, it identifies the loading party (the target application or a functional module) and the loaded party (the functional module) during loading.

[0054] In the embodiments of the present application, the dependency relationship can be divided into the following two types: direct dependency relationship and indirect dependency relationship. Among them, the direct dependency relationship can be understood as the dependency relationship between the functional modules directly loaded by the target application during the operation of the target application. The indirect dependency relationship can be understood as the dependency relationship between the functional modules that need to be loaded during the operation of the functional modules loaded in the target application.

[0055] For example, when running functional module a, in the scenario where functional module a needs to load functional module b before it can provide its own function, the dependency relationship between functional module a and functional module b is an indirect dependency. In the indirect dependency relationship of this example, functional module a is the loading party, functional module b is the sub-dependency of functional module a, and functional module a can have a direct dependency relationship with the target application, or it can also be the sub-dependency of other functional modules such as functional module c.

[0056] S202: Divide the set of functional modules into a direct dependency set and an indirect dependency set according to the dependency relationship.

[0057] The dependencies in the embodiments of the present application have been described above. After the terminal device obtains the function module set to be loaded by the target application and the dependencies, the function modules in the function module set can be divided according to different dependencies. Specifically, they are divided into a direct dependency set and an indirect dependency set. The function modules in the direct dependency set can be understood as the function modules directly loaded when the target application runs as a loading party; the function modules in the indirect dependency set can be understood as the function modules loaded when any function module in the function module set runs as a loading party. It can be seen from this that the function modules in the indirect dependency set can belong to the sub-function modules (i.e., sub-dependencies) of the function modules in the direct dependency set, and can also belong to the sub-function modules of the function modules in the indirect dependency set.

[0058] For example, assume that the function to be implemented by the target application at this time is identity recognition. The corresponding function module set may include: a fingerprint recognition module, a face recognition module, an image processing module, and a feature extraction module. At this time, it can be determined that the function modules directly loaded by the target application for the implementation of the identity recognition function in the target application are the fingerprint recognition module and the face recognition module. If you want the fingerprint recognition module and the face recognition module to be able to implement the corresponding fingerprint recognition function and face recognition function, it is necessary to load the image processing module and the feature extraction module for the fingerprint recognition module and the face recognition module respectively. Only in this way can the fingerprint recognition module perform image processing and feature extraction on the fingerprint image to determine the identity information. The face recognition module is the same and will not be elaborated here.

[0059] From the above description, it can be seen that if the function module set in this example is divided according to the dependencies, then the fingerprint recognition module and the face recognition module should belong to the direct dependency set, while the image processing module and the feature extraction module should belong to the indirect dependency set.

[0060] By dividing each function module according to the dependencies, the loading logic between each function module can be made clearer and more understandable, which is convenient for subsequent hierarchical addressing directories according to the dependencies.

[0061] S203: Construct an address directory of the function module set in the target application according to the direct dependency set and the indirect dependency set.

[0062] When the terminal device finishes partitioning the function module set according to the dependency relationship, it can construct an address directory for the target application based on the partitioning result. The address directory can include different address hierarchy levels. By partitioning the address hierarchy for the address directory, the dependency relationships between various function modules can be reflected. For example, the address directory can include the following form of query address: "node_modules / .dependencies / A@1.0.0". In this query address, " / A@1.0.0" after " / .dependencies" belongs to the next address hierarchy level of " / .dependencies". Suppose there are both "node_modules / .dependencies / A@1.0.0" and "node_modules / .dependencies / B@1.0.0" at the same time. At this time, "@1.0.0" and "B@1.0.0" belong to the same address hierarchy level and both belong to the next address hierarchy level of " / .dependencies". When the target loader needs to load the function module to be loaded, it can identify the query address of the function module to be loaded through the address directory, so as to load the function module to be loaded according to this query address. In the address directory, there is an association relationship between the query addresses of function modules with dependency relationships through the address hierarchy.

[0063] The association relationship can identify the loading logic between the loader and the loaded module, and this loading logic is related to the previously established address hierarchy. Through the partitioning of the aforementioned address hierarchy levels, the hierarchical positions of different function modules in the address directory can be determined. Based on the hierarchical positions, the loading logic between various function modules, that is, the association relationship, can be clarified. And the determination of the association relationship enables accurate loading according to the association relationship when the target loader loads function modules.

[0064] For example, the aforementioned association relationship can be reflected through the parent-child relationship of the address hierarchy. Suppose function module a is a function module in the direct dependency set, and function module b is a function module in the indirect dependency set. There is a dependency relationship between function module a and function module b. If at this time function module a is the loader and function module b is the loaded module, that is, function module b is the function module that still needs to be loaded when function module a runs, and the dependency relationship between the two belongs to an indirect dependency relationship. Then at this time, the query address of function module a can be constructed at the first directory level (i.e., the parent level) in the address directory, and the query address of function module b can be constructed at the sub-directory level (i.e., the child level) of the first directory level. That is, the query address of function module b will be located within the query address of function module a, and the query address of function module a and the query address of function module b will have a corresponding association relationship related to the address hierarchy.

[0065] S204: When a module loading request of a target loader is obtained during the running of the target application, according to the target query address of the target loader in the address directory and the query addresses associated with the target query address, the to-be-loaded functional module corresponding to the module loading request is queried and loaded.

[0066] Information such as the name, type, and version number of the to-be-loaded functional module may be included in the module loading request. When a module loading request of a target loader is obtained during the running of the target application, it is necessary to determine the to-be-loaded functional module according to the module loading request. Then, the query address of the target loader is determined, and according to the association relationship between the query address of the target loader and the query address of the to-be-loaded functional module, the query address of the to-be-loaded functional module is determined and loaded.

[0067] The target loader mentioned here may include two categories. One category is the target application itself, and the other category is the functional module loaded into the target application. The query addresses of different target loaders in the address directory may be different. When the target loader is the target application itself, the dependency relationship between the corresponding to-be-loaded functional module and the target loader is a direct dependency relationship; when the target loader is the functional module itself, the dependency relationship between the corresponding to-be-loaded functional module and the target loader is an indirect dependency relationship. The foregoing dependency relationships can all be reflected by the hierarchical association relationship between the query addresses. Similarly, when the query address of the target loader and the to-be-loaded functional module are determined, the query address of the to-be-loaded functional module can be determined according to the association relationship between the addresses in the address directory, thereby completing the loading of the to-be-loaded functional module.

[0068] It can be seen from the above description that in the embodiment of the present application, the loader of the terminal device may be the target application or the functional module, and the to-be-loaded party is the to-be-loaded functional module. When addressing and loading the to-be-loaded functional module, there may be multiple versions of the same functional module in the address directory. At this time, since the association relationship between the query addresses of the loader and the to-be-loaded party is established when constructing the address directory of the functional module set in the target application, and the hierarchical association relationship of the query addresses of the functional modules with dependency relationships is set, it is ensured that during the addressing and loading process of the to-be-loaded functional module, the functional module that has no association relationship with the loader will not be loaded. Therefore, even if there are multiple versions of the same type of functional module, due to the constraint of the association relationship between the query addresses in the address directory, the possibility of incorrect functional module loading can be avoided to a certain extent.

[0069] Through a data processing method provided above, functional modules are divided into directly dependent functional modules and indirectly dependent functional modules according to the dependency relationship, and a corresponding address directory is constructed. The query addresses of the corresponding functional modules are identified in the address directory. At the same time, according to the different types of functional modules in the query addresses, the query addresses of the directly dependent functional modules and the indirectly dependent functional modules are associated in the form of an address hierarchy relationship. When it is necessary to load a functional module, the corresponding functional module is loaded according to the loading request and the associated relationship of the query addresses. In this way, by classifying the dependency types of functional modules and determining the association relationship between functional modules of different dependency types according to the classification results, and constructing the association relationship by distinguishing different levels in the address directory, the dependency relationship between each functional module can be correctly represented by the association relationship between addresses. When an application needs to be installed, the functional modules can be accurately loaded according to the corresponding query addresses in the address directory. At the same time, by constructing the association relationship between the query addresses in the address directory, when there are multiple versions of the same functional module in the loading environment, the possibility of loading a non-required version of the functional module can be reduced, thereby improving the loading efficiency and accuracy of the functional module.

[0070] The functional module set mentioned above may include different versions of the same functional module.

[0071] In the related art, during the construction of its corresponding related address directory, only the types of functional modules are classified, and the version issue is not considered. Therefore, different versions of the same functional module will have the same functional module identifier in the directory. This processing method will result in the same query path for different versions of the functional module. If there are two target loaders at this time, namely the first target loader and the second target loader, both need to load the same functional module.

[0072] Among them, the first target loader is only compatible with the 1.0 version of the functional module, while the second target loader is only compatible with the 2.0 version of the functional module. Since the query paths corresponding to different versions of the functional module are the same, it will inevitably occur that the first target loader loads the 2.0 version of the functional module, while the second target loader loads the 1.0 version of the functional module. This loading method will cause application failures for the first target loader and the second target loader due to the incompatibility of the functional modules and cannot provide normal services.

[0073] In the embodiments of the present application, the functional modules are distinguished in terms of direct dependencies and indirect dependencies, so that when constructing an address directory for loading functional modules based on the dependency relationship, the query addresses of the loading party and the loaded party can accurately establish an association relationship in the address directory, and application failures caused by the mismatch between the functional module and the target loading party in the related art can be avoided. At the same time, in order to visually display the version of the functional module loaded by the loading party, a version identifier of the functional module can be added to the query address. Based on this, in a possible implementation, if the functional module set includes a target functional module of the first version and a target functional module of the second version, in the address directory, the query address of the target functional module of the first version carries the identifier of the first version, and the query address of the target functional module of the second version carries the identifier of the second version.

[0074] That is, when multiple versions of the same functional module appear in the functional module set at the same time, for different versions of the functional module, the corresponding version identifier is added to the query address. By adding the version identifier, the query addresses can be distinguished, and the version of the functional module loaded by the loading party can be visually determined. Taking the previous example as an example, the functional module to be loaded (i.e., the target functional module) includes version 1.0 and version 2.0. At this time, the identifier 1.0 needs to be added to the query path of the functional module to be loaded in version 1.0, and the identifier 2.0 needs to be added to the query path of the functional module to be loaded in version 2.0. By adding the identifier, the query paths of the two versions of the functional module to be loaded can be distinguished. Suppose the functional module to be loaded is the A functional module. Before adding the version identifier, the query path corresponding to the A functional module can be: "node_modules / .dependencies / A". After adding the version identifier, the query path corresponding to version 1.0 of the A functional module can be: "node_modules / .dependencies / A@1.0.0"; the query path corresponding to version 2.0 of the A functional module can be: "node_modules / .dependencies / A@2.0.0". When querying the functional module to be loaded, there will be no situation of loading the wrong version or the mismatch between the functional module to be loaded and the target loading party. At the same time, the version of the functional module to be loaded can be visually displayed, and the loading logic between the functional module to be loaded and the target loading party can be reflected.

[0075] By identifying different versions of the function module to be loaded in the query address, it is convenient to distinguish the function module to be loaded from the address level. When the target loader has a version requirement for the specified function module to be loaded, it is possible to accurately query the function module to be loaded according to the version identifier in the query path, and there will be no situation where the loaded function module to be loaded does not match the target loader and affects the normal operation of the target loader.

[0076] In the related art, when different target applications are running, it is necessary to complete the loading and installation of all function modules in the function module set in each target application. Since there may be overlapping function modules in different target applications, if complete function module installations are performed for each target application, a large number of repeated installations of function modules will occur. The repeated installation will generate a large number of redundant installation packages, resulting in the invalid occupation of the storage space of the target application. The reduction of the storage space will also affect the reading speed and running performance of the target application.

[0077] Based on this, to solve the problem that the repeated installation of function modules affects the operation of the target application, in a possible implementation, the function module set can be stored in the global storage space. The function modules in the global storage space can be loaded when different target applications are running.

[0078] Storing the function module set in the global storage space can be understood as completing the installation and storage of all function modules at the global storage space. When the target application needs to load a specified function module, it can directly read from the global storage space and use it, without the need to store the data file of the function module of the specified function in the address directory of the function module itself. For example, assume that target application A and target application B both depend on the lodash@1.0.0 version (lodash is a high-performance JavaScript utility library), and lodash@1.0.0 can be understood as the 1.0.0 version of lodash. Under the mechanism of the related art, when target application A and target application B are running, lodash@1.0.0 will be saved twice repeatedly (saved once in the address directory of target application A and once in the address directory of target application B), and due to the repeated saving, twice the storage space will be occupied. When the function module set is stored in the global storage space, lodash@1.0.0 will be installed once in the global directory. When target application A and target application B need to load the lodash module, they will read from the global storage space and do not need to perform two repeated saves in their respective address directories, so no redundant installation packages will be generated.

[0079] By installing the function modules in the global storage space as described above, the time for the target application to load the function modules can be shortened. At the same time, since all the function modules have been installed in the global storage space, when the target application needs to use a specific function module, it can directly load it from the global storage space without reinstallation, avoiding the occupation of the storage space of the target application by the redundancy of the installation package and improving the performance of the target application.

[0080] As mentioned above, all the function modules are installed in the global storage space. Then, when the target application needs to load a function module, it needs to load it from the global storage space. To achieve the smooth loading of the function module, the target application needs to establish a link with the global storage space. In a possible implementation, when the function module to be loaded is loaded through the module loading address, the module loading address is a soft link to the loading location, which is used to point to the storage location of the function module to be loaded in the global storage space.

[0081] A soft link (also called a symbolic link) is different from a hard link. As a special file type, the content it stores is the path name pointing to another file or directory address. In the embodiments of the present application, the soft link to the loading location can be regarded as a pointer, which is used to point to the storage location of the function module to be loaded in the global storage space, so that the loading content of the function module to be loaded can be accessed and loaded by multiple target applications.

[0082] In the embodiments of the present application, the soft link to the loading location plays a bridging role, which is used to establish the connection between the target application and the global storage space. When the target application needs to load the function module to be loaded, it needs to point to the storage location of the function module to be loaded in the global storage space according to the soft link to the loading location, and then obtain the specific content of the function module to be loaded.

[0083] By setting the soft link to the loading location, a certain storage location in the global storage space can be pointed to. When the target application obtains the soft link to the loading location, it can read the storage location corresponding to the soft link to the loading location in the global storage space, and then obtain the loading data of the function module to be loaded in the global storage space, and complete the loading of the function module to be loaded.

[0084] From the above discussion, it can be seen that when constructing the address directory of the function module set in the target application, an association relationship is established between the query addresses of the loading party and the loaded party. The expression methods of the association relationship can be specifically divided into two types. One is to represent the association relationship between the query addresses of the loading party and the loaded party through the parent-child relationship of the address hierarchy, and the other is to express the association relationship between the query addresses of the loading party and the loaded party through the soft link for directory jump.

[0085] First, the expression of the association relationship as a parent-child relationship at the address level will be explained.

[0086] The parent-child relationship of the address levels can be understood as an inclusion relationship between the various address levels. Each address level only contains the module loading addresses of the function modules in that address level. The module loading addresses of the function modules between different address levels are independent of each other. It is not possible to jump from the module loading address of a function module at a certain address level to the module loading address of a function module at another address level.

[0087] Figure 3 is a schematic diagram of an address directory of a parent-child relationship provided in an embodiment of the present application, such as Figure 3 As shown, assuming that the target loader at this time is the target application, the first function module and the second function module can be understood as function modules stored at the first address level in the address directory of the target application. The third function module can be understood as a function module stored at the second address level in the address directory of the target application, and the fourth and fifth function modules are analogous, which will not be repeated here. It can be seen from the figure that the first address level corresponding to the module loading address of the first function module and the second function module is the second address level corresponding to the third function module under the directory of the module loading address of the second function module. At this time, the first address level corresponding to the second function module is the parent address level of the second address level corresponding to the third function module, and the corresponding second address level corresponding to the third function module is the child address level of the first address level corresponding to the second function module.

[0088] When the expression of this association relationship is the parent-child relationship at the address level, the dependency relationship between the loader and the loaded party can also be expressed by the parent-child relationship in the address directory. The corresponding functional module in the parent address level may be the direct dependency of the loader or the indirect dependency of the loader. Figure 3 For example, assuming that the loader is the target application, then the first and second functional modules corresponding to the first address level as the parent address level are the direct dependencies of the target application. The third functional module in the second address level is the indirect dependency of the second functional module. At this time, the second address level is the parent address level of the third address level, and the functional modules contained in it are the indirect dependencies of the second functional module.

[0089] ​In a possible implementation, if the association relationship is a parent-child relationship at the address level, the specific process of "querying the function module to be loaded corresponding to the module loading request according to the target query address of the target loader in the address directory and the query address associated with the target query address, and performing the loading" mentioned in S204 may include: First, according to the module loading request, determine the target query address of the target loader in the address directory. Then, query the module loading address of the function module to be loaded from the query addresses associated with the target query address in the address directory. Finally, use the queried module loading address to load the function module to be loaded for the target loader.

[0090] Specifically, when a module loading request is obtained, the function module to be loaded can be determined according to the content in the request. When loading the function module to be loaded, first, the target query address of the target loader needs to be determined. The target loader can be the target application or a function module. After obtaining the target query address of the target loader, the module loading address of the function module to be loaded can be determined according to the parent-child relationship between each address level in the address directory. Then, according to the queried module loading address of the function module to be loaded, the function module to be loaded is loaded.

[0091] By establishing the parent-child relationship between address levels, it is possible to accurately lock the module loading address of the function module to be loaded according to the target query address of the target loader and in combination with the parent-child relationship between the target query address and the query addresses of each function module during the above-mentioned query process of the module loading address.

[0092] In a possible implementation, Figure 4 This is a schematic diagram of an address structure provided by an embodiment of the present application. As Figure 4 shown, assuming that the association relationship is a parent-child relationship at the address level, where the direct dependency set includes a first function module, and the indirect dependency set includes a second function module and a third function module. In the dependency relationship, the first function module is the loader of the second function module, and the second function module is the loader of the third function module. For the first function module, the second function module, and the third function module, the method for constructing the address directory at this time can be: Under the root directory of the function module in the address directory, create the query address of the first function module. Under the query address of the first function module, create the query address of the second function module. Under the query address of the second function module, create the query address of the third function module.

[0093] As mentioned above, in the dependency relationship, the first functional module is the loader of the second functional module, and the second functional module is the loader of the third functional module. It can be seen from this that the dependency relationship among the first functional module, the second functional module, and the third functional module is as follows: when the first functional module needs to be run, the second functional module needs to be loaded; when the second functional module needs to be run, the third functional module needs to be loaded. Corresponding to the address hierarchy structure, the address hierarchy where the query address corresponding to the loader is located should be the parent address hierarchy, and the address hierarchy where the query address corresponding to the loaded party is located should be the child address hierarchy. The manifestation of the parent-child address hierarchy relationship can be achieved by establishing the query addresses of the functional modules having a dependency relationship under the parent address hierarchy.

[0094] Figure 5 This is a schematic diagram of the address hierarchy structure of the parent-child relationship provided by the embodiment of the present application. As Figure 5 shown, Node_modules can be understood as the root directory. "bar@1.0.0 / / symlink to / store / bar@1.0.0" can be understood as the query address corresponding to the 1.0.0 version of the bar functional module, and "a@2.0.0 / / symlink to / store / a@2.0.0" can be understood as the query address corresponding to the 2.0.0 version of the a functional module. The remaining similar content in the figure is used to represent the query addresses of the corresponding functional modules and will not be elaborated here. Among them, both "bar@1.0.0 / / symlink to / store / bar@1.0.0" and "foo@1.0.0 / / symlink to / store / foo@1.0.0" belong to the first address hierarchy, and "a@2.0.0 / / symlink to / store / a@2.0.0" belongs to the second address hierarchy. The first address hierarchy is the parent address hierarchy of the second address hierarchy, and the second address hierarchy is the child address hierarchy of the first address hierarchy. By analogy, the third address hierarchy where "b@2.0.0 / / symlinkto / store / b@2.0.0" is located is the child address hierarchy of the aforementioned second address hierarchy, and the fourth address hierarchy where "c@2.0.0 / / symlink to / store / c@2.0.0" is located is the child address hierarchy of the aforementioned third address hierarchy.

[0095] Through the above address hierarchy construction method, the dependency relationship among each functional module can be clearly reflected. At the same time, when the target loader is determined, the location of the query address of the functional module to be loaded corresponding to the target loader can be quickly determined according to the parent-child relationship of the address hierarchy.

[0096] In the case where the expression of the association relationship mentioned above is the parent-child relationship of the address hierarchy, although it can successfully complete the query of the query address of the function module to be loaded when the target loader needs to load the function module to be loaded. However, when using this installation structure and the nesting relationship between each function module is complex, it may affect the loading speed due to the large nesting depth of the query address. Based on this, when the query address nesting relationship between function modules or between the loader and the loaded party is relatively complex, the method of expressing the association relationship between the query addresses of the loader and the loaded party by using directory jump soft links can be selected to achieve the fast query and loading of the function module to be loaded.

[0097] The following will illustrate the case of expressing the association relationship between the query addresses of the loader and the loaded party by using directory jump soft links.

[0098] The directory jump soft link can be understood as a directory jump pointer, and through the directory jump soft link, it is possible to achieve the jump of the query address of the function module at a certain address level to the query address of the function module at other address levels.

[0099] When using the directory jump soft link to express the association relationship between the loader and the loaded party, the method of constructing the address directory can be:

[0100] In the first directory level of the address directory, create the first query addresses corresponding to the function modules in the direct dependency set respectively, and in the second directory level of the address directory, create the second query addresses corresponding to the function modules in the direct dependency set and the function modules in the indirect dependency set respectively;

[0101] Among them, for the first function module in the direct dependency set, the first query address includes a first directory jump soft link, and the first directory jump soft link is used to point to the second query address of the first function module;

[0102] The second query address of the first function module includes the module loading address of the first function module and the second directory jump soft link of the second function module loaded at runtime;

[0103] The second directory jump soft link is used to point to the second query address of the second function module, and the second query address of the second function module includes the module loading address of the second function module.

[0104] In the method for constructing the above address directory, it involves the functional modules in the direct dependency set and the indirect dependency set of the target application. As can be seen from the above method, the first query address of the functional module directly dependent on the target application is created at the first directory level in the address directory; the second query address of the functional module indirectly or directly dependent on the target application is created at the second directory level in the address directory. The first query address may include a first directory jump soft link. When it is necessary to load the functional module to be loaded, through the first directory jump soft link in the first query address of the functional module to be loaded, it is possible to jump to the second query address of the corresponding functional module to be loaded and read the module loading address of the functional module to be loaded, thereby completing the loading of the functional module to be loaded. The aforementioned module loading address is used to point to the storage location of the corresponding functional module.

[0105] In addition to including the module loading address of the functional module to be loaded, the second query address of the functional module to be loaded may also include directory jump soft links of other functional modules. The reason is that the functional module to be loaded requires sub-functional modules (i.e., sub-dependencies) to support the normal operation of the functional module to be loaded during runtime. This sub-functional module is an indirect dependency of the functional module to be loaded. By setting the directory jump soft link of the sub-functional module in the second query address of the functional module to be loaded, it can be ensured that when the module to be loaded runs, it can jump to the second query address of the sub-functional module through this directory jump soft link and read the module loading address of the sub-functional module from this second query address, thereby completing the loading of the sub-functional module.

[0106] For example, assume that the first functional module is a direct dependency of the target loader, and the second functional module is an indirect dependency of the target loader. Figure 6 The figure shows a schematic diagram of an address directory structure including jump soft links provided by an embodiment of the present application, as Figure 6 shown. Under the root directory in the figure, there are two directory levels, namely the first directory level and the second directory level. Among them, the first directory level includes the first query address of the first functional module and a folder. All the content of the second directory level is included in this folder, that is, the second directory level in the address directory can be queried through this folder.

[0107] In the second directory level, it may include the second query address of the first functional module in the direct dependency set, or may include the second query address of the second functional module in the indirect dependency set. In the second query address of the first functional module, it may include the module loading address of the first functional module and the second directory jump soft link of the second functional module. Through the first directory jump soft link in the first query address, it can point to the second query address of the first functional module in the second directory level, obtain the module loading address of the first functional module from the second query address of the first functional module, and complete the loading of the first functional module. Through the second directory jump soft link of the second functional module in the second query address of the first functional module, it can point to the second query address of the second functional module in the second directory level, and obtain the module loading address of the second functional module to complete the loading of the second functional module.

[0108] Another exemplary example is that the foo functional module is a direct dependency of the target loader, the bar functional module is an indirect dependency of the target loader, and at the same time, the bar functional module is an indirect dependency of the foo functional module. It should be noted that the foo functional module and the bar functional module are not actual existing functional modules, and this is only an exemplary expression here. Figure 7 The following is a schematic diagram of an address directory structure including a jump soft link in an application scenario provided by an embodiment of the present application, as Figure 7 shown, "node_modules / .dependencies / foo@1.0.0 / node_modules" is the first query address of the foo functional module as a direct dependency. In the first query address, it includes the first directory jump soft link "node_modules / .dependencies / foo@1.0.0 / node_modules / foo", and the first directory jump soft link is used to point to the second query address of the foo functional module. ".dependencies" is a folder, and the next address level of this folder is the second directory level. In the second directory level, it includes the 1.0.0 version "foo@1.0.0" of the foo functional module and the 1.0.0 version "bar@1.0.0" of the bar functional module. Under the root directory "node_modules" indicated by the second query address of the foo functional module, it includes the module loading address " / store / foo" of the foo functional module and the second directory jump soft link "node_modules / .dependencies / / bar@1.0.0 / node_modules / bar" of the bar functional module. Through the second directory jump soft link of the bar functional module, it can point to the module loading address " / store / bar" of the bar functional module.

[0109] In a possible implementation, when the second functional module includes a third functional module loaded during runtime, the second query address of the second functional module further includes a third directory jump soft link of the third functional module. The third directory jump soft link is used to point to the second query address of the third functional module, and the second query address of the third functional module includes the module loading address of the third functional module.

[0110] For example, assume that the third functional module and the second functional module are indirect dependencies of the target loader. Figure 8 FIG. is a schematic diagram of an address directory structure including a jump soft link provided by an embodiment of the present application. As Figure 8 shown, the second directory level may include the second query address of the first functional module in the direct dependency set, or may include the second query address of the second functional module and the third query address of the third functional module in the indirect dependency set. The second query address of the second functional module may include the module loading address of the second functional module and the third directory jump soft link of the third functional module. Through the third directory jump soft link of the third functional module in the second query address of the second functional module, it can point to the second query address of the third functional module in the second directory level, and obtain the module loading address of the third functional module to complete the loading of the third functional module.

[0111] Another example, assume that the quz functional module is an indirect dependency of the target loader, the bar functional module is an indirect dependency of the target loader, and at the same time, the quz functional module is an indirect dependency of the bar functional module. It should be noted that the foo functional module, the bar functional module, and the quz functional module are not actual existing functional modules, and this is only an exemplary expression here. Figure 9 FIG. is a schematic diagram of an address directory structure including a jump soft link in another application scenario provided by an embodiment of the present application. As Figure 9As shown, "node_modules / .dependencies / bar@1.0.0 / node_modules" is the second query address of the bar functional module as an indirect dependency. The second query address includes the second directory jump soft link "node_modules / .dependencies / bar@1.0.0 / node_modules / bar", and the second directory jump soft link is used to point to the second query address of the bar functional module. ".dependencies" is a folder. At the next address level of this folder is the second directory level, and the second directory level includes the 2.0.0 version of the quz functional module "quz@2.0.0" and the 1.0.0 version of the bar functional module "bar@1.0.0". Under the root directory "node_modules" indicated by the second query address of the bar functional module, it includes the module loading address " / store / bar" of the bar functional module and the third directory jump soft link "node_modules / .dependencies / quz@2.0.0 / node_modules / quz" of the quz functional module. Through the third directory jump soft link of the quz functional module, it can point to the module loading address " / store / quz" of the quz functional module.

[0112] Through the above-mentioned method of constructing the address directory, the address directory is divided into two address levels. The query addresses corresponding to the functional modules in the direct dependency set are created in the first address level, and the second query addresses corresponding to the functional modules in the direct dependency set and the functional modules in the indirect dependency set are created in the second address level. When the query address nesting relationship between functional modules or between the loading party and the loaded party is relatively complex, the method of using directory jump soft links to express the association relationship between the query addresses of the loading party and the loaded party can reduce the nesting depth of the levels. Under the directories corresponding to each functional module in the two address levels, the method of using directory jump soft links to express the association relationship between the query addresses of the loading party and the loaded party can achieve the jump and acquisition of query addresses between different address levels and between the directories of different functional modules, and realizes the quick query and loading of the functional module to be loaded.

[0113] During the construction process of the address directory, it is necessary to divide the levels of the directory so that when querying the functional module to be loaded, it can be queried level by level according to the directory levels. Based on this, the embodiment of the present application provides a method for directory stratification. The specific method is as follows: The first directory level is under the root directory of the address directory for the functional module, and the second directory level is under the next-level directory of the root directory.

[0114] For example, Figure 10A schematic diagram of the directory hierarchy provided by the embodiments of the present application is as follows Figure 10 As shown, require('bar') is used to indicate that the current module loading request is to request the loading of the bar functional module. At this time, it is necessary to search layer by layer from top to bottom for the search path shown in the figure. Specifically, " / home / workspace / projects / node_modules / bar", where home is the upper-level directory of workspace, and workspace is the upper-level directory of projects. First, it is necessary to query the bar functional module from " / home / workspace / projects / node_modules / bar", that is, query the bar functional module from the root directory of projects. When the bar functional module does not exist in the root directory of projects, it is necessary to query the root directory of workspace. At this time, the corresponding query path is: " / home / workspace / node_modules / bar". And so on, when the bar functional module does not exist in the root directory of workspace, it is necessary to query the root directory of home until all address directories are queried or the bar functional module is found.

[0115] It can be understood that both the first directory level and the second directory level are relative concepts. Taking the previous example, assuming that the directory of workspace is the first directory level, then the directory of projects is the second directory level at this time; assuming that the directory of workspace is the second directory level, then the directory of home is the first directory level at this time.

[0116] Through the above settings of the directory hierarchy, the structure of the directory can follow the loading rules of Node.js and correctly load the functional modules in the global path. Node.js will first search for the functional module to be loaded in the node_modules folder of the current directory. If it cannot be found, it will recursively search in the node_modules folder of the upper-level directory. In this way, it is possible to query the module loading address of the module to be loaded layer by layer, without confusion in the query process, and to improve the efficiency of querying the functional module to be loaded to a certain extent.

[0117] The construction process of the address directory was introduced earlier. After the construction of the address directory is completed, it is necessary to use the address directory to query and load the loaded party by the loading party. The query and loading of specific functional modules can include the following two categories. One category is that the functional modules in the direct dependency set load the functional modules in the indirect dependency set, and the other is that the functional modules in the indirect dependency set load the functional modules in the indirect dependency set.

[0118] The loading process in which the functional modules in the direct dependency set load the functional modules in the indirect dependency set will be specifically introduced first below.

[0119] When the target loading party is the first functional module and the functional module to be loaded is the second functional module, the specific method for loading the functional module can be as follows: First, determine the first query address of the first functional module as the target query address according to the module loading request. Jump to the second query address of the first functional module according to the first directory jump soft link in the first query address of the first functional module. Then, jump to the second query address of the second functional module as the query address with an association relationship according to the second directory jump soft link in the second query address of the first functional module. Finally, load the second functional module for the first functional module from the module loading address of the second functional module included in the second query address of the second functional module.

[0120] The above-mentioned module loading request may include information such as the name of the corresponding functional module to be loaded. Below, Figure 7For example, a specific elaboration is as follows. Assume that the first functional module (the target loading party) is the foo functional module, and the second functional module (the functional module to be loaded) is the bar functional module. At this time, the module loading request is "require('bar') => node_modules / .dependencies / foo@1.0.0 / node_modules / bar". Through the module loading request, the first query address of the first functional module can be determined. node_modules is the root directory in this address directory. In the first directory level, it includes the first query address of the first functional module (the foo functional module). In the first query address, there is a first directory jump soft link "node_modules / .dependencies / foo@1.0.0 / node_modules / foo". Using the first directory jump soft link can jump to the second query address of the first functional module (the foo functional module) "node_modules / .dependencies / foo@1.0.0 / node_modules". In the second query address, it includes the module loading address of the first functional module (the foo functional module) " / store / foo" and the second directory jump soft link of the second functional module (the bar functional module) "node_modules / .dependencies / bar@1.0.0 / node_modules / bar". In the second directory jump soft link, it includes the second query address of the second functional module (the bar functional module) "node_modules / .dependencies / bar@1.0.0 / node_modules". In the second query address, it includes the module loading address of the second functional module " / store / bar".

[0121] Through the second directory jump soft link in the second query address of the first functional module, the jump of the query address can be realized. By setting the directory jump soft link, it can point to a certain storage location in the address directory. When the loading party obtains this directory jump soft link, it can read the storage location corresponding to this directory jump soft link in the address directory, and then obtain the loading data of the functional module to be loaded in the address directory, completing the loading of the functional module to be loaded.

[0122] Next, the loading process of loading the functional modules in the indirect dependency set by the functional modules in the indirect dependency set will be specifically introduced.

[0123] Suppose that both the second functional module and the third functional module are functional modules in the indirect dependency set. When the target loading party is the second functional module and the functional module to be loaded is the third functional module, the specific method for loading the functional module can be as follows: First, determine the second query address of the second functional module as the target query address according to the module loading request. Then, jump to the second query address of the third functional module as the query address with an associated relationship according to the third directory jump soft link in the second query address of the second functional module. Finally, load the third functional module for the second functional module from the module loading address of the third functional module included in the second query address of the third functional module.

[0124] The following Figure 9 is taken as an example for specific elaboration. Suppose the second functional module (target loading party) is the bar functional module, and the third functional module (functional module to be loaded) is the quz functional module. At this time, the module loading request is “require(‘quz’) => node_modules / .dependencies / bar@1.0.0 / node_modules / quz”. node_modules is the root directory in this address directory. In the first directory level, it includes the first query address of the first functional module (foo functional module) and the “.dependencies” folder. The second query address “node_modules / .dependencies / bar@1.0.0 / node_modules” of the second functional module (bar functional module) can be determined by using the module loading request. The module loading address “ / store / bar” of the second functional module (bar functional module) and the third directory jump soft link “node_modules / .dependencies / bar@1.0.0 / node_modules / quz” of the third functional module (quz functional module) are included in the second query address. The second query address “node_modules / .dependencies / quz@2.0.0 / node_modules” of the third functional module (quz functional module) is included in the third directory jump soft link, and the module loading address “ / store / quz” of the third functional module is included in the second query address.

[0125] The method for loading the functional module proposed above is mainly realized by using the directory jump soft link to express the association relationship between each address level. By setting the directory jump soft link of the loaded party under the directory of the loading party, the directory jump from the loading party to the module loading address under the directory of the loaded party is realized, and the functional module is loaded. Different types of dependent functional modules can be loaded through the above method.

[0126] Before constructing the address directory, it is also possible to first determine the versions of the functional modules that have an indirect dependency relationship with the party to be loaded. This can enable the party to be loaded to load the functional module with the optimal version adapted to it, avoiding redundant loading of functional modules. Based on this, an embodiment of the present application proposes a method for determining the version of a functional module, and the method is specifically as follows:

[0127] S1101: Determine the same functional modules with different versions in the indirect dependency set. The same functional modules include a to-be-determined functional module of the third version and a to-be-determined functional module of the fourth version. The dependent party of the to-be-determined functional module of the third version is the first dependent party, and the dependent party of the to-be-determined functional module of the fourth version is the second dependent party. The functional requirement of the first dependent party for the to-be-determined functional module of the third version is the first version range, and the functional requirement of the second dependent party for the to-be-determined functional module of the fourth version is the second version range.

[0128] The indirect dependency set may include different versions of the same functional module. Assume that the first dependent party is the A functional module, the second dependent party is the B functional module, and the to-be-determined functional module is the C functional module. Both the A functional module and the B functional module are dependent parties of the C functional module, but the A functional module has a dependency relationship with the 1.2.3 version (the third version) of the C functional module, and the B functional module has a dependency relationship with the 1.2.0 (the fourth version) of the C functional module. Exemplarily, the functional requirements of the A functional module and the B functional module for the C functional module (i.e., the first version range and the second version range) can be expressed in the following way (exemplarily):

[0129] ~1.2.3: => = 1.2.3, <1.3.0

[0130] ~1.2.0: => = 1.2.0, <1.3.0

[0131] ~1.0.0: => = 1.0.0, <2.0.0

[0132] ^1.2.3: => = 1.2.3, <2.0.0

[0133] ^1.2.0: => = 1.2.0, <2.0.0

[0134] ^1.0.0: => = 1.0.0, <2.0.0

[0135] Among them, "~1.2.3: => =1.2.3, <1.3.0" is used to indicate that the functional requirement of the dependent party for the to-be-determined function module is the to-be-determined function module of version 1.2.3. At this time, the version range of the to-be-determined function module that can meet the functional requirement is "> =1.2.3, <1.3.0". Similarly, "^1.2.0: => =1.2.0, <2.0.0" is used to indicate that the functional requirement of the dependent party for the to-be-determined function module is the to-be-determined function module of version 1.2.0. At this time, the version range of the to-be-determined function module that can meet the functional requirement is "> =1.2.0, <2.0.0".

[0136] For example, "~1.2.3: => =1.2.3, <1.3.0" is used to indicate that the functional requirement of Function Module A for Function Module C is that when Function Module C is of version 1.2.3 (the third version), it can meet the running requirement of Function Module A. At this time, loading any version from version 1.2.3 to version 1.2.9 (i.e., the first version range) of Function Module C can meet the requirements of Function Module A. "^1.2.3: => =1.2.3, <2.0.0" is used to indicate that the functional requirement of Function Module B for Function Module C is that when Function Module C is of version 1.2.0 (the fourth version), it can meet the running requirement of Function Module A. At this time, loading any version from version 1.2.0 to version 1.9.9 (i.e., the second version range) of Function Module C can meet the requirements of Function Module A.

[0137] S1102: In response to an overlapping range between the first version range and the second version range, determine a fifth version within the overlapping range, and in the indirect dependency set, replace the to-be-determined function module of the third version and the to-be-determined function module of the fourth version with the to-be-determined function module of the fifth version, and inherit the relevant dependency relationships;

[0138] When the functional requirement of the first dependent party for the to-be-determined function module of the third version is the first version range, and the functional requirement of the second dependent party for the to-be-determined function module of the fourth version is the second version range, if there is an overlapping range between the first version range and the second version range at this time, the largest version within the overlapping range can be selected and determined as the fifth version. Then, replace the function module of the third version on which the first dependent party depends, and the function module of the fourth version on which the second dependent party depends, with the to-be-loaded function module of the fifth version.

[0139] Continuing with the above example, assume that the functional requirement of functional module A for functional module C is "~1.2.3: => =1.2.3, <1.3.0", and the functional requirement of functional module B for functional module C is "^1.2.0: => =1.2.0, <2.0.0". At this time, it can be determined that the first version range corresponding to the functional requirement of the first dependent party (functional module A) for the undetermined functional module (functional module C) of the third version is "> =1.2.3, <1.3.0", and the second version range corresponding to the functional requirement of the second dependent party (functional module B) for the undetermined functional module (functional module C) of the third version is "> =1.2.0, <2.0.0". According to the first version range and the second version range, the overlapping range between the two can be determined as "> =1.2.3, <1.3.0". From the overlapping range, it can be determined that the maximum version of functional module C that functional module A and functional module B can both apply to is the C functional module of version 1.2.9 (i.e., the fifth version). At this time, the C functional module of version 1.2.9 can be used to replace the C functional module of version 1.2.3 to establish an indirect dependency with the first dependent party (functional module A), and the C functional module of version 1.2.9 can be used to replace the C functional module of version 1.2.0 to establish an indirect dependency with the second dependent party (functional module B).

[0140] S1103: In response to there being no overlapping range between the first version range and the second version range, retain the undetermined functional module of the third version and the undetermined functional module of the fourth version in the indirect dependency set.

[0141] When the functional requirement of the first dependent party for the undetermined functional module of the third version is the first version range, and the functional requirement of the second dependent party for the undetermined functional module of the fourth version is the second version range. At this time, if there is no overlapping relationship between the first version range and the second version range, then retain the undetermined functional module of the third version as the indirect dependency of the first dependent party, and retain the undetermined functional module of the fourth version as the indirect dependency of the second dependent party.

[0142] For example, assume that functional module A is the first dependent party, functional module B is the second dependent party, and functional module C is the undetermined functional module. Functional module A has a dependency relationship with the C functional module of version 1.1.0 (the third version), and functional module B has a dependency relationship with the C functional module of version 1.2.0 (the fourth version). The functional requirement of functional module A for the C functional module of version 1.1.0 is "~1.0.0:

[0143] " => >= 1.0.0, < 1.2.0" (the first version range), the functional requirement of the B functional module for the C functional module of version 1.2.0 is "~1.2.0: => >= 1.2.0, < 1.2.9" (the second version range). At this time, it can be seen that there is no overlapping part between the first version range and the second version range, which can also be understood as there is no intersection. At this time, it is necessary to continue to retain the C functional module of version 1.1.0 as an indirect dependency of the A functional module, and retain the C functional module of version 1.2.0 as an indirect dependency of the B functional module.

[0144] Through the above method for determining versions, when there are multiple dependent parties that have indirect dependency relationships with different versions of the same functional module (pending functional module), it is possible to determine the corresponding version of the pending functional module that can meet the running requirements of multiple requesters according to the functional requirements of the dependent parties for the pending functional module. In this way, the loading of different versions of the pending functional module can be reduced, thereby saving storage space while meeting the working running requirements of different dependent parties at the same time.

[0145] Figure 11 It is a flowchart of a method for dependency loading provided by an embodiment of the present application, as Figure 11 shown. In a possible implementation manner, the method specifically includes:

[0146] S1: Start installation.

[0147] When the target application needs to run, dependency installation needs to be performed.

[0148] S2: Dependency classification.

[0149] When starting dependency installation, first, the functional modules to be loaded need to be classified according to dependencies, which can be specifically divided into direct dependencies and indirect dependencies.

[0150] S3: Detect whether there is global storage.

[0151] In the set of directly dependent functional modules, each functional module needs to be detected to determine whether the functional module in this set has a global cache. That is, it is determined whether the functional module has been cached in the global directory.

[0152] S4: Install to the first directory level.

[0153] The corresponding query address of the directly dependent functional module needs to be installed in the first directory level of the address directory.

[0154] S5: Establish a soft link for the first directory to jump to the.dependencies directory.

[0155] After the installation of the corresponding query addresses of the directly dependent functional modules is completed, create a first directory jump soft link and link it to the.dependencies directory.

[0156] S6: Preprocess and determine the pending functional modules with the maximum version.

[0157] For the functional modules in the indirect dependency set, first, it is necessary to preprocess according to the functional requirements of the indirect dependencies for the loading party and determine the pending functional modules with the maximum version among them. Establish an indirect dependency between the pending functional modules with the maximum version and the loading party, and remove the pending functional modules of other versions in the indirect dependency set.

[0158] S7: Create a.dependencies directory.

[0159] Create a.dependencies directory for the remaining functional modules.

[0160] S8: Flatten all directories of indirect dependencies.

[0161] Flatten all directories of indirect dependencies to the.dependencies directory.

[0162] S9: Create directory jump soft links for indirect dependencies.

[0163] Finally, create directory jump soft links for indirect dependencies. In this way, the association relationship between each dependent party and the dependent party can be determined through dependency classification. At the same time, through the directory jump soft links, the jump of each functional module directory can be realized at different address levels of the address directory, and the query of the module loading address of the functional module to be loaded can be performed, and finally the loading of the functional module to be loaded can be completed.

[0164] In the foregoing Figure 1-11 on the basis of the corresponding embodiments Figure 12 FIG. is a schematic diagram of a data processing device provided by an embodiment of the present application. The data processing device 1200 includes an acquisition module 1201, a division module 1202, a construction module 1203, and a query module 1204;

[0165] The acquisition module is used to acquire the set of functional modules to be loaded during the operation of the target application and the dependency relationship, and the dependency relationship is used to identify the relationship between the functional modules in the functional module set and the loading party of the functional module;

[0166] The division module is configured to divide the set of functional modules into a direct-dependency set and an indirect-dependency set according to the dependency relationship. The functional modules in the direct-dependency set are the functional modules loaded when the target application runs as a loading party, and the functional modules in the indirect-dependency set are the functional modules loaded when any functional module in the set of functional modules runs as a loading party;

[0167] The construction module is configured to construct an address directory of the set of functional modules in the target application according to the direct-dependency set and the indirect-dependency set. The address directory is used to identify the query addresses of the loading parties when the functional modules in the set of functional modules are to be loaded. In the address directory, an association relationship is established between the query addresses of the functional modules with the dependency relationship through address levels;

[0168] The query module is configured to, when obtaining a module loading request of a target loading party during the running of the target application, query and load the functional module to be loaded corresponding to the module loading request according to the target query address of the target loading party in the address directory and the query addresses associated with the target query address;

[0169] In a possible implementation manner, the association relationship is a parent-child relationship of address levels, and the query module is configured to:

[0170] Determine the target query address of the target loading party in the address directory according to the module loading request;

[0171] Query the module loading address of the functional module to be loaded from the query addresses associated with the target query address in the address directory;

[0172] Load the functional module to be loaded for the target loading party from the obtained module loading address;

[0173] In a possible implementation manner, the association relationship is a parent-child relationship of address levels. The direct-dependency set includes a first functional module, and the indirect-dependency set includes a second functional module and a third functional module. In the dependency relationship, the first functional module is the loading party of the second functional module, and the second functional module is the loading party of the third functional module. For the first functional module, the second functional module, and the third functional module, the construction module is configured to:

[0174] Create a query address of the first functional module under the root directory of the functional module in the address directory, create a query address of the second functional module under the query address of the first functional module, and create a query address of the third functional module under the query address of the second functional module;

[0175] In a possible implementation, the building module is used for:

[0176] At the first directory level in the address directory, create first query addresses respectively corresponding to the functional modules in the direct dependency set, and at the second directory level in the address directory, create second query addresses respectively corresponding to the functional modules in the direct dependency set and the functional modules in the indirect dependency set;

[0177] Wherein, for the first functional module in the direct dependency set, the first query address includes a first directory jump soft link, and the first directory jump soft link is used to point to the second query address of the first functional module;

[0178] The second query address of the first functional module includes the module loading address of the first functional module and a second directory jump soft link of the second functional module loaded at runtime;

[0179] The second directory jump soft link is used to point to the second query address of the second functional module, and the second query address of the second functional module includes the module loading address of the second functional module;

[0180] When the second functional module includes a third functional module loaded at runtime, the second query address of the second functional module further includes a third directory jump soft link of the third functional module, the third directory jump soft link is used to point to the second query address of the third functional module, and the second query address of the third functional module includes the module loading address of the third functional module;

[0181] The module loading address is used to point to the storage location of the corresponding functional module.

[0182] In a possible implementation, the device is used for: placing the first directory level under the root directory of the address directory for the functional module, and placing the second directory level under the sub-directory of the root directory.

[0183] In a possible implementation, when the target loader is the first functional module and the functional module to be loaded is the second functional module, the query module is used for:

[0184] Determine the first query address of the first functional module as the target query address according to the module loading request;

[0185] Jump to the second query address of the first functional module according to the first directory jump soft link in the first query address of the first functional module;

[0186] Jump to the second query address of the second functional module as the query address with an associated relationship according to the second directory jump soft link in the second query address of the first functional module;

[0187] Load the second functional module for the first functional module from the module loading address of the second functional module included in the second query address of the second functional module.

[0188] In a possible implementation manner, when the target loading party is the second functional module and the functional module to be loaded is the third functional module, the query module is used for:

[0189] Determine the second query address of the second functional module as the target query address according to the module loading request;

[0190] Jump to the second query address of the third functional module as the query address with an associated relationship according to the third directory jump soft link in the second query address of the second functional module;

[0191] Load the third functional module for the second functional module from the module loading address of the third functional module included in the second query address of the third functional module.

[0192] In a possible implementation manner, the device is used for:

[0193] The functional module set includes a target functional module of a first version and a target functional module of a second version. In the address directory, the query address of the target functional module of the first version carries the identifier of the first version, and the query address of the target functional module of the second version carries the identifier of the second version.

[0194] In a possible implementation manner, the device is used for:

[0195] Store the functional module set in the global storage space, and the functional modules in the global storage space are used to be loaded when different target applications are running.

[0196] In a possible implementation manner, the device is used for:

[0197] When the functional module to be loaded is loaded through the module loading address, the module loading address is a loading position soft link for pointing to the storage position of the functional module to be loaded in the global storage space.

[0198] In a possible implementation manner, the device is used for:

[0199] Identify the same functional modules of different versions in the indirect dependency set. The same functional modules include the to-be-determined functional module of the third version and the to-be-determined functional module of the fourth version. The dependent party of the to-be-determined functional module of the third version is the first dependent party, and the dependent party of the to-be-determined functional module of the fourth version is the second dependent party. The functional requirement of the first dependent party for the to-be-determined functional module of the third version is the first version range, and the functional requirement of the second dependent party for the to-be-determined functional module of the fourth version is the second version range;

[0200] In response to an overlapping range between the first version range and the second version range, determine a fifth version within the overlapping range, and in the indirect dependency set, replace the to-be-determined functional module of the third version and the to-be-determined functional module of the fourth version with the to-be-determined functional module of the fifth version, and inherit the relevant dependency relationships;

[0201] In response to no overlapping range between the first version range and the second version range, retain the to-be-determined functional module of the third version and the to-be-determined functional module of the fourth version in the indirect dependency set.

[0202] Through a data processing device provided above, for a target application that needs to load functional modules to provide correct services, first use the acquisition module to acquire the set of functional modules and dependency relationships that the target application needs to load during operation. Then use the partitioning module to partition the set of functional modules to be loaded into a direct dependency set and an indirect dependency set. Among them, the functional modules in the direct dependency set are the functional modules loaded when the target application runs as a loading party, and the functional modules in the indirect dependency set are the functional modules loaded when any functional module in the set of functional modules runs as a loading party. By distinguishing functional modules from the dimensions of direct and indirect dependencies, when the construction module constructs an address directory for loading functional modules based on the dependency relationships, the query addresses of the loading party and the loaded party can accurately establish an association relationship in the address directory. Thus, when the loading party needs to load a functional module, the query module can accurately load the required functional module in the address directory based on the association relationship, and will not load other functional modules that do not have a dependency relationship with itself. When there are multiple versions of the same functional module in the loading environment, the possibility of loading a non-required version of the functional module is reduced, thereby greatly improving the loading efficiency and accuracy of the functional module through the address directory indicating the association relationship.

[0203] It should be noted that in the embodiments of the present application, the "first", "second", "third", and "fourth" mentioned are only for distinguishing nouns such as address levels, query addresses, functional modules, and directory levels, and do not have meanings such as priority, sequence, and importance.

[0204] The embodiments of the present application also provide a computer device, which is the computer device introduced above and may include a terminal device or a server. The foregoing data processing device may be configured in the computer device. The computer device will be introduced below with reference to the accompanying drawings.

[0205] If the computer device is a terminal device, please refer to Figure 13 As shown, the embodiments of the present application provide a terminal device. Taking the terminal device as a mobile phone as an example:

[0206] Figure 13 Shown is a block diagram of a part of the structure of a mobile phone related to the terminal device provided by the embodiments of the present application. Refer to Figure 13 , the mobile phone includes: a Radio Frequency (RF) circuit 1410, a memory 1420, an input unit 1430, a display unit 1440, a sensor 1450, an audio circuit 1460, a Wireless Fidelity (WiFi) module 1470, a processor 1480, and a power supply 1490, etc. Those skilled in the art can understand that Figure 13 the structure of the mobile phone shown in

[0207] does not constitute a limitation on the mobile phone and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Figure 13 The following will specifically introduce each component of the mobile phone in combination with

[0208] The RF circuit 1410 can be used for receiving and sending signals during information reception or call processes. Specifically, after receiving the downlink information from the base station, it is given to the processor 1480 for processing; in addition, the designed uplink data is sent to the base station.

[0209] The memory 1420 can be used to store software programs and modules. The processor 1480 executes various functional applications and data processing of the mobile phone by running the software programs and modules stored in the memory 1420. The memory 1420 may mainly include a program storage area and a data storage area. Among them, the program storage area can store an operating system, applications required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the mobile phone (such as audio data, phone book, etc.). In addition, the memory 1420 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0210] The input unit 1430 can be used to receive input digital or character information and generate key signal inputs related to the user settings and function controls of the mobile phone. Specifically, the input unit 1430 can include a touch panel 1431 and other input devices 1432.

[0211] The display unit 1440 can be used to display information input by the user or information provided to the user and various menus of the mobile phone. The display unit 1440 can include a display panel 1441.

[0212] The mobile phone may further include at least one sensor 1450, such as a light sensor, a motion sensor, and other sensors.

[0213] The audio circuit 1460, the speaker 1461, and the microphone 1462 can provide an audio interface between the user and the mobile phone.

[0214] WiFi belongs to short - range wireless transmission technology. The mobile phone can help users send and receive emails, browse the web, and access streaming media, etc. through the WiFi module 1470, which provides users with wireless broadband Internet access.

[0215] The processor 1480 is the control center of the mobile phone, connecting various parts of the entire mobile phone using various interfaces and circuits. By running or executing software programs and / or modules stored in the memory 1420, and by calling data stored in the memory 1420, it performs various functions of the mobile phone and processes data.

[0216] The mobile phone also includes a power supply 1490 (such as a battery) for powering each component.

[0217] In this embodiment, the processor 1480 included in the terminal device further has the following functions:

[0218] Obtain the set of function modules to be loaded during the operation of the target application and the dependency relationships, where the dependency relationships are used to identify the relationships between the function modules in the set of function modules and the loading parties of the function modules;

[0219] According to the dependency relationships, divide the set of function modules into a direct dependency set and an indirect dependency set. The function modules in the direct dependency set are the function modules loaded when the target application runs as a loading party, and the function modules in the indirect dependency set are the function modules loaded when any function module in the set of function modules runs as a loading party;

[0220] Construct an address directory of the function module set in the target application according to the direct dependency set and the indirect dependency set. The address directory is used to identify the query addresses of the loaders when the function modules in the function module set are to be loaded. In the address directory, the query addresses of the function modules with the dependency relationship are associated through address levels;

[0221] When a module loading request of a target loader is obtained during the running of the target application, query the function module to be loaded corresponding to the module loading request and load it according to the target query address of the target loader in the address directory and the query addresses associated with the target query address. If the computer device is a server, an embodiment of the present application further provides a server. Please refer to Figure 14 shown Figure 14 is a structural diagram of the server 1500 provided by an embodiment of the present application. The server 1500 may vary greatly due to configuration or performance differences, and may include one or more central processing units (Central Processing Units, abbreviated as CPUs) 1522 (for example, one or more processors) and a memory 1532, and one or more storage media 1530 for storing application programs 1542 or data 1544 (for example, one or more mass storage devices). Among them, the memory 1532 and the storage media 1530 may be transient storage or persistent storage. The program stored in the storage media 1530 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the server. Further, the central processing unit 1522 may be configured to communicate with the storage media 1530 and execute a series of instruction operations in the storage media 1530 on the server 1500.

[0222] The server 1500 may further include one or more power supplies 1526, one or more wired or wireless network interfaces 1550, one or more input / output interfaces 1558, and / or, one or more operating systems 1541, such as Windows Server TM , Mac OS X TM , Unix TM , Linux TM , FreeBSD TM and so on.

[0223] The steps performed by the server in the above embodiments may be based on Figure 14 the server structure shown.

[0224] In addition, an embodiment of the present application further provides a storage medium for storing a computer program for executing the method provided in the above embodiment.

[0225] An embodiment of the present application further provides a computer program product including a computer program, which, when running on a computer device, causes the computer device to execute the method provided in the above embodiment.

[0226] Those of ordinary skill in the art can understand that all or part of the steps for implementing the above method embodiments can be completed by hardware related to program instructions. The foregoing program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps including the above method embodiments; and the foregoing storage medium can be at least one of the following media: read-only memory (abbreviation: ROM), RAM, magnetic disk, or optical disc, etc., which can store computer programs.

[0227] In the embodiments of the present application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other related parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an overall module or unit including the function of the module or unit.

[0228] It should be noted that the embodiments in this specification are all described in a progressive manner. The same or similar parts among the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiments. The device and system embodiments described above are only illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art can understand and implement it without creative work.

[0229] As described above, it is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed by the present application should be covered within the protection scope of the present application. Moreover, based on the implementation manners provided in the above aspects of the present application, further combinations can be made to provide more implementation manners. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A data processing method, characterized in that: The method comprises: Obtaining a set of function modules that need to be loaded during the operation of the target application and dependency relationships, wherein the dependency relationships are used to identify the relationships between the function modules in the set of function modules and the loaders of the function modules; Dividing the function module set into a direct dependency set and an indirect dependency set according to the dependency relationship, the function modules in the direct dependency set are function modules loaded when the target application is used as a loader, and the function modules in the indirect dependency set are function modules loaded when any function module in the function module set is used as a loader; According to the direct dependency set and the indirect dependency set, an address directory of the function module set in the target application is constructed, the address directory is used to identify the query address of the loader when the function module in the function module set is to be loaded, and in the address directory, the query addresses of the function modules with the dependency relationship are associated with each other through the address hierarchy; When a module loading request of a target loader is obtained during the running of the target application, the functional module to be loaded corresponding to the module loading request is queried and loaded according to the target query address of the target loader in the address directory and the query address associated with the target query address.

2. The method according to claim 1, characterized in that The association relationship is a parent-child relationship at the address level, and querying and loading the to-be-loaded function module corresponding to the module loading request according to the target query address of the target loader in the address directory and the query address associated with the target query address, including: Determining the target query address of the target loader in the address directory according to the module loading request; Querying the module loading address of the to-be-loaded functional module from the query addresses associated with the target query address in the address directory; The module loading address obtained from the query is used to load the function module to be loaded for the target loader.

3. The method according to claim 1, characterized in that: The association relationship is a parent-child relationship at the address level, the direct dependency set includes a first functional module, the indirect dependency set includes a second functional module and a third functional module, in the dependency relationship, the first functional module is a loader of the second functional module, the second functional module is a loader of the third functional module, and for the first functional module, the second functional module and the third functional module, constructing an address directory of the functional module set in the target application according to the direct dependency set and the indirect dependency set includes: In the root directory of the function module in the address directory, a query address of the first function module is created, under the query address of the first function module, a query address of the second function module is created, and under the query address of the second function module, a query address of the third function module is created.

4. The method according to claim 1, characterized in that: The step of constructing an address directory of the function module set in the target application according to the direct dependency set and the indirect dependency set includes: In the first directory level of the address directory, first query addresses corresponding to the functional modules in the direct dependency set are created, and in the second directory level of the address directory, second query addresses corresponding to the functional modules in the direct dependency set and the functional modules in the indirect dependency set are created; Wherein, for the first functional module in the direct dependency set, the first query address includes a first directory jump soft link, and the first directory jump soft link is used to point to the second query address of the first functional module; The second query address of the first functional module includes the module loading address of the first functional module and the second directory jump soft link of the second functional module loaded at runtime; The second directory jump soft link is used to point to the second query address of the second functional module, and the second query address of the second functional module includes the module loading address of the second functional module; When the second function module includes a third function module loaded at runtime, the second query address of the second function module also includes a third directory jump soft link of the third function module, the third directory jump soft link is used to point to the second query address of the third function module, and the second query address of the third function module includes a module loading address of the third function module; The module loading address is used to point to the storage location of the corresponding functional module.

5. The method according to claim 4, characterized in that The first directory level is located under a root directory for a functional module in the address directory, and the second directory level is located under a directory at a level below the root directory.

6. The method according to claim 4, characterized in that When the target loader is the first functional module and the functional module to be loaded is the second functional module, querying and loading the functional module to be loaded corresponding to the module loading request according to the target query address of the target loader in the address directory and the query address associated with the target query address, comprises: According to the module loading request, determining a first query address of the first functional module as the target query address; Jump to the second query address of the first functional module according to the first directory jump soft link in the first query address of the first functional module; According to the second directory jump soft link in the second query address of the first functional module, jump to the second query address of the second functional module as the query address with the association relationship; The second functional module is loaded for the first functional module from the module loading address of the second functional module included in the second query address of the second functional module.

7. The method according to claim 4, characterized in that When the target loader is the second functional module and the functional module to be loaded is the third functional module, querying and loading the functional module to be loaded corresponding to the module loading request according to the target query address of the target loader in the address directory and the query address associated with the target query address includes: According to the module loading request, determining a second query address of the second functional module as the target query address; According to the third directory jump soft link in the second query address of the second functional module, jump to the second query address of the third functional module as the query address with the associated relationship; The third functional module is loaded for the second functional module from the module loading address of the third functional module included in the second query address of the third functional module.

8. The method according to claim 1, characterized in that The function module set includes a target function module of a first version and a target function module of a second version. In the address directory, the query address of the target function module of the first version carries an identifier of the first version, and the query address of the target function module of the second version carries an identifier of the second version.

9. The method according to any one of claims 1 to 8, characterized in that: The method further comprises: The function module set is stored in a global storage space, and the function modules in the global storage space are used to be loaded when different target applications are running.

10. The method according to claim 9, characterized in that When the function module to be loaded is loaded through the module loading address, the module loading address is a loading position soft link, which is used to point to the storage position of the function module to be loaded in the global storage space.

11. The method according to any one of claims 1 to 8, characterized in that: Before constructing the address directory of the function module set in the target application according to the direct dependency set and the indirect dependency set, the method further includes: Determine the same functional modules of different versions in the indirect dependency set, the same functional modules include a pending functional module of a third version and a pending functional module of a fourth version, the dependent party of the pending functional module of the third version is a first dependent party, the dependent party of the pending functional module of the fourth version is a second dependent party, the functional requirement of the first dependent party for the pending functional module of the third version is within a first version range, and the functional requirement of the second dependent party for the pending functional module of the fourth version is within a second version range; In response to the first version range and the second version range having an overlapping range, determining a fifth version within the overlapping range, and replacing the third version's pending function module and the fourth version's pending function module with the fifth version's pending function module in the indirect dependency set, and inheriting related dependency relationships; In response to the first version range and the second version range not having an overlapping range, the pending functional modules of the third version and the pending functional modules of the fourth version are retained in the indirect dependency set.

12. A data processing device, characterized in that: The device comprises: an acquisition module, a division module, a construction module and a query module; The acquisition module is used to acquire a set of function modules that need to be loaded during the operation of the target application and a dependency relationship, wherein the dependency relationship is used to identify the relationship between the function modules in the set of function modules and the loaders of the function modules; The division module is used to divide the function module set into a direct dependency set and an indirect dependency set according to the dependency relationship, the function modules in the direct dependency set are function modules loaded when the target application is run as a loader, and the function modules in the indirect dependency set are function modules loaded when any function module in the function module set is run as a loader; The construction module is used to construct an address directory of the function module set in the target application according to the direct dependency set and the indirect dependency set, wherein the address directory is used to identify the query address of the loader when the function modules in the function module set are to be loaded, and in the address directory, the query addresses of the function modules having the dependency relationship have an association relationship at the address level; The query module is used to obtain a module loading request from a target loader during the running of the target application, and query and load the function module to be loaded corresponding to the module loading request according to the target query address of the target loader in the address directory and the query address associated with the target query address.

13. A computer device, characterized in that: The computer device comprises a processor and a memory: The memory is used to store a computer program and transmit the computer program to the processor; The processor is configured to execute the method according to any one of claims 1 to 11 according to the computer program.

14. A computer-readable storage medium, characterized in that: The computer-readable storage medium is used to store a computer program, and when the computer program is executed by a computer device, the method according to any one of claims 1 to 11 is implemented.

15. A computer program product comprising a computer program, which, when executed on a computer device, causes the computer device to execute the method according to any one of claims 1 to 11.

Images