詳解LeakCanary分析內(nèi)存泄露如何實現(xiàn)
前言
平時我們都有用到LeakCanary來分析內(nèi)存泄露的情況，這里可以來看看LeakCanary是如何實現(xiàn)的，它的內(nèi)部又有哪些比較有意思的操作。
LeakCanary的使用
官方文檔：square.github.io/leakcanary/…
引用方式
dependencies {
// debugImplementation because LeakCanary should only run in debug builds.
debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.10'
}
可以看到LeakCanary的新版本中依賴非常簡單，甚至不需要你做什么就可以直接使用。
LeakCanary原理
LeakCanary的封裝主要是利用ContentProvider，LeakCanary檢測內(nèi)存泄漏主要是監(jiān)聽Activity和Fragment、view的生命周期，配合弱引用和ReferenceQueue。
源碼淺析
初始化
首先debugImplementation只是在Debug的包會依賴，在正式包不會把LeakCanary的內(nèi)容打進(jìn)包中。
LeakCanary的初始化是使用了ContentProvider，ContentProvider的onCreate會在Application的onCreate之前，它把ContentProvider寫在自己的AndroidMainifest中，打包時會進(jìn)行合并，所以這整個過程都不需要接入端做初始化操作。
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.squareup.leakcanary.objectwatcher" >
<uses-sdk android:minSdkVersion="14" />
<application>
<provider
android:name="leakcanary.internal.MainProcessAppWatcherInstaller"
android:authorities="${applicationId}.leakcanary-installer"
android:enabled="@bool/leak_canary_watcher_auto_install"
android:exported="false" />
</application>
</manifest>
這是它在AndroidManifest所定義的，打包的時候會合并所有的AndroidManifest
這就是它自動初始化的操作，也比較明顯了，不用過多解釋。
使用
先看看它要監(jiān)測什么，因為LeakCanary 2.x的代碼都是kotlin寫的，所以這里得分析kotlin，如果不熟悉kt的朋友，我只能說盡量講慢一些，因為我想看舊版本的能不能用java來分析，但是簡單看了下源碼上是有一定的差別，所以還是要分析2.x。
fun appDefaultWatchers(
application: Application,
reachabilityWatcher: ReachabilityWatcher = objectWatcher
): List<InstallableWatcher> {
return listOf(
ActivityWatcher(application, reachabilityWatcher),
FragmentAndViewModelWatcher(application, reachabilityWatcher),
RootViewWatcher(reachabilityWatcher),
ServiceWatcher(reachabilityWatcher)
)
}
從這里看到他主要分析Activity、Fragment和Fragment的View、RootView、Service。
看Activity的監(jiān)聽ActivityWatcher
監(jiān)聽Activity調(diào)用Destroy時會調(diào)用reachabilityWatcher的expectWeaklyReachable方法。
這里可以看看舊版本的做法（正好以前有記錄）
private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
new ActivityLifecycleCallbacksAdapter() {
@Override public void onActivityDestroyed(Activity activity) {
refWatcher.watch(activity);
}
};
舊版本是調(diào)用refWatcher的watch，雖然代碼不同，但是思想一樣，再看看舊版本的Fragment
private final FragmentManager.FragmentLifecycleCallbacks fragmentLifecycleCallbacks =
new FragmentManager.FragmentLifecycleCallbacks() {
@Override public void onFragmentViewDestroyed(FragmentManager fm, Fragment fragment) {
View view = fragment.getView();
if (view != null) {
refWatcher.watch(view);
}
}
@Override
public void onFragmentDestroyed(FragmentManager fm, Fragment fragment) {
refWatcher.watch(fragment);
}
};
這里監(jiān)聽了Fragment和Fragment的View，所以相比于新版本，舊版本只監(jiān)聽Activity、Fragment和Fragment的View
再回到新版本，分析完Activity的監(jiān)聽之后看看Fragment的
最終Destroy之后也是調(diào)用到reachabilityWatcher的expectWeaklyReachable。然后看看RootViewWatcher的操作
private val listener = OnRootViewAddedListener { rootView ->
val trackDetached = when(rootView.windowType) {
PHONE_WINDOW -> {
when (rootView.phoneWindow?.callback?.wrappedCallback) {
is Activity -> false
is Dialog -> {
......
}
else -> true
}
}
POPUP_WINDOW -> false
TOOLTIP, TOAST, UNKNOWN -> true
}
if (trackDetached) {
rootView.addOnAttachStateChangeListener(object : OnAttachStateChangeListener {
val watchDetachedView = Runnable {
reachabilityWatcher.expectWeaklyReachable(
rootView, "${rootView::class.java.name} received View#onDetachedFromWindow() callback"
)
}
......
})
}
}
最終也是調(diào)用到reachabilityWatcher的expectWeaklyReachabl。最后再看看Service的。
這邊因為只是做淺析，不是源碼詳細(xì)分析，所以我這邊就不去一個個分析是如何調(diào)用到銷毀的這個方法的，我們通過上面的方法得到一個結(jié)論，Activity、Fragment和Fragment的View、RootView、Service，他們幾個，在銷毀時都會調(diào)用到reachabilityWatcher的expectWeaklyReachabl。所以這些地方就是檢測對象是否泄漏的入口。
然后我們來看看expectWeaklyReachable方法
@Synchronized override fun expectWeaklyReachable(
watchedObject: Any,
description: String
) {
// 先從queue中移除一次已回收對象
removeWeaklyReachableObjects()
// 生成隨機(jī)數(shù)當(dāng)成key
val key = UUID.randomUUID().toString()
val watchUptimeMillis = clock.uptimeMillis()
// 創(chuàng)建弱引用關(guān)聯(lián)ReferenceQueue
val reference =
KeyedWeakReference(watchedObject, key, description, watchUptimeMillis, queue)
......
// 把reference和key 添加到一個Map中
watchedObjects[key] = reference
// 下一步
checkRetainedExecutor.execute {
moveToRetained(key)
}
}
你們運氣真好，我正好以前也有記錄舊版本的refWatcher的watch方法
public void watch(Object watchedReference, String referenceName) {
......
// 生成隨機(jī)數(shù)當(dāng)成key
String key = UUID.randomUUID().toString();
// 把key 添加到一個Set中
this.retainedKeys.add(key);
// 創(chuàng)建弱引用關(guān)聯(lián)ReferenceQueue
KeyedWeakReference reference = new KeyedWeakReference(watchedReference, key, referenceName, this.queue);
// 下一步
this.ensureGoneAsync(watchStartNanoTime, reference);
}
通過對比發(fā)現(xiàn)，模板的流程是一樣的，但是細(xì)節(jié)不一樣，以前是用Set，現(xiàn)在是用Map，這就是我覺得不能拿舊版本代碼來分析的原因。
文章寫到這里，突然想到一個很有意思的東西，你要是面試時，面試官看過新版本的代碼，你看的是舊版本的代碼，結(jié)果如果問到一些比較深入的細(xì)節(jié)，你答出來的和他所理解的不同，那就尷尬了，所以面試時得先說清楚你是看過舊版本的代碼
看到用一個弱引用生成一個key和對象綁定起來。然后調(diào)用ensureGoneAsync方法
private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) {
this.watchExecutor.execute(new Retryable() {
public Result run() {
return RefWatcher.this.ensureGone(reference, watchStartNanoTime);
}
});
}
execute里面會調(diào)用到waitForIdle方法。
我們再回到新版本的代碼中
checkRetainedExecutor.execute其實是會執(zhí)行到這里（kt里面的是寫得簡單，但是不熟的話可以先別管怎么執(zhí)行的，只要先知道反正執(zhí)行到這個地方就行）
這里是做了一個延時發(fā)送消息的操作，延時5秒，具體代碼在這里
寫到這里我感覺有點慌了，因為如果不熟kt的朋友可能真會看困，其實如果看不懂這個代碼的話沒關(guān)系，只要我圈出來的地方，我覺是大概能看懂的，然后流程我會說，我的意思是沒必要深入去看每一行是什么意思，我們的目的是找出大概的流程（用游戲的說法，我們是走主線任務(wù)，不是要全收集）
延遲5秒后會調(diào)回到前面的moveToRetained(key)。那不好意思各位，我又要拿舊版本來對比了，因為細(xì)節(jié)不同。
private void waitForIdle(final Retryable retryable, final int failedAttempts) {
// 使用IdleHandler來實現(xiàn)在閑時才去執(zhí)行后面的流程
Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
@Override public boolean queueIdle() {
postToBackgroundWithDelay(retryable, failedAttempts);
return false;
}
});
}
使用IdleHandler來完成閑時觸發(fā)，我不記得很早之前的版本是不是也用的IdleHandler，這里使用IdleHandler只能說有好有壞吧，好處是閑時觸發(fā)確實是一個很好的操作，不好的地方是如果一直有異步消息，就一直不會觸發(fā)后面的流程。
private void postToBackgroundWithDelay(final Retryable retryable, final int failedAttempts) {
long exponentialBackoffFactor = (long) Math.min(Math.pow(2, failedAttempts), maxBackoffFactor);
long delayMillis = initialDelayMillis * exponentialBackoffFactor;
// 根據(jù)上下文去計算，這里是5秒
backgroundHandler.postDelayed(new Runnable() {
@Override public void run() {
Retryable.Result result = retryable.run();
if (result == RETRY) {
postWaitForIdle(retryable, failedAttempts + 1);
}
}
}, delayMillis);
}
看到舊版本是先用IdelHanlder，在閑時觸發(fā)的情況下再去延時5秒，而新版本是直接延時5秒，不使用IdelHandler，我沒看過這塊具體的文檔描述，我猜是為了防止餓死，如果用IdelHanlder的話可能會出現(xiàn)一直不觸發(fā)的情況。
返回看新版本的moveToRetained
@Synchronized private fun moveToRetained(key: String) {
// 從ReferenceQueue中拿出對象移除
removeWeaklyReachableObjects()
// 經(jīng)過上一步之后判斷Map中還有沒有這個key，有的話進(jìn)入下一步操作
val retainedRef = watchedObjects[key]
if (retainedRef != null) {
retainedRef.retainedUptimeMillis = clock.uptimeMillis()
onObjectRetainedListeners.forEach { it.onObjectRetained() }
}
}
private fun removeWeaklyReachableObjects() {
// 從ReferenceQueue中拿出對象，然后從Map中移除
var ref: KeyedWeakReference?
do {
ref = queue.poll() as KeyedWeakReference?
if (ref != null) {
watchedObjects.remove(ref.key)
}
} while (ref != null)
}
moveToRetained主要是從ReferenceQueue中找出弱引用對象，然后移除Map中相應(yīng)的弱引用對象。弱引用+ReferenceQueue的使用，應(yīng)該不用多說吧，如果弱引用持有的對象被回收，弱引用會添加到ReferenceQueue中。所以watchedObjects代表的是應(yīng)該將要被回收的對象，queue表示已經(jīng)被回收的對象，這步操作就是從queue中找出已經(jīng)回收的對象，然后從watchedObjects移除相應(yīng)的對象，剩下的的就是應(yīng)該被回收卻沒被回收的對象。如果對象被正?；厥?，那這整個流程就走完了，如果沒被回收，會執(zhí)行到onObjectRetained()，之后就是Dump操作了，之后的就是內(nèi)存分析、彈出通知那堆操作了，去分析內(nèi)存的泄漏這些，因為內(nèi)容比較多，這篇先大概就先到這里。
總結(jié)
淺析，就是只做了簡單分析LeakCanary的整個工作過程和工作原理。
原理就是用弱引用和ReferenceQueue去判斷應(yīng)該被回收的對象是否已經(jīng)被回收。大致的工作流程是：監(jiān)聽Activity、Fragment和Fragment的View、RootView、Service對象的銷毀，然后將這些對象放入“應(yīng)該被回收”的容器中，然后5秒后通過弱引用和ReferenceQueue去判斷對象是否已被回收，如果被回收則從容器中刪除對應(yīng)的對象，否則進(jìn)行內(nèi)存分析。
至于是如何判斷不同對象的銷毀和如何分析內(nèi)存情況找出泄漏的引用鏈，這其中也是細(xì)節(jié)滿滿，但是我個人LeakCanary應(yīng)該是看過兩三次源碼了，從一開始手動初始化，到舊版本java的實現(xiàn)方式，到現(xiàn)在用kt去實現(xiàn)，能發(fā)現(xiàn)它的核心思想其實是一樣的，只不過在不斷的優(yōu)化一些細(xì)節(jié)和不斷的擴(kuò)展可以監(jiān)測的對象。
以上就是詳解LeakCanary分析內(nèi)存泄露如何實現(xiàn)的詳細(xì)內(nèi)容，更多關(guān)于LeakCanary分析內(nèi)存泄露的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
本文主要介紹了Android開發(fā)消息通知欄的相關(guān)知識。具有很好的參考價值。下面跟著小編一起來看下吧2017-04-04
Android開發(fā)使用自定義view實現(xiàn)ListView下拉的視差特效功能
這篇文章主要介紹了Android開發(fā)使用自定義view實現(xiàn)ListView下拉的視差特效功能,結(jié)合實例形式詳細(xì)分析了Android重寫ListView控件實現(xiàn)ListView下拉視差效果的步驟與相關(guān)操作技巧,需要的朋友可以參考下2017-10-10
Android?Flutter中Offstage組件的使用教程詳解
這篇文章主要為大家詳細(xì)介紹了Android?Flutter中Offstage組件的使用教程，文中的示例代碼講解詳細(xì)，對我們了解Flutter有一定的幫助，需要的可以參考一下2023-02-02
本篇文章主要介紹了android中okhttp實現(xiàn)斷點上傳示例，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2017-02-02
RatingBar為評分條控件，默認(rèn)效果為若干個綠色的星星，如果想將其換成其他自定義圖片就要自定義它的style。接下來通過本文給大家介紹Android控件之RatingBar自定義星級評分樣式，感興趣的朋友一起學(xué)習(xí)吧2016-02-02
本文主要介紹Android ListView萬能適配器,這里整理了詳細(xì)的資料及實現(xiàn)代碼，以及實現(xiàn)效果圖,有需要的小伙伴可以參考下2016-09-09
這篇文章主要介紹了Android Hilt的使用以及遇到的問題，幫助大家更好的理解和學(xué)習(xí)使用Android開發(fā)，感興趣的朋友可以了解下2021-04-04
android實現(xiàn)圖片驗證碼方法解析(自繪控件)
本文主要介紹了android自繪控件的應(yīng)用--實現(xiàn)圖片驗證碼方法案例，具有一定的參考價值，下面跟著小編一起來看下吧2017-01-01
Android開發(fā)實現(xiàn)的幾何圖形工具類GeometryUtil完整實例
這篇文章主要介紹了Android開發(fā)實現(xiàn)的幾何圖形工具類GeometryUtil,涉及Android坐標(biāo)圖形數(shù)值運算相關(guān)操作技巧,需要的朋友可以參考下2017-11-11
Android實現(xiàn)EditText換行自動縮進(jìn)功能
在很多需要輸入多行文本的應(yīng)用（如記事本、編程代碼編輯器、博客編輯器等）中,自動縮進(jìn)功能能大大提升用戶的編輯效率與體驗,本文給大家介紹了Android實現(xiàn)EditText換行自動縮進(jìn)功能,下面提供整合后的完整代碼示例,需要的朋友可以參考下2025-04-04