美文网首页Android开发Android进阶之路
Android-WebView还会存在内存泄漏吗?

Android-WebView还会存在内存泄漏吗?

作者: 木木玩Android | 来源:发表于2020-12-04 21:51 被阅读0次

    一直听说 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 方法处理其它销毁逻辑。

    本文在开源项目:https://github.com/Android-Alvin/Android-LearningNotes 中已收录,里面包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等,资源持续更新中...

    作者:苍耳叔叔
    链接:https://juejin.cn/post/6901487965562732551
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    相关文章

      网友评论

        本文标题:Android-WebView还会存在内存泄漏吗?

        本文链接:https://www.haomeiwen.com/subject/jxfwwktx.html