自己在Android開發中也會時常遇到OOM的問題，但是在此之前，我對他的處理沒有臺看重，因為我還是個新手，沒有開發過完整的APP項目，今天記錄自己在網上看到的大牛整理出來對Android和java的內存泄露處理方法，也是希望自己在以后的開發道路上能夠很好避免此類問題。

現在處理OOM常用的工具便是 LeakCanary。

先介紹一下LeakCanary在Android Studio中的使用方法：

1）在 build.gradle 中加入一下依賴：分為debug和release兩個引用方式

dependencies {   debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'   releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3' }2）使用RefWatcher監控那些本該被回收的對象，具體使用如下：
1.在application中，
public class ExampleApplication extends Application {  public static RefWatcher getRefWatcher(Context context) {    ExampleApplication application = (ExampleApplication) context.getApplicationContext();    return application.refWatcher;  }  PRivate RefWatcher refWatcher;  @Override   public void onCreate() {    super.onCreate();    refWatcher = LeakCanary.install(this);  }}
其中LeakCanary.install() 會返回一個預定義的 RefWatcher，同時也會啟用一個 ActivityRefWatcher，用于自動監控調用 Activity.onDestroy() 之后泄露的 activity。
2.監控Activity或者Fragment
public abstract class BaseFragment（Activity） extends Fragment( Activity）{  @Override public void onDestroy() {    super.onDestroy();    RefWatcher refWatcher = ExampleApplication.getRefWatcher(getActivity());    refWatcher.watch(this);  }}
工作機制：
RefWatcher.watch() 創建一個 KeyedWeakReference 到要被監控的對象。
然后在后臺線程檢查引用是否被清除，如果沒有，調用GC。
如果引用還是未被清除，把 heap 內存 dump 到 APP 對應的文件系統中的一個 .hprof 文件中。
在另外一個進程中的 HeapAnalyzerService 有一個 HeapAnalyzer 使用HAHA 解析這個文件。
得益于唯一的 reference key, HeapAnalyzer 找到 KeyedWeakReference，定位內存泄露。
HeapAnalyzer 計算 到 GC roots 的最短強引用路徑，并確定是否是泄露。如果是的話，建立導致泄露的引用鏈。
引用鏈傳遞到 APP 進程中的 DisplayLeakService， 并以通知的形式展示出來。
鏈接：
這里是我學習的網址：https://www.liaohuqiu.net/cn/posts/leak-canary-read-me/，如果需要了解更多可以去看一下！
一個非常簡單的 LeakCanary demo: https://github.com/liaohuqiu/leakcanary-demo