問(wèn)題1 內(nèi)存泄漏的基本定義是什么缎脾？?jī)?nèi)存泄漏有什么危害深滚？
問(wèn)題2 開(kāi)發(fā)中常見(jiàn)的內(nèi)存泄漏的情況有哪些拔鹰？什么原因造成的仪缸？怎么解決
問(wèn)題3 如何發(fā)現(xiàn)內(nèi)存泄漏？LeakCanary的核心原理是什么列肢？
什么是內(nèi)存泄漏
當(dāng)某個(gè)對(duì)象已經(jīng)完成了它的使命退出恰画，但是GC無(wú)法正常的回收內(nèi)存空間宾茂，這種情況叫做內(nèi)存泄漏。GC將GC Root和與GC Root（生命周期很長(zhǎng)）相連的對(duì)象對(duì)標(biāo)記為不可回收拴还，那么如果某個(gè)對(duì)象完成了使命但是依然能和GC Root相連那么它必然造成內(nèi)存泄漏跨晴，另外即便對(duì)象A不是GC Root如果它持有對(duì)象B且A生命周期比B要長(zhǎng)也還是會(huì)造成內(nèi)存泄漏，所以內(nèi)存泄漏其實(shí)就是生命周期長(zhǎng)的對(duì)象持有生命周期短的對(duì)象片林，導(dǎo)致后者在前者回收前無(wú)法被GC回收端盆。
內(nèi)存泄漏的例子
1 Handler造成的內(nèi)存泄漏
一般Handler會(huì)被定義成匿名內(nèi)部類，內(nèi)部類會(huì)持有外部類的強(qiáng)引用拇厢。如果將Handler寫(xiě)在Activity中Handler就會(huì)持有Activity的引用爱谁，根據(jù)Handler機(jī)制我們可以打出如下引用鏈：Activity->Handler->Message->MessageQueue->Looper->ThreadLocal->Thread，而Thread是GC Root孝偎。如果MessageQueue中還有Message對(duì)象那么必然會(huì)造成Activity退出時(shí)候內(nèi)存泄漏
解決方案：將Handler定義成靜態(tài)內(nèi)部類這樣Handler不會(huì)持有Activity的強(qiáng)引用访敌，然后Handler使用若引用持有Activity方便回調(diào)，當(dāng)activity退出觸發(fā)GC由于若引用特性activity能正骋露埽回收
2 Toast造成內(nèi)存泄漏
如果Toast傳的Context是Activity那么當(dāng)Activity退出時(shí)候會(huì)造成內(nèi)存泄漏寺旺。
解決方案：使用Application
3 集合造成的內(nèi)存泄漏
類似HashMap、HashSet不要修改參與計(jì)算過(guò)的key的hash势决，如果修改了會(huì)導(dǎo)致get阻塑、remove等操作沒(méi)法獲取這個(gè)值，它會(huì)一直存在map中導(dǎo)致內(nèi)存泄漏果复，如果是static的那就跟嚴(yán)重了
解決方案：一般人也不會(huì)這么傻
4 單例造成的內(nèi)存泄漏
一些不好的單例模式可能會(huì)造成內(nèi)存泄漏陈莽，例如必須要使用Context創(chuàng)建的對(duì)象。由于單例模式的唯一的一個(gè)變量一般都是static的虽抄，所以靜態(tài)變量持有Context走搁，如果這個(gè)Context是Activity的話就會(huì)造成內(nèi)存泄漏。引用鏈：Context-> static迈窟，static的變量是GC Root
解決方案：一般不建議這么寫(xiě)私植，如果非要傳Context可以使用Application最好，如果不行就使用若引用
5 WebView造成的內(nèi)存泄漏
WebView內(nèi)部一些線程會(huì)持有Activity车酣，導(dǎo)致Activity無(wú)法釋放曲稼。引用鏈?zhǔn)?Activity-> Thread
解決方案：將WebView放到一個(gè)單獨(dú)的進(jìn)程中，即可解決問(wèn)題
6 線程造成內(nèi)存泄漏
有時(shí)候我們?yōu)榱朔奖阍贏ctivity內(nèi)部用內(nèi)部類的形式定義一個(gè)線程湖员，因?yàn)閮?nèi)部類會(huì)持有外部類的引用贫悄，那么當(dāng)線程的任務(wù)沒(méi)有做完的時(shí)候退出Activity必然會(huì)造成內(nèi)存泄漏。引用鏈?zhǔn)茿ctivity-> Thread而Thread是GC Root
解決方案：使用其他的方法代替直接使用現(xiàn)場(chǎng)的方式娘摔，如使用RxJava清女、AsyncTask等等∥福或者和Handler處理方法類似使用WeakReference來(lái)持有Activity
LeakCanary的核心原理
LeakCanary的核心原理嫡丙，大致上可以分為三步：
1 LeakCanary監(jiān)聽(tīng)Activity的生命周期的最后一個(gè)onDestory
2 將Activity封裝到KeyedWeakReference，這是繼承WeakReference的所以是弱引用读第，它和ReferenceQueue結(jié)合起來(lái)一起使用曙博。當(dāng)GC能正常回收Activity就把持有Activity的弱引用放到引用隊(duì)列里面怜瞒，這樣后面只需要檢查引用隊(duì)列里面是否有該Activity的弱引用就能判斷是否內(nèi)存泄漏父泳。如果有就表示Activity被正常回收吴汪，如果沒(méi)有就表示有可能內(nèi)存泄漏惠窄，值得注意的是這時(shí)候LeakCanary還會(huì)幫我們主動(dòng)GC一次，然后再次判斷發(fā)現(xiàn)Activity還是沒(méi)有被回收則開(kāi)始拿heapDump文件開(kāi)始分析
3 將heapDumpFile打包成HeapDump對(duì)象漾橙，然后調(diào)用analyze方法開(kāi)始分析杆融，ServiceHeapDumpListener是對(duì)應(yīng)的實(shí)現(xiàn)。真正的分析交給HeapAnalyzerService這個(gè)服務(wù)去做的
4 通過(guò)HeapAnalyzerService發(fā)送前臺(tái)通知
詳情具體看后面文章《LeakCanary原理分析》
