問題1 內存泄漏的基本定義是什么？內存泄漏有什么危害？
問題2 開發中常見的內存泄漏的情況有哪些？什么原因造成的？怎么解決
問題3 如何發現內存泄漏？LeakCanary的核心原理是什么？

什么是內存泄漏

當某個對象已經完成了它的使命退出，但是GC無法正常的回收內存空間，這種情況叫做內存泄漏。GC將GC Root和與GC Root（生命周期很長）相連的對象對標記為不可回收，那么如果某個對象完成了使命但是依然能和GC Root相連那么它必然造成內存泄漏，另外即便對象A不是GC Root如果它持有對象B且A生命周期比B要長也還是會造成內存泄漏，所以內存泄漏其實就是生命周期長的對象持有生命周期短的對象，導致后者在前者回收前無法被GC回收。

內存泄漏的例子

1 Handler造成的內存泄漏

一般Handler會被定義成匿名內部類，內部類會持有外部類的強引用。如果將Handler寫在Activity中Handler就會持有Activity的引用，根據Handler機制我們可以打出如下引用鏈：Activity->Handler->Message->MessageQueue->Looper->ThreadLocal->Thread，而Thread是GC Root。如果MessageQueue中還有Message對象那么必然會造成Activity退出時候內存泄漏

解決方案：將Handler定義成靜態內部類這樣Handler不會持有Activity的強引用，然后Handler使用若引用持有Activity方便回調，當activity退出觸發GC由于若引用特性activity能正常回收

2 Toast造成內存泄漏

如果Toast傳的Context是Activity那么當Activity退出時候會造成內存泄漏。

解決方案：使用Application

3 集合造成的內存泄漏
類似HashMap、HashSet不要修改參與計算過的key的hash，如果修改了會導致get、remove等操作沒法獲取這個值，它會一直存在map中導致內存泄漏，如果是static的那就跟嚴重了

解決方案：一般人也不會這么傻

4 單例造成的內存泄漏

一些不好的單例模式可能會造成內存泄漏，例如必須要使用Context創建的對象。由于單例模式的唯一的一個變量一般都是static的，所以靜態變量持有Context，如果這個Context是Activity的話就會造成內存泄漏。引用鏈：Context-> static，static的變量是GC Root

解決方案：一般不建議這么寫，如果非要傳Context可以使用Application最好，如果不行就使用若引用

5 WebView造成的內存泄漏

WebView內部一些線程會持有Activity，導致Activity無法釋放。引用鏈是 Activity-> Thread

解決方案：將WebView放到一個單獨的進程中，即可解決問題

6 線程造成內存泄漏

有時候我們為了方便在Activity內部用內部類的形式定義一個線程，因為內部類會持有外部類的引用，那么當線程的任務沒有做完的時候退出Activity必然會造成內存泄漏。引用鏈是Activity-> Thread而Thread是GC Root

解決方案：使用其他的方法代替直接使用現場的方式，如使用RxJava、AsyncTask等等。或者和Handler處理方法類似使用WeakReference來持有Activity

LeakCanary的核心原理

LeakCanary的核心原理，大致上可以分為三步：
1 LeakCanary監聽Activity的生命周期的最后一個onDestory
2 將Activity封裝到KeyedWeakReference，這是繼承WeakReference的所以是弱引用，它和ReferenceQueue結合起來一起使用。當GC能正常回收Activity就把持有Activity的弱引用放到引用隊列里面，這樣后面只需要檢查引用隊列里面是否有該Activity的弱引用就能判斷是否內存泄漏。如果有就表示Activity被正常回收，如果沒有就表示有可能內存泄漏，值得注意的是這時候LeakCanary還會幫我們主動GC一次，然后再次判斷發現Activity還是沒有被回收則開始拿heapDump文件開始分析
3 將heapDumpFile打包成HeapDump對象，然后調用analyze方法開始分析，ServiceHeapDumpListener是對應的實現。真正的分析交給HeapAnalyzerService這個服務去做的
4 通過HeapAnalyzerService發送前臺通知
詳情具體看后面文章《LeakCanary原理分析》