Android WebView Memory Leak WebView內(nèi)存泄漏
在這次開發(fā)過程中,需要用到webview展示一些界面,但是加載的頁面如果有很多圖片就會發(fā)現(xiàn)內(nèi)存占用暴漲,并且在退出該界面后,即使在包含該 webview的Activity的destroy()方法中,使用webview.destroy();webview=null;對內(nèi)存占回收用還是沒有任何效果。有人說,一旦在你的xml布局中引用了webview甚至沒有使用過,都會阻礙重新進入Application之后對內(nèi)存的gc。包括使用 MapView有時一會引發(fā)OOM,幾經(jīng)周折在網(wǎng)上看到各種解決辦法,在這里跟大家分享一下。但是到目前為止還沒有找到根本的解決辦法,網(wǎng)上也有說是 sdk的bug。但是不管怎么樣,我們還是需要使用的。
要使用WebView不造成內(nèi)存泄漏,首先應(yīng)該做的就是不能在xml中定義webview節(jié)點,而是在需要的時候動態(tài)生成。即:可以在使用WebView 的地方放置一個LinearLayout類似ViewGroup的節(jié)點,然后在要使用WebView的時候,動態(tài)生成即:
- WebView mWebView = new WebView(getApplicationgContext());
- LinearLayout mll = findViewById(R.id.xxx);
- mll.addView(mWebView);
然后一定要在onDestroy()方法中顯式的調(diào)用
- protected void onDestroy() {
- super.onDestroy();
- mWebView.removeAllViews();
- mWebView.destroy()
- }
注意: new WebView(getApplicationgContext()) ;必須傳入ApplicationContext如果傳入Activity的 Context的話,對內(nèi)存的引用會一直被保持著。有人用這個方法解決了當Activity被消除后依然保持引用的問題。但是你會發(fā)現(xiàn),如果你需要在 WebView中打開鏈接或者你打開的頁面帶有flash,獲得你的WebView想彈出一個dialog,都會導(dǎo)致從 ApplicationContext到ActivityContext的強制類型轉(zhuǎn)換錯誤,從而導(dǎo)致你應(yīng)用崩潰。這是因為在加載flash的時候,系統(tǒng) 會首先把你的WebView作為父控件,然后在該控件上繪制flash,他想找一個Activity的Context來繪制他,但是你傳入的是 ApplicationContext。后果,你可以曉得了哈。
于是大牛們就Activity銷毀后還保持引用這個問題,提供了另一種解決辦法:既然你不能給我刪除引用,那么我就自己來吧。于是下面的這種方法誕生了:
(作者說這個方法是依賴android.webkit implementation有可能在最近的版本中失敗)
- 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中調(diào)用上面的方法:
- 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)確實有些用處,在應(yīng)用內(nèi)存占用到70M左右的時候會明顯釋放到50M或者60M然后的釋放就有些緩慢,其實就是看不出來了。之前在沒使用該方法的時候可能達到120M。
但是?。?!我們的應(yīng)用要求占用內(nèi)存更低啊,這腫么拌?涼拌么?No。在各種糾結(jié)之后,終于找到了***解決辦法?。?!該辦法適用于我們的需求,在退出 WebView的界面之后,迅速回收內(nèi)存。要問這個方法是什么,不要9999,不要8999,只要你仔細看好下面一句話:那就是為加載WebView的界 面開啟新進程,在該頁面退出之后關(guān)閉這個進程。
這一點說了之后,你懂了吧?
但是在這個其中,殺死自己進程的時候又遇到了問題,網(wǎng)上介紹的各種方法都不好使,
killBackgroundProcesses(getPackageName());各種不好用,***使用System.exit(0);直接退出虛擬機(Android為每一個進程創(chuàng)建一個虛擬機的)。這個肯定不用糾結(jié)了,一旦退出,內(nèi)存里面釋放。聽濤哥說QQ也是這么做。
***英雄要問出處,附上大牛解說引起該問題的出處
這個泄漏出現(xiàn)在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的解決狀態(tài)。
還有一個問題要說的,也是在WebView使用的時候出現(xiàn)的問題:WebView 中包含一個ZoomButtonsController,當使用 web.getSettings().setBuiltInZoomControls(true);啟用該設(shè)置后,用戶一旦觸摸屏幕,就會出現(xiàn)縮放控制圖 標。這個圖標過上幾秒會自動消失,但在3.0系統(tǒng)以上上,如果圖標自動消失前退出當前Activity的話,就會發(fā)生ZoomButton找不到依附的 Window而造成程序崩潰,解決辦法很簡單就是在Activity的ondestory方法中調(diào)用 web.setVisibility(View.GONE);方法,手動將其隱藏,就不會崩潰了。在3.0一下系統(tǒng)上不會出現(xiàn)該崩潰問題,真是各種崩潰, 防不勝防?。?/p>
***還有內(nèi)存泄漏的一些個建議:
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.