Analysis of memory release methods in JS class library Bindows1.3_javascript skills

I introduced the Memory Leak problem of JavaScript scripts in IE some time ago. Later, after discussions with several enthusiastic netizens, I basically recognized the facts and principles of memory leaks. In small-scale test cases, it has been achieved to basically avoid the ML problems of scripts in IE. However, it has recently been discovered that it seems to be very difficult to prevent script ML in IE just by being "careful". Is there a mistake in the initial discussion?

What does "careful" mean? That is to say, when objects refer to each other, break each other's reference chains when the objects are discarded (not necessarily page refresh), especially the references between objects created in scripts and objects in DHTML; clear all references in HTML elements Custom attributes; clear event handler function callbacks in all HTML elements; try to delete internal elements when discarding arrays.

The most important thing is to try not to create redundant script objects and DHTML element objects. The effect can be achieved by modifying attributes, and even if it is more troublesome, new objects will not be regenerated.

After passing the above steps, IE’s memory usage growth rate has decreased. However, it still cannot fully meet the support for complex script execution (close to the complexity of Bindows), which is reflected in the following points:
1. During the script execution process, the memory usage is still a process that only increases but does not decrease;
2. Use the minimized IE window method to force IE to perform GC, which can only GC physical memory and is invalid for virtual memory;
3. The page jumps out of the original script execution domain (URL changes), and the memory release amount is too small or even Do not release;
4. The IEXPLORE.EXE process (that is, all IE windows) must be closed to completely release the memory used by IE.

Today I suddenly remembered the long-lost Bindows. I ran to take a look and found that version 1.3 was released at the end of February, so I started running the demo given on the homepage. Needless to say the effect, just check it out for yourself, the efficiency is quite high. There is also a GRID in the demo that is similar to multi-dimensional data display, and it actually supports fixed row and column headers. Dazzling has been an everlasting feature of Bindows. Before I was stunned, I thought I should take a look at how Bindows handles memory. I really don’t know it until I see it, and I’m shocked when I see it!

Open www.bindows.net, my IE memory usage is around (28PM 18VM)M, open its demo program. The memory reached about (38PM 35VM)M. After a few more operations, the memory reached about (80PM 75VM)M. So I closed the demo window, and IE released about 15M of memory, which stopped at the level of (70PM 70VM)M. After changing the current IE URL and jumping to Google, IE's memory usage still didn't seem to decrease @_@. Haha, Bindows also has Memory Leak~. What a villain, 555... Looking at it after a short period of time, IE's memory usage has dropped to almost the same as when I started it :). Really good news, it seems that I can no longer be wronged by IE, so I started to track the processing code of Bindows during onunload.

How can I jump to the onunload code at once? There is a hack here. First press Alt V, u, b on IE (you need to uncheck "Disable script debugging" in the advanced IE options, and the U shortcut key option is only available in the menu View). Then immediately close the Bindows demo dome window, select VS.NET 2003 as the Script debugger, and jump directly to the entrance of onunload.

Bindows does a very thoughtful job in managing script memory usage in IE. Complex objects have implemented complete dispose methods. What are they used for? When called, first cut off the reference chain between the DHTML object instance and the script object instance; clear the data in the global cache variable and use the delete keyword; the event processing function imported using the attachEvent method needs to be detach; other event processing callbacks , clear it by assigning null; cut off the parent or child relationship reference chain between script objects.

What’s a little confusing here is that the trigger of IE’s GC is uncertain (the currently known sure trigger is to minimize the IE window), that is, if you have done the above work, in your When the page is just onloaded, the memory will not be released immediately. However, after a period of use, the memory used by IE will decrease. So there is no need to doubt the previously discussed method, and except for the point of "cutting off the parent or child relationship reference chain between script objects", the principle and processing method of Bindows' dispose are basically the same as what I discussed earlier.

Note: PM physical memory, VM virtual memory. All can be viewed in Task Manager.