在這次開發過程中，需要用到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);
|
|
1
2
3
4
5
|
protected
void
onDestroy() {
super
.onDestroy();
mWebView.removeAllViews();
mWebView.destroy()
}
|
於是大牛們就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) {
}
}
|
|
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