【移動應用開發技術】Android5.1應用中WebView出現內存泄漏如何解決

今天就跟大家聊聊有關Android5.1應用中WebView出現內存泄漏如何解決，可能很多人都不太了解，為了讓大家更加了解，在下給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。問題背景在排查項目內存泄漏過程中發現了一些由WebView引起的內存泄漏，經過測試發現該部分泄漏只會出現在android5.1及以上的機型。雖然項目使用WebView的場景并不多，但秉承著一個泄漏都不放過的精神，我們肯定要把它給解決了。遇到的問題項目中使用WebView的頁面主要在FAQ頁面，問題也出現在多次進入退出時，發現內存占用大，GC頻繁。使用LeakCanary觀察發現有兩個內存泄漏很頻繁：

我們分析一下這兩個泄漏：從圖一我們可以發現是WebView的ContentViewCore中的成員變量mContainerView引用著AccessibilityManager的mAccessibilityStateChangeListeners導致activity不能被回收造成了泄漏。引用關系：mAccessibilityStateChangeListeners->ContentViewCore->WebView->SettingHelpActivity從圖二可以發現引用關系是：mComponentCallbacks->AwContents->WebView->SettingHelpActivity問題分析我們找找mAccessibilityStateChangeListeners與mComponentCallbacks是在什么時候注冊的，我們先看看mAccessibilityStateChangeListenersAccessibilityManager.java上面這幾個方法是在AccessibilityManager.class中定義的，根據方法調用可以發現在ViewRootImpl初始化會調用addAccessibilityStateChangeListener添加一個listener，然后會在dispatchDetachedFromWindow的時候remove這個listener。既然是有remove的，那為什么會一直引用著呢？我們稍后再分析。我們再看看mComponentCallbacks是在什么時候注冊的Application.java上面這兩個方法是在Application中定義的，根據方法調用可以發現是在Context基類中被調用根據泄漏路徑，難道是AwContents中注冊了mComponentCallbacks未反注冊么？只有看chromium源碼才能知道真正的原因了，好在chromium是開源的，我們在android5.1Chromium源碼中找到我們需要的AwContents（自備梯子），看下在什么時候注冊了AwContents.java在以上兩個方法中我們發現了mComponentCallbacks的蹤影，在onAttachedToWindow的時候調用mContext.registerComponentCallbacks(mComponentCallbacks)進行注冊，在onDetachedFromWindow中反注冊。我們仔細看看onDetachedFromWindow中的代碼會發現如果在onDetachedFromWindow的時候isDestroyed條件成立會直接return，這有可能導致無法執行mContext.unregisterComponentCallbacks(mComponentCallbacks);也就會導致我們第一個泄漏，因為onDetachedFromWindow無法正常流程執行完也就不會調用ViewRootImp的dispatchDetachedFromWindow方法，那我們找下這個條件什么時候會為true發現是在destroy中設置為true的，也就是說執行了destroy()就會導致無法反注冊。我們一般在activity中使用webview時會在onDestroy方法中調用mWebView.destroy();來釋放webview。根據源碼可以知道如果在onDetachedFromWindow之前調用了destroy那就肯定會無法正常反注冊了，也就會導致內存泄漏。問題的解決我們知道了原因后，解決就比較容易了，就是在銷毀webview前一定要onDetachedFromWindow，我們先將webview從它的父view中移除再調用destroy方法，代碼如下：還有個問題，就是為什么在5.1以下的機型不會內存泄漏呢，我們看下4.4的源碼AwContents我們可以看到在onDetachedFromWindow方法上是沒有