Android 進階實現性能優化之OOM與Leakcanary詳解原理
本文主要探討以下幾個問題:
- Android內存泄漏常見場景以及解決方案
- Leakcanary 使用及原理
Android內存泄漏常見場景以及解決方案
資源性對象未關閉
對於資源性對象不再使用時,應該立即調用它的close()函數,將其關閉,然後再置為null。例如Bitmap等資源未關閉會造成內存泄漏,此時我們應該在Activity銷毀時及時關閉。
註冊對象未註銷
例如BraodcastReceiver、EventBus未註銷造成的內存泄漏,我們應該在Activity銷毀時及時註銷。
類的靜態變量持有大數據
對象盡量避免使用靜態變量存儲數據,特別是大數據對象,建議使用數據庫存儲。
單例造成的內存泄漏
優先使用Application的Context,如需使用Activity的Context,可以在傳入Context時使用弱引用進行封裝,然後,在使用到的地方從弱引用中獲取Context,如果獲取不到,則直接return即可。
非靜態內部類的靜態實例
該實例的生命周期和應用一樣長,這就導致該靜態實例一直持有該Activity的引用,Activity的內存資源不能正常回收。此時,我們可以將該內部類設為靜態內部類或將該內部類抽取出來封裝成一個單例,如果需要使用Context,盡量使用Application Context,如果需要使用Activity Context,就記得用完後置空讓GC可以回收,否則還是會內存泄漏。
Handler臨時性內存泄漏
Message發出之後存儲在MessageQueue中,在Message中存在一個target,它是Handler的一個引用,Message在Queue中存在的時間過長,就會導致Handler無法被回收。如果Handler是非靜態的,則會導致Activity或者Service不會被回收。並且消息隊列是在一個Looper線程中不斷地輪詢處理消息,當這個Activity退出時,消息隊列中還有未處理的消息或者正在處理的消息,並且消息隊列中的Message持有Handler實例的引用,Handler又持有Activity的引用,所以導致該Activity的內存資源無法及時回收,引發內存泄漏。解決方案如下所示:
1. 使用一個靜態Handler內部類,然後對Handler持有的對象(一般是Activity)使用弱引用,這樣在回收時,也可以回收Handler持有的對象。
2. 在Activity的Destroy或者Stop時,應該移除消息隊列中的消息,避免Looper線程的消息隊列中有待處理的消息需要處理。需要註意的是,AsyncTask內部也是Handler機制,同樣存在內存泄漏風險,但其一般是臨時性的。對於類似AsyncTask或是線程造成的內存泄漏,我們也可以將AsyncTask和Runnable類獨立出來或者使用靜態內部類。
容器中的對象沒清理造成的內存泄漏
在退出程序之前,將集合裡的東西clear,然後置為null,再退出程序
WebView
WebView都存在內存泄漏的問題,在應用中隻要使用一次WebView,內存就不會被釋放掉。我們可以為WebView開啟一個獨立的進程,使用AIDL與應用的主進程進行通信,WebView所在的進程可以根據業務的需要選擇合適的時機進行銷毀,達到正常釋放內存的目的。
使用ListView時造成的內存泄漏
在構造Adapter時,使用緩存的convertView。
Leakcanary
leakcanary 導入
// leakcanary 添加支持庫即可,隻在debug下使用 debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.3'
leakcanary 是如何安裝的
leakcanary 不需要初始化,用的是 ContentProvider!
ContentProvider.onCreate 方法比 Application.onCreate 更早執行。LeakCanary 源碼的 Manifest.xml 裡有聲明ContentProvider,apk打包流程中會把所有的Manifest合並到app 的 Manifest 裡,即APP就有瞭ContentProvider。
// package="com.squareup.leakcanary.leaksentry" <application> <provider android:name="leakcanary.internal.LeakSentryInstaller" android:authorities="${applicationId}.leak-sentry-installer" android:exported="false"/> </application>
下面是初始化的代碼
internal class LeakSentryInstaller : ContentProvider() { override fun onCreate(): Boolean { CanaryLog.logger = DefaultCanaryLog() val application = context!!.applicationContext as Application // 進行初始化工作,核心 InternalLeakSentry.install(application) return true }
監聽實現
fun install(application: Application) { CanaryLog.d("Installing LeakSentry") // 隻能在主線程調用,否則會拋出異常 checkMainThread() if (this::application.isInitialized) { return } InternalLeakSentry.application = application val configProvider = { LeakSentry.config } // 監聽 Activity.onDestroy() ActivityDestroyWatcher.install( application, refWatcher, configProvider ) // 監聽 Fragment.onDestroy() FragmentDestroyWatcher.install( application, refWatcher, configProvider ) // Sentry 哨兵 listener.onLeakSentryInstalled(application) }
leakcanary 如何監聽Activity、Fragment銷毀
在瞭解監聽過程前有必要瞭解下 ActivityLifecycleCallbacks 與 FragmentLifeCycleCallbacks
// ActivityLifecycleCallbacks 接口 public interface ActivityLifecycleCallbacks { void onActivityCreated(Activity var1, Bundle var2); void onActivityStarted(Activity var1); void onActivityResumed(Activity var1); void onActivityPaused(Activity var1); void onActivityStopped(Activity var1); void onActivitySaveInstanceState(Activity var1, Bundle var2); void onActivityDestroyed(Activity var1); } // FragmentLifecycleCallbacks 接口 public abstract static class FragmentLifecycleCallbacks { public void onFragmentCreated(FragmentManager fm, Fragment f, Bundle savedInstanceState) {} public void onFragmentViewDestroyed(FragmentManager fm, Fragment f) {} public void onFragmentDestroyed(FragmentManager fm, Fragment f) {} // 省略其他的生命周期 ... }
Application 類提供瞭 registerActivityLifecycleCallbacks 和 unregisterActivityLifecycleCallbacks 方法用於註冊和反註冊 Activity 的生命周期監聽類,這樣我們就能在 Application 中對所有的 Activity 生命周期回調中做一些統一處理。同理,FragmentManager 類提供瞭 registerFragmentLifecycleCallbacks 和 unregisterFragmentLifecycleCallbacks 方法用戶註冊和反註冊 Fragment 的生命周期監聽類,這樣我們對每一個 Activity 進行註冊,就能獲取所有的 Fragment 生命周期回調。
下面是 ActivityDestroyWatcher 的實現,refWatcher 監聽 activity 的 onActivityDestroyed
internal class ActivityDestroyWatcher private constructor( private val refWatcher: RefWatcher, private val configProvider: () -> Config ) { private val lifecycleCallbacks = object : ActivityLifecycleCallbacksAdapter() { override fun onActivityDestroyed(activity: Activity) { if (configProvider().watchActivities) { // 監聽到 onDestroy() 之後,通過 refWatcher 監測 Activity refWatcher.watch(activity) } } } companion object { fun install( application: Application, refWatcher: RefWatcher, configProvider: () -> Config ) { val activityDestroyWatcher = ActivityDestroyWatcher(refWatcher, configProvider) // 註冊 Activity 生命周期監聽 application.registerActivityLifecycleCallbacks(activityDestroyWatcher.lifecycleCallbacks) } } }
如此一來Activity、Fragment在調用onDestroy時我們都能知道。講道理,如果在調用onDestroy時被GC是正常的,如果沒有被回收則是發生瞭內存泄漏,這是我們要處理的。那 refWatcher.watch(activity) 監聽到銷毀後怎麼處理?
RefWatcher 核心原理
在讀這塊代碼前舉個栗子比較好理解:比如我們去科技中心面試
- 進去的時候會登記個人信息在觀察列表,並標明停留時間30分鐘
- 30分鐘過後查看是否有登出
- 如果未登出將信息由觀察列表轉移至懷疑列表
- 懷疑列表名單超過5個時,找公安人員確定是否是恐怖分子
- 確定是恐怖分子,警察抓人
RefWatcher 的實現原理跟上面的栗子神似:
- Activity調用onDestroy後,以UUID生成key,被KeyedWeakReference包裝,並與ReferenceQueue關聯,並把<key,KeyedWeakReference>存入 watchedReferences 中(watchedReferences 對應觀察隊列)
- 等待5s時間
- 調用 moveToRetained 方法,先判斷是否已經釋放,如果未釋放由 watchedReferences (觀察隊列) 轉入 retainedReferences(懷疑隊列)
- 當 retainedReferences 隊列的長度大於5時,先調用一次GC,用HAHA這個開源庫去分析dump之後的heap內存
- 確定內存泄漏對象
咱們先看下 refWatcher.watch(activity) 的實現
@Synchronized fun watch( watchedReference: Any, referenceName: String ) { if (!isEnabled()) { return } // 移除隊列中將要被 GC 的引用 removeWeaklyReachableReferences() val key = UUID.randomUUID().toString() val watchUptimeMillis = clock.uptimeMillis() // 構建當前引用的弱引用對象,並關聯引用隊列 queue val reference = KeyedWeakReference(watchedReference, key, referenceName, watchUptimeMillis, queue) if (referenceName != "") { CanaryLog.d( "Watching instance of %s named %s with key %s", reference.className, referenceName, key ) } else { CanaryLog.d( "Watching instance of %s with key %s", reference.className, key ) } // 將引用存入 watchedReferences watchedReferences[key] = reference checkRetainedExecutor.execute { // 如果當前引用未被移除,仍在 watchedReferences 隊列中, // 說明仍未被 GC,移入 retainedReferences 隊列中,暫時標記為泄露 moveToRetained(key) } }
分析上面這段代碼都做瞭什麼:
- 移除隊列中將要被 GC 的引用,這裡的隊列包括 watchedReferences 和 retainedReferences
- 使用UUID生成唯一key,構建 WeakReference 包裝 activity 並與 ReferenceQueue 關聯
- 將 reference 放入觀察隊列 watchedReferences 中
- 線程池調用 moveToRetained 函數,此函數先走一遍gc,依舊沒回收的對象會進入 retainedReferences 懷疑隊列,當隊列大於5時調用HAHA庫走可達性分析確定是否是內存泄漏
下面是細節分析 —》removeWeaklyReachableReferences() 邏輯
private fun removeWeaklyReachableReferences() { // WeakReferences are enqueued as soon as the object to which they point to becomes weakly // reachable. This is before finalization or garbage collection has actually happened. // 弱引用一旦變得弱可達,就會立即入隊。這將在 finalization 或者 GC 之前發生。 var ref: KeyedWeakReference? do { // 隊列 queue 中的對象都是會被 GC 的 ref = queue.poll() as KeyedWeakReference? //說明被釋放瞭 if (ref != null) { val removedRef = watchedReferences.remove(ref.key)//獲取被釋放的引用的key if (removedRef == null) { retainedReferences.remove(ref.key) } // 移除 watchedReferences 隊列中的會被 GC 的 ref 對象,剩下的就是可能泄露的對象 } } while (ref != null) }
removeWeaklyReachableReferences 函數會根據 ReferenceQueue 出來的 KeyedWeakReference 的 key 移除 watchedReferences(觀察隊列)和 retainedReferences(懷疑隊列)中的引用,即把已經釋放的移出,剩下的是內存泄漏的
moveToRetained(key) 邏輯實現
@Synchronized private fun moveToRetained(key: String) { // 再次調用,防止遺漏 removeWeaklyReachableReferences() val retainedRef = watchedReferences.remove(key) //說明可能存在內存泄漏 if (retainedRef != null) { retainedReferences[key] = retainedRef onReferenceRetained() } }
此函數的作用:
- 走一遍 removeWeaklyReachableReferences 方法,將已經回收的清除
- 將 watchedReferences(觀察隊列)中未被回收的引用移到 retainedReferences(懷疑隊列)中
- onReferenceRetained() 則是在工作線程中檢測內存泄漏,最後會調用 checkRetainedInstances 函數
下面是 checkRetainedInstances 的具體實現
private fun checkRetainedInstances(reason: String) { CanaryLog.d("Checking retained instances because %s", reason) val config = configProvider() // A tick will be rescheduled when this is turned back on. if (!config.dumpHeap) { return } var retainedKeys = refWatcher.retainedKeys // 當前泄露實例個數小於 5 個,不進行 heap dump if (checkRetainedCount(retainedKeys, config.retainedVisibleThreshold)) return if (!config.dumpHeapWhenDebugging && DebuggerControl.isDebuggerAttached) { showRetainedCountWithDebuggerAttached(retainedKeys.size) scheduleRetainedInstanceCheck("debugger was attached", WAIT_FOR_DEBUG_MILLIS) CanaryLog.d( "Not checking for leaks while the debugger is attached, will retry in %d ms", WAIT_FOR_DEBUG_MILLIS ) return } // 可能存在被觀察的引用將要變得弱可達,但是還未入隊引用隊列。 // 這時候應該主動調用一次 GC,可能可以避免一次 heap dump gcTrigger.runGc() retainedKeys = refWatcher.retainedKeys if (checkRetainedCount(retainedKeys, config.retainedVisibleThreshold)) return HeapDumpMemoryStore.setRetainedKeysForHeapDump(retainedKeys) CanaryLog.d("Found %d retained references, dumping the heap", retainedKeys.size) HeapDumpMemoryStore.heapDumpUptimeMillis = SystemClock.uptimeMillis() dismissNotification() val heapDumpFile = heapDumper.dumpHeap() // AndroidHeapDumper if (heapDumpFile == null) { CanaryLog.d("Failed to dump heap, will retry in %d ms", WAIT_AFTER_DUMP_FAILED_MILLIS) scheduleRetainedInstanceCheck("failed to dump heap", WAIT_AFTER_DUMP_FAILED_MILLIS) showRetainedCountWithHeapDumpFailed(retainedKeys.size) return } refWatcher.removeRetainedKeys(retainedKeys) // 移除已經 heap dump 的 retainedKeys HeapAnalyzerService.runAnalysis(application, heapDumpFile) // 分析 heap dump 文件 }
流程圖
到此這篇關於Android 進階實現性能優化之OOM與Leakcanary詳解原理的文章就介紹到這瞭,更多相關Android 性能優化內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!
推薦閱讀:
- Android中的LeakCanary的原理詳解
- 淺談Android性能優化之內存優化
- Java中的內存泄露問題和解決辦法
- 源碼淺析Android中內存泄漏檢測工具Leakcanary的使用
- Android LeakCanary的使用方法介紹