Android WebView Memory Leak WebView內存泄漏

在此次開發過程當中，須要用到webview展現一些界面，可是加載的頁面若是有不少圖片就會發現內存佔用暴漲，而且在退出該界面後，即便在包含該webview的Activity的destroy()方法中，使用webview.destroy();webview=null;對內存佔回收用仍是沒有任何效果。有人說，一旦在你的xml佈局中引用了webview甚至沒有使用過，都會阻礙從新進入Application以後對內存的gc。包括使用MapView有時一會引起OOM，幾經周折在網上看到各類解決辦法，在這裏跟你們分享一下。可是到目前爲止尚未找到根本的解決辦法，網上也有說是sdk的bug。可是無論怎麼樣，咱們仍是須要使用的。

要使用WebView不形成內存泄漏，首先應該作的就是不能在xml中定義webview節點，而是在須要的時候動態生成。即：能夠在使用WebView的地方放置一個LinearLayout相似ViewGroup的節點，而後在要使用WebView的時候，動態生成即：

?

1 2 3

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

，  而後必定要在onDestroy()方法中顯式的調用

?

1 2 3 4 5

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

;注意：  new   WebView(getApplicationgContext())  ; 必須傳入ApplicationContext若是傳入Activity的Context的話，對內存的引用會一直被保持着。有人用這個方法解決了當Activity被消除後依然保持引用的問題。可是你會發現，若是你須要在WebView中打開連接或者你打開的頁面帶有flash，得到你的WebView想彈出一個dialog，都會致使從ApplicationContext到ActivityContext的強制類型轉換錯誤，從而致使你應用崩潰。這是由於在加載flash的時候，系統會首先把你的WebView做爲父控件，而後在該控件上繪製flash，他想找一個Activity的Context來繪製他，可是你傳入的是ApplicationContext。後果，你能夠曉得了哈。

因而大牛們就Activity銷燬後還保持引用這個問題，提供了另外一種解決辦法：既然你不能給我刪除引用，那麼我就本身來吧。因而下面的這種方法誕生了：

（做者說這個方法是依賴android.webkit implementation有可能在最近的版本中失敗）

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

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) {      } }

而後在Activity中調用上面的方法：

?

1 2 3 4 5 6 7 8 9

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

該反射方法在個人實驗中（2.3.6）確實有些用處，在應用內存佔用到70M左右的時候會明顯釋放到50M或者60M而後的釋放就有些緩慢，其實就是看不出來了。以前在沒使用該方法的時候可能達到120M。

可是！！！咱們的應用要求佔用內存更低啊，這腫麼拌？涼拌麼？No。在各類糾結以後，終於找到了終極解決辦法！！！該辦法適用於咱們的需求，在退出WebView的界面以後，迅速回收內存。要問這個方法是什麼，不要9999，不要8999，只要你仔細看好下面一句話：那就是爲加載WebView的界面開啓新進程，在該頁面退出以後關閉這個進程。

這一點說了以後，你懂了吧？
可是在這個其中，殺死本身進程的時候又遇到了問題，網上介紹的各類方法都很差使，
killBackgroundProcesses(getPackageName());各類很差用，最後使用System.exit(0);直接退出虛擬機（Android爲每個進程建立一個虛擬機的）。這個確定不用糾結了，一旦退出，內存裏面釋放。聽濤哥說QQ也是這麼作。

最後英雄要問出處，附上大牛解說引發該問題的出處

這個泄漏出如今external/webkit/Source/WebKit/android/WebCoreSupport/UrlInterceptResponse.cpp.中。具體我本身真心沒有深刻研究。你們有興趣的話，能夠看看哈。

--- a/Source/WebKit/android/WebCoreSupport/UrlInterceptResponse.cpp +++ b/Source/WebKit/android/WebCoreSupport/UrlInterceptResponse.cpp @@ -63,10 +63,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<jbyteArray> buffer_local(env, env->NewByteArray(out->capacity())); +            m_buffer = static_cast<jbyteArray>(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.

並且從這裏https://github.com/android/platform_external_webkit/commit/1e3e46a731730c02d916ea805ec4b20191509282這個bug的解決狀態。

還有一個問題要說的，也是在WebView使用的時候出現的問題：WebView中包含一個ZoomButtonsController，當使用web.getSettings().setBuiltInZoomControls(true);啓用該設置後，用戶一旦觸摸屏幕，就會出現縮放控制圖標。這個圖標過上幾秒會自動消失，但在3.0系統以上上，若是圖標自動消失前退出當前Activity的話，就會發生ZoomButton找不到依附的Window而形成程序崩潰，解決辦法很簡單就是在Activity的ondestory方法中調用web.setVisibility(View.GONE);方法，手動將其隱藏，就不會崩潰了。在3.0一下系統上不會出現該崩潰問題，真是各類崩潰，防不勝防啊！

最後還有內存泄漏的一些個建議：

In summary, to avoid context-related memory leaks, remember the following:

• Do not keep long-lived references to a context-activity (a reference to an activity should have the same life cycle as the activity itself)
• Try using the context-application instead of a context-activity
• Avoid non-static inner classes in an activity if you don’t control their life cycle, use a static inner class and make a weak reference to the activity inside

And remember that a garbage collector is not an insurance against memory leaks. Last but not least, we try to make such leaks harder to make happen whenever we can.

 

 

via： http://my.oschina.net/zhibuji/blog/100580