15、WebView内存管理：WebView的内存泄漏场景，多进程方案，内存释放技巧

WebView 这东西，说它是 Android 开发里的「内存黑洞」，一点不过分。

我早期做混合开发时，就吃过它的亏。一个新闻详情页，打开三五次，App 直接 OOM 崩溃。查了半天，发现是 WebView 把 Activity 给「粘」住了，死活释放不掉。

今天咱们就把 WebView 的内存问题彻底聊透。从泄漏场景，到多进程方案，再到释放技巧，一步到位。

15.1 那些年我们踩过的 WebView 内存泄漏坑

WebView 的内存泄漏，说白了就两个原因：生命周期错乱 和 引用没断开。

15.1.1 Activity 泄漏：最常见的坑

你在 Activity 里 new 了一个 WebView，然后把它 addView 到布局里。Activity 退出时，WebView 还在后台加载页面，它持有了 Activity 的引用。结果呢？Activity 无法被 GC 回收。

我遇到过最离谱的一次，是 WebView 里的 JS 回调持有了 Activity 的匿名内部类。Activity 退出了，JS 还在跑，引用链一直不断。内存泄漏就这么产生了。

15.1.2 其他常见泄漏场景

• WebView 未从父容器移除：直接 destroy 而不 removeView，会导致 WindowManager 还持有引用。
• Handler 或内部类持有 WebView：比如 WebChromeClient 里的匿名内部类，隐式持有了外部类引用。
• JS 接口泄漏：addJavascriptInterface 注入的对象如果持有了 Activity，泄漏就发生了。
• WebView 缓存和 Cookie：大量缓存数据占用了内存，不及时清理也会导致问题。

15.2 多进程方案：把 WebView 关进「隔离区」

你想想看，WebView 的内存泄漏这么难搞，那干脆把它放到另一个进程里不就行了？

这就是多进程方案的核心思路。主进程挂了，WebView 进程也影响不到主进程。而且 WebView 进程退出时，系统会回收它占用的所有内存，干净利落。

15.2.1 如何实现多进程 WebView

实现起来其实不复杂。在 AndroidManifest 里给承载 WebView 的 Activity 指定一个独立进程：

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

然后在主进程和 WebView 进程之间通信，可以用 AIDL 或者 Messenger。我个人习惯用 AIDL，因为更直接。

15.2.2 多进程的代价

嗯，这里要注意。多进程不是银弹。它有几个代价：

• 内存开销增加：每个进程都有自己的 Zygote 副本，多一个进程就多一份基础内存。
• 通信成本：跨进程调用比同进程调用慢得多，频繁通信会影响性能。
• 状态同步复杂：Cookie、缓存、登录状态等需要手动同步。

15.3 内存释放技巧：让 WebView 乖乖交还内存

不管用不用多进程，释放技巧都得掌握。我总结了几个实战经验：

15.3.1 正确的销毁流程

这个流程我踩过坑，现在直接给你标准答案：

@Override
protected void onDestroy() {
    // 1. 先从父容器移除
    if (webView.getParent() != null) {
        ((ViewGroup) webView.getParent()).removeView(webView);
    }
    
    // 2. 停止加载
    webView.stopLoading();
    
    // 3. 移除所有子 View
    webView.removeAllViews();
    
    // 4. 销毁 WebView
    webView.destroy();
    
    // 5. 置 null
    webView = null;
    
    super.onDestroy();
}

15.3.2 清理缓存和 Cookie

WebView 的缓存和 Cookie 会占用不少内存。在合适的时机清理一下：

// 清除缓存
webView.clearCache(true);

// 清除 Cookie
CookieManager.getInstance().removeAllCookies(null);

// 清除历史记录
webView.clearHistory();

我个人建议在 Activity 的 onStop() 里做这些清理，而不是 onDestroy()。因为 onDestroy() 可能不会及时调用。

15.3.3 使用 WebView 池

如果你频繁打开 WebView 页面，每次都创建销毁，内存抖动会很严重。我做过一个项目，用对象池管理 WebView：

public class WebViewPool {
    private static final int MAX_POOL_SIZE = 3;
    private final LinkedList<WebView> pool = new LinkedList<>();
    
    public WebView acquire(Context context) {
        if (pool.isEmpty()) {
            return new WebView(context);
        }
        WebView webView = pool.removeFirst();
        // 重置状态
        webView.loadUrl("about:blank");
        return webView;
    }
    
    public void release(WebView webView) {
        if (pool.size() < MAX_POOL_SIZE) {
            pool.addLast(webView);
        } else {
            webView.destroy();
        }
    }
}

15.4 知识体系总览

下面这张图，把 WebView 内存管理的核心逻辑串起来了。你可以对照着看，心里就有谱了。

15.5 实战建议

说了这么多，给你几个可以直接用的建议：

• 优先用多进程方案：如果你的 App 重度依赖 WebView，多进程是性价比最高的选择。
• 销毁流程写进基类：把销毁逻辑封装到 BaseActivity 里，所有子类继承即可，避免遗漏。
• 定期清理缓存：在 App 进入后台时，或者 WebView 页面关闭时，顺手清理一下。
• 监控 WebView 内存：用 Profiler 或者 LeakCanary 盯着，泄漏了第一时间发现。