Утечка памяти в WebView

На основании приведенных выше комментариев и дальнейших тестов я пришел к выводу, что проблема заключается в ошибке в SDK: при создании WebView через XML-макет действие передается как контекст для WebView, а не контекст приложения. При завершении действия WebView по-прежнему сохраняет ссылки на действие, поэтому действие не удаляется из памяти. Я отправил отчет об ошибке для этого, см. Ссылку в комментарии выше.

webView = new WebView(getApplicationContext());

Обратите внимание, что этот обходной путь работает только для определенных случаев использования, например, если вам просто нужно отобразить html в веб-просмотре, без каких-либо href-ссылок, ссылок на диалоговые окна и т. д. См. комментарии ниже.

Мне повезло с этим методом:

Поместите FrameLayout в свой xml в качестве контейнера, позвольте называть его web_container. Затем программно объявите WebView, как упомянуто выше. onDestroy, удалите его из FrameLayout.

Скажите, что это где-то в вашем файле макета xml, например. layout / your_layout.xml

<FrameLayout
    android:id="@+id/web_container"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"/>

Затем после того, как вы увеличите представление, добавьте WebView, созданный с контекстом приложения, в свой FrameLayout. onDestroy, вызовите метод уничтожения веб-представления и удалите его из иерархии представлений, иначе произойдет утечка.

public class TestActivity extends Activity {
    private FrameLayout mWebContainer;
    private WebView mWebView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        setContentView(R.layout.your_layout);

        mWebContainer = (FrameLayout) findViewById(R.id.web_container);
        mWebView = new WebView(getApplicationContext());
        mWebContainer.addView(mWebView);
    }

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

Также FrameLayout, а также layout_width и layout_height были произвольно скопированы из существующего проекта, в котором он работает. Я предполагаю, что другая ViewGroup будет работать, и я уверен, что другие размеры макета будут работать.

Это решение также работает с RelativeLayout вместо FrameLayout.

Вот подкласс WebView, который использует описанный выше прием, чтобы избежать утечек памяти:

package com.mycompany.view;

import android.app.Activity;
import android.content.Context;
import android.content.Intent;
import android.net.Uri;
import android.util.AttributeSet;
import android.webkit.WebView;
import android.webkit.WebViewClient;

/**
 * see http://stackoverflow.com/questions/3130654/memory-leak-in-webview and http://code.google.com/p/android/issues/detail?id=9375
 * Note that the bug does NOT appear to be fixed in android 2.2 as romain claims
 *
 * Also, you must call {@link #destroy()} from your activity's onDestroy method.
 */
public class NonLeakingWebView extends WebView {
    private static Field sConfigCallback;

    static {
        try {
            sConfigCallback = Class.forName("android.webkit.BrowserFrame").getDeclaredField("sConfigCallback");
            sConfigCallback.setAccessible(true);
        } catch (Exception e) {
            // ignored
        }

    }


    public NonLeakingWebView(Context context) {
        super(context.getApplicationContext());
        setWebViewClient( new MyWebViewClient((Activity)context) );
    }

    public NonLeakingWebView(Context context, AttributeSet attrs) {
        super(context.getApplicationContext(), attrs);
        setWebViewClient(new MyWebViewClient((Activity)context));
    }

    public NonLeakingWebView(Context context, AttributeSet attrs, int defStyle) {
        super(context.getApplicationContext(), attrs, defStyle);
        setWebViewClient(new MyWebViewClient((Activity)context));
    }

    @Override
    public void destroy() {
        super.destroy();

        try {
            if( sConfigCallback!=null )
                sConfigCallback.set(null, null);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }


    protected static class MyWebViewClient extends WebViewClient {
        protected WeakReference<Activity> activityRef;

        public MyWebViewClient( Activity activity ) {
            this.activityRef = new WeakReference<Activity>(activity);
        }

        @Override
        public boolean shouldOverrideUrlLoading(WebView view, String url) {
            try {
                final Activity activity = activityRef.get();
                if( activity!=null )
                    activity.startActivity(new Intent(Intent.ACTION_VIEW, Uri.parse(url)));
            }catch( RuntimeException ignored ) {
                // ignore any url parsing exceptions
            }
            return true;
        }
    }
}

Чтобы использовать его, просто замените WebView на NonLeakingWebView в своих макетах.

                    <com.mycompany.view.NonLeakingWebView
                            android:layout_width="fill_parent"
                            android:layout_height="wrap_content"
                            ...
                            />

Затем обязательно вызовите NonLeakingWebView.destroy() из метода onDestroy вашей активности.

Обратите внимание, что этот веб-клиент должен обрабатывать общие случаи, но он может быть не таким полнофункциональным, как обычный веб-клиент. Я не тестировал, например, на такие вещи, как вспышка.

Основываясь на ответе пользователя 1668939 на этот пост (https://stackoverflow.com/a/12408703/1369016), вот как Я исправил утечку WebView внутри фрагмента:

@Override
public void onDetach(){

    super.onDetach();

    webView.removeAllViews();
    webView.destroy();
}

Отличие от ответа user1668939 заключается в том, что я не использовал никаких заполнителей. Просто вызов removeAllViews () в самой ссылке WebvView сделал свое дело.

## ОБНОВЛЕНИЕ ##

Если вы похожи на меня и имеете WebView внутри нескольких фрагментов (и вы не хотите повторять приведенный выше код во всех своих фрагментах), вы можете использовать отражение для решения этой проблемы. Просто сделайте так, чтобы ваши фрагменты расширили этот:

public class FragmentWebViewLeakFree extends Fragment{

    @Override
    public void onDetach(){

        super.onDetach();

        try {
            Field fieldWebView = this.getClass().getDeclaredField("webView");
            fieldWebView.setAccessible(true);
            WebView webView = (WebView) fieldWebView.get(this);
            webView.removeAllViews();
            webView.destroy();

        }catch (NoSuchFieldException e) {
            e.printStackTrace();

        }catch (IllegalArgumentException e) {
            e.printStackTrace();

        }catch (IllegalAccessException e) {
            e.printStackTrace();

        }catch(Exception e){
            e.printStackTrace();
        }
    }
}

Я предполагаю, что вы называете свое поле WebView «webView» (и да, ваша ссылка на WebView, к сожалению, должна быть полем). Я не нашел другого способа сделать это, который не зависел бы от имени поля (если я не перебираю все поля и не проверяю, принадлежит ли каждое из них к классу WebView, что я не хочу делать из-за проблем с производительностью).

После прочтения http://code.google.com/p/android/issues/detail?id=9375, возможно, мы могли бы использовать отражение, чтобы установить для ConfigCallback.mWindowManager значение null в Activity.onDestroy и восстановить его в Activity.onCreate. Я не уверен, требует ли он каких-либо разрешений или нарушает какую-либо политику. Это зависит от реализации android.webkit и может не работать в более поздних версиях Android.

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

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

public void onDestroy() {
    setConfigCallback(null);
    super.onDestroy();
}

Я исправил проблему с утечкой памяти, которая мешала Webview, например:

(Надеюсь, это многим поможет)

Основы:

• Чтобы создать веб-просмотр, нужна ссылка (скажем, действие).
• Чтобы убить процесс:

android.os.Process.killProcess(android.os.Process.myPid()); можно назвать.

Переломный момент:

По умолчанию все действия выполняются в одном процессе в одном приложении. (процесс определяется именем пакета). Но:

В одном приложении могут быть созданы разные процессы.

Решение. Если для действия создается другой процесс, его контекст можно использовать для создания веб-просмотра. И когда этот процесс завершается, все компоненты, имеющие ссылки на это действие (в данном случае веб-просмотр), уничтожаются, и основная желательная часть:

GC вызывается принудительно для сбора этого мусора (веб-просмотр).

Код для справки: (один простой случай)

Всего два действия: скажем A и B

Файл манифеста:

<application
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name"
        android:process="com.processkill.p1" // can be given any name 
        android:theme="@style/AppTheme" >
        <activity
            android:name="com.processkill.A"
            android:process="com.processkill.p2"
            android:label="@string/app_name" >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

        <activity
            android:name="com.processkill.B"
            android:process="com.processkill.p3"
            android:label="@string/app_name" >
        </activity>
    </application>

Начать A, затем B

A > B

B создается со встроенным веб-просмотром.

Когда backKey нажимается на действии B, вызывается onDestroy:

@Override
    public void onDestroy() {
        android.os.Process.killProcess(android.os.Process.myPid());
        super.onDestroy();
    }

и это убивает текущий процесс, то есть com.processkill.p3

и удаляет ссылку на веб-просмотр

ПРИМЕЧАНИЕ. Будьте особенно осторожны при использовании этой команды kill. (не рекомендуется по понятным причинам). Не реализуйте в действии какие-либо статические методы (в данном случае действие B). Не используйте никакие ссылки на это действие из любого другого (так как оно будет убито и больше не будет доступно).

Вы можете попробовать поместить веб-активность в отдельный процесс и выйти, когда активность будет уничтожена, если многопроцессорная обработка не представляет для вас больших усилий.

Перед вызовом WebView.destroy() необходимо удалить WebView из родительского представления.

Комментарий WebView destroy () - «Этот метод должен вызываться после того, как этот WebView был удален из системы просмотра».

Возникла проблема с обходным путем "контекст приложения": сбой, когда WebView пытается показать какой-либо диалог. Например, диалог «запомнить пароль» при подаче форм входа / пропуска (другие случаи?).

Это можно исправить с помощью WebView настроек 'setSavePassword(false) для случая «запомнить пароль».