Shulou(Shulou.com)06/01 Report--

In this article, the editor introduces "Android memory leak case analysis" in detail, with detailed content, clear steps and proper handling of details. I hope this "Android memory leak case analysis" article can help you solve your doubts.

In this development process, you need to use webview to show some interfaces, but if the loaded page has a lot of pictures, you will find that the memory footprint soars, and after exiting the interface, even in the destroy () method of the Activity that contains the webview, use webview.destroy (); webview=null; has no effect on memory reuse. Some people say that once you reference webview in your xml layout and don't even use it, it will hinder the gc of memory after re-entering Application. Including the use of MapView will sometimes lead to OOM, after several twists and turns to see a variety of solutions on the Internet, here to share with you. But so far, no fundamental solution has been found, and there is also a bug of sdk on the Internet. But we still need to use it anyway.

To use WebView without causing memory leaks, the first thing you should do is not to define webview nodes in xml, but to generate them dynamically when needed. That is, you can place a LinearLayout node similar to ViewGroup where WebView is used, and then dynamically generate it when you want to use WebView:

WebView mWebView = new WebView (getApplicationgContext ()); LinearLayout mll = findViewById (R.id.xxx); mll.addView (mWebView)

Then be sure to explicitly call in the onDestroy () method

Protected void onDestroy () {super.onDestroy (); mWebView.removeAllViews (); mWebView.destroy ()}

Note: new WebView (getApplicationgContext ()); ApplicationContext must be passed. If you pass in the Context of Activity, the reference to memory will always be maintained. Some people use this method to solve the problem of keeping references when Activity is eliminated. But you will find that if you need to open a link in WebView or if you open a page with flash, get your WebView and want to pop up a dialog, it will cause a cast error from ApplicationContext to ActivityContext, which will cause your application to crash. This is because when loading flash, the system will first take your WebView as the parent control, and then draw flash on the control. He wants to find a Context of Activity to draw him, but you pass in ApplicationContext. You can know the consequences.

So Daniel offers another solution to the problem of keeping citations after Activity is destroyed: since you can't delete references for me, I'll do it myself. So the following method was born:

(the author says that this method relies on android.webkit implementation and may fail in recent versions.)

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 above method in Activity:

Public void onCreate (Bundle savedInstanceState) {super.onCreate (savedInstanceState); setConfigCallback ((WindowManager) getApplicationContext (). GetSystemService (Context.WINDOW_SERVICE));} public void onDestroy () {setConfigCallback (null); super.onDestroy ();}

This reflection method is really useful in my experiment (2.3.6). When the application memory is about 70m, it will be obviously released to 50m or 60m, and then the release is a little slow, but it just can't be seen. Previously, it may have reached 120m when this method was not used.

But! Our application requires less memory, so what's wrong with it? Cold salad? No . After all kinds of entanglements, we finally found a solution! This method applies to our needs, quickly reclaim memory after exiting the WebView interface. To ask what this method is, not 9999, not 8999, as long as you look carefully at the following sentence: start a new process for loading the interface of WebView, and close the process after the page exits.

After saying this, do you understand?

But in this one, I encountered problems in killing my own process, and the various methods introduced on the Internet did not work well.

KillBackgroundProcesses (getPackageName ()); various unusable, * use System.exit (0); exit the virtual machine directly (Android creates a virtual machine for each process). There is no need to worry about this. Once you exit, it will be released in memory. Brother Tao said that QQ did the same thing.

* if the hero wants to ask the source, attach Daniel's explanation of the source of the problem.

The leak occurred in external/webkit/Source/WebKit/android/WebCoreSupport/UrlInterceptResponse.cpp. Medium. Specifically, I really did not study it in depth. If you are interested, you can have a look.

-a/Source/WebKit/android/WebCoreSupport/UrlInterceptResponse.cpp + b/Source/WebKit/android/WebCoreSupport/UrlInterceptResponse.cpp @ @-63 public 10 + 63 JSC::Bindings::getJNIEnv 10 @ @ public: JNIEnv* env = JSC::Bindings::getJNIEnv (); / / Initialize our read buffer to the capacity of out. If (! m_buffer) {- m_buffer = env- > NewByteArray (out- > capacity ());-m_buffer = (jbyteArray) env- > NewGlobalRef (m_buffer); + ScopedLocalRef buffer_local (env, env- > NewByteArray (out- > capacity ()); + m_buffer = static_cast (env- > NewGlobalRef (buffer_local.get () } int size = (int) env- > CallIntMethod (m_inputStream, m_read, m_buffer); if (checkException (env) | | size < 0) return; / / Copy from m_buffer to out.

There is one more problem to say, which is also a problem when using WebView: WebView contains a ZoomButtonsController when using web.getSettings (). SetBuiltInZoomControls (true); when this setting is enabled, once the user touches the screen, a zoom control icon appears. This icon will automatically disappear after a few seconds, but on systems above 3.0, if the icon automatically disappears before exiting the current Activity, ZoomButton can not find the attached Window and cause the program to crash, the solution is very simple is to call web.setVisibility (View.GONE) in the Activity's ondestory method; method, manually hide it, will not crash. The crash problem will not occur on the 3.0 system, it is really a variety of crashes, it is difficult to prevent ah!

After reading this, the article "Android memory leak instance Analysis" has been introduced. If you want to master the knowledge points of this article, you still need to practice and use it yourself to understand it. If you want to know more about related articles, welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.