Front-end application instance management method and device, electronic equipment and readable storage medium

Abstract

This disclosure relates to the field of front-end application architecture technology, and provides a front-end application instance management method, device, electronic device, and readable storage medium. The method includes: performing queue scheduling processing on a queue of application instances to be loaded to obtain an application instance loading sequence; performing resource reuse detection processing on the application instance loading sequence based on a preset container identifier to obtain a reuse determination result; performing configuration information orchestration processing on the application instance loading sequence based on the reuse determination result to obtain a target application instance; and associating the target application instance with the preset container identifier for storage processing to obtain a target application instance scheduling pool. This improves resource utilization efficiency and network bandwidth utilization, enhances the concurrency control capability and execution order controllability of the application loading process, improves application switching response speed and initialization efficiency, reduces memory usage, and enhances the state consistency and memory management fineness of multiple application instances.

Description

Technical Field

[0001] This disclosure relates to the field of front-end application architecture technology, and in particular to a front-end application instance management method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] In a micro-frontend architecture, sub-applications typically adopt a static registration and dynamic loading pattern. When users switch between different sub-applications, existing solutions can execute a complete process of uninstalling the old application and loading the new application, but this leads to problems such as repeated resource loading, excessive memory consumption, and significant application switching latency, affecting user experience and system performance. Existing technologies can avoid repeated loading through application caching, but it is difficult to manage the instance state in multi-container scenarios, which can easily cause state chaos. Preloading strategies can also reduce switching latency, but they occupy a large amount of memory in advance, increasing resource consumption.

[0003] However, existing technologies suffer from problems such as low resource utilization, chaotic application state, and excessive memory usage when switching micro-frontend applications due to the execution of a complete uninstallation and loading process and frequent memory allocation and release during application switching. Summary of the Invention

[0004] In view of this, the present disclosure provides a front-end application instance management method, device, electronic device, and readable storage medium to solve the problems in the prior art where the execution of a complete unloading and loading process and frequent memory allocation and release during application switching leads to low resource utilization, chaotic application status, and excessive memory usage during micro-front-end application switching.

[0005] A first aspect of this disclosure provides a front-end application instance management method, comprising: performing queue scheduling processing on a queue of application instances to be loaded to obtain an application instance loading sequence; performing resource reuse detection processing on the application instance loading sequence based on a preset container identifier to obtain a reuse determination result; performing configuration information orchestration processing on the application instance loading sequence based on the reuse determination result to obtain a target application instance; and associating and storing the target application instance and the preset container identifier to obtain a target application instance scheduling pool.

[0006] In some embodiments, resource reuse detection processing is performed on the application instance loading sequence based on a preset container identifier to obtain a reuse determination result, including: matching the preset container identifier and the application instance loading sequence to obtain an identifier matching result; performing state verification processing on the application instance loading sequence based on the identifier matching result to obtain a state verification result; and performing reuse determination processing on the identifier matching result and the state verification result to obtain a reuse determination result.

[0007] In some embodiments, the application instance loading sequence is configured and processed based on the reuse determination result to obtain a target application instance, including: if the reuse determination result is reused, the application instance loading sequence is activated and displayed to obtain a target application instance; if the reuse determination result is not reused, the preset application entry address is processed for environment judgment to obtain a target entry configuration; and the application instance loading sequence is loaded based on the target entry configuration to obtain a target application instance.

[0008] In some embodiments, performing queue scheduling processing on the queue of application instances to be loaded to obtain an application instance loading sequence includes: performing priority attribute identification processing on the queue of application instances to be loaded to obtain a priority identifier; performing sorting and adjustment processing on the queue of application instances to be loaded based on the priority identifier to obtain a priority scheduling queue; performing concurrency control detection processing on the priority scheduling queue to obtain a queue scheduling status identifier; and performing sequence generation processing based on the queue scheduling status identifier to obtain an application instance loading sequence.

[0009] In some embodiments, associating and storing the target application instance and a preset container identifier to obtain a target application instance scheduling pool includes: monitoring the mounting status of the target application instance to obtain a loading completion signal; associating and recording the target application instance, the preset container identifier, and the preset node name field based on the loading completion signal to obtain an application instance file; and updating the scheduling pool of the application instance file to obtain the target application instance scheduling pool.

[0010] In some embodiments, before performing queue scheduling processing on the queue of application instances to be loaded to obtain the application instance loading sequence, the method further includes: obtaining historical behavior data; performing application access prediction processing on the historical behavior data to obtain a predicted application identifier; and performing preloading triggering processing based on the predicted application identifier to obtain the queue of application instances to be loaded.

[0011] In some embodiments, the application instance loading sequence is subjected to status verification processing based on the identifier matching result to obtain a status verification result, including: performing matching processing on the application instance loading sequence based on preset application instance matching conditions and identifier matching results to obtain a matching application instance; performing version consistency verification processing on the matching application instance to obtain a version verification result; performing runtime status survival detection processing on the matching application instance to obtain an instance survival status identifier; and performing verification processing based on the version verification result and the instance survival status identifier to obtain a status verification result.

[0012] A second aspect of this disclosure provides a front-end application instance management device, comprising: a first processing module, configured to perform queue scheduling processing on a queue of application instances to be loaded to obtain an application instance loading sequence; a second processing module, configured to perform resource reuse detection processing on the application instance loading sequence based on a preset container identifier to obtain a reuse determination result; a third processing module, configured to perform configuration information orchestration processing on the application instance loading sequence based on the reuse determination result to obtain a target application instance; and a fourth processing module, configured to associate and store the target application instance and the preset container identifier to obtain a target application instance scheduling pool.

[0013] A third aspect of this disclosure provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0014] A fourth aspect of this disclosure provides a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0015] The beneficial effects of this embodiment compared with the prior art are as follows: by performing queue scheduling processing on the queue of application instances to be loaded, an application instance loading sequence is obtained; resource reuse detection processing is performed on the application instance loading sequence based on a preset container identifier to obtain a reuse judgment result; configuration information orchestration processing is performed on the application instance loading sequence based on the reuse judgment result to obtain a target application instance; the target application instance and the preset container identifier are associated and stored to obtain a target application instance scheduling pool. In this way, resource reuse detection processing improves resource utilization efficiency and network bandwidth utilization, queue scheduling processing enhances the concurrency control capability and execution order controllability of the application loading process, configuration information orchestration processing improves application switching response speed and initialization efficiency and reduces memory occupancy, and associated storage processing enhances the state consistency and memory management fineness of multiple application instances. Attached Figure Description

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

[0017] Figure 1 This is a schematic diagram illustrating an application scenario of an embodiment of this disclosure; Figure 2This is a flowchart illustrating a front-end application instance management method provided in an embodiment of this disclosure; Figure 3 This is a flowchart illustrating another front-end application instance management method provided in this embodiment of the disclosure; Figure 4 This is a schematic diagram of the structure of a front-end application instance management device provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0018] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, so as to provide a thorough understanding of the embodiments of this disclosure. However, those skilled in the art will understand that this disclosure may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this disclosure with unnecessary detail.

[0019] It should be noted that the user information (including but not limited to terminal device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties.

[0020] A front-end application instance management method and apparatus according to embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings.

[0021] Figure 1 This is a schematic diagram illustrating an application scenario of an embodiment of this disclosure. The application scenario may include terminal devices 1, 2, and 3, server 4, and network 5.

[0022] Terminal devices 1, 2, and 3 can be hardware or software. When terminal devices 1, 2, and 3 are hardware, they can be various electronic devices with displays and supporting communication with server 4, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal devices 1, 2, and 3 are software, they can be installed in the aforementioned electronic devices. Terminal devices 1, 2, and 3 can be implemented as multiple software programs or software modules, or as a single software program or software module; this disclosure does not limit this. Furthermore, various applications can be installed on terminal devices 1, 2, and 3, such as data processing applications, instant messaging tools, social platform software, search applications, shopping applications, etc.

[0023] Server 4 can be a server that provides various services, such as a backend server that receives requests sent by terminal devices with which it has established communication connections. This backend server can receive and analyze the requests sent by the terminal devices and generate processing results. Server 4 can be a single server, a server cluster consisting of several servers, or a cloud computing service center. This disclosure embodiment does not limit this.

[0024] It should be noted that server 4 can be either hardware or software. When server 4 is hardware, it can be various electronic devices that provide various services to terminal devices 1, 2, and 3. When server 4 is software, it can be multiple software programs or software modules that provide various services to terminal devices 1, 2, and 3, or it can be a single software program or software module that provides various services to terminal devices 1, 2, and 3. This disclosure does not limit the scope of the embodiments.

[0025] Network 5 can be a wired network using coaxial cable, twisted pair, and fiber optic connection, or it can be a wireless network that enables interconnection of various communication devices without wiring, such as Bluetooth, Near Field Communication (NFC), and Infrared. This disclosure does not limit the scope of the network.

[0026] Users can establish a communication connection with server 4 via network 5 through terminal devices 1, 2, and 3 to receive or send information. Specifically, server 4 can obtain a queue of application instances to be loaded through terminal devices 1, 2, and 3, and obtain an application instance loading sequence by performing queue scheduling on the queue of application instances to be loaded; perform resource reuse detection processing on the application instance loading sequence based on a preset container identifier to obtain a reuse judgment result; perform configuration information orchestration processing on the application instance loading sequence based on the reuse judgment result to obtain a target application instance; and perform associated storage processing on the target application instance and the preset container identifier to obtain a target application instance scheduling pool.

[0027] It should be noted that the specific types, quantities, and combinations of terminal devices 1, 2, and 3, server 4, and network 5 can be adjusted according to the actual needs of the application scenario, and this disclosure embodiment does not impose any restrictions on this.

[0028] Figure 2 This is a flowchart illustrating a front-end application instance management method provided in this embodiment. Figure 2 The front-end application instance management method can be provided by Figure 1 The server executes the command. For example... Figure 2 As shown, this front-end application instance management method includes: S201, perform queue scheduling processing on the queue of application instances to be loaded to obtain the application instance loading sequence.

[0029] Specifically, the queue of application instances to be loaded can be an ordered collection containing information on multiple front-end application instances to be loaded. This queue can be a data structure used to temporarily store the request or configuration information of sub-application instances that need to be loaded into the front-end container. This can serve as a buffer for application loading requests, ensuring that loading requests can be processed in an orderly manner and avoiding resource conflicts and system instability caused by concurrent loading. The content of the queue of application instances to be loaded can be generated by the front-end routing system or user interaction events. For example, when a user clicks on the navigation menu or the route changes, a loading request containing the target application identifier and container information can be generated, and this loading request can be added as a record to the tail of the queue of application instances to be loaded.

[0030] Furthermore, the queue scheduling process can sort and select records in the queue of application instances to be loaded to determine the data processing process of the next application instance to be loaded. This queue scheduling process can be used to select one or more application instances from the queue of application instances to be loaded for subsequent loading operations, thereby controlling the application loading process and order, realizing priority management and concurrency control of loading tasks, and obtaining the application instance loading sequence.

[0031] The application instance loading sequence can be a list of application instances with a determined execution order, output by queue scheduling. The application instance loading sequence can be an ordered set of application instance identifiers. The application instance loading sequence can specify the execution order of application loading, thereby providing an execution plan for subsequent loading orchestration, ensuring the orderliness and controllability of the application loading process. The application instance loading sequence can be generated based on the contents of the queue of application instances to be loaded and a preset scheduling strategy.

[0032] For example, in an online collaboration platform based on a micro-frontend architecture, when a user switches from a document editing page to a project management panel, a request to load the project management panel application can be generated. This request can be placed in a queue of application instances to be loaded. The queue can be processed using a first-in, first-out (FIFO) rule to retrieve the request from the queue and make it a task in the current application instance loading sequence. If there are other application requests waiting to be loaded in the queue, such as a pre-loaded communication tool request, they can be kept in the queue and processed according to the sequence order after the current loading task is completed.

[0033] This application embodiment performs queue scheduling on a queue of application instances containing information on multiple front-end application instances to be loaded. According to a preset scheduling strategy, the records in the queue are sorted and selected to determine the next application instance to be loaded, generating an application instance loading sequence. This enhances the buffering and orderly processing capabilities of application loading requests, improves the efficiency of concurrent control and priority management of loading tasks, and ensures the orderliness and stability of the application loading process.

[0034] S202, Based on the preset container identifier, perform resource reuse detection processing on the application instance loading sequence to obtain the reuse judgment result.

[0035] Specifically, the preset container identifier can be an identifier used to uniquely identify the Document Object Model (DOM) container element that carries the sub-application instance in the front-end application. The preset container identifier can be a string that corresponds to the Identifier (ID) attribute of the DOM element. This can serve as a key basis for resource reuse detection and can be used to match and locate the container on which the loaded application instance is mounted. The preset container identifier can be determined based on the front-end routing configuration or user interaction behavior when the application loading request is received, and can be used to specify the target container location where the sub-application instance needs to be rendered.

[0036] Furthermore, the resource reuse detection process can be a data processing procedure to check whether the application instance to be loaded now already exists in the pool of loaded application instances and whether its attached container identifier matches the container identifier of the current request. This resource reuse detection process can be used to avoid loading the same application instance repeatedly in the same container, thereby realizing resource reuse and reducing unnecessary network requests and initialization overhead. This resource reuse detection process can receive the application instance loading sequence from the queue scheduling process as input. The application instance loading sequence can contain the application loading requests to be processed in order and their associated container identifiers to obtain the reuse determination result.

[0037] The reuse determination result can be the output of the resource reuse detection process. The reuse determination result can be a Boolean value, which can be used to indicate whether the currently requested application instance can be reused. This can guide the subsequent loading orchestration logic. If it is determined to be reusable, the loading step can be skipped and the existing application instance can be used directly. If it is determined to be unreusable, a new application loading process can be triggered. The reuse determination result can be generated by the resource reuse detection process by comparing the preset container identifier with the loaded application record.

[0038] Furthermore, the specific implementation of resource reuse detection processing may include traversing the loaded application record. This loaded application record can be a collection used to store information on all application instances that have been successfully loaded and are currently in an active or standby state. This can serve as a comparison benchmark for resource reuse detection. The container identifier, application name, and key information of the instance object of each application instance are saved. This loaded application record can be updated and maintained by configuration information orchestration processing after each application instance is successfully loaded.

[0039] Furthermore, during the traversal, the preset container identifier carried by the current application instance to be processed can be matched with the container identifier field of each item in the loaded application record. This matching process can be to compare whether the two strings are completely equal, thereby determining whether there is a loaded application instance mounted on the target container.

[0040] If a matching container identifier is found in the loaded application record, a reuse determination result indicating reusability can be generated. This result indicates that the application instance being requested does not need to be reloaded, and its corresponding code resources and initialization state can be obtained and used from memory. This allows the processing logic to skip the time-consuming steps of resource download and application initialization.

[0041] If no matching container identifier is found in the loaded application record, a reuse determination result indicating that the application is not reusable can be generated. This non-reusable reuse determination result can be used to trigger the standard application loading process, including obtaining application resources from remote or local storage, initializing the application instance, and mounting it to the specified container. This ensures that when the application is loaded into a container for the first time, or when the same application needs to be loaded into different containers, the complete loading logic can be executed correctly.

[0042] For example, in an enterprise management platform based on a micro-frontend architecture, when a user switches from a dashboard page to a details panel, a request to load the details panel application can be generated. This request can carry a preset container identifier such as "Detail Container". The resource reuse detection process can traverse the loaded application records to check if there is a loaded application instance with the container identifier "detail-container". If the user has previously opened the details panel and the instance has not been uninstalled, a matching container identifier can be identified, a reuse judgment result indicating that it can be reused can be generated, and the instance can be reused directly. If the container is loading the application for the first time, a reuse judgment result indicating that it cannot be reused can be generated, triggering the complete loading process.

[0043] This application embodiment performs resource reuse detection processing on the application instance loading sequence based on a preset container identifier, traverses the loaded application records to match container identifiers, and generates reuse judgment results, thereby improving system resource utilization efficiency and network bandwidth utilization; enhancing the response speed and smoothness of application switching; and reducing memory usage and repeated initialization overhead.

[0044] S203, based on the reuse determination result, the configuration information of the application instance loading sequence is arranged and processed to obtain the target application instance.

[0045] Specifically, the configuration information orchestration process can be a data processing process that adjusts and optimizes the loading configuration parameters of each application instance in the application instance loading sequence based on the reuse determination result. The application instance loading sequence can be an ordered list that records one or more application instances waiting to be loaded and their related information. In this way, the target loading strategy of each application instance can be determined based on the reuse determination result to obtain the target application instance.

[0046] The target application instance can be an application instance entity that has been orchestrated to determine the target loading strategy and configuration parameters and is ready to perform loading or state transition operations.

[0047] Furthermore, when the reuse determination result is that the application is loaded, the configuration information orchestration process may include finding the corresponding application instance from the loaded application pool and preparing to migrate its state to the new target container, while skipping the resource loading step of the application instance; when the reuse determination result is that the application is not loaded, the configuration information orchestration process may include generating a complete loading configuration for the application instance, which includes, but is not limited to, the application name, resource entry address, target container identifier and / or initialization attributes.

[0048] Furthermore, the configuration information orchestration process can also include the evaluation of the application instance status, which can be a comprehensive information such as the application instance's memory usage, component tree structure, and internal data status during runtime. This application instance status can be maintained and updated by the application instance itself during loading and running, thereby assessing whether the status of the loaded application instance is suitable for cross-container reuse.

[0049] The assessment of the application instance's state can include checking whether the application instance is in a stable running state and whether its internal state is complete and serializable. If the state assessment passes, the configuration information orchestration process can generate a state migration instruction, which can be used to guide how to safely migrate the application instance from the original container to the target container while maintaining the continuity of its running state.

[0050] In addition, the configuration information orchestration process can also include dynamic adjustment of loading priority, which can be a numerical value or level identifier used to determine the processing order of multiple application instances to be loaded. The loading priority can be initially set by the queue scheduling process according to the application type or business rules, and can be recalculated when orchestrating based on the reuse determination result.

[0051] For application instances that are determined to be reusable, since they do not need to reload resources, they can be given a higher execution priority to improve the interface response speed. For application instances that need to be reloaded, the priority can be dynamically adjusted according to factors such as resource size and dependencies to optimize the overall loading experience. The configuration information of the target application instance can include the adjusted priority parameters.

[0052] For example, in a large management platform based on a micro-frontend architecture, when a user switches from the data reporting sub-application to the customer management sub-application and then back to the data reporting sub-application, the first time the user enters the data reporting sub-application, it can be added to the application instance loading sequence. Resource reuse detection can determine that it is not loaded, and configuration orchestration can generate a complete loading configuration containing resource addresses and container identifiers and load it, thus obtaining the target application instance. When the user switches back to the data reporting sub-application, resource reuse detection can determine that the application instance already exists in the loaded application pool by matching the container identifier, generating a loaded reuse determination result. Configuration orchestration can locate the application instance from the loaded application pool, assess that its component tree and data status are stable and available, determine the adoption of a reuse strategy, and the generated target application instance configuration can include state transition instructions. This can instruct the application instance to be migrated from its currently hidden container to the active container corresponding to the user's current view, while skipping resource download and code initialization steps and increasing its processing priority.

[0053] This application embodiment arranges configuration information for the application instance loading sequence based on the reuse determination result, dynamically selects a state transition or new loading strategy according to the reuse determination result, and generates a target application instance containing loading configuration or state transition instructions, thereby improving the response speed of application switching and the smoothness of user experience; enhancing the ability to dynamically adjust the loading priority of multiple application instances; and improving the efficiency of network bandwidth utilization and the utilization efficiency of client computing resources.

[0054] S204. Associate the target application instance with the preset container identifier and store the associated information to obtain the target application instance scheduling pool.

[0055] Specifically, associated storage processing can be a data processing process that stores the target application instance object and its corresponding preset container identifier as a set of associated records in a centralized data structure, which is the target application instance scheduling pool.

[0056] The target application instance scheduling pool can serve as a central storage area for managing all loaded application instances, thereby maintaining the mapping relationship between application instances and container identifiers and providing a data foundation for subsequent application instance lookup, reuse, and scheduling.

[0057] The associated storage processing can be implemented by pushing records containing container identifiers and application instance objects into an array or adding them to a map data structure. The target application instance scheduling pool can serve as the core data source for queue scheduling processing and resource reuse detection processing. When it is necessary to determine whether an application instance already exists in a container, the detection can be completed by traversing the target application instance scheduling pool and matching the container identifier.

[0058] This application embodiment constructs a centralized target application instance scheduling pool by associating and storing target application instances with preset container identifiers, and establishes a mapping management mechanism between application instances and container identifiers. This improves the efficiency of querying and locating loaded application instances and the speed of reuse detection; enhances the unified management capability of multiple application instances; and improves the resource scheduling response performance and user experience smoothness during application switching.

[0059] According to the technical solution provided in this disclosure, by performing queue scheduling on the queue of application instances to be loaded, sorting and selecting records in the queue according to a preset scheduling strategy, determining the next application instance to be loaded, generating an application instance loading sequence, performing resource reuse detection processing on the application instance loading sequence based on a preset container identifier, traversing the loaded application records for container identifier matching to obtain a reuse judgment result, performing configuration information orchestration processing on the application instance loading sequence based on the reuse judgment result, dynamically selecting a state transition or new loading strategy according to the judgment result, generating a target application instance containing loading configuration or state transition instructions, associating the target application instance with the preset container identifier for storage, constructing a centralized target application instance scheduling pool, and establishing a mapping management mechanism between application instances and container identifiers, thereby enhancing the buffering and orderly processing capabilities of application loading requests; improving the efficiency of concurrent control and priority management of loading tasks; improving resource utilization efficiency and network bandwidth utilization; enhancing the response speed and smoothness of application switching; reducing memory usage and repeated initialization overhead; improving the query and location efficiency and reuse detection speed of loaded application instances; and enhancing the unified management capability of multiple application instances.

[0060] In some embodiments, resource reuse detection processing is performed on the application instance loading sequence based on a preset container identifier to obtain a reuse determination result, including: matching the preset container identifier and the application instance loading sequence to obtain an identifier matching result; performing state verification processing on the application instance loading sequence based on the identifier matching result to obtain a state verification result; and performing reuse determination processing on the identifier matching result and the state verification result to obtain a reuse determination result.

[0061] Specifically, matching the preset container identifier with the application instance loading sequence is a data processing process that compares the container identifier to be detected with the container identifiers already recorded in the application instance loading sequence. This can determine whether the sub-application currently being requested to be loaded already exists in a specific container, thus providing a basis for resource reuse decisions.

[0062] Specifically, the matching process can be achieved by iterating through the loaded application information recorded in the application instance loading sequence and comparing the container identifier field recorded in each loaded application information with the preset container identifier. If a matching record exists, the identifier matching result can be considered a successful match; otherwise, the matching result can be considered a failed match.

[0063] The identifier matching result can be a determination information that indicates whether the preset container identifier matches the container identifier recorded in the application instance loading sequence. The identifier matching result can be in the form of a boolean value or an enumeration value. When there is a matching record, the identifier matching result can be a successful match; otherwise, it can be a failed match.

[0064] In addition, performing status verification on the application instance loading sequence based on the identifier matching result can be a data processing procedure for checking the availability of application instances that have successfully matched the identifier. This can confirm whether the application instance is currently in a state that can be accessed and used normally, ensuring that even if the container identifier matches successfully, the corresponding application instance is valid and reusable, avoiding reuse failures due to problems such as application instance corruption, uninstallation, or version incompatibility.

[0065] The application instance status information used for this status verification process can be derived from the status data recorded in the application instance loading sequence and dynamically updated when the application instance is loaded or unloaded. This status verification process can include checking whether the application instance's lifecycle status is mounted, checking whether the application instance's version number meets the current requirements, or checking whether the DOM node corresponding to the application instance still exists on the page, etc., to obtain the status verification result.

[0066] The status verification result can be a determination of whether the application instance that has successfully matched the identifier is currently in an available state. The status verification result can be in the form of a boolean value or an enumeration value. When the application instance is in an accessible and usable state, the status verification result can be "available"; otherwise, it can be "unavailable".

[0067] Furthermore, performing reuse judgment processing on the identifier matching results and status verification results can be a logical decision-making process to comprehensively judge whether an existing application instance can be reused based on the identifier matching results and status verification results. This generates instructions to guide subsequent processes on whether to directly reuse the existing instance or to start a new loading process.

[0068] Furthermore, the reuse determination process can receive the results from the matching process and the status verification process as input, and output a boolean value or an enumeration value as the reuse determination result. The reuse determination result can directly affect the execution path of the configuration information orchestration process.

[0069] The logic for this reuse determination process can be as follows: if the identifier matching result is successful and the status verification result is available, then the reuse determination result is reusable; otherwise, the reuse determination result is not reusable.

[0070] According to the technical solution provided in this disclosure, by matching a preset container identifier with an application instance loading sequence, and by traversing the loaded application information recorded in the sequence and comparing the container identifier field one by one, an identifier matching result is obtained. Based on the identifier matching result, the application instance loading sequence is subjected to status verification processing. For application instances with successfully matched identifiers, an availability check is performed to confirm their lifecycle status, version compatibility, and DOM node existence, thus obtaining a status verification result. The identifier matching result and the status verification result are then subjected to reuse determination processing. When the identifier matches successfully and the status verification is available, it is determined to be reusable; otherwise, it is determined to be unreusable, thus obtaining a reuse determination result. This enhances the collaborative judgment capability of container identifier matching and instance status verification, improves the accuracy and reliability of resource reuse decisions, and avoids the risk of reuse failure due to abnormal instance status.

[0071] In some embodiments, the application instance loading sequence is configured and processed based on the reuse determination result to obtain a target application instance, including: if the reuse determination result is reused, the application instance loading sequence is activated and displayed to obtain a target application instance; if the reuse determination result is not reused, the preset application entry address is processed for environment judgment to obtain a target entry configuration; and the application instance loading sequence is loaded based on the target entry configuration to obtain a target application instance.

[0072] Specifically, the activation display processing can be a data processing process that switches the corresponding application instance in the loaded application pool from a hidden or dormant state to a visible and interactive state when the reuse determination result is reusable. This can respond to the user's switching request without having to re-execute the time-consuming resource loading and initialization steps to obtain the target application instance.

[0073] Furthermore, the activation display process can specifically include: searching in the loaded application pool based on the container identifier contained in the application information to be processed in the application instance loading sequence; if a matching application instance is found, the display status of the instance can be set to visible and its communication connection with the main application framework can be restored; the application instance can be removed from the loading sequence and the queue management status can be updated. This process avoids network requests and code parsing and directly reuses objects in memory.

[0074] In addition, if the reuse determination result is no reuse, the preset application entry address is subjected to environment judgment processing to obtain the target entry configuration.

[0075] The preset application entry address can be a Uniform Resource Locator (URL) address that is predefined for the sub-application and can be used to obtain its resource files. This preset application entry address can be a network or local path of the sub-application code resources, which can be used as the starting point for loading the sub-application resources.

[0076] Furthermore, the environment judgment process can be a data processing process that dynamically analyzes and adapts the preset application entry address based on the current running environment variables or configuration information. This can distinguish between development and production environments, select the correct resource loading path for different environments, and obtain the target entry configuration.

[0077] The target entry configuration can be the sub-application loading configuration information that is determined after environmental judgment and is applicable to the current running environment. The target entry configuration can be a configuration object that includes the effective entry address and other relevant loading parameters, which can be used as input for subsequent loading processes.

[0078] Furthermore, the environment determination process may specifically include: reading a predefined environment identifier variable; if the environment identifier indicates a development environment, the preset local development server address can be used as the entry address; if the environment identifier indicates a production environment, the preset online content delivery network (CDN) address or the packaged static resource address can be used as the entry address; then the selected entry address can be combined with other necessary loading attributes to form a complete target entry configuration.

[0079] In addition, the loading process can be a data processing process that dynamically obtains the code resources of the sub-application based on the target entry configuration, performs initialization, and mounts them to the specified DOM container. This allows for the creation of new application instances to respond to user requests or when reuse conditions are not met.

[0080] The loading process can specifically include: calling the dynamic loading function provided by the micro-frontend framework, passing the target entry configuration as a parameter; the dynamic loading function can asynchronously obtain the programming language (JavaScript) package of the sub-application and can be executed in an independent sandbox environment; during execution, the lifecycle initialization of the sub-application can be completed, including its internal state, routes, and component construction; after initialization, the micro-frontend framework can mount the root component of the sub-application to the DOM container node specified in the target entry configuration; after successful mounting, an object representing the sub-application instance can be generated, which can contain methods to control the instance; this newly loaded application instance can be recorded in the loaded application pool and the current task can be removed from the application instance loading sequence, thereby completing the construction of the target application instance.

[0081] According to the technical solution provided in this disclosure, when the reuse determination result is reused, the application instance loading sequence is activated and displayed. By searching for a matching application instance in the loaded application pool, its display status is set to visible and the communication connection is restored to obtain the target application instance. When the reuse determination result is not reused, the preset application entry address is subjected to environment judgment processing. By reading the environment identifier variable, the resource loading path in the development or production environment is dynamically adapted to obtain the target entry configuration. Based on the target entry configuration, the application instance loading sequence is loaded. The dynamic loading function is called to asynchronously obtain code resources and perform initialization in the sandbox. The root component of the sub-application is mounted to the specified DOM container to obtain the target application instance. This enhances the ability of application instances to be quickly activated and displayed in reuse scenarios; improves the dynamic adaptation capability of application entry configuration in different environments; and enhances the flexibility of application instance loading and the accuracy of resource acquisition.

[0082] In some embodiments, performing queue scheduling processing on the queue of application instances to be loaded to obtain an application instance loading sequence includes: performing priority attribute identification processing on the queue of application instances to be loaded to obtain a priority identifier; performing sorting and adjustment processing on the queue of application instances to be loaded based on the priority identifier to obtain a priority scheduling queue; performing concurrency control detection processing on the priority scheduling queue to obtain a queue scheduling status identifier; and performing sequence generation processing based on the queue scheduling status identifier to obtain an application instance loading sequence.

[0083] Specifically, priority attribute identification processing of the queue of application instances to be loaded can be a data processing process that extracts or calculates the priority attribute of each application instance in the queue. This priority attribute identification processing can identify and obtain the loading priority of application instances, thereby providing a basis for subsequent sorting adjustments.

[0084] The priority identifier can be a symbol or value that represents the loading priority of application instances. This priority identifier can be identification information used to distinguish the loading order of application instances, and can be used as input for sorting adjustment processing. This priority identifier can be obtained by parsing the configuration items in the application instance information. These configuration items can include application type and user operation urgency.

[0085] Furthermore, priority attribute recognition processing can be based on the application instance's configuration information, such as the application's type label or preset priority field, to extract the corresponding priority identifier.

[0086] In addition, sorting and adjusting the queue of application instances to be loaded based on priority identifiers can be a data processing process that rearranges the elements in the queue according to priority identifiers. This sorting and adjustment process can be a process that changes the order of application instances in the queue, thereby generating a temporary queue arranged from high to low priority to guide the subsequent loading order, resulting in a priority scheduling queue.

[0087] The priority scheduling queue can be a queue of application instances arranged according to priority order after sorting and adjustment. This priority scheduling queue can be an intermediate queue used to guide the actual loading order, and can be used as input for concurrency control detection processing. This priority scheduling queue can be obtained by sorting the original queue of application instances to be loaded according to priority identifiers.

[0088] Furthermore, the sorting adjustment process can employ a stable sorting algorithm to ensure that application instances with the same priority maintain their original relative order.

[0089] In addition, performing concurrency control detection on the priority scheduling queue can be used to check whether the data processing process allows loading a new application instance. This concurrency control detection can be a detection mechanism to avoid resource conflicts, thereby determining whether the conditions for loading the next application instance are met at the current moment, preventing memory or network resource competition caused by multiple application instances loading at the same time, and obtaining the queue scheduling status identifier.

[0090] The queue scheduling status flag can be an identifier representing the current queue scheduling processing status, or a signal indicating whether sequence generation processing can be executed, thereby controlling the triggering timing of sequence generation processing. This queue scheduling status flag can be generated by checking whether an application instance is currently loading, whether the resource utilization rate exceeds a threshold, and other conditions.

[0091] Furthermore, the concurrency control detection process can query a global state variable that records the information of the application instance currently being processed. If the global state variable is empty, it indicates that no application instance is currently being loaded, and a new loading sequence can be generated.

[0092] Furthermore, sequence generation processing based on queue scheduling status identifiers can be a data processing process that extracts application instance information from the priority scheduling queue and generates a target loading instruction sequence based on the queue scheduling status identifiers. This sequence generation process can be an operation to generate target execution instructions. In this way, the application instance information after priority sorting and concurrency control detection can be transformed into an ordered list that can be used by the loading execution module, thus obtaining the application instance loading sequence.

[0093] Furthermore, the sequence generation process may include retrieving application instance information from the head of the priority scheduling queue, encapsulating it into a loading instruction, and adding it to the application instance loading sequence.

[0094] According to the technical solution provided in this disclosure, priority attribute identification processing is performed on the queue of application instances to be loaded. Configuration items are parsed from the information of each application instance to extract priority identifiers. Based on these priority identifiers, the queue of application instances to be loaded is sorted and adjusted. A stable sorting algorithm is used to rearrange the instances from high to low priority to generate a priority scheduling queue. Concurrency control detection processing is performed on the priority scheduling queue. By querying global state variables, it is checked whether there are currently any application instances loading or whether resource consumption exceeds the threshold to obtain a queue scheduling status identifier. Based on this queue scheduling status identifier, sequence generation processing is performed. When the identifier indicates that loading is allowed, application instance information is retrieved from the head of the priority scheduling queue and encapsulated into a loading instruction to generate an application instance loading sequence. This enhances the identification and sorting capabilities of application instance loading priorities, improves the efficiency of concurrency control and resource scheduling of loading tasks, and enhances the dynamic adaptability and orderliness of loading sequence generation.

[0095] In some embodiments, associating and storing the target application instance and a preset container identifier to obtain a target application instance scheduling pool includes: monitoring the mounting status of the target application instance to obtain a loading completion signal; associating and recording the target application instance, the preset container identifier, and the preset node name field based on the loading completion signal to obtain an application instance file; and updating the scheduling pool of the application instance file to obtain the target application instance scheduling pool.

[0096] Specifically, monitoring the mounting status of the target application instance can be a data processing process that listens to and judges the status of the target application instance as it is loaded into the specified DOM container. This mounting status monitoring process can monitor the complete lifecycle events of the application instance from the start of loading to successful mounting into the page container, thereby ensuring that the application instance is fully ready and providing status basis for subsequent related record processing, and obtaining a loading completion signal.

[0097] The loading completion signal can be an indication signal that the target application instance has been successfully mounted to the container and entered a usable state. The loading completion signal can be a Boolean value or can be triggered by a specific event, which can be used as a timing control signal to trigger associated record processing, ensuring the accuracy of record operations.

[0098] Furthermore, the mounting status monitoring can be implemented by listening to the application lifecycle hook functions provided by the micro-frontend framework. For example, when the mounting commitment status changes to resolved, it can be determined that the loading is complete and a loading completion signal can be generated.

[0099] In addition, based on the loading completion signal, the target application instance, the preset container identifier, and the preset node name fields are associated and recorded to obtain the application instance file.

[0100] The preset node name field can be a string used to identify the business node or routing node corresponding to the application instance. This preset node name field can be a logical identifier at the business level, thereby establishing a mapping relationship between the application instance and the business logic, which facilitates scheduling in complex business scenarios.

[0101] Association record processing can be a data processing process that persistently stores the reference to the target application instance, its mounted container identifier, and the corresponding node name field as a data entry, thereby forming a structured data record.

[0102] The application instance file can be a data record containing the relationship between the target application instance, container identifier, and node name fields. This application instance file can be a structured data object, which can serve as a global registry for loaded application instances, providing data support for subsequent scheduling pool updates and resource reuse queries.

[0103] Furthermore, the processing of associated records can be accomplished by pushing the aforementioned associated information as an object into a global array or Map data structure to form an application instance archive.

[0104] In addition, the scheduling pool update process can be a data processing procedure for integrating newly generated application instance files into the global application instance management collection.

[0105] Furthermore, the scheduling pool update process can also include maintenance operations such as updating the status of existing files and cleaning up invalid files to ensure the validity and consistency of data in the scheduling pool of the target application instance.

[0106] For example, in an enterprise-level internal management system based on a micro-frontend architecture, when a user first enters the HR management module from the homepage, configuration information orchestration can be performed to load and mount the HR management sub-application into a page container with a specific ID. During the loading process, the mounting status monitoring process can continuously listen to the mounting lifecycle of the sub-application. When a mounting success event is received from the framework, a loading completion signal is generated. Then, based on this loading completion signal, the successfully loaded HR management sub-application instance, container identifier, and node name fields can be associated to form an application instance file. This application instance file can be added to a dedicated array in memory for management, and this dedicated array can constitute the initial target application instance scheduling pool. When the user switches to another module and then returns to the HR management module, the resource reuse detection process can first query the target application instance scheduling pool to check if there is a matching application instance file with the container identifier and node name fields. Since the application instance file already exists, there is no need to reload the HR management sub-application. Instead, the cached application instance can be retrieved from the target application instance scheduling pool and remounted or activated.

[0107] According to the technical solution provided in this disclosure, by monitoring the mounting status of the target application instance, and by listening to the application lifecycle hook function provided by the micro-frontend framework, a loading completion signal is generated after successful mounting. Based on the loading completion signal, the target application instance, the preset container identifier, and the preset node name fields are associated and recorded. The above information is persistently stored as data entries to form an application instance file. The application instance file is updated in the scheduling pool, and the new file is integrated into the global application instance management set. Status updates and invalid file cleanup are performed to obtain the target application instance scheduling pool. This enhances the accurate monitoring capability of the application instance mounting status, improves the structured level of the mapping between associated records and business nodes, and enhances the effectiveness and consistency of scheduling pool data maintenance.

[0108] In some embodiments, before performing queue scheduling processing on the queue of application instances to be loaded to obtain the application instance loading sequence, the method further includes: obtaining historical behavior data; performing application access prediction processing on the historical behavior data to obtain a predicted application identifier; and performing preloading triggering processing based on the predicted application identifier to obtain the queue of application instances to be loaded.

[0109] Specifically, historical behavior data can be a collection of data recording past user or system operations. This historical behavior data can be time-series data that characterizes user access patterns, operating habits, or system operating status. It can serve as the basis for predictive model analysis and can be used to identify the application patterns that users are about to access, thereby providing data support for preloading decisions. This historical behavior data can be obtained through user behavior log collection or system monitoring and can be used to characterize information such as user access paths, application dwell time, and access frequency. This historical behavior data can also include timestamps of user access to applications, application identifiers, session identifiers, and operation type fields, etc., without limitation here.

[0110] In addition, application access prediction processing can be a data processing process that uses data analysis or machine learning algorithms to infer the applications that users will access in the future based on historical behavioral data. This application access prediction processing can model and predict user behavior patterns, thereby proactively identifying the applications that users are most likely to load next, thus triggering resource preparation in advance and reducing user waiting time.

[0111] This application access prediction processing can be based on sequence prediction models, such as Markov chains or recurrent neural networks, to analyze the user's historical access sequences, calculate the probability distribution of the next most likely application to be accessed, and output the application identifier with the highest probability as the prediction result, thus obtaining the predicted application identifier.

[0112] In addition, the preload triggering process can initiate a data processing flow for application resource loading and instantiation preparation based on the prediction results. This preload triggering process can transform the prediction logic into actual resource scheduling actions, thereby converting the predicted application identifier into specific application loading tasks to be executed, and scheduling them into the queue of application instances to be loaded, in preparation for subsequent queue scheduling processing.

[0113] Specifically, the preload triggering process can create a loading task description object containing the predicted application identifier and its related configuration information, and insert the loading task description object into an appropriate position in the queue of application instances to be loaded. For example, it can be sorted according to the prediction confidence or application priority, thereby forming an optimized loading sequence, i.e., the queue of application instances to be loaded.

[0114] For example, in an enterprise portal system based on a micro-frontend architecture, with user authorization, the backend can continuously collect user operation logs as historical behavior data. When it is detected that a user viewed the HR application in the morning and then processed the financial reimbursement process, the application access prediction processing can predict the next application that the user may visit during the current user's access to the HR application, which is the financial reimbursement application, and generate a corresponding predicted application identifier. The preload triggering processing can add the loading task of the financial reimbursement application to the queue of application instances to be loaded based on the predicted application identifier.

[0115] According to the technical solution provided in this disclosure, historical behavior data recording past user operations is obtained through user authorization. This historical behavior data is then processed for application access prediction. A sequence prediction model is used to analyze user access patterns, inferring the next most likely application to be accessed, thus obtaining a predicted application identifier. Based on this predicted application identifier, preloading triggering processing is performed, creating a loading task description object containing the predicted application identifier and configuration information, and inserting it into an appropriate position in the queue of application instances to be loaded, thereby obtaining a queue of application instances to be loaded. This enhances the intelligent analysis and prediction capabilities of user behavior patterns; improves the initiative and response speed of application loading; and enhances the smoothness of the user access experience and the foresight of resource scheduling.

[0116] In some embodiments, the application instance loading sequence is subjected to status verification processing based on the identifier matching result to obtain a status verification result, including: performing matching processing on the application instance loading sequence based on preset application instance matching conditions and identifier matching results to obtain a matching application instance; performing version consistency verification processing on the matching application instance to obtain a version verification result; performing runtime status survival detection processing on the matching application instance to obtain an instance survival status identifier; and performing verification processing based on the version verification result and the instance survival status identifier to obtain a status verification result.

[0117] Specifically, the preset application instance matching conditions can be a set of pre-defined rules that can be used to filter application instances. The form of the preset application instance matching conditions can be a set of logical judgment conditions that can be used to determine the instances in the application instance loading sequence that meet the current loading requirements. In this way, combined with the identification matching results, candidate application instances can be filtered from the application instance loading sequence. The preset application instance matching conditions can be rules pre-configured according to the application deployment strategy and can be used to characterize information such as the loading priority, resource dependency, or business relevance of application instances.

[0118] The application instance loading sequence is matched based on the preset application instance matching conditions and the identifier matching results. This can be achieved by combining the application instance identity information provided by the identifier matching results with the filtering logic framework provided by the preset application instance matching conditions, and then locating the target instance from the application instance loading sequence to obtain the matching application instance.

[0119] Among them, the matching application instance can be an application instance that meets all the conditions and is selected from the application instance loading sequence through matching processing. This matching application instance can be used as a candidate reuse object to enter the subsequent verification process.

[0120] For example, in an application management system based on a micro-frontend architecture, when a user switches from one business module to another, a new sub-application needs to be loaded. The system can obtain the application identifier of the current request, and based on preset application instance matching conditions, such as the application type being a business processing class and memory usage being below a threshold, and combined with the identifier matching results, it can traverse and compare the application instance loading sequence to filter out application instances that meet all the conditions as the matching application instances.

[0121] In addition, version consistency verification is a data processing process that verifies the version information of the selected matching application instances. This version consistency verification process checks whether the current running version of the application instance is consistent with the version required by the current request. This ensures that the reused application instances are compatible with the current requirements in terms of functionality, interface and dependency, and avoids functional abnormalities or runtime errors caused by version differences.

[0122] The version consistency verification process may specifically include reading the version metadata of the matching application instance, comparing it with the target version number carried in the current loading request, or checking whether the versions of its dependent libraries meet the compatibility requirements, and obtaining the version verification result.

[0123] The version verification result can be a determination of whether the version of the matching application instance is consistent with the version required by the current request. The version verification result can be in the form of a boolean value or an enumeration value. When the versions are consistent, it can be "consistent"; when the versions are inconsistent, it can be "inconsistent".

[0124] For example, in a micro-frontend architecture, when the main application requests to load a chart analysis sub-application, the loaded chart analysis application instance can be obtained through matching. The version number of the instance can be checked to see if it is a specific value. The current request requires a version of that specific value or higher. After verification, a version verification result indicating that the versions are consistent can be generated.

[0125] In addition, the runtime liveness detection process is a data processing procedure that detects whether the application instance is currently in a running state that can respond to requests normally. This runtime liveness detection process can determine whether the application instance is alive and functioning normally by checking the process status or listening to specific events. This can confirm that the reused application instance exists and is in a healthy and usable state, thereby ensuring the reliability of subsequent loading or switching operations.

[0126] Specifically, the liveness detection process can be achieved by injecting a lightweight detection script into the sandbox or container of the matching application instance. This detection script can execute an Application Programming Interface (API) call or return a status code. Based on the response result, it can determine whether the instance is alive and obtain the instance liveness status identifier.

[0127] The instance liveness status identifier can be used to determine whether the matching application instance is currently alive and functioning normally. The instance liveness status identifier can be in the form of a boolean value or an enumeration value. When the instance is alive and functioning normally, it can be identified as alive; when the instance fails or functions abnormally, it can be identified as failed.

[0128] For example, for a matched loaded sub-application instance, a status query request can be sent to its sandbox environment. If a successful response is received within a preset time, an instance liveness status identifier indicating that the instance is alive can be generated; if the timeout occurs or there is no response, an instance liveness status identifier indicating that the instance has failed can be generated.

[0129] In addition, the verification process can be a logical data processing process that combines the conclusions of version consistency verification and runtime status liveness detection to make a judgment on the overall availability of the matching application instance. This verification process can be based on the version verification result and the instance liveness status identifier, performing logical AND or other combined logical operations to output a comprehensive verification conclusion, thereby generating a status verification result. This status verification result can be used to determine whether to reuse the matching application instance or reload a new instance.

[0130] Specifically, the verification process can be a Boolean logic judgment: the status verification result is considered successful and reusable only if the version verification result indicates that the versions are consistent and the instance liveness status indicator indicates that the instance is alive; otherwise, the status verification result is considered unsuccessful and needs to be reloaded.

[0131] According to the technical solution provided in this disclosure, the application instance loading sequence is matched based on preset application instance matching conditions and identifier matching results. The identity information provided by the identifier matching results is combined with the filtering rules to locate the matching application instance. The matching application instance is then subjected to version consistency verification to check whether its version metadata is consistent with the target version of the current loading request, and a version verification result is obtained. The matching application instance is then subjected to runtime status liveness detection by sending a status query request to determine whether the instance is alive and functioning normally, and an instance liveness status identifier is obtained. Verification is performed based on the version verification result and the instance liveness status identifier. When the versions are consistent and the instance is alive, the status verification result is "verification passed"; otherwise, the verification fails, and a status verification result is obtained. This enhances the comprehensive verification capability of application instance filtering and version compatibility; improves the real-time detection accuracy of application instance liveness status; and enhances the reliability and security of resource reuse decisions.

[0132] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0133] Figure 3 This is a schematic diagram of another front-end application instance management method provided in this embodiment of the disclosure. For example... Figure 3 As shown, this front-end application instance management method includes: 1. Application Queue Management Algorithm: The core objective of this algorithm is to manage the loading order of sub-applications, ensuring that only one sub-application is loading or mounting at any given time, thus avoiding resource conflicts and performance issues caused by concurrent loading. Its workflow follows a strict "First In First Out" (FIFO) principle, supplemented by priority scheduling and concurrency control strategies.

[0134] Core data structure: The system maintains three key data records, including: The queue to be loaded is a first-in, first-out queue (the queue of application instances to be loaded) used to store information about all sub-applications waiting to be loaded, and is recorded as an array of sub-applications (sub-Applications Array, subApps).

[0135] Loaded Application Pool: A list that records all successfully mounted sub-application instances and their key information, recorded as an array of loaded sub-applications (Loaded Sub Applications Array, loadedSubApps).

[0136] Application under processing flag: A single flag indicating whether a sub-application is currently being processed (loaded or mounted). It is recorded as the Processing Sub Application Flag (processSubapp) variable, with an initial value of empty.

[0137] Application queuing and triggering process: When a sub-application is requested to be loaded, the following steps can be performed: Application information encapsulation. The system encapsulates the received sub-application information, including its attached container identifier (such as DOM container ID) and node name, into a standard data object, Sub Application Information Object (subappInfo).

[0138] The encapsulated data object is added to the end of the waiting queue `subApps`. At this point, the application enters a waiting state, and the current queue state is recorded.

[0139] After an application is added to the queue, the queue handling function (handleSubapp) is called to start checking if the next application can be processed.

[0140] Queue processing and scheduling flow: The queue processing function handleSubapp is the execution engine of the entire algorithm, and its core logic is as follows: Status checks. After the function is called, it checks two conditions: whether the queue of apps to be loaded, `subApps`, is empty, and whether there is an app currently being processed (i.e., whether `processSubapp` is true). If the queue is empty, or an app is being processed, the function will return without performing any operation and output the log "Queue empty or an app is being processed, return directly".

[0141] Retrieve the application to be processed. If the status check passes (the queue is not empty and there is no application being processed), you can retrieve the application information from the head of the subApps queue (i.e., the first application enqueued) and assign it to processSubapp, marking it as the application being processed.

[0142] Duplicate loading detection. Before officially starting the loading process, the "Is Sub Application Loaded" (isSubAppLoaded) function in the "Resource Reuse Detection Algorithm" can be called to determine if the application has already been loaded. If the application is detected to have already been loaded, the log "Already loaded, will not be loaded again" can be output.

[0143] Process the next application. If the current application doesn't need to be processed due to repeated loading, the next application in the queue can be processed by delaying and asynchronously calling the handleSubapp function again.

[0144] Perform application loading. If the detection finds that the application has not yet been loaded, the Load Application (loadApplication) function in the "Smart Load Orchestration Algorithm" can be called to perform the actual loading and mounting operations.

[0145] Queue management strategy: FIFO (First In First Out): This is the default and most basic queue processing order, ensuring fairness in application loading requests.

[0146] Priority scheduling: Building upon the basic strategy, the solution supports setting priorities based on application type (e.g., core applications, non-core applications). Applications with higher priority can be dynamically inserted at the head of the queue, thus achieving priority loading.

[0147] Concurrency control: By using the "processSubapp" mechanism, only one application can be executing the loading or mounting process at the same time, thus avoiding problems such as DOM resource conflicts and script execution order disorder that may be caused by multiple applications loading at the same time.

[0148] 2. Resource Reuse Detection Algorithm: The core objective of this algorithm is to avoid repeatedly loading and mounting the same sub-application, thereby saving system resources and improving loading efficiency. Its core principle is to determine whether an application has already been mounted by matching the "container identifier".

[0149] The core process of container-level reuse detection is as follows: When the queue processing function is about to load an application, it can call the isSubAppLoaded function to determine its performance. Get the current container identifier. Call the `getContainer` function to extract the container identifier that will be mounted from the application information (`processSubapp`) being processed. This identifier is usually a unique ID of the DOM container.

[0150] Iterate through the loaded application pool. You can iterate through all records in the "loaded application pool" loadedSubApps and check the container identifier stored in each record.

[0151] Perform a match. Compare the container identifier of the current application with the container identifiers of all records in the pool one by one.

[0152] Returns the detection result. Based on the comparison result, a Boolean value is returned. If a match is found, "Loaded" (true) is returned; if no match is found, "Not Loaded" (false) is returned.

[0153] Update records after mounting: When a new sub-application is successfully mounted, the "Loaded Applications Pool" can be updated by calling the functions on Sub Application Mounted, onSubAppMounted: Information gathering. In the successful mounting callback function of the sub-application, the node name and container identifier of the currently mounted application can be obtained by using the getNodeName and getContainer functions.

[0154] Add to the application pool. You can encapsulate the above information, along with the application instance objects of the sub-applications, into a new record and add it to the end of the "Loaded SubApps" pool.

[0155] Status cleanup. You can set "Application ID in process" to empty to indicate that there is currently no application being processed.

[0156] Delay processing of the next application. You can call `handleSubapp` with two delays: for example, the first delay could be 1000 milliseconds, and the second could be 5000 milliseconds. These delays are used to handle subsequent operations after the application has finished loading and to ensure continuous processing of the queue.

[0157] Container identifier matching: Matching can be performed based on the DOM container ID.

[0158] Application status verification: When reusing, the status of the loaded application instance can be further checked to ensure that it is in an available state (such as not uninstalled or without errors) to avoid reusing invalid applications.

[0159] Version consistency: Even if the container identifiers match, if the version of the application to be loaded is inconsistent with the version of the already loaded application, it will not be reused. Instead, the old version can be uninstalled first, and then the new version can be loaded.

[0160] 3. Intelligent loading and orchestration algorithm: Receives instructions from the queue management algorithm and calls the API of the underlying micro-frontend framework to complete the specific operation.

[0161] Application loading and mounting process: When the queue management algorithm decides to load an application, it calls the loadApplication function and passes in the sub-application information: Environment assessment and entry point configuration. The current runtime environment is determined by checking if a variable indicates a development or production environment. Based on the environment, the entry point address for the sub-application is dynamically selected.

[0162] Build the application configuration. Combine the sub-application's name, entry address, mounting container, and custom properties that need to be passed to the sub-application into a complete configuration object. The custom properties include query parameters, such as the node name (nodeName).

[0163] Execute the loading. Call the `Load Micro Application` (`loadMicroApp`) function provided by the micro-frontend framework, passing in the configuration object, and trigger the resource loading and initialization process of the sub-application. This operation returns an application instance object representing the sub-application.

[0164] Loading status monitoring. This feature allows monitoring of the application instance's mountPromise (i.e., the asynchronous callback that occurs after mounting is complete). The Promise object will change to a "completed" state after the child application successfully mounts, and to a "rejected" state if mounting fails.

[0165] Successfully completed. When mountPromise completes successfully, a success callback can be triggered, outputting the log "Subapp mounted successfully". The onSubAppMounted function can be called to record the application's information in the "Loaded Apps Pool" and clear the "Processing App Identifier".

[0166] Failure handling. If mountPromise fails, a failure callback can be triggered, outputting the log "Subapp mount failed". The onSubAppMounted function can be called to record the failure status, but the purpose is to maintain the integrity of the process. To ensure the process is not interrupted, even if loading fails, it can be considered "processed", and the "processing application identifier" can be cleared.

[0167] Exception handling. If any synchronous error that is not caught by Promise occurs during execution, the exception can be caught and the error log "Loading subapp exception" will be output. You can clear `processSubapp` and immediately call the `handleSubapp` function to avoid blocking the entire loading queue due to an exception in a single application.

[0168] Performance Optimization: To improve user experience, the solution supports a preloading strategy, implemented through the `prefetchSubApp` function. The micro-frontend framework's `prefetchApps` function can be invoked during idle time or when a user is about to access a sub-application. Preloading only downloads the sub-application's static resources but does not instantiate or mount them, thus achieving near-instantaneous loading when the user actually clicks.

[0169] To free up system resources, especially when a user leaves a page or no longer needs a sub-application, the system provides an uninstallation mechanism: Unmount a specified sub-application: This is achieved through the unmountSubApp function, which receives the container identifier as a parameter.

[0170] Locate the target application. Based on the passed container identifier, use the findIndex method in the loadedApps pool to find the corresponding application record.

[0171] If no record is found, the return value can be -1, indicating that the application has not been loaded or has been uninstalled, and the process ends directly.

[0172] If found, the application instance can be retrieved from the record, and its provided unmount method can be called. This method cleans up DOM elements, event listeners, timers, and other resources generated by the child application on the page.

[0173] Update local records. After uninstallation, the corresponding records can be removed from the "Loaded Applications Pool" using the splice method to ensure state synchronization.

[0174] Uninstall all sub-applications: This is achieved using the unmountAllSubApp function.

[0175] When scenarios such as route redirection occur, you can use forEach to traverse the entire "loaded application pool" loadedSubApps and call the unmount method of each application instance one by one.

[0176] After uninstalling all applications, you can set the "loaded application pool" loadedSubApps to an empty array to completely release all micro-frontend application resources.

[0177] According to the technical solution provided in this disclosure, a queue management algorithm is used to maintain three core data structures: a queue to be loaded, a pool of loaded applications, and an application identifier in processing. This follows the FIFO principle and is supplemented by priority scheduling and concurrency control. When a sub-application is requested, the system encapsulates its information and adds it to the tail of the queue to be loaded. The queue processing function checks the status: if the queue is not empty and there is no application being processed, the application is retrieved from the head and marked as processing. After reuse detection, the loading function is called. The processing identifier ensures that only one application is in the loading or mounting process at any given time, avoiding resource conflicts. The resource reuse detection algorithm performs reuse determination using container identifiers before loading. The system extracts the mounting container ID of the current application, traverses the container identifiers recorded in the pool of loaded applications for matching. If a match exists, it is determined that the application is already loaded and duplicate loading is skipped. If it is a new application, after successful mounting, its application instance, container identifier, and node name are recorded in the pool of loaded applications, and the processing identifier is cleared, providing a basis for subsequent reuse. The intelligent loading orchestration algorithm executes specific loading operations according to queue instructions. The system dynamically selects the sub-application entry address through environment variables. After constructing a configuration object containing name, entry point, container, and custom attributes, it calls the loading function of the micro-frontend framework to trigger resource loading and initialization. By monitoring the mounting period, the application pool is updated and the processing status is cleared upon success; in case of failure or exception, the status is also cleared and the processing queue continues, ensuring that a single point of failure does not block the overall process. In addition, the solution supports a pre-loading strategy to download resources in advance during idle periods and provides a specified uninstallation and full uninstallation mechanism based on container status. By calling the instance uninstallation method and updating the application pool, resources are released in a timely manner.

[0178] The following are embodiments of the apparatus disclosed herein, which can be used to execute embodiments of the method disclosed herein. For details not disclosed in the apparatus embodiments of this disclosure, please refer to the embodiments of the method disclosed herein.

[0179] Figure 4 This is a schematic diagram of a front-end application instance management device provided in an embodiment of this disclosure. Figure 4 As shown, the front-end application instance management device includes: The first processing module 401 is used to perform queue scheduling processing on the queue of application instances to be loaded, so as to obtain the application instance loading sequence. The second processing module 402 is used to perform resource reuse detection processing on the application instance loading sequence based on the preset container identifier, and obtain the reuse judgment result; The third processing module 403 is used to perform configuration information arrangement processing on the application instance loading sequence based on the reuse determination result to obtain the target application instance. The fourth processing module 404 is used to associate and store the target application instance with the preset container identifier to obtain the target application instance scheduling pool.

[0180] According to the technical solution provided in this disclosure, an application instance loading sequence is obtained by performing queue scheduling processing on the queue of application instances to be loaded; resource reuse detection processing is performed on the application instance loading sequence based on a preset container identifier to obtain a reuse judgment result; configuration information orchestration processing is performed on the application instance loading sequence based on the reuse judgment result to obtain a target application instance; the target application instance and the preset container identifier are associated and stored to obtain a target application instance scheduling pool. In this way, resource reuse detection processing improves resource utilization efficiency and network bandwidth utilization, queue scheduling processing enhances the concurrency control capability and execution order controllability of the application loading process, configuration information orchestration processing improves application switching response speed and initialization efficiency and reduces memory occupancy, and associated storage processing enhances the state consistency and memory management fineness of multiple application instances.

[0181] In some embodiments, the second processing module 402 is specifically used to: match a preset container identifier with an application instance loading sequence to obtain an identifier matching result; perform state verification processing on the application instance loading sequence based on the identifier matching result to obtain a state verification result; and perform reuse determination processing on the identifier matching result and the state verification result to obtain a reuse determination result.

[0182] In some embodiments, the third processing module 403 is specifically used to: activate and display the application instance loading sequence to obtain the target application instance when the reuse determination result is reuse; perform environment judgment processing on the preset application entry address to obtain the target entry configuration when the reuse determination result is non-reuse; and load the application instance loading sequence based on the target entry configuration to obtain the target application instance.

[0183] In some embodiments, the first processing module 401 is specifically used to: perform priority attribute identification processing on the queue of application instances to be loaded to obtain a priority identifier; perform sorting and adjustment processing on the queue of application instances to be loaded based on the priority identifier to obtain a priority scheduling queue; perform concurrency control detection processing on the priority scheduling queue to obtain a queue scheduling status identifier; and perform sequence generation processing on the queue scheduling status identifier to obtain an application instance loading sequence.

[0184] In some embodiments, the fourth processing module 404 is specifically used to: perform mounting status monitoring processing on the target application instance to obtain a loading completion signal; perform association recording processing on the target application instance, the preset container identifier, and the preset node name field based on the loading completion signal to obtain an application instance file; and perform scheduling pool update processing on the application instance file to obtain a target application instance scheduling pool.

[0185] In some embodiments, the aforementioned front-end application instance management device is further configured to: acquire historical behavior data; perform application access prediction processing on the historical behavior data to obtain a predicted application identifier; and perform preloading triggering processing based on the predicted application identifier to obtain a queue of application instances to be loaded.

[0186] In some embodiments, performing status verification processing on the application instance loading sequence based on the identifier matching result to obtain the status verification result specifically involves: performing matching processing on the application instance loading sequence based on preset application instance matching conditions and identifier matching results to obtain a matching application instance; performing version consistency verification processing on the matching application instance to obtain a version verification result; performing runtime status liveness detection processing on the matching application instance to obtain an instance liveness status identifier; and performing verification processing based on the version verification result and the instance liveness status identifier to obtain the status verification result.

[0187] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this disclosure.

[0188] Figure 5 This is a schematic diagram of the electronic device 5 provided in an embodiment of this disclosure. Figure 5 As shown, the electronic device 5 of this embodiment includes: a processor 501, a memory 502, and a computer program 503 stored in the memory 502 and executable on the processor 501. When the processor 501 executes the computer program 503, it implements the steps in the various method embodiments described above. Alternatively, when the processor 501 executes the computer program 503, it implements the functions of each module / unit in the various device embodiments described above.

[0189] Electronic device 5 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 5 may include, but is not limited to, processor 501 and memory 502. Those skilled in the art will understand that... Figure 5 This is merely an example of electronic device 5 and does not constitute a limitation on electronic device 5. It may include more or fewer components than shown, or different components.

[0190] The processor 501 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0191] The memory 502 can be an internal storage unit of the electronic device 5, such as a hard disk or RAM of the electronic device 5. The memory 502 can also be an external storage device of the electronic device 5, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the electronic device 5. The memory 502 can also include both internal and external storage units of the electronic device 5. The memory 502 is used to store computer programs and other programs and data required by the electronic device.

[0192] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0193] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0194] The above embodiments are only used to illustrate the technical solutions of this disclosure, and are not intended to limit it. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be included within the protection scope of this disclosure.

Claims

1. A method for managing front-end application instances, characterized in that, include: Perform queue scheduling on the queue of application instances to be loaded to obtain the application instance loading sequence; Based on the preset container identifier, the application instance loading sequence is subjected to resource reuse detection processing to obtain the reuse determination result; Based on the reuse determination result, the configuration information of the application instance loading sequence is arranged and processed to obtain the target application instance; The target application instance and the preset container identifier are associated and stored to obtain the target application instance scheduling pool.

2. The front-end application instance management method according to claim 1, characterized in that, The resource reuse detection process based on the preset container identifier for the application instance loading sequence is performed to obtain a reuse determination result, including: The preset container identifier and the application instance loading sequence are matched to obtain the identifier matching result; Based on the identifier matching result, the application instance loading sequence is subjected to state verification processing to obtain the state verification result; The identifier matching result and the state verification result are subjected to reuse determination processing to obtain the reuse determination result.

3. The front-end application instance management method according to claim 1, characterized in that, The step of arranging configuration information for the application instance loading sequence based on the reuse determination result to obtain the target application instance includes: If the reuse determination result is reuse, the application instance loading sequence is activated and displayed to obtain the target application instance; If the reuse determination result is no reuse, the preset application entry address is subjected to environment judgment processing to obtain the target entry configuration; The target application instance is obtained by loading the application instance loading sequence based on the target entry configuration.

4. The front-end application instance management method according to claim 1, characterized in that, The process of scheduling the queue of application instances to be loaded to obtain the application instance loading sequence includes: The priority attribute identification process is performed on the queue of application instances to be loaded to obtain priority identifiers; Based on the priority identifier, the queue of application instances to be loaded is sorted and adjusted to obtain a priority scheduling queue. The priority scheduling queue is subjected to concurrent control detection processing to obtain the queue scheduling status identifier; The application instance loading sequence is obtained by performing sequence generation processing based on the queue scheduling status identifier.

5. The front-end application instance management method according to claim 1, characterized in that, The step of associating and storing the target application instance and the preset container identifier to obtain the target application instance scheduling pool includes: The mounting status of the target application instance is monitored to obtain a loading completion signal; Based on the loading completion signal, the target application instance, the preset container identifier, and the preset node name field are associated and recorded to obtain the application instance file; The application instance file is updated with a scheduling pool to obtain the target application instance scheduling pool.

6. The front-end application instance management method according to claim 1, characterized in that, Before performing queue scheduling processing on the queue of application instances to be loaded to obtain the application instance loading sequence, the process further includes: Obtain historical behavior data; The historical behavior data is processed for application access prediction to obtain the predicted application identifier; Based on the predicted application identifier, a preloading triggering process is performed to obtain the queue of application instances to be loaded.

7. The front-end application instance management method according to claim 2, characterized in that, The state verification process for the application instance loading sequence based on the identifier matching result, to obtain the state verification result, includes: The application instance loading sequence is matched based on the preset application instance matching conditions and the identifier matching results to obtain a matching application instance. The matching application instance is subjected to version consistency verification to obtain the version verification result; Perform runtime status survival detection processing on the matched application instance to obtain the instance survival status identifier; The verification process is performed based on the version verification result and the instance liveness status identifier to obtain the status verification result.

8. A front-end application instance management device, characterized in that, include: The first processing module is used to perform queue scheduling processing on the queue of application instances to be loaded, so as to obtain the application instance loading sequence. The second processing module is used to perform resource reuse detection processing on the application instance loading sequence based on a preset container identifier, and obtain a reuse determination result. The third processing module is used to perform configuration information arrangement processing on the application instance loading sequence based on the reuse determination result to obtain the target application instance. The fourth processing module is used to associate and store the target application instance and the preset container identifier to obtain the target application instance scheduling pool.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images