概述

一直听说 WebView 使用不当容易造成内存泄漏，网上有很多针对内存泄漏的解决方案，比较多的是在 Activity.onDestroy 的时候将 WebView 从 View 树中移除，然后再调用 WebView.destroy 方法：

override fun onDestroy() {
    val parent = webView?.parent
    if (parent is ViewGroup) {
        parent.removeView(webView)
    }
    webView?.destroy()
    super.onDestroy()
}

于是我写了一个简单的包含一个 WebView 的 Activity，然后在 Activity.onDestroy 中分别尝试 啥也不干 和 只调用 WebView.destroy 方法，接着项目里面集成了 leakcanary 用来检测内存泄漏，启动 App 后，反复横屏竖屏，发现 Activity.onDestroy 有被正常调用，但是 leakcanary 并没有提示有内存泄漏，因此猜想 WebView 高版本应该把这个问题修复了。我用的测试机是 Android 9 版本的，于是想着换个低版本的机型试试，就弄了个 Android 6 的手机一跑，发现还是没有发生内存泄漏，看了下网上这些讲 WebView 内存泄漏的文章，有的还是 2019 年的，既然都 2019 年了还在谈 WebView 会造成内存泄漏，那感觉 Android 6 的机型不应该表现正常呀，一脸懵逼。。。秉着不弄明白不罢休的原则，遇到这种问题好办，Read The Fucking Source Code 就完事了。

WebView销毁时做了什么

既然网上的解决方案说先调用 removeView 移除 WebView，然后再调用 WebView.destroy 方法，那想着内存泄漏应该可以从 onDetachedFromWindow(从 Window 中 detach) 和 destroy(销毁) 这两个逻辑里找原因，看一下 WebView 中的这两个方法：

public void destroy() {
    checkThread();
    mProvider.destroy();
}

protected void onDetachedFromWindowInternal() {
    mProvider.getViewDelegate().onDetachedFromWindow();
    super.onDetachedFromWindowInternal();
}

一般而言 destroy 方法应该在 Activity.onDestroy 时手动调用，而 onDetachedFromWindowInternal 方法在 View detach 的时候会由系统回调。注意 onDestroy 的调用时机早于 onDetachedFromWindow，相关的源码可以参考 Android图形系统综述中 View 系列的文章自行跟踪。

上面这两个方法都出现了一个叫 mProvider 的对象，这个对象是啥呢？在 WebView.java 中搜索了一下 mProvider = 发现只有一处赋值：

private WebViewProvider mProvider;

mProvider = getFactory().createWebView(this, new PrivateAccess());

它是一个 WebViewProvider 类型的实例，接着看它是怎么被赋值的，首先看一看 getFactory 返回的工厂对象是什么：

private static WebViewFactoryProvider getFactory() {
    return WebViewFactory.getProvider();
}

// WebViewFactory
static WebViewFactoryProvider getProvider() {
    if (sProviderInstance != null) return sProviderInstance;
    Class<WebViewFactoryProvider> providerClass = getProviderClass();
    // CHROMIUM_WEBVIEW_FACTORY_METHOD = "create"
    staticFactory = providerClass.getMethod(CHROMIUM_WEBVIEW_FACTORY_METHOD, WebViewDelegate.class);
    sProviderInstance = (WebViewFactoryProvider) staticFactory.invoke(null, new WebViewDelegate());
    return sProviderInstance;
}

上面的 WebViewFactory.getProvider() 方法看上去是通过调用 providerClass 中的 create 方法拿到了 sProviderInstance 实例，于是得继续看 getProviderClass 方法到底是返回了一个什么类型的类：

private static Class<WebViewFactoryProvider> getProviderClass() {
    // ...
    return getWebViewProviderClass(clazzLoader);
}

public static Class<WebViewFactoryProvider> getWebViewProviderClass(ClassLoader clazzLoader) throws ClassNotFoundException {
    return (Class<WebViewFactoryProvider>) Class.forName(CHROMIUM_WEBVIEW_FACTORY, true, clazzLoader);
}

查看源码，可以发现 CHROMIUM_WEBVIEW_FACTORY 取值为 com.android.webview.chromium.WebViewChromiumFactoryProviderForP，我查看的源码版本是 Android P 的，所以这里是 WebViewChromiumFactoryProviderForP，看了一下其它 Android 版本的源码，发现都有一个对应的 WebViewChromiumFactoryProviderForX 值。这个 WebViewChromiumFactoryProviderForP 类在 AOSP 中是没有的，那应该去哪里找呢？

参考 Chrome developer 的文档: WebView for Android，可以看到从 Android 4.4 开始，WebView 组件基于 Chromium open source project 项目，新的 Webview 与 Android 端的 Chrome 浏览器共享同样的渲染引擎，因此 WebView 和 Chrome 之间的渲染应该会更加一致。而从 Android 5.0(Lollipop) 版本开始将 WebView 迁移到了一个独立的 APK — Android System WebView，因此可以单独在 Android 平台更新。这个 APP 可以在应用管理中看到，看到这里我大概明白了之前为啥用 Android 6 的机器也没有测试出内存泄漏，猜想应该是它的 Android System WebView 应用版本已经把内存泄漏的问题解决了吧，看了一下其应用版本是 86.0.4240.198(可以在应用管理中查看 Android System WebView 应用的版本，另外也可以在浏览器中打开这个网址也会显示版本)。于是我们验证一下这个猜想。

关于 Chromium open source project 的源码可以在这里查看: Chromium open source project Ref，在这里可以查看目标版本的源码，我选择 86.0.4240.198 版本的源码进行解析。接着上面的 WebViewChromiumFactoryProviderForP 开始：

public class WebViewChromiumFactoryProviderForP extends WebViewChromiumFactoryProvider {
    public static WebViewChromiumFactoryProvider create(android.webkit.WebViewDelegate delegate) {
        return new WebViewChromiumFactoryProviderForP(delegate);
    }

    protected WebViewChromiumFactoryProviderForP(android.webkit.WebViewDelegate delegate) {
        super(delegate);
    }
}

可以看到返回了一个 WebViewChromiumFactoryProviderForP 实例，其 createWebView 方法在父类 WebViewChromiumFactoryProvider 中：

public WebViewProvider createWebView(WebView webView, WebView.PrivateAccess privateAccess) {
    return new WebViewChromium(this, webView, privateAccess, mShouldDisableThreadChecking);
}

因此上面的 mProvider 是 WebViewChromium 实例，来看一下它的 onDetachedFromWindow 和 destroy 方法：

public WebViewProvider.ViewDelegate getViewDelegate() {
    return this;
}

public void onDetachedFromWindow() {
    // ...
    mAwContents.onDetachedFromWindow();
}

public void destroy() {
    // ...
    mAwContents.destroy();
}

这俩都会调用到 AwContents 中对应的方法，所以上面 WebView 销毁的时候，其 destroy 和 onDetachedFromWindowInternal 方法最后会调用到 AwContents 中对应的方法，低版本的内存泄漏就发生在这里。

AwContents中的内存泄漏

我们先看一下 mAwContents 的创建：

mAwContents = new AwContents(mFactory.getBrowserContextOnUiThread(), mWebView, mContext, ...);

86.0.4240.198版本

首先看看 86.0.4240.198 版本中的 AwContents 类中的几个相关方法：

public void destroy() {
    if (isDestroyed(NO_WARN)) return;
    // ...
    // Remove pending messages
    mContentsClient.getCallbackHelper().removeCallbacksAndMessages();
    if (mIsAttachedToWindow) {
        // 如果此时没有 detach 则先调用 onDetachedFromWindow 方法，然后才将 mIsDestroyed 置为 true
        Log.w(TAG, "WebView.destroy() called while WebView is still attached to window.");
        onDetachedFromWindow();
    }
    mIsDestroyed = true;
}

// onAttachedToWindow 时会调用
public void onAttachedToWindow() {
    if (isDestroyed(NO_WARN)) return;
    if (mIsAttachedToWindow) {
        Log.w(TAG, "onAttachedToWindow called when already attached. Ignoring");
        return;
    }
    mIsAttachedToWindow = true;
    // ...
    if (mComponentCallbacks != null) return;
    mComponentCallbacks = new AwComponentCallbacks();
    // 注册 ComponentCallbacks
    mContext.registerComponentCallbacks(mComponentCallbacks);
}

// onDetachedFromWindow 时会调用
public void onDetachedFromWindow() {
    if (isDestroyed(NO_WARN)) return;
    if (!mIsAttachedToWindow) {
        Log.w(TAG, "onDetachedFromWindow called when already detached. Ignoring");
        return;
    }
    mIsAttachedToWindow = false;
    // ...
    if (mComponentCallbacks != null) {
        // 将 ComponentCallbacks 解注册
        mContext.unregisterComponentCallbacks(mComponentCallbacks);
        mComponentCallbacks = null;
    }
}

在 View attach 到 Window 中的时候会调用上面的 onAttachedToWindow 方法，在 View detach 的时候会调用到 onDetachedFromWindow 方法，这两个方法中调用了一个 registerComponentCallbacks 和 unregisterComponentCallbacks 函数分别注册和解注册了一个 Callback，低版本会发生内存泄漏的原因就在此！

所以我们再来看一下 ComponentCallbacks 相关的逻辑：

// Context
public void registerComponentCallbacks(ComponentCallbacks callback) {
    getApplicationContext().registerComponentCallbacks(callback);
}

// Application
public void registerComponentCallbacks(ComponentCallbacks callback) {
    synchronized (mComponentCallbacks) {
        mComponentCallbacks.add(callback);
    }
}

所以假设在 AwContents 中只调用了 registerComponentCallbacks 注册方法而没有调用 unregisterComponentCallbacks 方法来解注册，那么会出现什么情况呢？我们看一下这个 AwComponentCallbacks 类的实现，发现它是 AwContents 中的一个非静态内部类，因此它会持有外部 AwContents 实例的引用，而 AwContents 持有 WebView 的 Context 上下文，对于 xml 中的 WebView 布局而言，这个上下文就是其所在的 Activity，因此如果在 Activity 生命周期结束后没有调用 unregisterComponentCallbacks 方法解注册的话，便可能会发生内存泄漏。

在 86.0.4240.198 版本中，如果在 Activity.onDestroy 方法中啥也不干，那么在 View detach 的时候依旧会调用 unregisterComponentCallbacks 方法解注册；而如果在 Activity.onDestroy 方法中只手动调用了 WebView.destroy 方法，那么还是会先通过调用 onDetachedFromWindow 来解注册，此时的 if (isDestroyed(NO_WARN)) return; 判断是 false，可以正常执行到解注册的逻辑，然后才会标记为已销毁。

54.0.2805.1版本

接着我们再看一个旧版本 54.0.2805.1 中的 AwContents 这几个方法：

public void destroy() {
    if (isDestroyed(NO_WARN)) return;
    // Remove pending messages
    mContentsClient.getCallbackHelper().removeCallbacksAndMessages();
    // ...
    if (mIsAttachedToWindow) {
        Log.w(TAG, "WebView.destroy() called while WebView is still attached to window.");
        nativeOnDetachedFromWindow(mNativeAwContents);
    }
    mIsDestroyed = true;
}

public void onAttachedToWindow() {
    if (isDestroyed(NO_WARN)) return;
    // ...
    if (mComponentCallbacks != null) return;
    mComponentCallbacks = new AwComponentCallbacks();
    mContext.registerComponentCallbacks(mComponentCallbacks);
}

public void onDetachedFromWindow() {
    if (isDestroyed(NO_WARN)) return;
    nativeOnDetachedFromWindow(mNativeAwContents);
    // ...
    if (mComponentCallbacks != null) {
        mContext.unregisterComponentCallbacks(mComponentCallbacks);
        mComponentCallbacks = null;
    }
}

可以看到如果在 Activity.onDestroy 中只调用了 WebView.destroy 方法的话，那么此时还没有调用到 onDetachedFromWindow 方法去解注册，却已经将 mIsDestroyed 置为了 true，于是当 detach 的时候，onDetachedFromWindow 判断到 isDestroyed 为 true 则不会走接下来解注册的逻辑了，于是内存泄漏也随之而来。

而如果在 Activity.onDestroy 中不手动调用 WebView.destroy 的话，理论上在 WebView detach 的时候能调用 onDetachedFromWindow 方法解注册 Callback，那么这个内存泄漏问题应该不会发生，但是没有调用 WebView.destroy 方法的话，很可能会发生其它问题，比如说不会调用 mContentsClient.getCallbackHelper().removeCallbacksAndMessages() 去移除 pending 的消息，说不定又有新的内存泄漏之类的。。。

要测试低版本 Chromium 的内存泄漏，可以找一个低版本的 Android 手机，然后将其 Android System WebView 应用卸载到装机版本，然后查看对应版本的 AwContents 类源码，如果源码中有内存泄漏的可能的话就可以测试了。另外如果手里头有 Root 的手机，可以尝试将 Android System WebView 最新版卸载，然后在 apkmirror 中下载一个低版本的 Android System WebView APK 安装到手机上；或者直接从源码中编译出一个指定版本的 Android System WebView 应用，源码编译时间有限我也没试过，可以参考 build-instructions。

总结

WebView 中的内存泄漏其实与 Chromium 内核版本有关，在新版本的 Chromium 内核中内存泄漏问题已经被解决了，而且从 Android 5.0(Lollipop) 版本开始将 Chromium WebView 迁移到了一个独立的 APP – Android System WebView，随着 Android System WebView 的独立发布，低版本 Android 系统(Android 5以上)上搭载的 Chromium 内核一般来说也不会太旧，所以出现内存泄漏的概率应该是比较小的。如果仍需要兼容这很小的一部分机型，可以通过文章开头的方式销毁 WebView，即先移除 WebView 组件，确保先调用到 onDetachedFromWindow 方法解注册，然后再通过 WebView.destroy 方法处理其它销毁逻辑。

文中相关的内容如有错误或遗漏欢迎指出，共同进步！觉得不错的留个赞再走哈~

面试复习笔记：

这份资料我从春招开始，就会将各博客、论坛。网站上等优质的Android开发中高级面试题收集起来，然后全网寻找最优的解答方案。每一道面试题都是百分百的大厂面经真题+最优解答。包知识脉络 + 诸多细节。
节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。
给文章留个小赞，就可以免费领取啦~

戳我领取：Android对线暴打面试指南、超硬核Android面试知识笔记、3000页Android开发者架构师核心知识笔记

《960页Android开发笔记》