編輯:關於Android編程
背景
在 Android 5.1 系統上,在項目中遇到一個WebView引起的問題,每打開一個帶webview的界面,退出後,這個activity都不會被釋放,activity的實例會被持有,由於我們項目中經常會用到浏覽web頁面的地方,可能引起內存積壓,導致內存溢出的現象,所以這個問題還是比較嚴重的。
問題分析
使用Android Studio的內存monitor,得到了以下的內存分析,我打開了三個BookDetailActivity界面(都有webview),檢查結果顯示有3個activity洩漏,如下圖所示:
這個問題還是比較嚴重的,那麼進一步看詳細的信息,找出到底是哪裡引起的內存洩漏,詳情的reference tree如下圖所示:
從上圖中可以看出,在第1層中的 TBReaderApplication 中的 mComponentCallbacks 成員變量,它是一個array list,它裡面會持有住activity,引導關系是 mComponentCallbacks->AwContents->BaseWebView->BookDetailActivity, 代碼在 Application 類裡面,代碼如下所示:
public void registerComponentCallbacks(ComponentCallbacks callback) { synchronized (mComponentCallbacks) { mComponentCallbacks.add(callback); } } public void unregisterComponentCallbacks(ComponentCallbacks callback) { synchronized (mComponentCallbacks) { mComponentCallbacks.remove(callback); } }
上面兩個方法,會在 Context 基類中被調用,代碼如下:
/** * Add a new {@link ComponentCallbacks} to the base application of the * Context, which will be called at the same times as the ComponentCallbacks * methods of activities and other components are called. Note that you * must be sure to use {@link #unregisterComponentCallbacks} when * appropriate in the future; this will not be removed for you. * * @param callback The interface to call. This can be either a * {@link ComponentCallbacks} or {@link ComponentCallbacks2} interface. */ public void registerComponentCallbacks(ComponentCallbacks callback) { getApplicationContext().registerComponentCallbacks(callback); } /** * Remove a {@link ComponentCallbacks} object that was previously registered * with {@link #registerComponentCallbacks(ComponentCallbacks)}. */ public void unregisterComponentCallbacks(ComponentCallbacks callback) { getApplicationContext().unregisterComponentCallbacks(callback); }
從第二張圖我們已經知道,是webview引起的內存洩漏,而且能看到是在 org.chromium.android_webview.AwContents 類中,難道是這個類注冊了component callbacks,但是未反注冊?一般按系統設計,都會反注冊的,最有可能的原因就是某些情況下導致不能正常反注冊,不多說,read the fucking source。基於這個思路,我把chromium的源碼下載下來,代碼在這裡 chromium_org(https://android.googlesource.com/platform/external/chromium_org/?spm=5176.100239.blogcont61612.7.j9EPtE)
然後找到 org.chromium.android_webview.AwContents 類,看看這兩個方法 onAttachedToWindow 和 onDetachedFromWindow:
@Override public void onAttachedToWindow() { if (isDestroyed()) return; if (mIsAttachedToWindow) { Log.w(TAG, "onAttachedToWindow called when already attached. Ignoring"); return; } mIsAttachedToWindow = true; mContentViewCore.onAttachedToWindow(); nativeOnAttachedToWindow(mNativeAwContents, mContainerView.getWidth(), mContainerView.getHeight()); updateHardwareAcceleratedFeaturesToggle(); if (mComponentCallbacks != null) return; mComponentCallbacks = new AwComponentCallbacks(); mContext.registerComponentCallbacks(mComponentCallbacks); } @Override public void onDetachedFromWindow() { if (isDestroyed()) return; if (!mIsAttachedToWindow) { Log.w(TAG, "onDetachedFromWindow called when already detached. Ignoring"); return; } mIsAttachedToWindow = false; hideAutofillPopup(); nativeOnDetachedFromWindow(mNativeAwContents); mContentViewCore.onDetachedFromWindow(); updateHardwareAcceleratedFeaturesToggle(); if (mComponentCallbacks != null) { mContext.unregisterComponentCallbacks(mComponentCallbacks); mComponentCallbacks = null; } mScrollAccessibilityHelper.removePostedCallbacks(); }
系統會在attach處detach進行注冊和反注冊component callback,注意到 onDetachedFromWindow() 方法的第一行,if (isDestroyed()) return;, 如果 isDestroyed() 返回 true 的話,那麼後續的邏輯就不能正常走到,所以就不會執行unregister的操作,通過看代碼,可以得到,調用主動調用 destroy()方法,會導致 isDestroyed() 返回 true。
/** * Destroys this object and deletes its native counterpart. */ public void destroy() { if (isDestroyed()) return; // If we are attached, we have to call native detach to clean up // hardware resources. if (mIsAttachedToWindow) { nativeOnDetachedFromWindow(mNativeAwContents); } mIsDestroyed = true; new Handler().post(new Runnable() { @Override public void run() { destroyNatives(); } }); }
一般情況下,我們的activity退出的時候,都會主動調用 WebView.destroy() 方法,經過分析,destroy()的執行時間在onDetachedFromWindow之前,所以就會導致不能正常進行unregister()。
解決方案
找到了原因後,解決方案也比較簡單,核心思路就是讓onDetachedFromWindow先走,那麼在主動調用之前destroy(),把webview從它的parent上面移除掉。
ViewParent parent = mWebView.getParent(); if (parent != null) { ((ViewGroup) parent).removeView(mWebView); } mWebView.destroy();
完整的代碼如下:
public void destroy() { if (mWebView != null) { // 如果先調用destroy()方法,則會命中if (isDestroyed()) return;這一行代碼,需要先onDetachedFromWindow(),再 // destory() ViewParent parent = mWebView.getParent(); if (parent != null) { ((ViewGroup) parent).removeView(mWebView); } mWebView.stopLoading(); // 退出時調用此方法,移除綁定的服務,否則某些特定系統會報錯 mWebView.getSettings().setJavaScriptEnabled(false); mWebView.clearHistory(); mWebView.clearView(); mWebView.removeAllViews(); try { mWebView.destroy(); } catch (Throwable ex) { } } }
Android 5.1之前的代碼
對比了5.1之前的代碼,它是不會存在這樣的問題的,以下是kitkat的代碼,它少了一行 if (isDestroyed()) return;,有點不明白,為什麼google在高版本把這一行代碼加上。
/** * @see android.view.View#onDetachedFromWindow() */ public void onDetachedFromWindow() { mIsAttachedToWindow = false; hideAutofillPopup(); if (mNativeAwContents != 0) { nativeOnDetachedFromWindow(mNativeAwContents); } mContentViewCore.onDetachedFromWindow(); if (mComponentCallbacks != null) { mContainerView.getContext().unregisterComponentCallbacks(mComponentCallbacks); mComponentCallbacks = null; } if (mPendingDetachCleanupReferences != null) { for (int i = 0; i < mPendingDetachCleanupReferences.size(); ++i) { mPendingDetachCleanupReferences.get(i).cleanupNow(); } mPendingDetachCleanupReferences = null; } }
結束
在開發過程中,還發現一個支付寶SDK的內存問題,也是因為這個原因,具體的類是 com.alipay.sdk.app.H5PayActivity,我們沒辦法,也想了一個不是辦法的辦法,在每個activity destroy時,去主動把 H5PayActivity 中的webview從它的parent中移除,但這個問題限制太多,不是特別好,但的確也能解決問題,方案如下:
/** * 解決支付寶的 com.alipay.sdk.app.H5PayActivity 類引起的內存洩漏。 * * * 說明: * 這個方法是通過監聽H5PayActivity生命周期,獲得實例後,通過反射將webview拿出來,從 * 它的parent中移除。如果後續支付寶SDK官方修復了該問題,則我們不需要再做什麼了,不管怎麼 * 說,這個方案都是非常惡心的解決方案,非常不推薦。同時,如果更新了支付寶SDK後,那麼內部被混淆 * 的字段名可能更改,所以該方案也無效了。 * * * @param activity */ public static void resolveMemoryLeak(Activity activity) { if (activity == null) { return; } String className = activity.getClass().getCanonicalName(); if (TextUtils.equals(className, "com.alipay.sdk.app.H5PayActivity")) { Object object = Reflect.on(activity).get("a"); if (DEBUG) { LogUtils.e(TAG, "AlipayMemoryLeak.resolveMemoryLeak activity = " + className + ", field = " + object); } if (object instanceof WebView) { WebView webView = (WebView) object; ViewParent parent = webView.getParent(); if (parent instanceof ViewGroup) { ((ViewGroup) parent).removeView(webView); } } } }
以上是對發現的WebView內存洩漏的一個簡單分析,權且記錄一下。
MagicalRecordhttps://github.com/magicalpanda/MagicalRecord注意: MagicalRecord 在 ARC 下運作
Android中的消息處理機制大量依賴於Handler。每個Handler都有對應的Looper,用於不斷地從對應的MessageQueue中取出消息處理。一直以來,覺得
Android RecyclerView 是Android5.0推出來的,導入support-v7包即可使用。個人體驗來說,RecyclerView絕對是一款功能強大的控
public class EngineerJspActivity extends Activity { private static String Tag = &q