Tab page management method and device based on micro front end and electronic equipment

Abstract

The invention discloses a tab management method and device based on a micro front end and electronic equipment, and relates to the field of front-end architecture and resource management. The method comprises the steps that each label page is mapped into an independent sub-application, resources of the independent sub-applications are loaded through a micro-front-end framework, and an independent running environment is created for each sub-application through a double-layer sandbox; dynamically binding each label page with a parameterized path, and establishing a unique identifier of each label page; when the tab page is loaded for the first time, caching the complete state of the tab page during operation according to the unique identifier of the tab page; and when a user switches the tab page, analyzing the unique identifier of the tab page, and multiplexing the complete state of the cache corresponding to the tab page according to the unique identifier. The technical problem of natural contradictions between isolation and collaboration and between performance and stability in a micro-front-end multi-label-page scene in the prior art is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of front-end architecture and resource management, and particularly relates to a tab page management method and device based on micro front-end and electronic equipment. BACKGROUND

[0002] At present, with the increasing complexity of enterprise-level web applications, multi-tab page management has become a core requirement for improving user operation efficiency. Traditional multi-tab page solutions are mainly implemented based on single-page application (SPA) frameworks (such as Vue and React), and the tab page state is retained through route management and component caching technology. Multiple page components are loaded in parallel in a single running environment, and JavaScript global variables and CSS styles lack isolation mechanisms, resulting in variable pollution and style conflicts. Long-running tab pages may occupy memory due to incomplete unloading of resources, causing system lag and even crashes. Data sharing between different tab pages relies on global state libraries (such as Vuex), and under the micro front-end architecture, there is a lack of standardized solutions for state synchronization between the main application and sub-applications and between sub-applications. When performing cross-tab page operations (such as batch editing), data updates may cause state inconsistencies due to asynchronous loading or cache invalidation. If sub-applications developed by multiple teams may use different UI frameworks, the visual style and interaction logic between tab pages may not be uniform, and the opening, closing, and refreshing of tab pages rely on scattered logic and lack of unified APIs. When a large number of tab pages are concurrently running, traditional multi-tab page technology cannot dynamically adjust resource allocation, which may easily cause performance degradation. A single tab page failure may affect the overall system stability.

[0003] Therefore, how to solve the natural contradiction between isolation and cooperation, performance and stability in the micro front-end multi-tab page scenario is an urgent problem. SUMMARY

[0004] Embodiments of the present application provide a micro front-end based tab page management method, device and electronic equipment, which can solve the technical problem of the natural contradiction between isolation and cooperation, performance and stability in the micro front-end multi-tab page scenario in the prior art. The technical solution is as follows:

[0005] In a first aspect, embodiments of the present application provide a micro front-end based tab page management method, comprising:

[0006] Each tab page is mapped to an independent sub-application, the resources of the independent sub-application are loaded through a micro front-end framework, and a double-layer sandbox is used to create an independent running environment for each sub-application;

[0007] Each tab page is dynamically bound to a parameterized path to establish a unique identifier for each tab page;

[0008] When the tab page is first loaded, cache the complete state of the tab page runtime according to the unique identification of the tab page;

[0009] When the user switches the tab page, parse the unique identification of the tab page, and reuse the cached complete state of the tab page according to the unique identification.

[0010] In some embodiments of the present application, the double-layer sandbox is used to create an independent running environment for each sub-application, including:

[0011] The JS proxy sandbox is used to intercept global variable operations, and the CSS class name prefix isolation technology is used to limit the style scope of each independent sub-application, so as to create an independent running environment for each sub-application.

[0012] In some embodiments of the present application, the unique identification of each tab page is established by dynamically binding the tab page and the parameterized path, including:

[0013] The preset extension dynamic routing protocol is used to dynamically bind the tab page and the parameterized path, and generate the unique identification of each tab page;

[0014] According to the unique identification of each tab page, the LRU strategy is used to manage the sub-application instance cache queue corresponding to each tab page.

[0015] In some embodiments of the present application, the complete state of the tab page runtime is cached, including:

[0016] The DOM memory snapshot of the VM instance of each tab page is cached.

[0017] In some embodiments of the present application, further comprising:

[0018] When the number of cached complete states of the tab page runtime exceeds a set threshold, the least frequently used cache is discarded according to the LRU strategy.

[0019] In some embodiments of the present application, further comprising:

[0020] The hash fingerprint of each sub-application resource is calculated, a unique hash identification is generated, and the unique hash identification is stored in a resource pool;

[0021] When the tab page is newly opened, the unique hash identification of the tab page is determined, and it is checked whether the same unique hash identification exists in the resource pool;

[0022] If it exists, the cached complete state of the tab page is reused.

[0023] In some embodiments of the present application, further comprising:

[0024] Adopt a rolling trigger lazy loading strategy to delay the loading of non-first-screen tab page resources to the time when the user actually needs to trigger.

[0025] In some embodiments of the application, further comprising:

[0026] Real-time monitoring of the resource occupancy rate of each tab page, triggering a three-level degradation operation of the tab page when the resource occupancy rate exceeds the occupancy threshold or the occupancy time threshold; wherein the three-level degradation operation includes hiding the DOM of the abnormal tab page, unloading the sub-application to release resources, and removing the routing and cache instance.

[0027] In a second aspect, the application further provides a micro-frontend-based tab page management device, comprising:

[0028] An isolation module is configured to map each tab page as an independent sub-application, load resources of the independent sub-application through a micro-frontend framework, and create an independent running environment for each sub-application using a double-layer sandbox;

[0029] An identification establishment module is configured to dynamically bind each tab page with a parameterized path, and establish a unique identification of each tab page;

[0030] A cache module is configured to cache a complete state of a runtime of the tab page according to the unique identification of the tab page when the tab page is loaded for the first time;

[0031] A multiplexing module is configured to parse the unique identification of the tab page when the user switches the tab page, and multiplex the complete state of the tab page corresponding to the cache according to the unique identification.

[0032] In a third aspect, the application further provides an electronic device, comprising a processor and a memory;

[0033] The memory has stored thereon a computer readable program that can be executed by the processor;

[0034] The processor executes the computer readable program to implement the steps in the micro-frontend-based tab page management method described above.

[0035] In a fourth aspect, the application further provides a computer readable storage medium, which stores one or more programs that can be executed by one or more processors to implement the steps in the micro-frontend-based tab page management method described above.

[0036] The technical scheme provided by some embodiments of the present application has at least the following beneficial effects: each tab page is mapped as an independent sub-application, resources of the independent sub-application are loaded through a micro-frontend framework, and a double-layer sandbox is used to create an independent running environment for each sub-application, so that resource pollution conflicts in the traditional multi-window mode are completely eliminated, sub-application resources are loaded only when a new tab page is activated by a user, and each tab page is dynamically bound with a parameterized path, and then when the tab page is loaded for the first time, the complete state of the runtime of the tab page is cached according to the unique identifier of the tab page; when a user switches tab pages, the unique identifier of the tab page is parsed, and the complete state cached by the tab page is reused according to the unique identifier, so that the first loading is reduced and the cache hit rate is improved. Therefore, a global state management mechanism is realized, data interaction between a main application and a sub-application can be performed through shared states, and data consistency between multiple tab pages is ensured. Meanwhile, the micro-frontend framework provides a state management capability across sub-applications, and data sharing and state synchronization in a complex scenario are further simplified. BRIEF DESCRIPTION OF DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0038] Figure 1 An exemplary system architecture of the micro-frontend-based tab page management method or the micro-frontend-based tab page management device provided by the present application;

[0039] Figure 2 A method flowchart of an embodiment of the micro-frontend-based tab page management method provided by the present application;

[0040] Figure 3 For Figure 1 In step S101, the sub-applications are isolated from each other through a sandbox mechanism.

[0041] Figure 4 For Figure 1 A flowchart of an embodiment of step S102;

[0042] Figure 5 A method flowchart of an embodiment of resource loading in the micro-frontend-based tab page management method provided by the present application;

[0043] Figure 6 A schematic diagram of an embodiment of the micro-frontend-based tab page management device provided by the present application;

[0044] Figure 7 is a structural schematic diagram of a terminal device provided by the present application. DETAILED DESCRIPTION

[0045] For the purpose, technical solutions and advantages of the present application to be clearer, the embodiments of the present application will be further described in detail below with reference to the drawings.

[0046] It should be noted that the micro-frontend-based tab page management method provided by the present application is generally executed by a terminal device, and correspondingly, the micro-frontend-based tab page management apparatus is generally arranged in the terminal device.

[0047] Figure 1 An exemplary system architecture that can be applied to the micro-frontend-based tab page management method or the micro-frontend-based tab page management apparatus of the present application is shown.

[0048] As shown in Figure 1 , the system architecture can include a terminal device 101 and a server 102. The terminal device 101 and the server 102 can communicate with each other through a network, which is a medium for providing a communication link between the above-mentioned units. The network can include various types of wired communication links or wireless communication links, such as optical fiber, twisted pair or coaxial cable, etc., and wireless communication links, such as Bluetooth communication link, wireless fidelity (WIreless-FIdelity, Wi-Fi) communication link or microwave communication link, etc.

[0049] It should be noted that the terminal device 101 and the server 102 can be hardware or software. When the terminal device 101 and the server 102 are hardware, they can be implemented as a distributed server cluster composed of multiple servers, or as a single server. When the terminal device 101 and the server 102 are software, they can be implemented as multiple software or software modules (for example, to provide distributed services), or as a single software or software module, which is not specifically limited here.

[0050] Various communication client applications can be installed on the terminal device of the present application, such as video recording applications, video playback applications, voice interaction applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0051] The terminal device can be hardware or software. When the terminal device is hardware, it can be various terminal devices with display screens, including but not limited to smartphones, tablet computers, laptop computers and desktop computers, etc. When the terminal device is software, it can be installed in the above-mentioned terminal devices. It can be implemented as multiple software or software modules (for example, to provide distributed services), or as a single software or software module, which is not specifically limited here.

[0052] When the terminal device is hardware, a display device and a camera can also be installed thereon, the display device can be various devices capable of realizing display function, and the camera is used to collect a video stream; for example, the display device can be a cathode ray tube display (CR), a light-emitting diode display (LED), an electronic ink screen, a liquid crystal display (LCD), a plasma display panel (PDP), etc. A user can use the display device on the terminal device to view displayed text, pictures, videos, etc.

[0053] It should be understood that Figure 1 The number of terminal devices, networks and servers in the above description is only illustrative. According to the needs of implementation, any number of terminal devices, networks and servers can be used.

[0054] The following will be described in conjunction with the accompanying Figure 2 The micro-frontend-based tab page management method provided by the embodiments of the present application will be described in detail. The micro-frontend-based tab page management device in the embodiments of the present application can be a terminal device as shown in Figure 1

[0055] Please refer to Figure 2 The embodiments of the present application provide a flowchart of a micro-frontend-based tab page management method.

[0056] As shown in Figure 2 The method of the embodiments of the present application can include the following steps:

[0057] S201, mapping each tab page as an independent sub-application, loading resources of the independent sub-application through a micro-frontend framework, and creating an independent running environment for each sub-application using a double-layer sandbox;

[0058] It should be noted that micro-frontend is an architectural style of splitting monolithic front-end applications into smaller, independent, independently developed, deployed and run "micro-applications".

[0059] The type of sandbox is not limited here. In a preferred embodiment, a JS proxy sandbox is used to intercept global variable operations, and a CSS class name prefix isolation technology is used to limit the style scope of each independent sub-application, to create an independent running environment for each sub-application, as shown in Figure 3 ​The JS proxy sandbox isolates the global variable operation of the sub-application by proxying the window attribute access through the Proxy object. The CSS class name prefix isolation technology injects a randomly generated unique class name prefix into the root node of the sub-application.

[0060] It should be noted that before mapping the tab page, the Qiankun main container needs to be loaded, the sub-application configuration (including the entry URL, routing rules) needs to be registered, the sandbox management module needs to be initialized, and the JS proxy sandbox and the CSS style isolation strategy need to be configured. Qiankun loads sub-application resources on demand, injects an independent sandbox environment, and CSS styles are isolated through the scoped attribute and a random class name prefix.

[0061] S202, dynamically bind each tab page to a parameterized path to establish a unique identifier for each tab page;

[0062] It should be noted that the tab page is dynamically bound to the parameterized path in order to associate independent sub-applications. In the sandbox isolation environment, the state confusion caused by the lack of a unique identifier for the tab page is avoided. Specifically, in one preferred embodiment, please refer to Figure 4 , including:

[0063] S401, dynamically bind the tab page to the parameterized path using a preset extension dynamic routing protocol to generate a unique identifier for each tab page;

[0064] S402, based on the unique identifier of each tab page, manage the sub-application instance cache queue corresponding to each tab page based on the LRU strategy.

[0065] In one specific embodiment, the user opens a new tab page to trigger the openTab(tabId) API to generate a unique tab page ID (such as tab_001). The YJPL4.0 extension Vue Router is added to add dynamic registration routes.

[0066] It should be noted that the dynamic routing extension Vue Router of YJPL4.0 realizes deep routing dynamic binding, supports parameterized path matching of the type / app / detail / :id, synchronously updates the tab page state identifier using route meta information, and integrates the Vue keep-alive component cache and the YJPL4.0 LRU algorithm to build a hybrid cache strategy, realizing DOM structure memory snapshot reuse, with a cache hit rate of more than 92%. It can flexibly configure and load routes according to business needs, greatly improving the scalability and maintainability of the system.

[0067] S203, when the tab page is first loaded, cache the complete state of the tab page runtime according to the unique identifier of the tab page;

[0068] S204, when the user switches the tab page, the unique identification of the tab page is parsed, and the complete state of the cache corresponding to the tab page is reused according to the unique identification.

[0069] It should be noted that when the user opens a new tab page, the path parameter is bound as a unique identification by the dynamic routing extension module YJPL4.0: for example, the path / order / detail / 1001 generates the tab page identification tab_1001. When the tab page is loaded for the first time, the DOM memory snapshot of the VM instance is saved to the cache pool, and the route identification is used as the Key. The cache pool structure is: {tab_1001: VM snapshot, tab_1002: VM snapshot...}. When the user switches the tab page to trigger the route jump (for example, switches to / order / detail / 1001): the target identification tab_1001 is parsed through the path, the Key value is matched in the LRU cache queue, and the VM snapshot is directly reused when hit.

[0070] In one specific embodiment, the keep-alive component combines the LRU strategy to retain the three most recently used tab page VM instances. The cache instance is directly reused when switching to avoid re-rendering.

[0071] Therefore, in the embodiment, through the micro front-end sandbox isolation, dynamic routing extension, intelligent resource scheduling, and global state synchronization technology, the core defects of the traditional multi-tab page system in resource isolation, performance, scalability, consistency, and stability are systematically solved, and an efficient and reliable multi-tab page management method is provided for high complexity and high concurrency enterprise-level Web applications. Each tab page is run as an independent sub-application through the Qiankun micro front-end architecture, the runtime environment is isolated through the double sandbox mechanism (JS agent sandbox / CSS style sandbox), resource conflicts are completely eliminated, and only sub-application resources are loaded when a new tab page is activated by the user. Combined with the YJPL4.0 dynamic routing extension, the Vue Router supports nested dynamic routing, realizes flexible binding of tab pages and paths, and supports dynamic registration of ten thousand routes. Based on the import-html-entry of Qiankun, the resource version management is built, the JS / CSS resources are reused across tab pages, the repeated requests are reduced, the master-sub application two-way communication channel is established, the real-time data synchronization across tab pages is supported, and the consistency is ensured. The standardized API is encapsulated to dynamically inject the master application theme variable into the sub-application, and the UI style error of multiple subsystems is ensured.

[0072] In some embodiments of the application, the method further comprises:

[0073] When the number of cached complete states of the tab page running exceeds a set threshold, the least used cache is eliminated according to the LRU strategy.

[0074] In the embodiment, the keep-alive is combined with the LRU elimination algorithm, and the high-frequency tab page VM instance is automatically cached to improve the cache hit rate.

[0075] In some embodiments of the application, refer to Figure 5 , and the method further comprises:

[0076] S501, calculating a hash fingerprint of each sub-application resource, generating a unique hash identifier, and storing the unique hash identifier in a resource pool;

[0077] S502, when a tab page is newly opened, determining the unique hash identifier of the tab page, and checking whether the same unique hash identifier exists in the resource pool;

[0078] S503, if it exists, the cached tab page complete state is reused.

[0079] In the embodiment, when the same sub-application is opened by multiple tab pages (such as 10 order / detail / :id tab pages), the JS / CSS resources are completely the same. In order to avoid repeated loading of the same resources (such as loading JS / CSS only once for 10 order tab pages), reduce network requests, and generate a unique identifier resHash by calculating a hash fingerprint (such as sha256), when a new tab page is opened by a user, it is checked whether the same resHash exists in the resource pool, and if it exists, the cached resource is reused; if it does not exist, it is loaded from the CDN and cached.

[0080] In some embodiments of the application, the method further comprises:

[0081] The loading of non-first-screen tab page resources is delayed to the time when the user actually needs to trigger by using a scroll-triggered lazy loading strategy.

[0082] In the embodiment, in order to solve the problem that non-first-screen resources (such as charts and long lists) in a tab page occupy a large amount of bandwidth, but the user may not need to view them immediately, resulting in a large resource occupation space, a scroll-triggered lazy loading strategy is used to delay the loading of non-first-screen tab page resources to the time when the user actually needs to trigger.

[0083] In some embodiments of the application, the method further comprises:

[0084] The resource occupation rate of each tab page is monitored in real time, and when the resource occupation rate exceeds an occupation threshold or an occupation time threshold, a three-level degradation operation of the tab page is triggered; wherein the three-level degradation operation includes hiding the DOM of the abnormal tab page, unloading the sub-application to release resources, and removing the route and the cache instance.

[0085] In the embodiment, the CPU / memory occupation rate of the tab page is collected in real time (such as cpuUsage>80% for 5 seconds), and a three-level degradation strategy is used:

[0086] Primary degradation (hidden): Set the abnormal tab DOM display:none, keep the process.

[0087] Secondary degradation (uninstall): Call qiankun.unmount(tabId) to release resources.

[0088] Tertiary degradation (destroyed): Completely remove the tab route and cache, and recycle the memory.

[0089] And define the abnormal threshold: cpuThreshold=80%,memThreshold=1GB.

[0090] Trigger condition: cpuUsage≥cpuThreshold||memoryUsage≥memThreshold.

[0091] The application has the following beneficial effects: by integrating the Qiankun micro front-end framework and the YJPL4.0 dynamic cache mechanism, the intelligent reuse and isolation management of cross-tab resources are realized, and the problems of resource repeated loading, sub-application environment conflict and insufficient support for complex workflow in traditional multi-tab technology are solved. The dynamic resource loading and isolation mechanism driven by micro front-end, the independent sandbox operation of sub-application, the JS / CSS sandbox isolation technology based on Qiankun framework, the binding of independent sub-application instance for each tab, ensure that the runtime environment (global variable, style, event) of each sub-application is completely isolated, and the resource pollution problem in the traditional multi-window mode is avoided. Through intelligent routing, the user operation behavior is analyzed to dynamically pre-load the resource package of high-priority sub-application, and the first loading delay is reduced by more than 30%. Through the intelligent cache and reuse technology of YJPL4.0, the three-level cache architecture of "memory-local storage-cloud", the resource type (static resource, dynamic data) is automatically selected to store level. Under the YJPL4.0 framework, the global state management mechanism is realized, and the main application and the sub-application can interact through shared state, ensuring the data consistency between multiple tabs. At the same time, Qiankun provides cross-sub-application state management capability, which further simplifies data sharing and state synchronization in complex scenarios. Through the dependency tree analysis of YJPL4.0, the conflict resources (such as the same CSS class) across sub-applications are identified, and namespaces are automatically added for isolation, completely solving the style pollution problem in the micro front-end environment.

[0092] The following is an embodiment of the device of the present application, which can be used to execute the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0093] Please refer to Figure 6Fig. 6 shows a structural diagram of a micro-frontend-based tab management apparatus provided by an example embodiment of the present application, hereinafter referred to as apparatus 6. The apparatus 6 can be implemented by software, hardware, or a combination of both to become all or part of a terminal device. The apparatus 6 comprises:

[0094] An isolation module 610 is configured to map each tab as an independent sub-application, load resources of the independent sub-application through a micro-frontend framework, and create an independent running environment for each sub-application using a double-layer sandbox.

[0095] An identification establishment module 620 is configured to dynamically bind each tab with a parameterized path and establish a unique identification of each tab.

[0096] A cache module 630 is configured to cache a complete state of a runtime of the tab according to the unique identification of the tab when the tab is loaded for the first time.

[0097] A multiplexing module 640 is configured to parse the unique identification of the tab and multiplex a complete state of the tab corresponding to the cache according to the unique identification when a user switches tabs.

[0098] In one or more possible embodiments, the creation of the independent running environment for each sub-application using the double-layer sandbox comprises:

[0099] The creation of the independent running environment for each sub-application using a JS proxy sandbox to intercept global variable operations and a CSS class name prefix isolation technology to limit a style scope of each independent sub-application.

[0100] In one or more possible embodiments, the dynamic binding of each tab with the parameterized path and the establishment of the unique identification of each tab comprises:

[0101] The dynamic binding of each tab with the parameterized path using a preset extension dynamic routing protocol and the generation of the unique identification of each tab.

[0102] The management of the sub-application instance cache queue corresponding to each tab based on an LRU strategy according to the unique identification of each tab.

[0103] It should be noted that the apparatus 6 provided by the above embodiments in the execution of the micro-frontend-based tab management method is only exemplified by the division of the above functional modules, and in actual applications, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the above functions. In addition, the micro-frontend-based tab management apparatus and the micro-frontend-based tab management method embodiments provided by the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0104] The above sequence numbers of the embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0105] The embodiment of the present application further provides a computer storage medium, which can store a plurality of instructions, the instructions being suitable for being loaded and executed by a processor to perform the method steps of the embodiments as shown in the above Figure 2 The specific execution process can refer to the specific description of the embodiments as shown in the above Figure 2 The specific execution process can refer to the specific description of the embodiments as shown in the above

[0106] The present application further provides a computer program product, which stores at least one instruction, the at least one instruction being loaded and executed by the processor to implement the micro-frontend-based tab page management method as described in each of the above embodiments.

[0107] Please refer to Figure 7 , which provides a structural schematic diagram of a terminal device. As shown in the above Figure 7 The terminal device 700 can include at least one processor 701, at least one network interface 704, a user interface 703, a memory 705, and at least one communication bus 702.

[0108] The communication bus 702 is used to realize the connection and communication between the components.

[0109] The user interface 703 can include a display screen (Display), a camera (Camera), and can optionally include a standard wired interface and a wireless interface.

[0110] The network interface 704 can optionally include a standard wired interface and a wireless interface (such as a WI-FI interface).

[0111] The processor 701 can include one or more processing cores. The processor 701 connects various parts within the terminal device 700 through various interfaces and lines, executes various functions of the terminal device 700 and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory 705, and calling data stored in the memory 705. Optionally, the processor 701 can be implemented in at least one of a hardware form of a digital signal processing (DSP), a field-programmable gate array (FPGA), and a programmable logic array (PLA). The processor 701 can integrate a combination of one or more of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes operating systems, user interfaces, and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; and the modem is used for processing wireless communication. It can be understood that the above-mentioned modem can also not be integrated into the processor 701, but can be realized by a separate chip.

[0112] The memory 705 can include a random access memory (RAM) and can also include a read-only memory (ROM). Optionally, the memory 705 includes a non-transitory computer-readable storage medium. The memory 705 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 705 can include a program storage area and a data storage area, wherein the program storage area can store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area can store data involved in the above-mentioned various method embodiments, etc. The memory 705 can also be at least one storage device located away from the aforementioned processor 701. As shown, the memory 705 as a computer storage medium can include an operating system, a network communication module, a user interface module, and an application program. Figure 7 As shown, the memory 705 as a computer storage medium can include an operating system, a network communication module, a user interface module, and an application program.

[0113] In Figure 7In the terminal device 700 shown, the user interface 703 is mainly used to provide an interface for user input, and obtain data input by the user; and the processor 701 can be used to call an application stored in the memory 505, and specifically execute the steps of the method shown in the above embodiments. Figure 2 The specific process can refer to the method shown in the above embodiments. Figure 2 The specific process can refer to the method shown in the above embodiments.

[0114] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by a computer program instructing related hardware. The program can be stored in a computer readable storage medium, and when the program is executed, the program can include the processes of the above-mentioned embodiments. The storage medium can be a magnetic disc, an optical disc, a read-only memory, a random access memory, etc.

[0115] The above only describes the preferred embodiments of the present application, and cannot limit the scope of the present application. Any equivalent changes made according to the claims of the present application are still within the scope of the present application.

Claims

1. A tab management method based on micro-frontend, characterized in that, The method comprises the following steps: mapping each tab page as an independent sub-application, loading resources of the independent sub-application through a micro-frontend framework, and creating an independent running environment for each sub-application by using a double-layer sandbox; dynamically binding each tab page with a parameterized path to establish a unique identifier of each tab page; when the tab page is first loaded, caching a complete state of a runtime of the tab page according to the unique identifier of the tab page; when a user switches a tab page, parsing the unique identifier of the tab page, and reusing a complete state of the tab page corresponding to the cached complete state according to the unique identifier.

2. The micro-frontend based tab management method of claim 1, wherein, The step of creating an independent running environment for each sub-application by using a double-layer sandbox comprises the following steps: using a JS proxy sandbox to intercept global variable operations, and using a CSS class name prefix isolation technology to limit a style scope of each independent sub-application, so as to create an independent running environment for each sub-application.

3. The micro-frontend based tab management method of claim 1, wherein, The step of dynamically binding each tab page with a parameterized path to establish a unique identifier of each tab page comprises the following steps: using a preset extension dynamic routing protocol to dynamically bind a tab page with a parameterized path, and generating a unique identifier of each tab page; based on an LRU strategy, managing a sub-application instance cache queue corresponding to each tab page according to the unique identifier of each tab page.

4. The micro-frontend based tab management method of claim 1, wherein, The step of caching a complete state of a runtime of the tab page comprises the following steps: caching a DOM memory snapshot of a VM instance of each tab page.

5. The micro-frontend based tab management method of claim 1, wherein, The method further comprises the following steps: when a number of cached complete states of runtimes of the tab pages exceeds a set threshold, discarding the least used cache according to an LRU strategy.

6. The micro-frontend based tab management method of claim 1, wherein, The method further comprises the following steps: calculating a hash fingerprint of each sub-application resource, generating a unique hash identifier, and storing the unique hash identifier in a resource pool; when a tab page is newly opened, determining a unique hash identifier of the tab page, and checking whether the resource pool contains the same unique hash identifier; if yes, reusing a cached complete state of the tab page.

7. The micro-frontend based tab management method of claim 1, wherein, The method further comprises the following steps: using a scroll-triggered lazy loading strategy to delay loading of resources of a non-first-screen tab page until the user actually needs to trigger.

8. The micro-frontend based tab management method of claim 1, wherein, The method further comprises the following steps: real-time monitoring of a resource occupancy rate of each tab page, triggering a three-level degradation operation of the tab page when the resource occupancy rate exceeds an occupancy threshold or an occupancy time threshold; wherein the three-level degradation operation comprises hiding a DOM of an abnormal tab page, unloading a sub-application to release resources, and removing a route and a cache instance. 9.A micro-frontend based tab management apparatus, characterized in that, The method comprises the following steps: an isolation module is configured to map each tab page as an independent sub-application, load resources of the independent sub-application through a micro-frontend framework, and create an independent running environment for each sub-application by using a double-layer sandbox; an identifier establishing module is configured to dynamically bind each tab page with a parameterized path to establish a unique identifier of each tab page; a caching module is configured to cache a complete state of a runtime of the tab page according to the unique identifier of the tab page when the tab page is first loaded; a reuse module is configured to parse the unique identifier of the tab page when a user switches a tab page, and reuse a complete state of the tab page corresponding to the cached complete state according to the unique identifier.

10. An electronic device, comprising: The method comprises the following steps: a processor and a memory; a computer readable program stored on the memory and executable by the processor. The processor implements the steps in the micro-frontend based tab management method as claimed in any one of claims 1-7 when executing the computer readable program. The processor implements the steps in the micro-frontend based tab management method as claimed in any one of claims 1-7 when executing the computer readable program.

Images