Android WebView Memories Leak WebView Memory leak

Android WebView Memories Leak WebView Memory leaks

In this development process, you need to use the WebView to display some interfaces, but the loaded page if there are many pictures will find the memory consumption soared, and after exiting the interface, even in the activity of the webview containing the Destroy () method, Use Webview.destroy (), webview=null, or no effect on memory for recycling. It is said that once you reference the WebView in your XML layout, it is not even used, which will block the GC of memory after re-entering application. Including the use of Mapview sometimes one will trigger Oom, after several setbacks on the internet to see a variety of solutions, here to share with you. But so far has not found the fundamental solution, the Internet is also said to be the SDK bug. But anyway, we still need to use it.

To use WebView without causing a memory leak, the first thing to do is to not define the WebView node in XML, but to generate it dynamically when needed. That is, you can place a linearlayout-like ViewGroup node where you use WebView, and then dynamically generate when you want to use WebView: WebView mwebview = new WebView ( Getapplicationgcontext ());

LinearLayout MLL = Findviewbyid (r.id.xxx);

Mll.addview (Mwebview), and then be sure to explicitly call protected void OnDestroy () in the OnDestroy () method () {

Super.ondestroy ();

Mwebview.removeallviews ();

Mwebview.destroy ()

}; Note: New WebView (Getapplicationgcontext ()); must be passed in ApplicationContext if the context of the activity is passed in, the reference to the memory will always be maintained. Some people use this method to solve the problem of keeping references when the activity is eliminated. But you will find that if you need to open the link in webview or you open the page with Flash, get your webview want to pop up a dialog, Will cause a forced type conversion error from ApplicationContext to Activitycontext, causing your app to crash. This is because when the flash is loaded, the system will first take your webview as the parent control, and then draw flash on the control, he wants to find an activity context to draw him, but you pass in the ApplicationContext. The consequences, you can know ha.

So Daniel kept citing the problem after the activity was destroyed, providing another solution: since you can't delete the references, I'll do it myself. So the following method was born:

(the author says this method is dependent on android.webkit implementation is likely to fail in the most recent version) public void Setconfigcallback (WindowManager windowmanager) {

try {

Field field = WebView.class.getDeclaredField ("Mwebviewcore");

field = Field.gettype (). Getdeclaredfield ("Mbrowserframe");

field = Field.gettype (). Getdeclaredfield ("Sconfigcallback");

Field.setaccessible (TRUE);

Object configcallback = Field.get (null);

if (null = = Configcallback) {

Return

}

field = Field.gettype (). Getdeclaredfield ("Mwindowmanager");

Field.setaccessible (TRUE);

Field.set (Configcallback, WindowManager);

} catch (Exception e) {

}

Then call the method above in the activity: public void OnCreate (Bundle savedinstancestate) {

Super.oncreate (savedinstancestate);

Setconfigcallback ((WindowManager) Getapplicationcontext (). Getsystemservice (Context.window_service));

}

public void OnDestroy () {

Setconfigcallback (NULL);

Super.ondestroy ();

}

The reflection method in my experiment (2.3.6) is really useful, in the application of memory to 70M or so when the release will be significantly released to 50M or 60M and then the release of some slow, in fact, it is not visible. It may have reached 120M before using this method.

But!!! Our application requires less memory ah, this swollen mix? A cold salad? No. After a variety of entanglements, finally found the ultimate solution!!! This approach applies to our needs and quickly reclaims memory after exiting the WebView interface. To ask what this method is, do not 9999, not 8999, as long as you carefully watch the following sentence: that is to load the WebView interface to open a new process, after the page exits after the shutdown process.

After that, you understand?

But in this one, the killing of their own process and encountered a problem, the online introduction of the various methods are not so,

Killbackgroundprocesses (Getpackagename ()); All kinds of useless, and finally use System.exit (0); exit the virtual machine directly (Android creates a virtual machine for each process). This must not be tangled up, once exited, memory inside release. Listen to Tao elder brother said QQ also do so.

Android WebView Memories Leak WebView Memory leak