Android中的LeakCanary的原理詳解

Posted on by

場景：最新的leakCanary2.8.1：

debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.8.1'

原理：首先就是我們在引入最新的依賴包，什麼都不用幹瞭，因為他的初始化在清單文件中註冊瞭contentProvider（），把初始化放到瞭這裡面的onCreate（）去初始化瞭，在初始化的過程中，他會用application監聽觀察對象activity、fragment等對象的生命周期的變化，當執行銷毀的生命周期，他就會用對應ActivityWatch—>ObjectWatch來觀察你這個銷毀的對象，那怎麼觀察呢？將對象加入到弱引用對象，並把這個弱引用和一個引用隊列Queue來綁定（同時把這個弱引用先添加到一個map的觀察列表），這樣的話當主動Gc的時候，如果沒有泄露，就會回收這個activity觀察對象，並會把這個弱引用加入到引用隊列中去，我們就可以去判斷這個引用隊列有沒有值，有就代表沒泄露，否則為queue.poll()取出來為null就泄露瞭，最後會把這個泄露對象的弱引用添加到一個set集合，叫做retained objects，最終會使用shark庫（原來是haha分析庫）去查詢泄露的地方生成Dump文件，把分析結果發通知給開發者。

通知點擊：告知retained objects—點擊–>Dumping Heap—自動–>Analyzing heap

如何看這個分析的結果：

 上面兩個圖就是這個泄露對象的引用鏈關系，最後就是存在泄露的對象LoginActivity，那為什麼泄露就得往上去尋找，發現是在Dialog單例中持有瞭context（即LoginActivity對象），及時走瞭destory也不會銷毀這個對象，因為被GcRoot一直持有。

 這是引起內存泄漏的代碼：

object LoadingDialog {
 
 
    //內部生成的時候，根據INSTANCE 看起來感覺是靜態，因為可以LoadingDialog.show()
    //其實是偽靜態
    fun show() {
 
    }
 
    //這種寫法才是靜態方法
    @JvmStatic
    fun show2() {
 
    }
 
    private var dialog:Dialog?=null
 
    fun show(context: Context) {
 
        cancel()
        dialog = Dialog(context)
        dialog?.setContentView(R.layout.dialog_loading)
        dialog?.setCancelable(false)
        dialog?.setCanceledOnTouchOutside(false)
        dialog?.show()
 
    }
 
    fun cancel() {
        dialog?.dismiss()
    }
 
}

解決就是，把dialog用完要置為null

fun cancel() {
        dialog?.dismiss()
        dialog = null;
    }

這樣leakCanary就不會通知泄露點瞭。

到此這篇關於Android中的LeakCanary的原理詳解的文章就介紹到這瞭,更多相關Android LeakCanary內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：