Memory management method and device, equipment and storage medium

Abstract

The invention discloses a memory management method and device, equipment and a storage medium, and the method comprises the steps: analyzing a template code in an editing stage of the template code of a Vue single file component, so as to determine each piece of target data; generating a rendering function by each piece of target data; running the rendering function to create a virtual DOM, and in the creation process, determining each target object conforming to the static mark management range; and recovering each target object to a pre-obtained memory management library. According to the method, firstly, the template codes are analyzed, the target data in the template codes are determined, then the rendering function is generated, the virtual DOM is created, all the target objects conforming to the static mark management range are determined, which data need to be subjected to memory management are determined, and finally the data are migrated to the independent memory management library. According to the method, the number of large and complex object graphs in a JavaScript heap is greatly reduced, and the traversal depth and calculation burden of a garbage collector are reduced.

Description

Technical Field

[0001] This application relates to the field of memory management technology, specifically to a memory management method, apparatus, device, and storage medium. Background Technology

[0002] As the complexity of front-end applications continues to increase, the widespread use of modern frameworks such as Vue.js in large single-page applications (SPAs) and complex interactive interfaces has posed unprecedented challenges to the browser's memory management mechanism. Modern front-end frameworks rely on the virtual DOM to achieve efficient rendering, but frequent view updates lead to a surge in heavy objects such as the virtual DOM tree and state objects, causing the main thread to be blocked and resulting in user experience issues such as page lag and frame rate drops.

[0003] Current technology still relies on manual memory management, which increases development complexity and is very inefficient. Summary of the Invention

[0004] In view of this, this application provides a memory management method, apparatus, device, and storage medium to solve the problem that the existing technology still relies on manual memory management, which increases development complexity and has very low efficiency.

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

[0006] Firstly, a memory management method includes:

[0007] During the editing phase of the Vue single-file component template code, the template code is parsed to determine the various target data.

[0008] Rendering functions are generated from the target data.

[0009] The rendering function is run to create a virtual DOM, during which each target object that falls within the scope of static tag management is determined;

[0010] Each of the target objects is recycled to the pre-acquired memory management library.

[0011] Preferably, the step of generating a rendering function from each of the target data includes:

[0012] The target data includes various element types, various attributes, and various child nodes;

[0013] The initial template tree structure is constructed from each of the aforementioned element types, attributes, and child nodes;

[0014] Traverse the initial template tree structure. When traversing to the child node corresponding to the virtual node creation statement, inject the preset special identifier into the child node to obtain the first template tree structure.

[0015] The rendering function is generated from the first template tree structure.

[0016] Preferably, the target object includes each Vue component instance, and after determining each Vue component instance as the target object, it further includes:

[0017] Establish a memory monitor to periodically scan each of the Vue component instances;

[0018] Calculate the memory usage and survival metrics for each Vue component instance;

[0019] Based on the memory usage and survival metrics, one or more target component instances are selected from each of the Vue component instances.

[0020] Preferably, calculating the memory usage metrics for each Vue component instance includes:

[0021] For each Vue component instance, the basic memory usage of the template code is determined based on that Vue component instance.

[0022] Iterate through all associated objects of the Vue component instance and calculate the total memory size of the Vue component instance itself and all associated objects;

[0023] Get all functions of the Vue component instance, analyze the scope chain of each function to determine the external variables referenced by the closure, and calculate the total memory value of each external variable.

[0024] The memory usage index is obtained by adding the basic memory usage of the component, the total memory size, and the total memory value of the variables.

[0025] Preferably, determining the basic memory footprint of the template code based on the Vue component instance includes:

[0026] Determine the total initial heap memory usage of the template code before instantiation of the Vue component instance;

[0027] Determine the total amount of the second heap memory for the template code after the Vue component instance is mounted;

[0028] Calculate the difference between the total amount of the first heap memory and the total amount of the second heap memory to obtain the basic memory usage of the component.

[0029] Preferably, the calculation process of the survival index includes:

[0030] A counter is created for this Vue component instance so that the counter can monitor and accumulate the number of times the Vue component instance is mounted and updated in real time;

[0031] The mounting rate of the number of mountings is calculated according to a preset mounting threshold; at the same time, the update rate of the number of updates is calculated according to a preset update threshold.

[0032] The survival index is obtained by weighted summation of the mounting rate and update rate.

[0033] Preferably, the target object includes each Vue component instance, each virtual DOM tree, and each nested virtual DOM subtree;

[0034] The step of recycling each of the target objects to the pre-acquired memory management library includes:

[0035] The pre-acquired memory management library is used to partition and lay out the memory into a stable area, an active area, and a transition area;

[0036] Traverse each virtual DOM tree and store the virtual DOM trees that have not changed after N consecutive renderings in the stable area at a preset first recycling cycle;

[0037] Traverse each of the nested virtual DOM subtrees. For each nested virtual DOM subtree, if the dynamic component that generated the nested virtual DOM subtree is a newly created component, then recycle the nested virtual DOM subtree in the transition area with a preset second recycling cycle.

[0038] If the dynamic component that generates the nested virtual DOM subtree meets the preset active rendering index, then the nested virtual DOM subtree is recycled in the active area at a preset second recycling cycle;

[0039] Each of the Vue component instances is recycled into the stable region.

[0040] In a second aspect, a memory management device includes:

[0041] The target data acquisition module is used to parse the template code during the editing phase of Vue single-file component template code to determine each target data.

[0042] A rendering function generation module is used to generate rendering functions from the various target data.

[0043] The target object determination module is used to run the rendering function to create a virtual DOM, and during the creation process, it determines each target object that conforms to the scope of static tag management;

[0044] The recycling module is used to recycle each of the target objects into a pre-acquired memory management library.

[0045] Thirdly, a memory management device includes a memory and a processor;

[0046] The memory is used to store programs;

[0047] The processor is configured to execute the program to implement the steps of the memory management method as described in any of the first aspects.

[0048] Fourthly, a storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the memory management method as described in any of the first aspects.

[0049] As can be seen from the above technical solution, this application parses the template code during the editing stage of Vue single-file component template code to determine various target data; generates rendering functions from the various target data; runs the rendering functions to create a virtual DOM, and during the creation process, determines various target objects that conform to the scope of static tag management; and recycles each target object to a pre-acquired memory management library. This application first parses the template code during the editing stage of Vue single-file component template code to determine the target data, then generates rendering functions, that is, edits and solidifies the information of the target data identified in the previous step into the final executed rendering function, and then runs the rendering function to create a virtual DOM. During the creation process, it is necessary to determine various target objects that conform to the scope of static tag management. This step is to determine which data needs to be managed in memory, and finally migrates it to an independent memory management library, thereby significantly reducing the number of large and complex object graphs in the JavaScript heap and reducing the traversal depth and computational burden of the garbage collector.

[0050] This application provides a compile-time and runtime collaborative memory management method. By migrating specific target objects in the Vue single-file component template code to an independent memory management library for unified and efficient management, it fundamentally solves the problems of main thread blocking, untimely memory reclamation, and page lag caused by the traditional JavaScript garbage collection mechanism when dealing with large-scale, long-lifecycle Vue components. It greatly improves memory management efficiency, realizes the transformation from passive recycling to active management, and thus significantly improves the running performance and user experience of front-end applications. Attached Figure Description

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

[0052] Figure 1 An optional flowchart of a memory management method provided in an embodiment of this application;

[0053] Figure 2 This is a schematic diagram of the structure of a memory management device provided in an embodiment of this application;

[0054] Figure 3 This is a schematic diagram of the structure of a memory management device provided in an embodiment of this application. Detailed Implementation

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

[0056] As the complexity of front-end applications continues to increase, the widespread use of modern frameworks such as Vue.js in large single-page applications (SPAs) and complex interactive interfaces has posed unprecedented challenges to the browser's memory management mechanism. Modern front-end frameworks rely on the virtual DOM to achieve efficient rendering, but frequent view updates lead to a surge in heavy objects such as the virtual DOM tree and state objects (heavy objects refer to long-lived and memory-intensive JavaScript objects such as the virtual DOM tree and large-scale state objects), causing the main thread to be blocked, resulting in GC pauses (thread blocking caused by JavaScript engine garbage collection, causing interface lag), frame rate drops, and other user experience issues.

[0057] Current technology still relies on manual memory management, which increases development complexity and is very inefficient.

[0058] To address the shortcomings of the prior art, embodiments of the present invention provide a memory management method. This method can be applied to various computer terminals or smart terminals, and its execution entity can be the processor or server of the computer terminal or smart terminal. The present invention can be used in numerous general-purpose or special-purpose computing device environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, and distributed computing environments including any of the above devices, etc.

[0059] The flowchart of the method is as follows: Figure 1 As shown, it specifically includes:

[0060] S1: During the editing phase of the Vue single-file component template code, the template code is parsed to determine the various target data.

[0061] This step intervenes at the earliest possible stage of compilation, enabling proactive planning of memory management. By statically analyzing the Vue single-file component template code, it can accurately identify target data with high memory reclamation value (such as large static node trees, dynamic component placeholders, etc.), laying the foundation for subsequent targeted management. Compared with runtime dynamic analysis, this avoids the performance overhead of performing analysis and calculations on the user side.

[0062] One approach is to use Vue's compiler to parse the template code into an abstract syntax tree. This abstract syntax tree describes the structure of the template code, including element types, attributes, child nodes, etc. The element types, attributes, and child nodes are the target data.

[0063] S2: Generate rendering functions from the target data.

[0064] This step encodes and solidifies the target data information identified in the previous step into the final execution rendering function, ensuring the determinism and consistency of management. The generated rendering function is equivalent to having built-in memory management instructions, completing the initial classification of objects at the same time as creating the DOM, eliminating the computational overhead of secondary identification and judgment at runtime, and improving overall efficiency.

[0065] S3: Run the rendering function to create a virtual DOM, and during the creation process, determine each target object that falls within the scope of static tag management.

[0066] When the rendering function performs the core task of creating the virtual DOM, it synchronously and instantly marks virtual nodes that meet the scope of static tag management (such as the number of subtree nodes exceeding the threshold, or being a KeepAlive component) as target objects according to the instructions embedded in the compilation stage. These target objects are the data that need to be managed in memory.

[0067] S4: Recycle each of the target objects into the pre-acquired memory management library.

[0068] By migrating marked target objects and their associated data to a separate memory management library (such as Wasm GC, which refers to the garbage collection extension of WebAssembly that supports the lifecycle of managed objects across languages), the isolation of memory space and the specialization of management strategies are achieved. This greatly reduces the number of large and complex object graphs in the JavaScript heap, reduces the traversal depth and computational burden of the garbage collector, and makes the pause time of JS GC shorter and more predictable.

[0069] For the target objects, they can obtain more efficient and accurate memory lifecycle management in a management library optimized for long-lived, large-memory objects.

[0070] As can be seen from the above technical solution, this application parses the template code during the editing stage of Vue single-file component template code to determine various target data; generates rendering functions from the various target data; runs the rendering functions to create a virtual DOM, and during the creation process, determines various target objects that conform to the scope of static tag management; and recycles each target object to a pre-acquired memory management library. This application first parses the template code during the editing stage of Vue single-file component template code to determine the target data, then generates rendering functions, that is, edits and solidifies the information of the target data identified in the previous step into the final executed rendering function, and then runs the rendering function to create a virtual DOM. During the creation process, it is necessary to determine various target objects that conform to the scope of static tag management. This step is to determine which data needs to be managed in memory. Finally, the data is migrated to an independent memory management library, which significantly reduces the number of large and complex object graphs in the JavaScript heap, reduces the traversal depth and computational burden of the garbage collector, and makes the JS GC pause time shorter and more predictable.

[0071] This application provides a compile-time and runtime collaborative memory management method. By migrating specific target objects in the Vue single-file component template code to an independent memory management library for unified and efficient management, it fundamentally solves the problems of main thread blocking, untimely memory reclamation, and page lag caused by the traditional JavaScript garbage collection mechanism when dealing with large-scale, long-lifecycle Vue components. It greatly improves memory management efficiency, realizes the transformation from passive recycling to active management, and thus significantly improves the running performance and user experience of front-end applications.

[0072] The process of generating rendering functions from the target data in the method provided by this invention is described in detail below:

[0073] The target data includes various element types, various attributes, and various child nodes;

[0074] The initial template tree structure is constructed from each of the aforementioned element types, attributes, and child nodes;

[0075] Traverse the initial template tree structure. When traversing to the child node corresponding to the virtual node creation statement, inject the preset special identifier into the child node to obtain the first template tree structure.

[0076] The rendering function is generated from the first template tree structure.

[0077] Specifically, during the compilation phase, this application marks the generated virtual DOM nodes so that, in a runtime environment that supports garbage collection, these marked virtual DOM subtrees can be managed and garbage collected more efficiently.

[0078] After constructing the initial template tree structure from element types, attributes, and child nodes, the initial template tree structure is traversed, that is, each child node in the initial template tree structure is traversed. When the child node corresponding to the virtual node creation statement is traversed, that is, when this child node represents the "virtual node creation statement" in the code, this is a concept in the final generated JavaScript code, referring to those function calls that create virtual DOM nodes, then a preset special identifier is injected into this child node, which will modify this node, that is, inject a special identifier, such as "__wasmGC__", into the function call of this virtual node creation statement, and obtain the first template tree structure.

[0079] Then, the Vue compiler can generate the final JavaScript code, i.e., the rendering function, from this first template tree structure.

[0080] The process of determining each Vue component instance as the target object in this application is described in detail below.

[0081] Establish a memory monitor to periodically scan each of the Vue component instances;

[0082] Calculate the memory usage and survival metrics for each Vue component instance;

[0083] Based on the memory usage and survival metrics, one or more target component instances are selected from each of the Vue component instances.

[0084] Specifically, the target object includes various Vue component instances. This step provides a detailed explanation of Vue component instances. Among them, a memory monitor can be set up to periodically scan each Vue component instance. Then, two metrics of Vue component instances need to be monitored: one is the memory usage metric, and the other is the survival metric.

[0085] The memory usage metric for a Vue component instance refers to the total memory usage of the Vue component instance object itself and all associated objects. Associated objects include all reactive data, external variables referenced in closures, and references to associated DOM elements. The lifespan metric refers to the survival status of the Vue component instance during the rendering cycle.

[0086] Specifically, the step of calculating the memory usage metric for each Vue component instance in the above process may include:

[0087] For each Vue component instance, the basic memory usage of the template code is determined based on that Vue component instance.

[0088] Iterate through all associated objects of the Vue component instance and calculate the total memory size of the Vue component instance itself and all associated objects;

[0089] Get all functions of the Vue component instance, analyze the scope chain of each function to determine the external variables referenced by the closure, and calculate the total memory value of each external variable.

[0090] The memory usage index is obtained by adding the basic memory usage of the component, the total memory size, and the total memory value of the variables.

[0091] Specifically, a Vue component instance itself includes the memory structure of the Vue component object, including methods, properties, prototype chain, etc.; component configuration options, including methods, computed properties, watch, etc.; and the instance's lifecycle hooks, etc.; all associated objects include the reactive data system, such as all reactive objects returned by data(), all properties received through props, cached results of computed properties, and the dependency tracking structure created by the Vue reactive system for each property; it also includes the virtual DOM subtree, including the complete virtual node tree rendered by the current component, properties of each virtual node, child node references, dynamic tags, directive information, etc.; it also includes external variables referenced by closures, such as external scope variables referenced in component methods, external environment captured by event handlers, and external data referenced in asynchronous callbacks; and it also includes DOM-related references, such as the actual DOM elements corresponding to the component and bound events.

[0092] Therefore, when calculating the memory usage of a Vue component instance, it is necessary to consider the total memory size of the Vue component instance itself and all associated objects. For example, the total memory size can be determined by analyzing the memory size of the above data.

[0093] During the calculation, the total memory size is determined to include three memory components: the component's base memory usage, the total memory size, and the total memory value of variables.

[0094] The process of determining the basic memory usage of the template code based on the Vue component instance in the above process can include the following steps:

[0095] Determine the total initial heap memory usage of the template code before instantiation of the Vue component instance;

[0096] Determine the total amount of the second heap memory for the template code after the Vue component instance is mounted;

[0097] Calculate the difference between the total amount of the first heap memory and the total amount of the second heap memory to obtain the basic memory usage of the component.

[0098] The calculation process for survival indicators in the above process includes:

[0099] A counter is created for this Vue component instance so that the counter can monitor and accumulate the number of times the Vue component instance is mounted and updated in real time;

[0100] The mounting rate of the number of mountings is calculated according to a preset mounting threshold; at the same time, the update rate of the number of updates is calculated according to a preset update threshold.

[0101] The survival index is obtained by weighted summation of the mounting rate and update rate.

[0102] Specifically, the survival metric refers to the number of cycles a Vue component instance survives. To calculate this metric, a counter needs to be created to monitor and accumulate the number of times the Vue component instance is mounted and updated in real time. For example, 1 point is added for each completed mounting and 0.5 points are added for each completed data update. There is a time limit; within a preset time period, the accumulated number of mountings and updates is compared with their respective thresholds to determine the mounting rate and update rate. Then, a weighted sum is performed to calculate the survival metric. For example, the weight of the mounting rate can be set to 0.6, and the weight of the update rate can be set to 0.4.

[0103] The following embodiments provide a detailed explanation of the steps in this application for reclaiming each of the target objects into a pre-acquired memory management library.

[0104] The pre-acquired memory management library is used to partition and lay out the memory into a stable area, an active area, and a transition area;

[0105] Traverse each virtual DOM tree and store the virtual DOM trees that have not changed after N consecutive renderings in the stable area at a preset first recycling cycle;

[0106] Traverse each of the nested virtual DOM subtrees. For each nested virtual DOM subtree, if the dynamic component that generated the nested virtual DOM subtree is a newly created component, then recycle the nested virtual DOM subtree in the transition area with a preset second recycling cycle.

[0107] If the dynamic component that generates the nested virtual DOM subtree meets the preset active rendering index, then the nested virtual DOM subtree is recycled in the active area at a preset second recycling cycle;

[0108] Each of the Vue component instances is recycled into the stable region.

[0109] Specifically, the target objects include each Vue component instance, each virtual DOM tree, and each nested virtual DOM subtree. The virtual DOM tree refers to the root-level virtual DOM tree, which is a tree structure containing more than 50 child nodes. Marking the entire tree as a whole facilitates subsequent batch memory management and recycling, avoiding traversing a large number of small objects. The nested virtual DOM subtree refers to the nested virtual DOM subtree generated by dynamic components. That is, when the compiler creates placeholder virtual nodes for dynamic components, it injects a mark. When the dynamic component is parsed and rendered, the entire nested subtree it generates will be considered as the marked range. This is because dynamic components themselves are uncertain, and the lifecycle of their entire subtree is different from that of the parent component. Therefore, marking it as a whole helps to track this "potentially changing" block of memory during memory management.

[0110] To improve adaptability and flexibility, different recycling methods are adopted to consider different target components. Recycling can be triggered when a preset time threshold is reached, adopting a timed recycling method. It can also monitor the memory pressure of the memory management library in real time and perform dynamic recycling.

[0111] For the virtual DOM tree, due to its large structure, it is not frequently reconstructed and is therefore relatively stable. A stable region can be selected. The characteristics of the data recycled in the stable region can include: large memory usage but no change after multiple renderings, long recycling cycle, and long-term residence.

[0112] For nested virtual DOM subtrees, you can choose to swap the active area and the transition area because their lifecycle is not very certain and they may switch frequently.

[0113] For Vue component instances, which exist for a long time but may become inactive, a stabilizer is chosen. However, a four-layer reference counting approach can be used for fine-grained lifecycle management and control. This includes basic counting: using a built-in counter from a memory management library; recording the number of Vue components bound to the object to implement component association; implementing event listening by counting mounted DOM event listeners; and implementing cross-language reference counting based on the number of JS object references. Then, when all four layers simultaneously reach zero, the memory is immediately released.

[0114] Furthermore, this application creates a bidirectional mapping mechanism between JavaScript and the memory management library, including forward mapping and reverse mapping. Forward mapping refers to JS object ID → memory address of the memory management library + object type metadata; reverse mapping refers to memory address of the memory management library → weak reference of the JS object. Automatic cleanup based on the FinalizationRegistry is also established, including registering finalizer callbacks for JS-side proxy objects; automatically decrementing the Wasm-side reference count when the JS engine reclaims proxy objects; and verifying the consistency of the mapping table every 10 seconds to implement heartbeat detection.

[0115] Furthermore, this application also employs a dual-GC scheduler, which is a decision-making module that coordinates the execution timing of the JS engine's GC and WasmGC.

[0116] A frame interval timer is embedded in the `requestAnimationFrame` callback to calculate the instantaneous frame rate (frame rate = 1000ms / adjacent callback interval). When 10 consecutive frames have a frame rate > 55fps and a fluctuation < 5%, it is considered a rendering idle period. A dynamic GC time window is allocated: a base of 50ms + (current frame rate - 55) × 2ms (with an upper limit of 20ms). A predictive model is built to make dynamic decisions by continuously collecting three key parameters: the trigger interval of the last 20 JavaScript garbage collection events, the heap memory growth rate, and the main thread blocking duration. First, a weighted average trigger interval is calculated based on historical data, with the last three garbage collection events assigned 60% weight and the historical average accounting for 40%. Then, dynamic adjustments are made based on real-time memory pressure: when the heap memory growth rate exceeds 5MB per second, the predicted interval is shortened by 15%; if there are uncollected large objects exceeding 500KB, the predicted value is further shortened by 25%. Finally, when the model determines that the next JS garbage collection will occur within 200 milliseconds, the execution of WebAssembly garbage collection is proactively delayed until the JavaScript garbage collection process is completely finished before triggering it.

[0117] For the memory management library, a priority scheduling strategy is implemented. If the memory management library is currently in the Vue.patch phase, all GC tasks are paused. If a user interaction event is triggered, the memory management library is delayed until the idle period. In other cases, the reclamation of non-overlapping memory regions is performed in parallel.

[0118] This application also develops framework lifecycle hooks to trigger object migration / release operations during Vue's beforeMount / beforeUnmount phases. During the mounting phase, the beforeMount hook serializes the virtual DOM tree into a Wasm-manageable structure (preserving reactive links). During the update phase, the beforeUpdate hook compares the differences between the old and new virtual DOMs, only transferring the changed subtrees to WasmGC management. During the unmount phase, the beforeUnmount hook notifies WasmGC to release associated memory and remove cross-language references. Furthermore, priority markers are implemented for high-frequency and low-frequency components. For high-frequency components, a PRIORITY_HIGH marker is used, and the virtual DOM is retained in Wasm for 10 rendering cycles. For low-frequency components, a PRIORITY_LOW marker is used, and the virtual DOM is released immediately after rendering.

[0119] It also implements an adaptive rollback strategy, which dynamically adjusts the retention time of the virtual DOM in the memory management library according to the component update frequency. For example, when the memory management library is short of memory, it automatically rolls back to the JS heap and enables the incremental marking strategy. Whenever Vue data changes, it verifies the validity of the pointers between the JS proxy object and the memory management library to ensure that it has been executed.

[0120] and Figure 1 Corresponding to the method described above, embodiments of the present invention also provide a memory management device for... Figure 1 In the specific implementation of the method, the memory management device provided in this embodiment of the invention can be integrated into a computer terminal or various mobile devices. Figure 2 This section introduces memory management devices, such as... Figure 2 As shown, the device may include:

[0121] The target data acquisition module 10 is used to parse the template code during the editing stage of the Vue single-file component template code to determine each target data.

[0122] The rendering function generation module 20 is used to generate rendering functions from the various target data.

[0123] The target object determination module 30 is used to run the rendering function to create a virtual DOM, and during the creation process, it determines each target object that conforms to the scope of static tag management.

[0124] The recycling module 40 is used to recycle each of the target objects into a pre-acquired memory management library.

[0125] As can be seen from the above technical solution, this application parses the template code during the editing stage of Vue single-file component template code to determine various target data; generates rendering functions from the various target data; runs the rendering functions to create a virtual DOM, and during the creation process, determines various target objects that conform to the scope of static tag management; and recycles each target object to a pre-acquired memory management library. This application first parses the template code during the editing stage of Vue single-file component template code to determine the target data, then generates rendering functions, that is, edits and solidifies the information of the target data identified in the previous step into the final executed rendering function, and then runs the rendering function to create a virtual DOM. During the creation process, it is necessary to determine various target objects that conform to the scope of static tag management. This step is to determine which data needs to be managed in memory. Finally, the data is migrated to an independent memory management library, which significantly reduces the number of large and complex object graphs in the JavaScript heap, reduces the traversal depth and computational burden of the garbage collector, and makes the JS GC pause time shorter and more predictable.

[0126] This application provides a compile-time and runtime collaborative memory management method. By migrating specific target objects in the Vue single-file component template code to an independent memory management library for unified and efficient management, it fundamentally solves the problems of main thread blocking, untimely memory reclamation, and page lag caused by the traditional JavaScript garbage collection mechanism when dealing with large-scale, long-lifecycle Vue components. It greatly improves memory management efficiency, realizes the transformation from passive recycling to active management, and thus significantly improves the running performance and user experience of front-end applications.

[0127] Furthermore, embodiments of this application provide a memory management device. Optionally, Figure 3 A hardware block diagram of the memory management device is shown, with reference to... Figure 3 The hardware structure of the memory management device may include: at least one processor 01, at least one communication interface 02, at least one memory 03, and at least one communication bus 04.

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

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

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

[0131] The memory stores a program, which the processor can call to execute. The program is used to perform the following memory management methods, including:

[0132] During the editing phase of the Vue single-file component template code, the template code is parsed to determine the various target data.

[0133] Rendering functions are generated from the target data.

[0134] The rendering function is run to create a virtual DOM, during which each target object that falls within the scope of static tag management is determined;

[0135] Each of the target objects is recycled to the pre-acquired memory management library.

[0136] Optionally, the refined and extended functions of the program can be found in the description of the memory management method in the method embodiments.

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

[0138] During the editing phase of the Vue single-file component template code, the template code is parsed to determine the various target data.

[0139] Rendering functions are generated from the target data.

[0140] The rendering function is run to create a virtual DOM, during which each target object that falls within the scope of static tag management is determined;

[0141] Each of the target objects is recycled to the pre-acquired memory management library.

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

[0143] Optionally, the refined and extended functions of the program can be found in the description of the memory management method in the method embodiments.

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

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

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

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

Claims

1. A memory management method characterized by comprising: The method comprises the following steps: In the editing stage of the Vue single file component template code, the template code is parsed to determine each target data; A rendering function is generated from each target data; The rendering function is run to create a virtual DOM, and in the creation process, each target object that meets the static tag management range is determined; Each target object is recycled into a pre-acquired memory management library.

2. The method of claim 1, wherein, The rendering function generated from each target data comprises: The target data comprises each element type, each attribute, and each child node; An initial template tree structure is constructed from each element type, attribute, and child node; The initial template tree structure is traversed, and when a child node corresponding to a virtual node creation statement is traversed, a preset special identifier is injected into the child node to obtain a first template tree structure; The rendering function is generated from the first template tree structure.

3. The method of claim 1, wherein, Each Vue component instance is included in the target object, and after each Vue component instance is determined as a target object, the following steps are further included: A memory monitor is established to periodically scan each Vue component instance using the memory monitor; The memory occupation index and survival index of each Vue component instance are calculated; One or more target component instances are selected from each Vue component instance according to the memory occupation index and survival index.

4. The method of claim 3, wherein, The memory occupation index of each Vue component instance is calculated, comprising: For each Vue component instance, the component base memory occupation of the template code is determined based on the Vue component instance; All associated objects of the Vue component instance are traversed to calculate the total memory size of the Vue component instance itself and all associated objects; All functions of the Vue component instance are obtained, the scope chain of each function is analyzed to determine each external variable referenced by the closure, and the total variable memory value of each external variable is counted; The component base memory occupation, total memory size, and total variable memory value are added to obtain the memory occupation index.

5. The method of claim 4, wherein, The component base memory occupation of the template code is determined based on the Vue component instance, comprising: The first heap memory total amount of the template code before the instantiation of the Vue component instance is determined; The second heap memory total amount of the template code after the mounting of the Vue component instance is determined; The difference between the first heap memory total amount and the second heap memory total amount is calculated to obtain the component base memory occupation.

6. The method of claim 3, wherein, The survival index calculation process comprises: A counter is created for the Vue component instance to monitor and accumulate the mounting times and update times of the Vue component instance in real time; The mounting rate of the mounting times is calculated according to a preset mounting threshold, and the update rate of the update times is calculated according to a preset update threshold; The mounting rate and update rate are weighted and summed to obtain the survival index.

7. The method according to any one of claims 1 to 6, characterized in that, The target object comprises each Vue component instance, each virtual DOM tree, and each nested virtual DOM sub-tree; The recycling of each target object into the pre-acquired memory management library comprises: The pre-acquired memory management library is subjected to memory partition layout to form a stable area, an active area and a transition area; Each of the virtual DOM trees is traversed, and the virtual DOM trees without changes in continuous N times of rendering are stored to be recycled in the stable area with a preset first recycling period; Each of the nested virtual DOM sub-trees is traversed, and for each of the nested virtual DOM sub-trees, if a dynamic component generating the nested virtual DOM sub-tree is a newly created component, the nested virtual DOM sub-tree is recycled in the transition area with a preset second recycling period; If the dynamic component generating the nested virtual DOM sub-tree meets a preset active rendering index, the nested virtual DOM sub-tree is recycled in the active area with the preset second recycling period; Each of the Vue component instances is recycled in the stable area.

8. A memory management device, characterized by Comprise: A target data obtaining module, configured to parse a template code of a Vue single file component in an editing stage of the template code to determine each target data; A rendering function generating module, configured to generate a rendering function from each of the target data; A target object determining module, configured to create a virtual DOM by running the rendering function, and determine each target object meeting a static mark management range in a creating process; A recycling module, configured to recycle each of the target objects into a pre-acquired memory management library.

9. A memory management device, characterized by Comprise a memory and a processor; The memory is configured to store a program; The processor is configured to execute the program to implement each step of the memory management method according to any one of claims 1-7.

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

Images