Tracking and solving browser memory leakage issues)

Before Ajax became popular, browser memory leakage was not a major problem, because it was all through page Jump and refresh to interact with the server, but now the situation is different, ajax and IFRAME are widely used in many applications. As a result, memory leakage has become a risk for many rich client applications. For example, the projects I am currently working on have been plagued by memory leaks for a long time. Testers often complain that they are the ones who use the most software, after several hours of clicking, the browser may occupy several hundred MB of memory, sometimes even GB. However, our developers have never been able to solve this problem well, which is the reason, the main reason is that developers are not aware of memory leaks. during development, only functions are implemented. Whether or not memory leaks are caused, the cost of solving the problems will not be small if the problems accumulate to a certain level. At the same time, the tools and methods for detecting memory leaks are indeed limited. The only two tools (JavaScript Memory Leak Detector and Sieve) Is not easy to use, unlike some java tools that can precisely locate. In addition, the ext and jquery frameworks are widely used in the project. These frameworks have the memory leakage problem. Therefore, we often need to go deep into the source code of these frameworks, this naturally increases the difficulty of solving the problem.

This is a tough nut to crack, but it must be done, because the impact is so bad that this project will serve tens of millions of customers, if tens of millions of customers can tolerate applications that occupy hundreds of m at will, I can't say that. Memory leakageArticleMany, for example, understanding and solving Internet Explorer leak patterns is the most authoritative article, which mentions several modes that cause memory leakage. The excerpt is as follows:

2. Circular references-when mutual references are counted between Internet Explorer's com infrastructure and any scripting engine, objects can leak memory. This is the broadest pattern.

4. Closures-closures are a specific form of circular reference that pose the largest pattern to existing web application ubuntures. closures are easy to spot because they rely on a specific language keyword and can be searched for generically.

6. Cross-page leaks-Cross-page leaks are often very small leaks of internal book-keeping objects as you move from site to site. we'll examine the DOM insertion order issue, along with a workaround that shows how small changes to your code can prevent the creation of these book-keeping objects.

8. Pseudo-leaks-These aren't really leaks, but can be extremely annoying if you don't understand where your memory is going. we'll examine the script element rewriting and how it appears to leak quite a bit of memory, when it is really established as required.

However, if you use these modes to checkCodeJust like a haystack. I only have to predict the most likely leak points based on experience. Then, I use exclusion to remove the relevant code and check whether the memory is leaked. I expect leakage in the following situations:

1. Frequently operated IFRAME
2. Dynamic Dom Creation
3. Event binding
4. EXT framework itself

After investigation, it is found that the Project Memory leakage is serious for such several points:

1. Binds a large number of Keyboard Events to pages in IFRAME.
2. Dynamically create Dom on the page in IFRAME
3. IFRAME refresh
4. EXT itself

My solutions to these problems are as follows:

2. Delete all event bindings before exiting the page in IFRAME and delete all dynamically created dom
4. Called before refreshing IFRAME content
   Iframe.contentdomaindoc ument. Write ('');
   Iframe.contentdomaindoc ument. Close ();
   Force release of page elements in IFRAME
6. Modify certain vertices of Ext.
   For example, ext. getdoc ()
   Getdoc: function (){
   // Original implementation
   // Return Ext. Get (document );
   // After modification
   VaR F = function (){
   };
   F. Prototype = ext. element. Prototype;
   VaR docel = new F ();
   Docel. DOM = document;
   Return docel;
   }
   The specific reason has not been found, but after modification, the memory is indeed released a lot.
8. Modify ext garbage collection code. Delete the garbage collection round robin in time.

after the above points are modified, the memory is basically kept at more than 100 MB, which has improved a lot compared with the previous one, but does not completely eliminate Memory leakage. Therefore, the problem still needs to be tracked, strive to reduce memory leakage to 0