Front-end memory optimization method and system, electronic equipment and storage medium

Abstract

The invention provides a front-end memory optimization method and system, electronic equipment and a storage medium. The front-end memory optimization method comprises the steps that in the page initialization stage, multiple pieces of first data needing to be rendered are acquired; determining a label of each piece of rendered first data; the first data of which the label is a first type label is taken as second data, and the first type label is a label for automatically performing event monitoring; and rendering the second data into third data with a second type label according to a preset front-end framework, and displaying the third data on the page, the second type label being a label which does not perform event monitoring. According to the method and the device, the memory performance bottleneck caused by page rendering is solved, such as the problems of large memory usage, page lagging, white screen and long page rendering time.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a front-end memory optimization method and system, electronic device, and storage medium. Background Technology

[0002] In front-end development, issues such as slow page response, memory lag, unresponsive edit boxes, delayed menu switching, and blank screens are frequent, not only prolonging page rendering time but also severely impacting user experience. To address these problems, the front-end development field urgently needs performance optimization solutions that can effectively reduce page memory usage. Summary of the Invention

[0003] The present invention aims to solve at least one of the technical problems existing in the prior art or related art.

[0004] Therefore, the first aspect of the present invention proposes a front-end memory optimization method.

[0005] A second aspect of the present invention proposes a front-end memory optimization system.

[0006] A third aspect of the present invention provides an electronic device.

[0007] A fourth aspect of the present invention provides a storage medium.

[0008] In view of this, according to a first aspect of the present invention, a front-end memory optimization method is proposed, comprising: during the page initialization phase, acquiring multiple first data to be rendered; determining the tags that each first data will have after rendering; using the first data with tags of a first type as second data, wherein the first type tags are tags that automatically perform event listening; rendering the second data into third data with second type tags according to a preset front-end framework, and displaying it on the page, wherein the second type tags are tags that do not perform event listening.

[0009] The front-end memory optimization method provided by this invention specifically includes: During the page initialization phase, i.e., before the page is generated, acquiring multiple first data sets to be rendered (i.e., intercepting rendering data). These first data sets can be divided in the form of components, with each first data set representing a component. Then, determining the tags that each first data set will have after rendering. This can be understood as the component generating native tags after rendering; therefore, the tags that each first data set will have after rendering refer to the native tags generated after rendering. Next, the first data sets with tags of the first type are used as second data. That is, among the multiple first data sets, the first data sets whose generated tags are of the first type are identified and used as second data. Here, the first type tags refer to tags that automatically perform event listening. When the tags generated after data rendering are of the first type, these tags automatically bind to on-type event listeners and occupy corresponding space in memory. After determining the second tags, the second data is rendered according to a preset front-end framework. During the rendering process, the second data is rendered into third data with second type tags and displayed on the page. Here, the second type tags are tags that do not perform event listening. In other words, data that would normally be rendered as a first-type tag is presented as a second-type tag, thus preventing the third data from being bound to event listeners. For example, the style of the third data is completely identical to the second data. This means that the data obtained after normal rendering of the third and second data is identical in content and style, except for the tags and the absence of event listeners, so it is imperceptible to the user and does not affect normal use. Simultaneously, while rendering the second data, all other first data (excluding the second data) are rendered normally, ensuring page integrity. This invention, by defaulting to presenting data that would normally be rendered as a first-type tag as second-type tag data, prevents the corresponding data on the page from automatically binding event listeners, reducing the memory space occupied by event listeners and solving memory performance bottlenecks caused by page rendering, such as high memory usage, page lag, blank screens, and long page rendering times.

[0010] In some technical solutions, optionally, after rendering the second data into third data with a second type of tag according to a preset front-end framework and displaying it on the page, the front-end memory optimization method further includes: when the user edits the third data on the page, converting the second type of tag of the third data into a first type of tag.

[0011] In this technical solution, after rendering the second data into third data with second type tags according to the preset front-end framework and displaying it on the page, the front-end memory optimization method also includes: when the user edits the third data on the page, converting the second type tags of the third data into first type tags, that is, when the user performs an editing operation on the third data, dynamically converting the second type tags of the third data into first type tags, and binding a custom on-event listener, thereby monitoring the user's operation and monitoring the changes in the third data.

[0012] In some technical solutions, optionally, after the step of converting the second type label of the third data into the first type label, the front-end memory optimization method further includes: when the user finishes editing the third data, converting the first type label of the edited third data into the second type label.

[0013] In this technical solution, after converting the second type label of the third data to the first type label, the front-end memory optimization method also includes: when the user finishes editing the third data, converting the first type label of the edited third data to the second type label. That is, when the user switches to other labels, the first type label of the edited third data is converted back to the second type label to disconnect the event listener, thereby reducing memory usage.

[0014] In some technical solutions, optionally, the first type of tags includes: native input tags, native select tags, el-input components of the Element UI framework, and el-select components of the Element UI framework, and the second type of tags includes: span tags.

[0015] In this technical solution, the first type of tag includes native input / select tags, and el-input and el-select components from frameworks such as Element UI (an open-source user interface component library for front-end framework development). The second type of tag can be the span tag. It can be understood that native tags like input and select automatically bind event listeners, while span tags do not. Therefore, by presenting input and / or select tags as span tags, unnecessary event listeners can be reduced, significantly lowering memory usage and fundamentally solving a series of problems caused by performance bottlenecks.

[0016] According to a second aspect of the present invention, a front-end memory optimization system is proposed, comprising: a first acquisition module, configured to acquire multiple first data to be rendered during the page initialization phase; a first determination module, configured to determine the tag that each first data has after rendering; a first processing module, configured to use the first data with a tag of a first type as second data, wherein the first type tag is a tag that automatically performs event listening; and a second processing module, configured to render the second data into third data with a second type tag according to a preset front-end framework and display it on the page, wherein the second type tag is a tag that does not perform event listening.

[0017] The front-end memory optimization system provided by this invention specifically includes: a first acquisition module, a first determination module, a first processing module, and a second processing module. During the page initialization phase, i.e., before the page is generated, the first acquisition module acquires multiple first data sets to be rendered, i.e., intercepts rendering data. These multiple first data sets can be divided in the form of components, with each first data set representing a component. Subsequently, the first determination module determines the tags that each first data set will have after rendering. This can be understood as the component generating native tags after rendering; therefore, the tags that each first data set will have after rendering refer to the native tags generated after rendering. Then, the first processing module uses the first data sets with tags of the first type as second data. That is, it determines the first data sets with tags of the first type from among the multiple first data sets and uses these first data sets as second data. The first type tags refer to tags that automatically perform event listening. When the tags generated after data rendering are of the first type, these tags automatically bind to on-type event listeners and occupy corresponding space in memory. After determining the second tag, the second processing module renders the second data according to the preset front-end framework. During the rendering process, the second data is rendered as third data with a second type of tag and displayed on the page. The second type of tag is a tag that does not perform event listening. In other words, what would have been rendered as a first type of tag is presented as a second type of tag, thus preventing the third data from being bound to event listeners. For example, the style of the third data is completely consistent with the second data. That is, the data obtained after normal rendering of the third data and the second data are completely identical in content and style, except for the tags and the absence of event listening, so it will not be perceived by the user and will not affect normal user experience. Simultaneously, while rendering the second data, the other first data (excluding the second data) are also rendered normally, ensuring the integrity of the page. This invention, by defaulting to presenting data that would have been rendered as first type of tag as second type of tag data, prevents the corresponding data on the page from automatically binding event listeners, reducing the memory space occupied by event listeners and solving memory performance bottlenecks caused by page rendering, such as high memory usage, page lag, white screens, and long page rendering times.

[0018] In some technical solutions, the front-end memory optimization system may optionally include a third processing module, which is used to convert the second type of tags of the third data into first type tags when the user edits the third data on the page.

[0019] In this technical solution, the front-end memory optimization system also includes a third processing module. When a user edits third-level data on the page, the third processing module converts the second-type tags of the third-level data into first-type tags. That is, when the user edits the third-level data, the second-type tags are dynamically converted to first-type tags, and a custom on-event listener is bound, thereby monitoring the user's actions and changes to the third-level data.

[0020] In some technical solutions, the front-end memory optimization system may optionally include a fourth processing module, which is used to convert the first type label of the edited third data into a second type label when the user finishes editing the third data.

[0021] In this technical solution, the front-end memory optimization system also includes a fourth processing module. When the user finishes editing the third data, the fourth processing module converts the first type label of the edited third data into a second type label. In other words, when the user switches to other labels, the first type label of the edited third data is converted back to the second type label to disconnect the event listener, thereby reducing memory usage.

[0022] In some technical solutions, optionally, the first type of tags includes: native input tags, native select tags, el-input components of the Element UI framework, and el-select components of the Element UI framework, and the second type of tags includes: span tags.

[0023] In this technical solution, the first type of tag includes native input / select tags, and components such as el-input and el-select from frameworks like Element UI (an open-source user interface component library for front-end framework development). The second type of tag can be the span tag. It's understandable that native tags like input and select automatically bind event listeners, while span tags do not. Therefore, by presenting input and / or select tags as span tags, unnecessary event listeners can be reduced, significantly lowering memory usage and fundamentally solving a series of problems caused by performance bottlenecks.

[0024] According to a third aspect of the present invention, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the front-end memory optimization method as described above.

[0025] The electronic device provided by this invention, when the processor executes a computer program, implements the steps of the above-mentioned front-end memory optimization method, and can achieve the technical effects of any of the above technical solutions, which will not be elaborated here.

[0026] According to a fourth aspect of the invention, a storage medium is provided on which a computer program is stored, which, when executed by a processor, implements the steps of the front-end memory optimization method as described above.

[0027] The storage medium provided by this invention enables the computer program to implement the steps of the aforementioned front-end memory optimization method when executed by a processor, and can achieve the technical effects of any of the above technical solutions, which will not be elaborated further here.

[0028] Additional aspects and advantages of the invention will become apparent in the following description or may be learned by practice of the invention. Attached Figure Description

[0029] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 A flowchart illustrating a front-end memory optimization method according to an embodiment of the present invention is shown; Figure 2 A schematic block diagram of a front-end memory optimization system according to an embodiment of the present invention is shown; Figure 3 A schematic block diagram of an electronic device according to an embodiment of the present invention is shown. Detailed Implementation

[0030] To better understand the above-mentioned objectives, features, and advantages of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments of the present invention and the features thereof can be combined with each other.

[0031] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0032] Figure 1 A flowchart illustrating a front-end memory optimization method according to an embodiment of the present invention is shown. Specifically, the front-end memory optimization method includes: Step 102: During the page initialization phase, obtain multiple initial data that need to be rendered; Step 104: Determine the label that each first data point has after rendering; Step 106: Use the first data with the label of the first type of label as the second data, where the first type of label is a label that automatically listens for events; Step 108: Render the second data into third data with a second type of tag according to the preset front-end framework, and display it on the page. The second type of tag is a tag that does not perform event listening.

[0033] The front-end memory optimization method provided by this invention specifically includes: During the page initialization phase, i.e., before the page is generated, acquiring multiple first data sets to be rendered (i.e., intercepting rendering data). These first data sets can be divided in the form of components, with each first data set representing a component. Then, determining the tags that each first data set will have after rendering. This can be understood as the component generating native tags after rendering; therefore, the tags that each first data set will have after rendering refer to the native tags generated after rendering. Next, the first data sets with tags of the first type are used as second data. That is, among the multiple first data sets, the first data sets whose generated tags are of the first type are identified and used as second data. Here, the first type tags refer to tags that automatically perform event listening. When the tags generated after data rendering are of the first type, these tags automatically bind to on-type event listeners and occupy corresponding space in memory. After determining the second tags, the second data is rendered according to a preset front-end framework. During the rendering process, the second data is rendered into third data with second type tags and displayed on the page. Here, the second type tags are tags that do not perform event listening. In other words, data that would normally be rendered as a first-type tag is presented as a second-type tag, thus preventing the third data from being bound to event listeners. For example, the style of the third data is completely identical to the second data. This means that the data obtained after normal rendering of the third and second data is identical in content and style, except for the tags and the absence of event listeners, so it is imperceptible to the user and does not affect normal use. Simultaneously, while rendering the second data, all other first data (excluding the second data) are rendered normally, ensuring page integrity. This invention, by defaulting to presenting data that would normally be rendered as a first-type tag as second-type tag data, prevents the corresponding data on the page from automatically binding event listeners, reducing the memory space occupied by event listeners and solving memory performance bottlenecks caused by page rendering, such as high memory usage, page lag, blank screens, and long page rendering times.

[0034] In some embodiments, optionally, after the step of rendering the second data into third data with a second type of label according to a preset front-end framework and displaying it on the page, the front-end memory optimization method further includes: when the user edits the third data on the page, converting the second type of label of the third data into a first type of label.

[0035] In this embodiment, after rendering the second data into third data with a second type of tag according to the preset front-end framework and displaying it on the page, the front-end memory optimization method further includes: when the user edits the third data on the page, converting the second type of tag of the third data into a first type of tag, that is, when the user performs an editing operation on the third data, dynamically converting the second type of tag of the third data into a first type of tag, and binding a custom on-event listener, thereby monitoring the user's operation and monitoring the changes in the third data.

[0036] In some embodiments, optionally, after the step of converting the second type label of the third data into the first type label, the front-end memory optimization method further includes: when the user finishes editing the third data, converting the first type label of the edited third data into the second type label.

[0037] In this embodiment, after the step of converting the second type label of the third data into the first type label, the front-end memory optimization method further includes: when the user finishes editing the third data, converting the first type label of the edited third data into the second type label. That is, when the user switches to other labels, the first type label of the edited third data is converted back to the second type label to disconnect the event listener, thereby reducing memory usage.

[0038] In some embodiments, the first type of tag may optionally include: native input tag, native select tag, el-input component of Element UI framework, and el-select component of Element UI framework, and the second type of tag may include: span tag.

[0039] In this embodiment, the first type of tag includes native input / select tags, and el-input and el-select components from frameworks such as Element UI. The second type of tag can be a span tag. It is understood that native tags like input and select automatically bind event listeners, while span tags do not. Therefore, by presenting input and / or select tags as span tags, unnecessary event listeners can be reduced, significantly lowering memory usage and fundamentally solving a series of problems caused by performance bottlenecks.

[0040] For example, the core reason for issues such as memory performance bottlenecks, high memory usage, page lag, blank screens, and excessively long rendering times is that components like el-input and el-select generate native tags such as input and select after rendering. These tags automatically bind on- event listeners and occupy corresponding space in memory. As the number of components increases, memory consumption accumulates, ultimately leading to the aforementioned performance problems.

[0041] Therefore, this invention, through code-level modifications, intercepts rendering data, defaulting to displaying tags that would otherwise be rendered as input or select elements as span tags, while ensuring that the span style is completely consistent with the original input components, so users cannot perceive the difference. Only when the user triggers an edit operation is the corresponding span tag dynamically converted to an input or select tag and a custom on-event listener bound. When the user switches to other tags, the edited component automatically reverts to span tag display mode. This approach, by reducing unnecessary event listeners, can significantly reduce memory usage and fundamentally solve a series of problems caused by performance bottlenecks.

[0042] For example, to achieve versatility, common components of Element UI can be encapsulated, and the above optimization scheme can be integrated in the middle layer. This invention is perfectly compatible with Vue (a front-end framework) and the Element UI front-end framework, and only requires minor modifications to adapt to other frameworks such as React (a front-end framework), thereby improving the versatility and practicality of memory performance optimization.

[0043] This invention effectively eliminates problems such as page lag, blank screens, and excessively long rendering times, significantly enhancing system stability. Furthermore, this invention simplifies and simplifies the optimization process for user experience, achieving performance improvements without complex operations.

[0044] Figure 2A schematic block diagram of a front-end memory optimization system according to an embodiment of the present invention is shown; wherein, the front-end memory optimization system 20 includes: The first acquisition module 202 is used to acquire multiple first data that need to be rendered during the page initialization phase; The first determining module 204 is used to determine the label that each first data has after rendering; The first processing module 206 is used to take the first data with the label of the first type of label as the second data, wherein the first type of label is a label that automatically listens for events; The second processing module 208 is used to render the second data into third data with a second type of tag according to the preset front-end framework and display it on the page, wherein the second type of tag is a tag that does not perform event listening.

[0045] The front-end memory optimization system 20 provided by this invention specifically includes: a first acquisition module 202, a first determination module 204, a first processing module 206, and a second processing module 208. During the page initialization phase, i.e., before the page is generated, the first acquisition module 202 acquires multiple first data sets to be rendered, i.e., intercepts rendering data. These multiple first data sets can be divided in the form of components, with each first data set representing a component. Subsequently, the first determination module 204 determines the tags that each first data set will have after rendering. It can be understood that components generate native tags after rendering; therefore, the tags that each first data set will have after rendering refer to the native tags generated after rendering. Then, the first processing module 206 uses the first data sets with tags of a first type as second data. That is, it determines the first data sets with tags of the first type from among the multiple first data sets and uses these first data sets as second data. Here, the first type tags refer to tags that automatically perform event listening. When the tags generated after data rendering are of the first type, these tags automatically bind to on-type event listeners and occupy corresponding space in memory. After determining the second tag, the second processing module 208 renders the second data according to the preset front-end framework. During the rendering process, the second data is rendered as third data with a second type of tag and displayed on the page. The second type of tag is a tag that does not perform event listening. In other words, what would have been rendered as a first type of tag is presented as a second type of tag, thus preventing the third data from being bound to event listeners. For example, the style of the third data is completely consistent with the second data. That is, the data obtained after normal rendering of the third data and the second data are completely identical in content and style, except for the tags and the absence of event listening, so it will not be perceived by the user and will not affect normal user experience. Simultaneously, while rendering the second data, the other first data (excluding the second data) are also rendered normally, ensuring the integrity of the page. This invention, by defaulting to presenting data that would have been rendered as first type of tag as second type of tag data, prevents the corresponding data on the page from automatically binding to event listeners, reducing the memory space occupied by event listeners and solving memory performance bottlenecks caused by page rendering, such as high memory usage, page lag, white screens, and long page rendering times.

[0046] In some embodiments, the front-end memory optimization system 20 may optionally include a third processing module, which is used to convert the second type of tags of the third data into first type tags when the user edits the third data on the page.

[0047] In this embodiment, the front-end memory optimization system 20 further includes a third processing module. When a user edits third data on the page, the third processing module converts the second type of tags of the third data into first type tags. That is, when the user edits the third data, the second type of tags are dynamically converted to first type tags, and a custom on-event listener is bound to it, thereby monitoring the user's actions and changes in the third data.

[0048] In some embodiments, the front-end memory optimization system 20 may optionally include a fourth processing module, which is used to convert the first type label of the edited third data into a second type label when the user finishes editing the third data.

[0049] In this embodiment, the front-end memory optimization system 20 further includes a fourth processing module. When the user finishes editing the third data, the fourth processing module converts the first type label of the edited third data into a second type label. That is, when the user switches to other labels, the first type label of the edited third data is converted back to the second type label to disconnect the event listener, thereby reducing memory usage.

[0050] In some embodiments, the first type of tag may optionally include: native input tag, native select tag, el-input component of Element UI framework, and el-select component of Element UI framework, and the second type of tag may include: span tag.

[0051] In this embodiment, the first type of tag includes native input / select tags, and el-input and el-select components from frameworks such as Element UI. The second type of tag can be a span tag. It is understood that native tags like input and select automatically bind event listeners, while span tags do not. Therefore, by presenting input and / or select tags as span tags, unnecessary event listeners can be reduced, significantly lowering memory usage and fundamentally solving a series of problems caused by performance bottlenecks.

[0052] Figure 3 A schematic block diagram of an electronic device according to an embodiment of the present invention is shown; wherein, the electronic device 30 includes a memory 302, a processor 304, and a computer program stored in the memory 302 and executable on the processor 304, wherein the processor 304 executes the computer program to implement the steps of the front-end memory optimization method as described above.

[0053] The electronic device 30 provided by the present invention, when the processor 304 executes a computer program, implements the steps of the above-described front-end memory optimization method, which can achieve the technical effects of any of the above embodiments, and will not be described again.

[0054] One embodiment of the present invention provides a storage medium on which a computer program is stored, which, when executed by a processor, implements the steps of the front-end memory optimization method as described above.

[0055] The storage medium provided by this invention enables the computer program to implement the steps of the above-described front-end memory optimization method when executed by a processor, and can achieve the technical effects of any of the above embodiments, which will not be elaborated further.

[0056] In the description of this specification, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance, unless otherwise expressly specified and limited. The terms "connection," "installation," and "fixing," etc., should be interpreted broadly. For example, "connection" can mean a fixed connection, a detachable connection, or an integral connection; it can mean a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0057] In the description of this specification, the terms "one embodiment," "some embodiments," "specific embodiment," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0058] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A front-end memory optimization method, characterized in that, include: During the page initialization phase, obtain multiple initial data sets that need to be rendered; Determine the label that each of the first data points has after rendering; The first data with the label of the first type is used as the second data, wherein the first type label is a label that automatically listens for events; The second data is rendered into third data with a second type of tag according to the preset front-end framework and displayed on the page, wherein the second type of tag is a tag that does not perform event listening.

2. The front-end memory optimization method according to claim 1, characterized in that, After the step of rendering the second data into third data with a second type of tag according to a preset front-end framework and displaying it on the page, the front-end memory optimization method further includes: When a user edits the third data on the page, the second type of tag in the third data is converted to the first type of tag.

3. The front-end memory optimization method according to claim 2, characterized in that, After the step of converting the second type label of the third data to the first type label, the front-end memory optimization method further includes: When the user finishes editing the third data, the first type label of the edited third data is converted into the second type label.

4. The front-end memory optimization method according to any one of claims 1 to 3, characterized in that, The first type of tag includes: native input tag, native select tag, el-input component of Element UI framework, and el-select component of Element UI framework. The second type of tag includes: span tag.

5. A front-end memory optimization system, characterized in that, include: The first acquisition module is used to acquire multiple first data that need to be rendered during the page initialization phase. The first determining module is used to determine the label that each of the first data has after rendering; A first processing module is used to take the first data with the label of a first type of label as the second data, wherein the first type of label is a label that automatically listens for events; The second processing module is used to render the second data into third data with a second type of tag according to a preset front-end framework and display it on the page, wherein the second type of tag is a tag that does not perform event listening.

6. The front-end memory optimization system according to claim 5, characterized in that, Also includes: The third processing module is used to convert the second type tag of the third data into the first type tag when the user edits the third data on the page.

7. The front-end memory optimization system according to claim 6, characterized in that, Also includes: The fourth processing module is used to convert the first type label of the edited third data into the second type label when the user finishes editing the third data.

8. The front-end memory optimization system according to any one of claims 5 to 7, characterized in that, The first type of tag includes: native input tag, native select tag, el-input component of Element UI framework, and el-select component of Element UI framework. The second type of tag includes: span tag.

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 front-end memory optimization method as described in any one of claims 1 to 4.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the front-end memory optimization method as described in any one of claims 1 to 4.

Images