第26章 WebView性能优化

课程目录第26章 WebView性能优化

26、WebView性能优化：WebView内存泄漏、缓存策略、JS Bridge优化、预加载与复用池

WebView 在 Android 开发里，一直是个让人又爱又恨的东西。爱它，是因为它能承载 H5 页面，实现动态更新、跨平台复用；恨它，是因为它实在太容易出问题了——内存泄漏、加载慢、卡顿、OOM……我这些年做性能优化，光是 WebView 相关的坑，就踩了不下十几个。

今天咱们就好好聊聊 WebView 性能优化。说白了，核心就四个方向：内存泄漏治理、缓存策略、JS Bridge 优化、预加载与复用池。把这四点吃透了，你的 WebView 体验至少能提升 50%。

核心观点：WebView 优化不是单一技巧，而是一套组合拳。从创建到销毁，从网络到渲染，每个环节都有优化空间。

一、WebView 内存泄漏：最隐蔽的杀手

内存泄漏是 WebView 的头号问题。我见过太多 App 因为 WebView 泄漏导致频繁 OOM，最后不得不强制杀死进程。为什么会这样？因为 WebView 的上下文（Context）引用链太长了。

WebView 一旦被创建，它会持有 Activity 的引用。如果你在 Activity 销毁时没有正确释放 WebView，整个 Activity 就无法被 GC 回收。更可怕的是，WebView 内部还有独立的渲染进程和线程池，这些资源释放起来非常麻烦。

我曾经踩过的坑：在 Fragment 里使用 WebView，Fragment 销毁时只调用了 webView.destroy()，但忘了从父布局中移除 WebView。结果 Fragment 的实例一直被 WebView 持有，导致整个页面的图片、Bitmap 全部泄漏。那次线上 OOM 率直接飙升了 3 倍。

正确的释放流程应该是这样的：

// 正确的 WebView 释放方式
@Override
public void onDestroy() {
    if (webView != null) {
        // 1. 先从父布局移除
        ViewGroup parent = (ViewGroup) webView.getParent();
        if (parent != null) {
            parent.removeView(webView);
        }
        // 2. 停止加载
        webView.stopLoading();
        // 3. 清空历史记录
        webView.clearHistory();
        // 4. 移除所有 View
        webView.removeAllViews();
        // 5. 销毁
        webView.destroy();
        webView = null;
    }
    super.onDestroy();
}

嗯，这里要注意一点：不要在 onPause 里调用 destroy()。我见过有人这么写，结果页面切到后台再回来，WebView 已经没了，直接白屏。destroy() 只应该在确定不再使用 WebView 时调用。

二、缓存策略：让页面秒开

WebView 加载慢，很大一部分原因是网络请求耗时。缓存策略就是解决这个问题的。我个人习惯把缓存分为三层：离线包、内存缓存、磁盘缓存。

缓存层级	速度	容量	适用场景
离线包	极快（本地读取）	大（可预置）	核心页面、首页
内存缓存	最快	小（需控制）	频繁访问的页面
磁盘缓存	较快	中等	常规页面

离线包策略是我最推荐的。说白了，就是把 H5 资源打包到 APK 里，或者启动时下载到本地。WebView 加载时直接拦截请求，从本地读取资源。这样即使没网，页面也能正常展示。

// 离线包拦截示例
webView.setWebViewClient(new WebViewClient() {
    @Override
    public WebResourceResponse shouldInterceptRequest(WebView view, String url) {
        // 检查本地是否有离线包
        String localPath = OfflinePackageManager.getLocalPath(url);
        if (localPath != null) {
            try {
                FileInputStream inputStream = new FileInputStream(localPath);
                String mimeType = getMimeType(url);
                return new WebResourceResponse(mimeType, "UTF-8", inputStream);
            } catch (Exception e) {
                // 本地文件异常，走网络
            }
        }
        return super.shouldInterceptRequest(view, url);
    }
});

小技巧：离线包更新时，不要全量替换。用版本号 + 增量更新的方式，只下载变更的文件。我之前的项目用这个方案，离线包下载量从 5MB 降到了 200KB 左右。

三、JS Bridge 优化：别让通信成为瓶颈

JS Bridge 是 Native 和 H5 之间的桥梁。但很多人不知道，JS Bridge 的调用是有性能损耗的。每次调用都要经过序列化、跨进程通信（如果是独立进程）、回调处理等环节。调用频率一高，页面就会卡顿。

我建议遵循三个原则：

批量调用：把多次 JS Bridge 调用合并成一次。比如获取设备信息，不要分别获取 IMEI、MAC、型号，而是封装成一个接口一次性返回。
异步回调：JS Bridge 的回调不要在主线程执行。尤其是涉及 IO 操作（如读取文件、数据库查询）时，一定要切到子线程。
数据精简：传递的数据越小越好。JSON 字符串能精简就精简，字段名用缩写，去掉不必要的嵌套。

// 优化前的 JS Bridge 调用（三次调用）
// jsBridge.call("getIMEI", callback1);
// jsBridge.call("getMAC", callback2);
// jsBridge.call("getModel", callback3);

// 优化后：合并为一次调用
// jsBridge.call("getDeviceInfo", {
//     fields: ["imei", "mac", "model"]
// }, callback);

// Native 端处理
@JavascriptInterface
public String getDeviceInfo(String jsonParams) {
    // 切到子线程处理
    new Thread(() -> {
        JSONObject params = new JSONObject(jsonParams);
        JSONArray fields = params.getJSONArray("fields");
        JSONObject result = new JSONObject();
        for (int i = 0; i < fields.length(); i++) {
            String field = fields.getString(i);
            // 获取对应的设备信息
            result.put(field, getFieldValue(field));
        }
        // 回调给 H5
        callback(result.toString());
    }).start();
    return "processing";
}

注意：@JavascriptInterface 注解的方法会在 WebView 的渲染线程中执行。如果你的方法里有耗时操作，一定要自己切线程。否则会阻塞 WebView 的渲染，导致页面卡死。

四、预加载与复用池：消灭白屏等待

用户最不能忍的是什么？是白屏。点开一个 H5 页面，等 2 秒才看到内容，用户早就划走了。预加载和复用池就是解决这个问题的。

预加载的思路很简单：在用户还没点击之前，就把 WebView 创建好，甚至把页面加载好。比如用户在列表页时，我们可以提前创建下一个页面的 WebView，并开始加载 URL。等用户点击跳转时，直接展示已经加载好的页面。

复用池就更进一步了。我习惯维护一个 WebView 对象池，大小控制在 2-3 个。当页面关闭时，不销毁 WebView，而是重置状态后放回池中。下次需要时直接从池中取出，省去了 WebView 创建和初始化的时间。

// WebView 复用池示例
public class WebViewPool {
    private static final int MAX_POOL_SIZE = 3;
    private final LinkedList pool = new LinkedList<>();
    private final Context context;

    public WebViewPool(Context context) {
        this.context = context.getApplicationContext();
    }

    public WebView acquire() {
        WebView webView = pool.poll();
        if (webView == null) {
            // 池中没有，创建新的
            webView = createWebView();
        }
        return webView;
    }

    public void release(WebView webView) {
        if (pool.size() >= MAX_POOL_SIZE) {
            // 池已满，直接销毁
            destroyWebView(webView);
            return;
        }
        // 重置状态
        webView.stopLoading();
        webView.loadUrl("about:blank");
        webView.clearHistory();
        // 放回池中
        pool.offer(webView);
    }

    private WebView createWebView() {
        WebView webView = new WebView(context);
        // 配置 WebView 设置
        WebSettings settings = webView.getSettings();
        settings.setJavaScriptEnabled(true);
        settings.setCacheMode(WebSettings.LOAD_CACHE_ELSE_NETWORK);
        // ... 其他配置
        return webView;
    }

    private void destroyWebView(WebView webView) {
        ViewGroup parent = (ViewGroup) webView.getParent();
        if (parent != null) {
            parent.removeView(webView);
        }
        webView.removeAllViews();
        webView.destroy();
    }
}

我的经验：复用池里的 WebView 不要超过 3 个。超过 3 个后，内存占用会明显增加，反而得不偿失。另外，复用前一定要重置状态，否则会出现页面错乱、历史记录残留等问题。

预加载和复用池配合使用，效果最好。比如在首页预创建 1 个 WebView 并加载常用页面，同时维护一个 2 个 WebView 的复用池。这样用户无论点击哪个 H5 页面，都能在 200ms 内看到内容。

好了，WebView 性能优化就聊到这里。这四个方向——内存泄漏、缓存策略、JS Bridge、预加载与复用池——每一个都值得深入实践。你想想看，如果你的 App 能做到页面秒开、不闪退、不卡顿，用户的留存率怎么可能不高？

📚 课程目录

26、WebView性能优化：WebView内存泄漏、缓存策略、JS Bridge优化、预加载与复用池

一、WebView 内存泄漏：最隐蔽的杀手

二、缓存策略：让页面秒开

三、JS Bridge 优化：别让通信成为瓶颈

四、预加载与复用池：消灭白屏等待