背景
在Android開發過程中，我們經常碰到的情況就是在我們不清楚為什么情況下，程序突然出現Crash了。其中有一類日志相信大家都經常碰到過，這類日志就是OOM相關的日志。這類日志除了我們知道的Bitmap操作的時候會經常導致，還有一種隱藏的較深的原因就是內存泄露（Memory Leak）。
內存泄露產生原因和影響：
- 原因：當一個Object不再需要的時候，本該被GC回收時，但是因為另一個正在使用的Object持有它導致不能正常的被回收，本該被回收的對象不能回收，還存留在堆內存中，此時就產生了內存泄露。
- 影響：Android系統能夠為每個應用程序分配的內存是有限的，當一個應用程序中產生的內存泄露過多的時候，會難免導致應用程序需要的內存超過限額而導致內存溢出使得應用程序崩潰。
內存泄露的檢測方式
推薦使用 LeakCanary 工具來檢測應用程序是否存在內存泄露。LeakCanary是由 Square 開源的一款輕量級的第三方內存泄漏檢測工具，當檢測到程序中產生內存泄漏時，它將以最直觀的方式告訴我們哪里產生了內存泄漏和導致誰泄漏了而不能被回收。
如何避免內存泄露
1、合理使用單例模式。
單例的靜態特性使得其生命周期和應用的生命周期一樣長。
如圖，我們先聲明一個單例對象：
然后在Activity使用的時候，習慣性的傳一個this：
集成了LeakCanary后測試，發現內存泄露了：
解決方案：
一般情況下，改成如下圖的寫法就可以了，因為單例的生命周期和應用的一樣長，這樣就防止了內存泄漏。：
總結：單例模式造成泄漏的原因是擁有更長生命周期的對象持有短生命周期對象的強引用。
2、使用資源時注意資源的關閉
一般情況下，容易產生內存泄露的資源主要為：File，Cursor，Stream，Bitmap，BroadcastReceiver等，這些資源在使用時建議及時關閉，否則當這些資源沒有及時回收的時候，內存泄露也就產生了。針對這些資源使用，給如下建議：
- BroadcastReceiver 在register之后，需要在適當的時機unregister
- Cursor、Stream、File 這類資源類型的對象往往會使用一些Cache，所以我們在不使用的時候，應該及時關閉，以便Cache被及時回收。如果我們僅僅把它的引用設置為null，而不去關閉他們，往往會造成內存泄露。一般建議是先close()后置為null。
- Bitmap在不使用的時候，調用recycle()方法。目前 Android 2.3版本以后，不需要我們手動去這樣做的，這里也就是簡單的交代一下。
3、 合理使用Handler避免內存泄露
在我們使用Handler的時候，經常看到編輯器提示我們Handler可能會造成內存泄露，一般在這種情況下，我們可以將Handler獨立出來或者使用靜態內部類，這樣可以避免內存泄露。
這樣做的原因是：非靜態內部類會潛在的持有它所屬的外部類的引用，但是靜態內部類是不會的。
4、 合理的使用WeakReference來引用外部類的成員變量
我們可以使用WeakReference來規避好多潛在的內存泄露的問題，但是並不表明WeakReference就是解決內存泄露的金鑰匙。是否使用WeakReference主要取決於對當前對問題的理解，這需要我們對問題的的建模思想。