WebView内存泄漏的原因是什么？如何避免和检测？

核心原因

WebView内存泄漏的根源在于它的生命周期与宿主组件（Activity/Fragment）不一致。具体来说：

WebView持有Activity Context引用。 这是最高频的泄漏场景。WebView在XML中声明时，默认拿到的Context就是Activity本身，而WebView内部的各种回调（ChromeClient、WebViewClient等）会长期持有这个引用，导致Activity退出后无法被GC回收。这跟普通View不一样——普通View随Activity销毁而销毁，但WebView底层有独立的渲染引擎和JS引擎，它们的生命周期由自己管理。

JavaScriptInterface持有外部引用。 通过addJavascriptInterface注入的Java对象，默认持有外部类的强引用。如果注入的是Activity内部类或匿名类，Activity就被间接持有了。

WebView未正确销毁。 直接调用webView.destroy()是不够的。如果WebView还附着在Window上，destroy会抛异常或静默失败，WebView对象仍然留在内存中。

匿名内部类和Handler泄漏。 WebView内部的WebViewClient、WebChromeClient、各种Listener如果用匿名类实现，默认持有外部Activity引用，加上WebView本身就不容易被回收，形成泄漏链。

静态变量或单例持有WebView。 有些开发者为了"复用"WebView，用静态变量保存实例，结果整个Activity都跟着泄漏。

正确的避免方式

动态创建WebView，使用Application Context

不要在XML中声明WebView，改为代码动态创建，并传入Application Context：

java
// 在Activity中
webView = new WebView(getApplicationContext());
frameLayout.addView(webView, new FrameLayout.LayoutParams(
    ViewGroup.LayoutParams.MATCH_PARENT,
    ViewGroup.LayoutParams.MATCH_PARENT));

注意：使用Application Context后，WebView中的弹窗（如alert）会抛异常，需要额外处理——在WebChromeClient.onJsAlert中用Dialog替代。

完整的销毁流程

这是实际项目中验证过的销毁顺序，顺序不能乱：

java
@Override
protected void onDestroy() {
    if (webView != null) {
        // 1. 停止加载
        webView.stopLoading();
        // 2. 清除历史记录
        webView.clearHistory();
        // 3. 移除所有JS接口
        webView.removeJavascriptInterface("xxx");
        // 4. 加载空白页，断开与当前页面的关联
        webView.loadUrl("about:blank");
        // 5. 从父容器移除
        ViewGroup parent = (ViewGroup) webView.getParent();
        if (parent != null) {
            parent.removeView(webView);
        }
        // 6. 销毁WebView
        webView.destroy();
        webView = null;
    }
    super.onDestroy();
}

Fragment中的额外处理

Fragment比Activity更复杂，因为View的创建和销毁不等于Fragment的生命周期：

java
@Override
public void onDestroyView() {
    if (webView != null) {
        webView.stopLoading();
        webView.loadUrl("about:blank");
        ((ViewGroup) webView.getParent()).removeView(webView);
        webView.destroy();
        webView = null;
    }
    super.onDestroyView();
}

关键点：不要在Fragment中缓存WebView实例，每次onCreateView重新创建。

使用WeakReference包装Context

如果某些场景必须传Activity Context（比如需要弹窗），用WeakReference包装：

java
public class SafeWebViewClient extends WebViewClient {
    private WeakReference<Activity> activityRef;

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

    @Override
    public boolean shouldOverrideUrlLoading(WebView view, String url) {
        Activity activity = activityRef.get();
        if (activity != null && !activity.isFinishing()) {
            // 处理URL跳转
        }
        return false;
    }
}

独立进程方案

对于重度使用WebView的场景（如混合开发App），最彻底的方案是把WebView放到独立进程：

xml
<activity
    android:name=".WebViewActivity"
    android:process=":web" />

退出时直接杀掉进程，内存100%释放：

java
@Override
protected void onDestroy() {
    // 先做常规清理
    // ...
    // 杀进程，彻底释放内存
    android.os.Process.killProcess(android.os.Process.myPid());
}

这个方案的代价是进程间通信需要用AIDL或广播，UI层面要做好进程切换的体验。

检测手段

LeakCanary

集成最简单，Debug包自动检测：

groovy
dependencies {
    debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.12'
}

频繁进出WebView页面，LeakCanary会自动捕获泄漏并输出引用链。关注引用链中是否有WebView -> Activity的模式。

Android Studio Profiler

手动检测流程：打开Profiler的Memory面板，反复进出WebView页面5-10次，观察内存曲线。如果每次退出后内存只降一点点、整体持续上升，就是泄漏。Dump heap后搜索WebView和你的Activity类名，看是否有不该存在的实例。

MAT分析

从Profiler导出.hprof文件，用MAT打开，执行以下查询：

shell
SELECT * FROM instancesof android.webkit.WebView
WHERE retainedSize > 10000

通过Dominator Tree找到最大的 retained size 对象，沿引用链向下追溯，定位泄漏源。

面试追问

Q: 为什么WebView用Application Context后alert弹窗会崩？

因为JsResult内部依赖Window来创建Dialog，而Application Context没有Window。解决方案是在WebChromeClient.onJsAlert中拦截，用当前Activity创建Dialog（需要持有Activity的WeakReference），或者统一用Toast提示。

Q: WebView独立进程方案的坑有哪些？

进程启动有额外开销（冷启动多100-200ms）；进程间不能直接共享内存和对象；WebView进程崩溃不影响主进程但需要做恢复逻辑；某些厂商ROM对多进程支持有bug。实际项目中建议只用在WebView密集的页面，不要所有页面都放独立进程。

Q: 如何判断是WebView泄漏还是其他原因导致的内存增长？

对比实验：用空Activity（不含WebView）做同样的进出操作，观察内存曲线。如果空Activity不泄漏而WebView Activity泄漏，基本可以确认。再用LeakCanary看引用链，确认是否经过WebView相关对象。