Speicherleck in WebView

Ich habe eine Aktivität, die ein XML-Layout verwendet, in das eine WebView eingebettet ist. Ich verwende die WebView überhaupt nicht in meinem Aktivitätscode, sie sitzt nur dort in meinem XML-Layout und ist sichtbar.

Wenn ich jetzt die Aktivität beende, stelle ich fest, dass meine Aktivität nicht aus dem Speicher gelöscht wird. (Ich überprüfe über hprof dump). Die Aktivität wird jedoch vollständig gelöscht, wenn ich die WebView aus dem XML-Layout entferne.

Ich habe schon versucht, a

webView.destroy();
webView = null;

in onDestroy() meiner Aktivität, aber das hilft nicht viel.

In meinem hprof-Dump hat meine Aktivität (mit dem Namen ‘Browser’) die folgenden verbleibenden GC-Wurzeln (nach dem Aufruf von destroy() drauf):

com.myapp.android.activity.browser.Browser
  - mContext of android.webkit.JWebCoreJavaBridge
    - sJavaBridge of android.webkit.BrowserFrame [Class]
  - mContext of android.webkit.PluginManager
    - mInstance of android.webkit.PluginManager [Class]  

Ich habe festgestellt, dass ein anderer Entwickler ähnliche Erfahrungen gemacht hat, siehe die Antwort von Filipe Abrantes auf:
http://www.curious-creature.org/2008/12/18/avoid-memory-leaks-on-android/

In der Tat ein sehr interessanter Beitrag. Kürzlich hatte ich eine sehr harte Zeit, ein Speicherleck in meiner Android-App zu beheben. Am Ende stellte sich heraus, dass mein XML-Layout eine WebView-Komponente enthielt, die, selbst wenn sie nicht verwendet wurde, verhinderte, dass der Speicher nach Bildschirmdrehungen/App-Neustarts g-gesammelt wurde … ist dies ein Fehler der aktuellen Implementierung oder gibt es etwas Spezifisch, was man tun muss, wenn man WebViews verwendet

Nun, leider gibt es noch keine Antwort auf dem Blog oder der Mailingliste auf diese Frage. Daher frage ich mich, ob es sich um einen Fehler im SDK handelt (vielleicht ähnlich dem gemeldeten MapView-Fehler http://code.google.com/p/android/issues/detail?id=2181) oder wie Sie die Aktivität mit einer eingebetteten Webansicht vollständig aus dem Speicher entfernen?

Ich schließe aus den obigen Kommentaren und weiteren Tests, dass das Problem ein Fehler im SDK ist: Beim Erstellen einer WebView über das XML-Layout wird die Aktivität als Kontext für die WebView übergeben, nicht der Anwendungskontext. Beim Beenden der Aktivität behält die WebView immer noch Verweise auf die Aktivität, daher wird die Aktivität nicht aus dem Speicher entfernt. Ich habe dafür einen Fehlerbericht eingereicht, siehe den Link im Kommentar oben.

webView = new WebView(getApplicationContext());

Beachten Sie, dass diese Problemumgehung nur für bestimmte Anwendungsfälle funktioniert, dh wenn Sie nur HTML in einer Webansicht anzeigen müssen, ohne Href-Links oder Links zu Dialogen usw. Siehe die Kommentare unten.

Ich hatte etwas Glück mit dieser Methode:

Fügen Sie ein FrameLayout als Container in Ihre XML-Datei ein, nennen wir es web_container. Fügen Sie dann die WebView wie oben erwähnt programmgesteuert hinzu. onDestroy, entfernen Sie es aus dem FrameLayout.

Angenommen, dies befindet sich irgendwo in Ihrer XML-Layoutdatei, z. B. layout/your_layout.xml

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

Nachdem Sie die Ansicht vergrößert haben, fügen Sie Ihrem FrameLayout die mit dem Anwendungskontext instanziierte WebView hinzu. onDestroy, rufen Sie die Destroy-Methode der Webansicht auf und entfernen Sie sie aus der Ansichtshierarchie, sonst werden Sie lecken.

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();
    }
}

Auch FrameLayout sowie layout_width und layout_height wurden willkürlich aus einem bestehenden Projekt kopiert, wo es funktioniert. Ich gehe davon aus, dass eine andere ViewGroup funktionieren würde, und ich bin mir sicher, dass andere Layoutdimensionen funktionieren werden.

Diese Lösung funktioniert auch mit RelativeLayout anstelle von FrameLayout.

Hier ist eine Unterklasse von WebView, die den obigen Hack verwendet, um Speicherlecks nahtlos zu vermeiden:

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;
        }
    }
}

Um es zu verwenden, ersetzen Sie einfach WebView in Ihren Layouts durch NonLeakingWebView

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

Dann unbedingt anrufen NonLeakingWebView.destroy() aus der onDestroy-Methode Ihrer Aktivität.

Beachten Sie, dass dieser Webclient die üblichen Fälle verarbeiten sollte, aber möglicherweise nicht so umfassend wie ein normaler Webclient ist. Ich habe es zum Beispiel nicht auf Dinge wie Flash getestet.

Basierend auf der Antwort von Benutzer1668939 auf diesen Beitrag (https://stackoverflow.com/a/12408703/1369016) habe ich mein WebView-Leck in einem Fragment folgendermaßen behoben:

@Override
public void onDetach(){

    super.onDetach();

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

Der Unterschied zur Antwort von user1668939 besteht darin, dass ich keine Platzhalter verwendet habe. Der Aufruf von removeAllViews() in der WebvView-Referenz selbst hat den Zweck erfüllt.

## AKTUALISIEREN ##

Wenn Sie wie ich sind und WebViews in mehreren Fragmenten haben (und Sie den obigen Code nicht über alle Ihre Fragmente hinweg wiederholen möchten), können Sie die Reflektion verwenden, um das Problem zu lösen. Lassen Sie einfach Ihre Fragmente dieses erweitern:

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();
        }
    }
}

Ich gehe davon aus, dass Sie Ihr WebView-Feld “webView” nennen (und ja, Ihre WebView-Referenz muss leider ein Feld sein). Ich habe keinen anderen Weg gefunden, der unabhängig vom Namen des Felds wäre (es sei denn, ich durchlaufe alle Felder und überprüfe, ob jedes aus einer WebView-Klasse stammt, was ich aus Leistungsgründen nicht tun möchte).

Nach dem Lesen http://code.google.com/p/android/issues/detail?id=9375, vielleicht könnten wir Reflektion verwenden, um ConfigCallback.mWindowManager auf Activity.onDestroy auf null zu setzen und es auf Activity.onCreate wiederherzustellen. Ich bin mir jedoch nicht sicher, ob es einige Berechtigungen erfordert oder gegen eine Richtlinie verstößt. Dies hängt von der Implementierung von android.webkit ab und kann bei späteren Versionen von Android fehlschlagen.

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

Aufrufen der obigen Methode in Activity

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

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

Ich habe das Problem mit Speicherlecks bei frustrierenden Webviews wie folgt behoben:

(ich hoffe das hilft vielen)

Grundlagen:

• Um eine Webansicht zu erstellen, wird eine Referenz (z. B. eine Aktivität) benötigt.
• So beenden Sie einen Prozess:

android.os.Process.killProcess(android.os.Process.myPid()); kann angerufen werden.

Wendepunkt:

Standardmäßig werden alle Aktivitäten im selben Prozess in einer Anwendung ausgeführt. (Der Prozess wird durch den Paketnamen definiert). Aber:

Innerhalb derselben Anwendung können verschiedene Prozesse erstellt werden.

Lösung:
Wenn für eine Aktivität ein anderer Prozess erstellt wird, kann sein Kontext verwendet werden, um eine Webansicht zu erstellen. Und wenn dieser Prozess beendet wird, werden alle Komponenten mit Verweisen auf diese Aktivität (in diesem Fall Webview) beendet und der wichtigste wünschenswerte Teil ist:

GC wird nachdrücklich aufgerufen, diesen Müll einzusammeln (Webview).

Code für Hilfe: (ein einfacher Fall)

Insgesamt zwei Aktivitäten: Sagen Sie A & B

Manifestdatei:

<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>

Beginnen Sie mit A, dann mit B

A > B

B wird mit eingebetteter Webansicht erstellt.

Wenn backKey bei Aktivität B gedrückt wird, wird onDestroy aufgerufen:

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

und dies beendet den aktuellen Prozess, dh com.processkill.p3

und nimmt die darauf referenzierte Webansicht weg

HINWEIS: Seien Sie besonders vorsichtig, wenn Sie diesen Kill-Befehl verwenden. (aus offensichtlichen Gründen nicht empfohlen). Implementieren Sie keine statische Methode in der Aktivität (in diesem Fall Aktivität B). Verwenden Sie keinen Verweis auf diese Aktivität von einer anderen (da sie gelöscht und nicht mehr verfügbar ist).

Sie können versuchen, die Webaktivität in einen separaten Prozess zu stecken und zu beenden, wenn die Aktivität zerstört ist, wenn die Handhabung mehrerer Prozesse für Sie kein großer Aufwand ist.