內存泄漏，這個名詞很常見，那什么是內存泄漏呢？通俗易懂的來說 就是對象已經不需要被使用了，但是還沒有被釋放。
專業一點來說下安卓的泄漏，生命周期較長的對象持有生命周期較短的對象的引用。內存不在GC掌控之內了。當一個對象已經不需要再使用了，本該被回收時，而有另外一個正在使用的對象持有它的引用從而就導致，對象不能被回收。這種導致了本該被回收的對象不能被回收而停留在堆內存中，就產生了內存泄漏。
下面我們將從一個handler例子 來分析內存泄漏。
這是一個在Activity 中 handler發送一個延遲2s的消息，緊接著finish()界面，來模擬界面崩潰。看到這里，請大家閉上眼睛來思考一下，這個會不會造成內存泄漏？
好睜開眼，繼續往下看，上面當做一個遺留問題 來思考。
先解釋一下 最后一行 這個finish（），這里也是模擬界面崩潰的一個操作。解決內存泄漏 就是需要在程序正常運行和非正常運行時，保證內存的穩定，防止內存泄漏。
直入主題，下面帶大家來看為啥會造成泄漏。
這是在追尋源碼時，里面的一個死循環+一個鎖。這兩個東西 其實會帶出很多的面試點 比如死循環為什么不會造成anr等。加鎖之后 ，延遲發送的消息是否還準確等。這個如果大家感興趣 以后我會再寫一個專題 來詳細翻源碼來看具體原因。咱們繼續：
咱們直入主題，handler.sendxx： MessageQueue.enqueueMessage()消息入隊列
Thread -> Looper.loop()：MessageQueue.next()? -> handler.dispatchMessage()消息出隊列,從上面的源碼中 我們看到了 有一句msg.target==null的判斷。 這個target是啥呢？在學習的時候 大家可以思考下，下面給大家看一下源碼。
沒想到盡然是一個handler。那么現在內存泄漏就很明顯 了。handler 是message 的成員變量。當我們使用handler的時候 handler里面未處理完的消息 還持有handler的引用。相信初級安卓開發的人員 都知道怎么去解決這個問題，調用他的移除消息方法，這是處理方式，如果別人問道原因和原理會一臉懵逼，或者會答handler持有外部類的引用，其實只是答對了一部分 或者也可以說根本沒有答。最后來一筆畫龍點睛的總結，為什么造成泄漏。Message 持有handler的引用，handler持有當前界面的引用，如果當前界面銷毀 ，消息沒有處理完 就造成了泄漏。
順便帶大家來了解一下總結LeakCanary的原理
leacCanary添加依賴不需要初始化，根據源碼可知道會先走到contprovider 的onCreate（）方法，完成自動初始化。
1、LeakCanary只能檢測Activity已經與Activity相關聯的對象，通過注冊生命周期。
2、它的實現是通過：
監聽Activity的生命周期，在onDestroy時，去分析這個要銷毀的Activity以及與的相關的對象是否存在內存泄漏
采用了弱引用和弱引用Queue的特性進行判斷引用對象即Activity是否已經被回收，具體原理是: KeyedWeakReference繼承了WeakReference，它也是弱引用的實現類，一般我們創建弱引用對象時都是只傳與之關聯的對象，這里還傳遞使用了一個WeakReferenceQueue，這個用來干嘛的？這個queue它的作用是用來存放已經被回收的弱引用對象，如果queue中有這個弱引用就代表這個弱引用所關聯的對象已經被回收；而如果queue中沒有這個弱引用對象則代表這個弱引用所關聯的對象還沒被回收，是存在內存泄漏的可能性。
如果GC之后引用對象還存活，那么通過Debug的dumpHprofData方法調用nativie方法讓虛擬機去抓取堆內存快照（File heapDumpFile = heapDumper.dumpHeap();），根據堆內存快照文件的格式hprof協議、GC ROOT、GC引用鏈的原理進行解析、分析堆內存快照，heapdumpListener.analyze（。。。） 開啟HeapAnalyzerService.class 服務，得到分析結果信息類，sendResultToListener，最后將這個分析結果發送給監聽者，讓結果監聽者處理這個分析結果。將分析結果通過通知欄的方式顯示出來，如果存在內存泄漏則當點擊通知欄時會打開DispalyLeakActivity將內存泄漏的信息展示處理
面試核心流程。以上所有內容如有錯誤 歡迎大家指出。共同交流。
