Sub-application version unification method and device, equipment and storage medium

Abstract

The invention discloses a sub-application version unification method and device, equipment and a storage medium, and the method comprises the steps: for each sub-application, generating a standardized dependency descriptor corresponding to the sub-application in the construction process of the sub-application; when each sub-application is loaded, constructing a target dependency version topological graph corresponding to all the sub-applications according to the standardized dependency descriptors; calculating the compatibility between each sub-application and the corresponding version in the target dependency version topological graph; generating a candidate shared version set corresponding to the sub-application based on the target dependency version topological graph; and based on the compatibility, selecting a target shared version from the candidate version set as a unified version of each sub-application. According to the method, the most suitable version is selected as the target shared version to serve as the unified version of the sub-applications, so that the compatibility problem caused by the fact that the sub-applications depend on different versions in the prior art is solved, and the stability of the applications is ensured.

Description

Technical Field

[0001] This application relates to the field of version unification technology, specifically to a method, apparatus, device, and storage medium for unifying sub-application versions. Background Technology

[0002] Today, front-end architecture, as a technical solution that decomposes a monolithic application into multiple independent, writable sub-applications, has been widely used in recent years. This architecture allows multiple teams to independently develop and deploy the sub-applications they are responsible for, thereby improving development efficiency and system maintainability. In front-end practice, technologies such as module federation make it possible for sub-applications to share code resources, which can reduce the number of duplicate dependency libraries that the user's browser needs to load and optimize application performance.

[0003] However, in this decentralized development model, each sub-application will inevitably depend on different versions of the same third-party library. Differences between different versions can easily lead to incompatibility issues and affect the stability of the application. Summary of the Invention

[0004] In view of this, this application provides a method, apparatus, device, and storage medium for unifying sub-application versions, which solves the problem that sub-applications inevitably depend on different versions of the same third-party library, and the differences between different versions can easily cause incompatibility and other problems, affecting the stability of the application.

[0005] To achieve the above objectives, the following solution is proposed:

[0006] Firstly, a method for unifying sub-application versions includes:

[0007] For each sub-application, a standardized dependency descriptor corresponding to that sub-application is generated during the sub-application's build process;

[0008] When each of the sub-applications is loaded, a target dependency version topology graph corresponding to all sub-applications is constructed based on the standardized dependency descriptor.

[0009] Calculate the compatibility between each sub-application and its corresponding version in the target dependency version topology graph;

[0010] Based on the target dependency version topology graph, generate a set of candidate shared versions corresponding to the sub-application;

[0011] Based on the compatibility, a target shared version is selected from the candidate version set as the unified version for each of the sub-applications.

[0012] Preferably, the step of generating a standardized dependency descriptor corresponding to the sub-application during the sub-application construction process includes:

[0013] During the construction of this sub-application, obtain the metadata of each dependency;

[0014] Create an empty data structure with fixed fields;

[0015] Analyze the relationships between the metadata entries.

[0016] Bind each of the aforementioned dependency metadata entries according to the aforementioned relationship to obtain the bound data and each of the aforementioned dependency metadata entries;

[0017] The binding data and each of the dependency metadata entries are added to the data structure to obtain a standardized dependency descriptor.

[0018] Preferably, obtaining each dependency metadata item includes:

[0019] When a module of the subapplication is marked as needing to be exposed, determine the source code of the module and the semantic version range corresponding to the module;

[0020] Identify the dependencies imported by this module from the source code.

[0021] Obtain the identity identifier corresponding to this module;

[0022] The dependencies and identifiers of each module marked as needing exposure are aggregated to obtain the first dataset;

[0023] Determine the semantic version range and dependency types declared by the sub-application during construction;

[0024] The first dataset, semantic version range, and dependency type are all used as the dependency metadata.

[0025] Preferably, the step of constructing a target dependency version topology graph corresponding to all sub-applications based on the standardized dependency descriptor includes:

[0026] For each sub-application, when the sub-application is loaded, the dependency version corresponding to the sub-application and the usage relationship between the sub-application and the dependency version are determined according to the standardized dependency descriptor.

[0027] Update the dependency versions and usage relationships to the pre-built initial dependency version topology graph;

[0028] The target dependency version topology map is obtained when all the dependency versions and usage relationships of the sub-applications are updated to the initial dependency version topology map.

[0029] Preferably, calculating the compatibility between each sub-application and its corresponding version in the target dependency version topology graph includes:

[0030] Get the version range expected by the sub-application;

[0031] Identify all existing actual versions in the target version topology graph;

[0032] The compatibility of the version range with each of the actual versions is calculated to obtain the compatibility degree.

[0033] Preferably, generating a set of candidate shared versions corresponding to the sub-application based on the target dependency version topology graph includes:

[0034] Identify the third-party libraries corresponding to each of the aforementioned sub-applications;

[0035] In the target version topology graph, the dependency versions related to the third-party library are determined to form a candidate version set;

[0036] Based on the compatibility, a graph traversal is performed on the candidate version set to obtain each compatibility subgraph;

[0037] Determine the number of sub-applications covered in each of the aforementioned compatibility sub-graphs;

[0038] The compatibility subgraph with the largest number of elements is selected as the target subgraph.

[0039] Each candidate version within the target subgraph is scored.

[0040] Preferably, scoring each candidate version within the target subgraph includes:

[0041] For each candidate version, count the number of sub-applications that directly use that candidate version;

[0042] Determine the number of patches required for this candidate version;

[0043] Determine whether the candidate version has been released; if so, assign it a preset first score.

[0044] If not, then obtain the current time and the release time of the candidate version;

[0045] Calculate the time difference between the current time and the publication time, and assign a first score based on the time difference;

[0046] Calculate the volume value of the candidate version and assign a second score based on the volume value;

[0047] Configure weighting coefficients for the number of sub-applications, the number of patches, the first score, and the second score, respectively;

[0048] According to the weighting coefficients, the number of sub-applications, the number of patches, the first score and the second score are weighted and summed to obtain the comprehensive score of the candidate version;

[0049] The candidate version with the highest overall score is selected as the target shared version.

[0050] Secondly, a sub-application version unification device includes:

[0051] The standardized dependency descriptor generation module is used to generate a standardized dependency descriptor corresponding to each sub-application during the sub-application's construction process.

[0052] The topology graph construction module is used to construct a target dependency version topology graph corresponding to all sub-applications based on the standardized dependency descriptors when each of the sub-applications is loaded.

[0053] The compatibility calculation module is used to calculate the compatibility between each sub-application and its corresponding version in the target dependency version topology graph;

[0054] The candidate shared version set generation module is used to generate a candidate shared version set corresponding to the sub-application based on the target dependency version topology graph.

[0055] The target shared version determination module is used to select a target shared version from the candidate version set as the unified version for each of the sub-applications based on the compatibility.

[0056] Thirdly, a sub-application version unified device, including memory and processor;

[0057] The memory is used to store programs;

[0058] The processor is configured to execute the program to implement the steps of the sub-application version unification method as described in any of the first aspects.

[0059] Fourthly, a storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the sub-application version unification method as described in any of the first aspects.

[0060] As can be seen from the above technical solution, this application generates a standardized dependency descriptor corresponding to each sub-application during the sub-application construction process; when each sub-application is loaded, a target dependency version topology graph corresponding to all sub-applications is constructed based on the standardized dependency descriptor; the compatibility degree between each sub-application and its corresponding version in the target dependency version topology graph is calculated; a candidate shared version set corresponding to the sub-application is generated based on the target dependency version topology graph; and a target shared version is selected from the candidate version set as the unified version for all sub-applications based on the compatibility degree. This application first generates a standardized dependency descriptor, which can be applied to the dependency version topology graph construction process during sub-application loading. It can clearly represent the dependency relationships corresponding to sub-applications. By calculating the compatibility degree between sub-applications and their dependent versions, it can accurately identify which sub-applications can safely switch versions and which pose a risk. This is a key step in avoiding runtime crashes and ensuring system stability. Then, based on the compatibility degree, the most suitable version is selected from the candidate version set as the target shared version, serving as the unified version for all sub-applications. This solves the compatibility problem caused by sub-applications depending on different versions in the prior art and ensures application stability. Attached Figure Description

[0061] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0062] Figure 1 An optional flowchart of a sub-application version unification method provided in an embodiment of this application;

[0063] Figure 2 A schematic diagram of the structure of a sub-application version unification device provided in an embodiment of this application;

[0064] Figure 3 This is a schematic diagram of the structure of a sub-application version unified device provided in an embodiment of this application. Detailed Implementation

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

[0066] This invention can be used in a wide variety of general-purpose or special-purpose computing device environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, distributed computing environments including any of the above devices, etc.

[0067] This invention provides a method for unifying sub-application versions. This method can be applied to various computer terminals or smart terminals, and its execution entity can be the processor or server of the computer terminal or smart terminal. The method flowchart is shown below. Figure 1 As shown, it specifically includes:

[0068] S1: For each sub-application, during the sub-application build process, a standardized dependency descriptor corresponding to that sub-application is generated.

[0069] This application enables the automatic collection of dependency metadata during the application building process. Then, it generates standardized dependency descriptors based on the dependency metadata, thus avoiding the tediousness and omissions of human intervention and ensuring the comprehensiveness and timeliness of the data.

[0070] By generating standardized dependency descriptors, heterogeneous dependency information generated by different sub-applications and different component tools can be unified into a structured format that can be processed by subsequent processes, preventing data format chaos.

[0071] S2: When each of the sub-applications is loaded, construct a target dependency version topology graph corresponding to all sub-applications based on the standardized dependency descriptor.

[0072] Constructing a target dependency version topology graph can aggregate isolated dependency information into a global, centralized data model. This target dependency version topology graph not only records who used what, but more importantly, it clearly reveals the network relationships between sub-applications and dependency versions, as well as between dependency versions, through a graph structure, providing data support for subsequent processes.

[0073] S3: Calculate the compatibility between each sub-application and its corresponding version in the target dependency version topology graph.

[0074] Existing technologies often only analyze compatibility issues without translating them into specific, user-calculate compatibility metrics. This application, by calculating the compatibility between each sub-application and its corresponding version, can accurately identify which sub-applications can safely switch versions and which pose risks. This is a crucial step in avoiding runtime crashes and ensuring system stability.

[0075] S4: Generate a set of candidate shared versions corresponding to the sub-application based on the target dependency version topology graph.

[0076] In this step, a set of candidate shared versions is first determined, and then one of them is selected as the final target shared version. This can narrow down the scope and improve efficiency.

[0077] S5: Based on the compatibility, select the target shared version from the candidate version set as the unified version for each of the sub-applications.

[0078] The decision-making basis for this step is the compatibility calculated in the above steps. This ensures that the final selected target shared version is safe, usable, and compatible for the vast majority of sub-applications, fundamentally and significantly reducing application performance problems caused by version incompatibility and mismatch.

[0079] In addition, this application selects a unified shared version for all sub-applications, so that the browser only needs to load one copy of the dependent code, thereby reducing resource redundancy, reducing network transmission load, and improving the overall loading performance of the application.

[0080] As can be seen from the above technical solution, this application generates a standardized dependency descriptor corresponding to each sub-application during the sub-application construction process; when each sub-application is loaded, a target dependency version topology graph corresponding to all sub-applications is constructed based on the standardized dependency descriptor; the compatibility degree between each sub-application and its corresponding version in the target dependency version topology graph is calculated; a candidate shared version set corresponding to the sub-application is generated based on the target dependency version topology graph; and a target shared version is selected from the candidate version set as the unified version for all sub-applications based on the compatibility degree. This application first generates a standardized dependency descriptor, which can be applied to the dependency version topology graph construction process during sub-application loading. It can clearly represent the dependency relationships corresponding to sub-applications. By calculating the compatibility degree between sub-applications and their dependent versions, it can accurately identify which sub-applications can safely switch versions and which pose a risk. This is a key step in avoiding runtime crashes and ensuring system stability. Then, based on the compatibility degree, the most suitable version is selected from the candidate version set as the target shared version, serving as the unified version for all sub-applications. This solves the compatibility problem caused by sub-applications depending on different versions in the prior art and ensures application stability.

[0081] The method provided in this embodiment of the invention includes a process for generating a standardized dependency descriptor corresponding to the sub-application during the sub-application construction process, which is described in detail below:

[0082] During the construction of this sub-application, obtain the metadata of each dependency;

[0083] Create an empty data structure with fixed fields;

[0084] Analyze the relationships between the metadata entries.

[0085] Bind each of the aforementioned dependency metadata entries according to the aforementioned relationship to obtain the bound data and each of the aforementioned dependency metadata entries;

[0086] The binding data and each of the dependency metadata entries are added to the data structure to obtain a standardized dependency descriptor.

[0087] Specifically, the pre-acquired extended Module Federation protocol can be used to synchronously collect dependency metadata in the exposed modules of the sub-application, such as identity identifiers, each dependency, semantic version range, dependency type, third-party library name, version number, module path, export interface, etc. This embodiment does not impose any restrictions on this.

[0088] The process of obtaining each dependency metadata in the above process includes:

[0089] When a module of the subapplication is marked as needing to be exposed, determine the source code of the module and the semantic version range corresponding to the module;

[0090] Identify the dependencies imported by this module from the source code.

[0091] Obtain the identity identifier corresponding to this module;

[0092] The dependencies and identifiers of each module marked as needing exposure are aggregated to obtain the first dataset;

[0093] Determine the semantic version range and dependency types declared by the sub-application during construction;

[0094] The first dataset, semantic version range, and dependency type are all used as the dependency metadata.

[0095] Specifically, abstract dependency declarations can be bound to specific module usage locations. This allows us to know which exposed modules use each dependency. For example, when generating standardized dependency descriptors, we can read the dependency declaration list from the package.json file and the dependency import relationship list from the module analysis results of the sub-application build process. Then, using the dependency list in package.json as a benchmark, we can match the module import relationship list, thus binding the abstract dependency declarations to specific module usage locations.

[0096] A rule engine can be predefined and applied to each piece of data after the above association. Then, the data can be encapsulated by adding it to a pre-built empty data structure with fixed fields to obtain a standardized dependency descriptor.

[0097] The process of constructing a target dependency version topology graph corresponding to all sub-applications based on the standardized dependency descriptor in this application is described in detail below.

[0098] For each sub-application, when the sub-application is loaded, the dependency version corresponding to the sub-application and the usage relationship between the sub-application and the dependency version are determined according to the standardized dependency descriptor.

[0099] Update the dependency versions and usage relationships to the pre-built initial dependency version topology graph;

[0100] The target dependency version topology map is obtained when all the dependency versions and usage relationships of the sub-applications are updated to the initial dependency version topology map.

[0101] Specifically, in this process, we can apply a version resolver. When the application is ready to load a sub-application, the version resolver is started. It dynamically accesses the exposed module information of the remote sub-application through the container interface of Module Federation. Then, the version resolver normalizes the dependency descriptor from the remote sub-application loader to obtain the dependency information declared by the sub-application during the build, especially its expected version. Then, a dependency version topology graph can be constructed, where the nodes include dependency versions and sub-applications, and the edges represent relationships, including usage relationships (between sub-applications and dependency versions) and compatibility relationships (between dependency versions).

[0102] Furthermore, this application can also monitor the dynamic changes of sub-application dependencies in real time, such as hot updates, lazy loading of modules, or runtime dependency switching. By rewriting the loader hook of Module Federation, the context information of import requests is recorded during the module resolution phase. Using the publish-subscribe pattern, a target dependency version topology graph reconstruction event is triggered when the dependency version is updated or the sub-application is redeployed. A heartbeat detection and health reporting mechanism is integrated to periodically verify the availability and version consistency of remote dependencies, ensuring that the status of shared resources is synchronized in real time. An incremental update strategy is adopted, only the changed dependency subgraph is processed, and the calculation process is optimized through a difference comparison algorithm, which can reduce monitoring overhead.

[0103] The following embodiments provide a detailed explanation of the steps in this application for calculating the compatibility between each sub-application and its corresponding version in the target dependency version topology graph.

[0104] Get the version range expected by the sub-application;

[0105] Identify all existing actual versions in the target version topology graph;

[0106] The compatibility of the version range with each of the actual versions is calculated to obtain the compatibility degree.

[0107] Specifically, in the compatibility calculation process, if the actual version falls entirely within the expected version range, it means that it is fully compatible; if it does not fall entirely within the expected range, it means that the major version of the actual version is the same, but the minor version is higher, which may include new features, but is usually backward compatible; however, if it is incompatible, it means that the major version of the actual version is different.

[0108] Furthermore, the process of generating a set of candidate shared versions corresponding to the sub-application based on the target dependency version topology graph may include the following steps:

[0109] Identify the third-party libraries corresponding to each of the aforementioned sub-applications;

[0110] In the target version topology graph, the dependency versions related to the third-party library are determined to form a candidate version set;

[0111] Based on the compatibility, a graph traversal is performed on the candidate version set to obtain each compatibility subgraph;

[0112] Determine the number of sub-applications covered in each of the aforementioned compatibility sub-graphs;

[0113] The compatibility subgraph with the largest number of elements is selected as the target subgraph.

[0114] Each candidate version within the target subgraph is scored.

[0115] Specifically, after forming a set of candidate versions, a graph traversal is performed. The purpose is to identify subgraph structures that are highly interconnected internally but have low compatibility or are disconnected from other parts. Then, all nodes with the same major version number in the semantic version range are found. These nodes can be considered to be within the same compatibility boundary, so these nodes are collectively formed into a compatibility subgraph. Nodes with different major version numbers are considered to be different and incompatible compatibility subgraphs.

[0116] In the process of determining the target subgraph from the compatibility subgraph, we consider that the more sub-applications a compatibility subgraph covers, the more compatible it is and the higher its serviceability. Based on this, we determine the target subgraph, and then score each candidate version in the target subgraph to determine the final target shared version.

[0117] The process of scoring each candidate version within the target subgraph in the above process is explained in detail below:

[0118] For each candidate version, count the number of sub-applications that directly use that candidate version;

[0119] Determine the number of patches required for this candidate version;

[0120] Determine whether the candidate version has been released; if so, assign it a preset first score.

[0121] If not, then obtain the current time and the release time of the candidate version;

[0122] Calculate the time difference between the current time and the publication time, and assign a first score based on the time difference;

[0123] Calculate the volume value of the candidate version and assign a second score based on the volume value;

[0124] Configure weighting coefficients for the number of sub-applications, the number of patches, the first score, and the second score, respectively;

[0125] According to the weighting coefficients, the number of sub-applications, the number of patches, the first score and the second score are weighted and summed to obtain the comprehensive score of the candidate version;

[0126] The candidate version with the highest overall score is selected as the target shared version.

[0127] Specifically, this application selects the target shared version based on multiple dimensions of indicators to improve accuracy. These dimensions include usage frequency, version freshness, version stability, and performance.

[0128] In terms of usage frequency, the more sub-applications that directly use this candidate version, the more sub-applications will be adapted globally. In terms of version freshness, under the premise of compatibility, versions with more patches will include important bug fixes. In terms of version stability, released versions have the highest stability, and for unreleased versions, the closer the release date, the higher the stability. In terms of performance, smaller versions are more beneficial to the overall operation of the application.

[0129] Therefore, by combining the scores under the above four dimensions and performing a weighted summation, a comprehensive score can be obtained. The candidate version with the highest comprehensive score can then be selected as the target shared version.

[0130] Understandably, if the final target shared version is not suitable as a unified version for all sub-applications, version negotiation is required first. This could involve wrapping incompatible interfaces with an API adaptation layer or using multi-version coexistence isolation technology. If negotiation fails, a fallback strategy is needed to select alternative solutions, such as loading independent dependencies for sub-applications, using downgraded versions, or penalizing error handling processes. Fallback strategies include progressive downgrade, conditional isolation, and dynamic pads.

[0131] and Figure 1 Corresponding to the method described above, this embodiment of the invention also provides a sub-application version unification device for... Figure 1 In the specific implementation of the method, the sub-application version unification device provided in this embodiment of the invention can be used in computer terminals or various mobile devices, combined with Figure 2 The unified device for sub-application versions is introduced, such as... Figure 2 As shown, the device may include:

[0132] The standardized dependency descriptor generation module 10 is used to generate a standardized dependency descriptor corresponding to each sub-application during the sub-application building process.

[0133] The topology graph construction module 20 is used to construct a target dependency version topology graph corresponding to all sub-applications based on the standardized dependency descriptor when each of the sub-applications is loaded.

[0134] The compatibility calculation module 30 is used to calculate the compatibility between each sub-application and its corresponding version in the target dependency version topology graph;

[0135] The candidate shared version set generation module 40 is used to generate a candidate shared version set corresponding to the sub-application based on the target dependency version topology graph.

[0136] The target shared version determination module 50 is used to select a target shared version from the candidate version set as the unified version for each of the sub-applications based on the compatibility.

[0137] As can be seen from the above technical solution, this application generates a standardized dependency descriptor corresponding to each sub-application during the sub-application construction process; when each sub-application is loaded, a target dependency version topology graph corresponding to all sub-applications is constructed based on the standardized dependency descriptor; the compatibility degree between each sub-application and its corresponding version in the target dependency version topology graph is calculated; a candidate shared version set corresponding to the sub-application is generated based on the target dependency version topology graph; and a target shared version is selected from the candidate version set as the unified version for all sub-applications based on the compatibility degree. This application first generates a standardized dependency descriptor, which can be applied to the dependency version topology graph construction process during sub-application loading. It can clearly represent the dependency relationships corresponding to sub-applications. By calculating the compatibility degree between sub-applications and their dependent versions, it can accurately identify which sub-applications can safely switch versions and which pose a risk. This is a key step in avoiding runtime crashes and ensuring system stability. Then, based on the compatibility degree, the most suitable version is selected from the candidate version set as the target shared version, serving as the unified version for all sub-applications. This solves the compatibility problem caused by sub-applications depending on different versions in the prior art and ensures application stability.

[0138] Furthermore, embodiments of this application provide a unified device for sub-application versions. Optionally, Figure 3 The hardware structure block diagram of the unified device for sub-application versions is shown below, for reference. Figure 3 The hardware structure of the sub-application version unified device may include: at least one processor 01, at least one communication interface 02, at least one memory 03 and at least one communication bus 04.

[0139] In this embodiment, the number of processor 01, communication interface 02, memory 03 and communication bus 04 is at least one, and processor 01, communication interface 02 and memory 03 communicate with each other through communication bus 04.

[0140] Processor 01 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0141] Memory 03 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device.

[0142] The memory stores a program, which the processor can call to execute the following sub-application version unification method, including:

[0143] For each sub-application, a standardized dependency descriptor corresponding to that sub-application is generated during the sub-application's build process;

[0144] When each of the sub-applications is loaded, a target dependency version topology graph corresponding to all sub-applications is constructed based on the standardized dependency descriptor.

[0145] Calculate the compatibility between each sub-application and its corresponding version in the target dependency version topology graph;

[0146] Based on the target dependency version topology graph, generate a set of candidate shared versions corresponding to the sub-application;

[0147] Based on the compatibility, a target shared version is selected from the candidate version set as the unified version for each of the sub-applications.

[0148] Optionally, the refined and extended functions of the program can be found in the description of the sub-application version unification method in the method embodiment.

[0149] This application embodiment also provides a storage medium that can store a program suitable for execution by a processor. When the program runs, it controls the device where the storage medium is located to execute the following sub-application version unification method, including:

[0150] For each sub-application, a standardized dependency descriptor corresponding to that sub-application is generated during the sub-application's build process;

[0151] When each of the sub-applications is loaded, a target dependency version topology graph corresponding to all sub-applications is constructed based on the standardized dependency descriptor.

[0152] Calculate the compatibility between each sub-application and its corresponding version in the target dependency version topology graph;

[0153] Based on the target dependency version topology graph, generate a set of candidate shared versions corresponding to the sub-application;

[0154] Based on the compatibility, a target shared version is selected from the candidate version set as the unified version for each of the sub-applications.

[0155] Specifically, the storage medium can be a computer-readable storage medium, which can be an electronic storage device such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM.

[0156] Optionally, the refined and extended functions of the program can be found in the description of the sub-application version unification method in the method embodiment.

[0157] Furthermore, the functional modules in the various embodiments of this disclosure can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part. If the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a live streaming device, or a network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this disclosure.

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

[0159] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0160] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for uniformizing sub-application versions, characterized by, The method comprises the following steps: For each sub-application, a standardized dependency descriptor corresponding to the sub-application is generated during the construction of the sub-application; When each sub-application is loaded, a target dependency version topology graph corresponding to all sub-applications is constructed according to the standardized dependency descriptor; The compatibility between each sub-application and its corresponding version in the target dependency version topology graph is calculated; A candidate shared version set corresponding to the sub-application is generated based on the target dependency version topology graph; A target shared version is selected from the candidate version set as the uniform version of each sub-application based on the compatibility.

2. The method of claim 1, wherein, The method of generating the standardized dependency descriptor corresponding to the sub-application during the construction of the sub-application comprises the following steps: During the construction of the sub-application, each piece of dependency metadata is obtained; An empty data structure with fixed fields is created; The association between each piece of metadata is analyzed; The dependency metadata is bound according to the association to obtain binding data and each piece of dependency metadata; The binding data and each piece of dependency metadata are added to the data structure to obtain the standardized dependency descriptor.

3. The method of claim 2, wherein, The method of obtaining each piece of dependency metadata comprises the following steps: When a module of the sub-application is marked as needing to be exposed, the source code of the module and the semantic version range corresponding to the module are determined; Each dependency imported by the module is determined from the source code; The identity corresponding to the module is obtained; Each dependency and identity of each module marked as needing to be exposed is summarized to obtain a first data set; The semantic version range and dependency type declared by the sub-application during construction are determined; The first data set, semantic version range and dependency type are all taken as the dependency metadata.

4. The method of claim 1, wherein, The method of constructing the target dependency version topology graph corresponding to all sub-applications according to the standardized dependency descriptor comprises the following steps: For each sub-application, when the sub-application is loaded, the dependency version corresponding to the sub-application and the use relationship between the sub-application and the dependency version are determined according to the standardized dependency descriptor; The dependency version and use relationship are updated to the pre-constructed initial dependency version topology graph; Until the dependency version and use relationship corresponding to all sub-applications are updated to the initial dependency version topology graph, the target dependency version topology graph is obtained.

5. The method of claim 1, wherein, The method of calculating the compatibility between each sub-application and its corresponding version in the target dependency version topology graph comprises the following steps: The version range expected by the sub-application is obtained; Each actual version already existing in the target version topology graph is determined; The compatibility between the version range and each actual version is calculated respectively to obtain the compatibility.

6. The method according to any one of claims 1 to 5, characterized in that, The method of generating the candidate shared version set corresponding to the sub-application based on the target dependency version topology graph comprises the following steps: Third-party libraries corresponding to each sub-application are determined; In the target version topology graph, dependency versions related to the third-party libraries are determined to form a candidate version set; According to the compatibility, the candidate version set is graph traversed to obtain each compatibility subgraph; The number of sub-applications covered in each compatibility subgraph is determined; taking the most compatible subgraph as a target subgraph; scoring each candidate version in the target subgraph.

7. The method of claim 6, wherein, The scoring each candidate version in the target subgraph comprises: counting the number of sub-applications directly using the candidate version for each candidate version; determining the patch number of the candidate version; judging whether the candidate version has been released, and assigning a preset first score to the candidate version if yes; if not, obtaining the current time and the release time of the candidate version; calculating the time difference between the current time and the release time, and assigning a first score according to the time difference; calculating the volume value of the candidate version, and assigning a second score based on the volume value; configuring weight coefficients for the number of sub-applications, the patch number, the first score and the second score respectively; weighting and summing the number of sub-applications, the patch number, the first score and the second score according to the weight coefficients to obtain the comprehensive score of the candidate version; selecting the candidate version with the maximum comprehensive score as the target shared version.

8. A sub-application version unification apparatus characterized by comprising: a sub-application version unification unit configured to unify versions of sub-applications. comprise: a standardized dependency descriptor generation module configured to generate a standardized dependency descriptor corresponding to each sub-application during the construction of the sub-application; a topology graph construction module configured to construct a target dependency version topology graph corresponding to all sub-applications according to the standardized dependency descriptors when the sub-applications are loaded; a compatibility calculation module configured to calculate the compatibility between each sub-application and its corresponding version in the target dependency version topology graph; a candidate shared version set generation module configured to generate a candidate shared version set corresponding to the sub-application based on the target dependency version topology graph; a target shared version determination module configured to select a target shared version from the candidate version set as the unified version of each sub-application based on the compatibility.

9. A child application version unification device, characterized by, comprise a memory and a processor; the memory is configured to store a program; the processor is configured to execute the program to implement each step of the sub-application version unification method according to any one of claims 1-7.

10. A storage medium having stored thereon a computer program, characterized in that The computer program is executed by the processor to implement each step of the sub-application version unification method according to any one of claims 1-7.

Images