Android WebView Memory Leak WebView記憶體洩漏

l_serein發表於2013-06-02
AndroidWebView記憶體

在這次開發過程中，需要用到webview展示一些介面，但是載入的頁面如果有很多圖片就會發現記憶體佔用暴漲，並且在退出該介面後，即使在包含該webview的Activity的destroy()方法中，使用webview.destroy();webview=null;對記憶體佔回收用還是沒有任何效果。有人說，一旦在你的xml佈局中引用了webview甚至沒有使用過，都會阻礙重新進入Application之後對記憶體的gc。包括使用MapView有時一會引發OOM，幾經周折在網上看到各種解決辦法，在這裡跟大家分享一下。但是到目前為止還沒有找到根本的解決辦法，網上也有說是sdk的bug。但是不管怎麼樣，我們還是需要使用的。

要使用WebView不造成記憶體洩漏，首先應該做的就是不能在xml中定義webview節點，而是在需要的時候動態生成。即：可以在使用WebView的地方放置一個LinearLayout類似ViewGroup的節點，然後在要使用WebView的時候，動態生成即：

1 WebView      mWebView = new WebView(getApplicationgContext());
2 LinearLayout mll      = findViewById(R.id.xxx);
3 mll.addView(mWebView);
， 然後一定要在onDestroy()方法中顯式的呼叫
1 protected void onDestroy() {
2       super.onDestroy();
3       mWebView.removeAllViews();
4       mWebView.destroy()
5 }
;注意： new  WebView(getApplicationgContext()) ;必須傳入ApplicationContext如果傳入Activity的Context的話，對記憶體的引用會一直被保持著。有人用這個方法解決了當Activity被消除後依然保持引用的問題。但是你會發現，如果你需要在WebView中開啟連結或者你開啟的頁面帶有flash，獲得你的WebView想彈出一個dialog，都會導致從ApplicationContext到ActivityContext的強制型別轉換錯誤，從而導致你應用崩潰。這是因為在載入flash的時候，系統會首先把你的WebView作為父控制元件，然後在該控制元件上繪製flash，他想找一個Activity的Context來繪製他，但是你傳入的是ApplicationContext。後果，你可以曉得了哈。


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

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

01 public void setConfigCallback(WindowManager windowManager) {
02     try {
03         Field field = WebView.class.getDeclaredField("mWebViewCore");
04         field = field.getType().getDeclaredField("mBrowserFrame");
05         field = field.getType().getDeclaredField("sConfigCallback");
06         field.setAccessible(true);
07         Object configCallback = field.get(null);
08  
09         if (null == configCallback) {
10             return;
11         }
12  
13         field = field.getType().getDeclaredField("mWindowManager");
14         field.setAccessible(true);
15         field.set(configCallback, windowManager);
16     } catch(Exception e) {
17     }
18 }
然後在Activity中呼叫上面的方法：
1 public void onCreate(Bundle savedInstanceState) {
2     super.onCreate(savedInstanceState);
3     setConfigCallback((WindowManager)getApplicationContext().getSystemService(Context.WINDOW_SERVICE));
4 }
5  
6 public void onDestroy() {
7     setConfigCallback(null);
8     super.onDestroy();
9 }

該反射方法在我的實驗中（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.

相關文章