關於內存泄漏有很多中問題引起，比如：
- Context引用（常見的就是單例模式的套用），通過context來獲取系統服務；
- 圖片bitmap的處理；
- Handler的Runnable回調；
- 強引用；
- 在一個Activity內啓動了一個線程但在該Activity退出時卻沒有即時關閉該線程等；
內存泄漏最終會導致我們常說的OOM；
一般解決辦法如下：
- 對於Context一般會使用applicationContext代替，同時我們編碼過程儘量做到與context解耦；
- 圖片屬於大內存的處理的問題，需要手動進行釋放，使用完畢後注意對其recycle。
- 一般我們需要在當前時間下間隔一段時間去操作某個事情時，我們可以直接用Handler定時，比定時器會簡單點，但在完成操作要即使移除綁定的Runnable；
- 對於強引用，要注意對其的釋放，可以改成SoftwareReference或WeakReference下建議改成這兩種方式；
- 對於這種情況我們可以使用異步任務或者IntentService代替，我們編碼儘量少出現這種new Thread{}.start;的代碼，因爲啓動一個線程是要花費系統較多的資源的，建議採用線程池代替（注意線程池的容量問題）；
分析完以上這幾種情況，那麼問題來了，我們要如何來找一個app是否有內存泄漏的問題呢？總不能老是要等到app崩潰後再來分析吧，可以用Android Studio的Montior觀察，啓動一個Activiy然後退出該Activity，觀察這個過程內存的變化過程感性判斷，也可以用使用AS內存檢測工具獲得內存報告，前後比對，eclipse的DDMS中的heap工具這裏就不贅述了；
在感性判斷後，怎樣排查問題這個纔是關鍵點，對於這種情況網上有好多工具如MAT定位內存泄漏位置，這裏建議使用leakcanry，它會在app發生內存泄漏時將泄漏的棧顯示出來，這樣有利於我們大致定位然後深入排查。
工具的工具下載地址：https://download.csdn.net/download/u012724841/10500112
需要的資源下載地址：https://download.csdn.net/download/u012724841/10500139
使用詳見第一個鏈接的readme.txt；
該工具在檢查內存發現有泄漏問題時會有一個toast提示，同時可打開桌面的Leaks查看發生泄漏的棧。