場(chǎng)景：最新的leakCanary2.8.1：

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

原理：首先就是我們?cè)谝胱钚碌囊蕾嚢?，什么都不用干了，因?yàn)樗某跏蓟谇鍐挝募凶?cè)了contentProvider（），把初始化放到了這里面的onCreate（）去初始化了，在初始化的過(guò)程中，他會(huì)用application監(jiān)聽(tīng)觀察對(duì)象activity、fragment等對(duì)象的生命周期的變化，當(dāng)執(zhí)行銷毀的生命周期，他就會(huì)用對(duì)應(yīng)ActivityWatch--->ObjectWatch來(lái)觀察你這個(gè)銷毀的對(duì)象，那怎么觀察呢？將對(duì)象加入到弱引用對(duì)象，并把這個(gè)弱引用和一個(gè)引用隊(duì)列Queue來(lái)綁定（同時(shí)把這個(gè)弱引用先添加到一個(gè)map的觀察列表），這樣的話當(dāng)主動(dòng)Gc的時(shí)候，如果沒(méi)有泄露，就會(huì)回收這個(gè)activity觀察對(duì)象，并會(huì)把這個(gè)弱引用加入到引用隊(duì)列中去，我們就可以去判斷這個(gè)引用隊(duì)列有沒(méi)有值，有就代表沒(méi)泄露，否則為queue.poll()取出來(lái)為null就泄露了，最后會(huì)把這個(gè)泄露對(duì)象的弱引用添加到一個(gè)set集合，叫做retained objects，最終會(huì)使用shark庫(kù)（原來(lái)是haha分析庫(kù)）去查詢泄露的地方生成Dump文件，把分析結(jié)果發(fā)通知給開(kāi)發(fā)者。

通知點(diǎn)擊：告知retained objects---點(diǎn)擊-->Dumping Heap---自動(dòng)-->Analyzing heap

如何看這個(gè)分析的結(jié)果：

 上面兩個(gè)圖就是這個(gè)泄露對(duì)象的引用鏈關(guān)系，最后就是存在泄露的對(duì)象LoginActivity，那為什么泄露就得往上去尋找，發(fā)現(xiàn)是在Dialog單例中持有了context（即LoginActivity對(duì)象），及時(shí)走了destory也不會(huì)銷毀這個(gè)對(duì)象，因?yàn)楸籊cRoot一直持有。

 這是引起內(nèi)存泄漏的代碼：

object LoadingDialog {
 
 
    //內(nèi)部生成的時(shí)候，根據(jù)INSTANCE 看起來(lái)感覺(jué)是靜態(tài)，因?yàn)榭梢訪oadingDialog.show()
    //其實(shí)是偽靜態(tài)
    fun show() {
 
    }
 
    //這種寫(xiě)法才是靜態(tài)方法
    @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就不會(huì)通知泄露點(diǎn)了。

到此這篇關(guān)于Android中的LeakCanary的原理詳解的文章就介紹到這了,更多相關(guān)Android LeakCanary內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論