在混合型app中它是主角，一切由它呈現，如58同城，趕集網等；在另一些超級app中亦有它的影子，微信，qq，支付寶，沒有一個超級app能少了它，既能展示最新最潮的實時資訊，又能扮演盤踞一方的全功能型網站，與native結合後又能扮演諸如公眾號之內的應用等等，其能力可想而知。

webview在android端的演化可謂曲折，2015年google宣佈不在支援4.4版本一下的webview^[1]，這意味著目前扔有近四分之一的Android使用者因無法獲得Google的支援而受到安全威脅。對於深度依賴webview的巨頭開始自家的核心及上層sdk以求提升整體穩定性及其效能,騰訊x5核心是比較通用的一種.

目前大致的webview記憶體處理方式分為兩類:

1.獨立的web程序，與主程序隔開

這個方法被運用於類似qq，微信這樣的超級app中，這也是解決任何webview記憶體問題屢試不爽的方法
對於封裝的webactivity，在manifest.xml中設定

<activity android:name=".webview.WebViewActivity" android:launchMode="singleTop" android:process=":remote" android:screenOrientation="unspecified" />

然後在關閉webactivity時銷燬程序

@Overrideprotected void onDestroy() {                
     super.onDestroy(); 
     System.exit(0);
}

關閉瀏覽器後便銷燬整個程序，這樣一般95%的情況下不會造成記憶體洩漏之類的問題，但這就涉及到android程序間通訊，比較不方便處理， 優劣參半，也是可選的一個方案.

2.封裝過的webview

相比系統內建的webview的支援自2005年之後就沒有了，而首推google的chrome。 騰訊的x5webview對h5的相容性與穩定性與安全性逐漸凸顯出來，並自成一系, 下面以使用x5webview為例做說明:

• 首先使用webview的時候，不在xml裡面宣告，而是直接程式碼new個物件，傳入application context防止activity引用濫用.

webView =  new BridgeWebView(getContext().getApplicationContext());
webFrameLayout.addView(webView, 0);

在使用了這個方式後，基本上90%的webview記憶體洩漏的問題便得以解決.

• 而在android4.4版本以下，會出現android webview無法自動釋放，如在fragment中,使用ondetach的釋放webview是比較好的時機^[2]

public void onDetach() {
    releaseWebViews();
    super.onDetach();
}
public synchronized void releaseWebViews() {
    if(webView != null) {
        try {
            if(webView.getParent() != null) {
                ((ViewGroup) webView.getParent()).removeView(webView);
            }
//                if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR2) {
//this is causing the segfault occasionally below 4.2
            webView.destroy();
    //                }
        }catch (IllegalArgumentException e) {
            DLog.p(e);
        }
        RefWatcher refWatcher = FApplication.getRefWatcher();
        refWatcher.watch(webView);
        webView = null;
    }
}

其中webview自身的銷燬程式碼如下：

@Override
public void destroy()
//flushMessageQueue();
    clearCache(true);
    clearFormData();
    clearMatches();
    clearSslPreferences();
    clearDisappearingChildren();
    clearHistory();
    //@Deprecated
    //clearView();
    clearAnimation();
    loadUrl("about:blank");
    removeAllViews();
    freeMemory();
    super.destroy();
}

• 如果以上的方案還不管用，實時加入反射來清理webview的引用：

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(BundlesavedInstanceState){
    super.onCreate(savedInstanceState);
    setConfigCallback((WindowManager);
    getApplicationContext().getSystemService(Context.WINDOW_SERVICE));
}
publicvoidonDestroy()
{
    setConfigCallback(null);
    super.onDestroy();
}

• 對於application 級別的可能的misbehaving callbacks，加入

private static String[] misbehavingClasses = new String[]{
    "com.google.android.gms.ads",
    "com.android.org.chromium.android_webview.AwContents$AwComponentCallbacks",
};
public static boolean isMisbehavingCallBacks(String name){
    for(String s : misbehavingClasses){
        if(name.startsWith(s)){
            return true;
        }
    }
    return false;
}

然後重寫applicaiton類記錄這些callback, 並在適當的時機刪掉：

@Override
public void registerComponentCallbacks(ComponentCallbacks callback) {
    super.registerComponentCallbacks(callback);
    ComponentCallbacksBehavioralAdjustmentToolIcs.INSTANCE.onComponentCallbacksRegistered(callback);
}

@Override
public void unregisterComponentCallbacks(ComponentCallbacks callback) {
    ComponentCallbacksBehavioralAdjustmentToolIcs.INSTANCE.onComponentCallbacksUnregistered(callback);
    super.unregisterComponentCallbacks(callback);
}

public void forceUnregisterComponentCallbacks() {
    ComponentCallbacksBehavioralAdjustmentToolIcs.INSTANCE.unregisterAll(this);
}


private static class ComponentCallbacksBehavioralAdjustmentToolIcs {
    private static final String TAG = "componentCallbacks";
    static ComponentCallbacksBehavioralAdjustmentToolIcs INSTANCE = new ComponentCallbacksBehavioralAdjustmentToolIcs();

    private WeakHashMap<ComponentCallbacks, ApplicationErrorReport.CrashInfo> mCallbacks = new WeakHashMap<>();
    private boolean mSuspended = false;

    public void onComponentCallbacksRegistered(ComponentCallbacks callback) {
        Throwable thr = new Throwable("Callback registered here.");
        ApplicationErrorReport.CrashInfo ci = new ApplicationErrorReport.CrashInfo(thr);

        if (FApplication.DEBUG) DLog.w(TAG, "registerComponentCallbacks: " + callback.getClass().getName(), thr);

        if (!mSuspended) {
            if (BugFix.isMisbehavingCallBacks(callback.getClass().getName())) {
                mCallbacks.put(callback, ci);
            }
            // TODO: other classes may still prove to be problematic?  For now, only watch for .gms.ads, since we know those are misbehaving
        } else {
            if (FApplication.DEBUG) DLog.e(TAG, "ComponentCallbacks was registered while tracking is suspended!");
        }
    }

    public void onComponentCallbacksUnregistered(ComponentCallbacks callback) {
        if (!mSuspended) {
            if (FApplication.DEBUG) {
                DLog.i(TAG, "unregisterComponentCallbacks: " + callback, new Throwable());
            }

            mCallbacks.remove(callback);
        }
    }

    public void unregisterAll(Context context) {
        mSuspended = true;
        for (Map.Entry<ComponentCallbacks, ApplicationErrorReport.CrashInfo> entry : mCallbacks.entrySet()) {
            ComponentCallbacks callback = entry.getKey();
            if (callback == null) continue;

            if (FApplication.DEBUG) {
                DLog.w(TAG, "Forcibly unregistering a misbehaving ComponentCallbacks: " + entry.getKey());
                DLog.w(TAG, entry.getValue().stackTrace);
            }

            try {
                context.unregisterComponentCallbacks(entry.getKey());
            } catch (Exception exc) {
                if (FApplication.DEBUG) DLog.e(TAG, "Unable to unregister ComponentCallbacks", exc);
            }
        }

        mCallbacks.clear();
        mSuspended = false;
    }
}

為方便webactivity的debug

• 在application的oncreate裡面，我們加入

private static void enableStrictMode() {
StrictMode.ThreadPolicy.Builder threadPolicyBuilder =
    new StrictMode.ThreadPolicy.Builder()
    .detectAll()
    .penaltyLog();
    StrictMode.VmPolicy.Builder vmPolicyBuilder =
    new StrictMode.VmPolicy.Builder()
    .detectAll()
    .penaltyLog();
    threadPolicyBuilder.penaltyFlashScreen();
    vmPolicyBuilder.setClassInstanceLimit(WebActivity.class, 1);
    StrictMode.setThreadPolicy(threadPolicyBuilder.build());
    StrictMode.setVmPolicy(vmPolicyBuilder.build());
}

• 在webview中，對於android4.4以上的版本，我們開啟除錯模式

if (FApplication.DEBUG && Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
    WebView.setWebContentsDebuggingEnabled(true);
}

• 最後不可缺少的是, leakcanary的加入來跟蹤這些消耗記憶體的元件:
  在webfragment，webactivity，webview ondestory後加上

    RefWatcher refWatcher = FApplication.getRefWatcher();
    refWatcher.watch(obj);

總結: 如果你只是簡單地用 webview 做呈現, 使用application context啟動webview已經足夠了，但如果你需要webview來播放視訊，處理彈窗等複雜工作, 新建一個程序來處理會更可靠.