場景：最新的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就不會通知泄露點了。