問題1 內(nèi)存泄漏的基本定義是什么？內(nèi)存泄漏有什么危害？
問題2 開發(fā)中常見的內(nèi)存泄漏的情況有哪些？什么原因造成的？怎么解決
問題3 如何發(fā)現(xiàn)內(nèi)存泄漏？LeakCanary的核心原理是什么？
什么是內(nèi)存泄漏
當某個對象已經(jīng)完成了它的使命退出，但是GC無法正常的回收內(nèi)存空間，這種情況叫做內(nèi)存泄漏。GC將GC Root和與GC Root（生命周期很長）相連的對象對標記為不可回收，那么如果某個對象完成了使命但是依然能和GC Root相連那么它必然造成內(nèi)存泄漏，另外即便對象A不是GC Root如果它持有對象B且A生命周期比B要長也還是會造成內(nèi)存泄漏，所以內(nèi)存泄漏其實就是生命周期長的對象持有生命周期短的對象，導致后者在前者回收前無法被GC回收。
內(nèi)存泄漏的例子
1 Handler造成的內(nèi)存泄漏
一般Handler會被定義成匿名內(nèi)部類，內(nèi)部類會持有外部類的強引用。如果將Handler寫在Activity中Handler就會持有Activity的引用，根據(jù)Handler機制我們可以打出如下引用鏈：Activity->Handler->Message->MessageQueue->Looper->ThreadLocal->Thread，而Thread是GC Root。如果MessageQueue中還有Message對象那么必然會造成Activity退出時候內(nèi)存泄漏
解決方案：將Handler定義成靜態(tài)內(nèi)部類這樣Handler不會持有Activity的強引用，然后Handler使用若引用持有Activity方便回調，當activity退出觸發(fā)GC由于若引用特性activity能正?；厥?/p>
2 Toast造成內(nèi)存泄漏
如果Toast傳的Context是Activity那么當Activity退出時候會造成內(nèi)存泄漏。
解決方案：使用Application
3 集合造成的內(nèi)存泄漏
類似HashMap、HashSet不要修改參與計算過的key的hash，如果修改了會導致get、remove等操作沒法獲取這個值，它會一直存在map中導致內(nèi)存泄漏，如果是static的那就跟嚴重了
解決方案：一般人也不會這么傻
4 單例造成的內(nèi)存泄漏
一些不好的單例模式可能會造成內(nèi)存泄漏，例如必須要使用Context創(chuàng)建的對象。由于單例模式的唯一的一個變量一般都是static的，所以靜態(tài)變量持有Context，如果這個Context是Activity的話就會造成內(nèi)存泄漏。引用鏈：Context-> static，static的變量是GC Root
解決方案：一般不建議這么寫，如果非要傳Context可以使用Application最好，如果不行就使用若引用
5 WebView造成的內(nèi)存泄漏
WebView內(nèi)部一些線程會持有Activity，導致Activity無法釋放。引用鏈是 Activity-> Thread
解決方案：將WebView放到一個單獨的進程中，即可解決問題
6 線程造成內(nèi)存泄漏
有時候我們?yōu)榱朔奖阍贏ctivity內(nèi)部用內(nèi)部類的形式定義一個線程，因為內(nèi)部類會持有外部類的引用，那么當線程的任務沒有做完的時候退出Activity必然會造成內(nèi)存泄漏。引用鏈是Activity-> Thread而Thread是GC Root
解決方案：使用其他的方法代替直接使用現(xiàn)場的方式，如使用RxJava、AsyncTask等等?；蛘吆虷andler處理方法類似使用WeakReference來持有Activity
LeakCanary的核心原理
LeakCanary的核心原理，大致上可以分為三步：
1 LeakCanary監(jiān)聽Activity的生命周期的最后一個onDestory
2 將Activity封裝到KeyedWeakReference，這是繼承WeakReference的所以是弱引用，它和ReferenceQueue結合起來一起使用。當GC能正常回收Activity就把持有Activity的弱引用放到引用隊列里面，這樣后面只需要檢查引用隊列里面是否有該Activity的弱引用就能判斷是否內(nèi)存泄漏。如果有就表示Activity被正常回收，如果沒有就表示有可能內(nèi)存泄漏，值得注意的是這時候LeakCanary還會幫我們主動GC一次，然后再次判斷發(fā)現(xiàn)Activity還是沒有被回收則開始拿heapDump文件開始分析
3 將heapDumpFile打包成HeapDump對象，然后調用analyze方法開始分析，ServiceHeapDumpListener是對應的實現(xiàn)。真正的分析交給HeapAnalyzerService這個服務去做的
4 通過HeapAnalyzerService發(fā)送前臺通知
詳情具體看后面文章《LeakCanary原理分析》
