面試官問我：如何使用LeakCanary排查Android中的內存泄露，看我如何用漫畫裝逼！

1）在項目的build.gradle文件添加：

debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'
    releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
    testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
複製代碼

能夠看到，debugCompile跟releaseCompile 引入的是不一樣的包，在 debug 版本上，集成 LeakCanary 庫，並執行內存泄漏監測，而在 release 版本上，集成一個無操做的 wrapper ，這樣對程序性能就不會有影響。java

2）在Application類添加：android

public class LCApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        if (LeakCanary.isInAnalyzerProcess(this)) {
            // This process is dedicated to LeakCanary for heap analysis.
            // You should not init your app in this process.
            return;
        }
        LeakCanary.install(this);
        // Normal app init code...
    }
}
複製代碼

LeakCanary.install() 會返回一個預約義的 RefWatcher，同時也會啓用一個 ActivityRefWatcher，用於自動監控調用 Activity.onDestroy() 以後泄露的 activity。程序員

若是是簡單的檢測activity是否存在內存泄漏，上面兩個步驟就能夠了，是否是很簡單。那麼當某個activity存在內存泄漏的時候，會有什麼提示呢？LeakCanary會自動展現一個通知欄，點開提示框你會看到引發內存溢出的引用堆棧信息。面試

具體使用代碼

1）Application 相關代碼：bash

public class LCApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        if (LeakCanary.isInAnalyzerProcess(this)) {
            // This process is dedicated to LeakCanary for heap analysis.
            // You should not init your app in this process.
            return;
        }
        LeakCanary.install(this);
        // Normal app init code...
    }

}
複製代碼

2）泄漏的activity類代碼：微信

public class MainActivity extends Activity {

    private Button next;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        next = (Button) findViewById(R.id.next);
        next.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Intent intent = new Intent(MainActivity.this, SecondActivity.class);
                startActivity(intent);
                finish();
            }
        });
        new Thread(new Runnable() {
            @Override
            public void run() {
                while (true) {
                    System.out.println("=================");
                }
            }
        }).start();
    }
}
複製代碼

當點擊next跳到第二個界面後，LeakCanary會自動展現一個通知欄，點開提示框你會看到引發內存溢出的引用堆棧信息，如上圖所示，這樣你就很容易定位到原來是線程引用住當前activity，致使activity沒法釋放。 markdown

上面提到，LeakCanary.install() 會返回一個預約義的 RefWatcher，同時也會啓用一個 ActivityRefWatcher，用於自動監控調用 Activity.onDestroy() 以後泄露的 activity。如今不少app都使用到了fragment，那fragment如何檢測呢。

1）Application 中獲取到refWatcher對象。app

public class LCApplication extends Application {

    public static RefWatcher refWatcher;

    @Override
    public void onCreate() {
        super.onCreate();
        if (LeakCanary.isInAnalyzerProcess(this)) {
            // This process is dedicated to LeakCanary for heap analysis.
            // You should not init your app in this process.
            return;
        }
        refWatcher  = LeakCanary.install(this);
        // Normal app init code...
    }
}
複製代碼

2）使用 RefWatcher 監控 Fragment：dom

public abstract class BaseFragment extends Fragment {
  @Override public void onDestroy() {
    super.onDestroy();
    RefWatcher refWatcher = LCApplication.refWatcher;
    refWatcher.watch(this);
  }
}
複製代碼

這樣則像監聽activity同樣監聽fragment。其實這種方式同樣適用於任何對象，好比圖片，自定義類等等，很是方便。ide

LeakCanary.install(this)源碼以下所示：

public static RefWatcher install(Application application) {
        return ((AndroidRefWatcherBuilder)refWatcher(application).listenerServiceClass(DisplayLeakService.class).excludedRefs(AndroidExcludedRefs.createAppDefaults().build())).buildAndInstall();
    }
複製代碼

listenerServiceClass(DisplayLeakService.class)：用於分析內存泄漏結果信息，而後發送通知給用戶。 excludedRefs(AndroidExcludedRefs.createAppDefaults().build())：設置須要忽略的對象，好比某些系統漏洞不須要統計。 buildAndInstall()：真正檢測內存泄漏的方法，下面將展開分析該方法。

public RefWatcher buildAndInstall() {
        RefWatcher refWatcher = this.build();
        if(refWatcher != RefWatcher.DISABLED) {
            LeakCanary.enableDisplayLeakActivity(this.context);
            ActivityRefWatcher.installOnIcsPlus((Application)this.context, refWatcher);
        }

        return refWatcher;
    }
複製代碼

能夠看到，上面方法主要作了三件事情： 1.實例化RefWatcher對象，該對象主要做用是檢測是否有對象未被回收致使內存泄漏； 2.設置APP圖標可見； 3.檢測內存

RefWatcher的使用後面講，這邊主要看第二件事情的處理過程，及enableDisplayLeakActivity方法的源碼

public static void enableDisplayLeakActivity(Context context) {
        LeakCanaryInternals.setEnabled(context, DisplayLeakActivity.class, true);
    }
複製代碼

public static void setEnabled(Context context, final Class<?> componentClass, final boolean enabled) {
        final Context appContext = context.getApplicationContext();
        executeOnFileIoThread(new Runnable() {
            public void run() {
                LeakCanaryInternals.setEnabledBlocking(appContext, componentClass, enabled);
            }
        });
    }
複製代碼

public static void setEnabledBlocking(Context appContext, Class<?> componentClass, boolean enabled) {
        ComponentName component = new ComponentName(appContext, componentClass);
        PackageManager packageManager = appContext.getPackageManager();
        int newState = enabled?1:2;
        packageManager.setComponentEnabledSetting(component, newState, 1);
    }
複製代碼

可見，最後調用packageManager.setComponentEnabledSetting（）方法，實現應用圖標的隱藏和顯示。

接下來，進入真正的內存檢查的方法installOnIcsPlus（）

public static void installOnIcsPlus(Application application, RefWatcher refWatcher) {
        if(VERSION.SDK_INT >= 14) {
            ActivityRefWatcher activityRefWatcher = new ActivityRefWatcher(application, refWatcher);
            activityRefWatcher.watchActivities();
        }
    }
複製代碼

該方法實例化出ActivityRefWatcher 對象，該對象用來監聽activity的生命週期，具體實現以下所示：

public void watchActivities() {
        this.stopWatchingActivities();
        this.application.registerActivityLifecycleCallbacks(this.lifecycleCallbacks);
    }
複製代碼

private final ActivityLifecycleCallbacks lifecycleCallbacks = new ActivityLifecycleCallbacks() {
        public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
        }

        public void onActivityStarted(Activity activity) {
        }

        public void onActivityResumed(Activity activity) {
        }

        public void onActivityPaused(Activity activity) {
        }

        public void onActivityStopped(Activity activity) {
        }

        public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
        }

        public void onActivityDestroyed(Activity activity) {
            ActivityRefWatcher.this.onActivityDestroyed(activity);
        }
    };
複製代碼

調用了registerActivityLifecycleCallbacks方法後，當Activity執行onDestroy方法後，會觸發ActivityLifecycleCallbacks 的onActivityDestroyed方法，在當前方法中，調用refWatcher的watch方法，前面已經講過RefWatcher對象主要做用是檢測是否有對象未被回收致使內存泄漏。下面繼續看refWatcher的watch方法源碼：

public void watch(Object watchedReference) {
        this.watch(watchedReference, "");
    }

    public void watch(Object watchedReference, String referenceName) {
        if(this != DISABLED) {
            Preconditions.checkNotNull(watchedReference, "watchedReference");
            Preconditions.checkNotNull(referenceName, "referenceName");
            long watchStartNanoTime = System.nanoTime();
            String key = UUID.randomUUID().toString();
            this.retainedKeys.add(key);
            KeyedWeakReference reference = new KeyedWeakReference(watchedReference, key, referenceName, this.queue);
            this.ensureGoneAsync(watchStartNanoTime, reference);
        }
    }
複製代碼

能夠看到，上面方法主要作了三件事情： 1.生成一個隨機數key存放在retainedKeys集合中，用來判斷對象是否被回收； 2.把當前Activity放到KeyedWeakReference（WeakReference的子類）中； 3.經過查找ReferenceQueue，看該Acitivity是否存在，存在則證實能夠被正常回收，不存在則證實可能存在內存泄漏。前兩件事很簡單，這邊主要看第三件事情的處理過程，及ensureGoneAsync方法的源碼：

private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) {
        this.watchExecutor.execute(new Retryable() {
            public Result run() {
                return RefWatcher.this.ensureGone(reference, watchStartNanoTime);
            }
        });
    }
    
  Result ensureGone(KeyedWeakReference reference, long watchStartNanoTime) {
        long gcStartNanoTime = System.nanoTime();
        long watchDurationMs = TimeUnit.NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);
        this.removeWeaklyReachableReferences();
        if(this.debuggerControl.isDebuggerAttached()) {
            return Result.RETRY;
        } else if(this.gone(reference)) {
            return Result.DONE;
        } else {
            this.gcTrigger.runGc();
            this.removeWeaklyReachableReferences();
            if(!this.gone(reference)) {
                long startDumpHeap = System.nanoTime();
                long gcDurationMs = TimeUnit.NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);
                File heapDumpFile = this.heapDumper.dumpHeap();
                if(heapDumpFile == HeapDumper.RETRY_LATER) {
                    return Result.RETRY;
                }

                long heapDumpDurationMs = TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);
                this.heapdumpListener.analyze(new HeapDump(heapDumpFile, reference.key, reference.name, this.excludedRefs, watchDurationMs, gcDurationMs, heapDumpDurationMs));
            }

            return Result.DONE;
        }
    }
複製代碼

該方法中首先執行removeWeaklyReachableReferences()，從ReferenceQueue隊列中查詢是否存在該弱引用對象，若是不爲空，則說明已經被系統回收了，則將對應的隨機數key從retainedKeys集合中刪除。

private void removeWeaklyReachableReferences() {
        KeyedWeakReference ref;
        while((ref = (KeyedWeakReference)this.queue.poll()) != null) {
            this.retainedKeys.remove(ref.key);
        }
    }
複製代碼

而後經過判斷retainedKeys集合中是否存在對應的key判斷該對象是否被回收。

private boolean gone(KeyedWeakReference reference) {
        return !this.retainedKeys.contains(reference.key);
    }
複製代碼

若是沒有被系統回收，則手動調用gcTrigger.runGc();後再調用removeWeaklyReachableReferences方法判斷該對象是否被回收。

GcTrigger DEFAULT = new GcTrigger() {
        public void runGc() {
            Runtime.getRuntime().gc();
            this.enqueueReferences();
            System.runFinalization();
        }

        private void enqueueReferences() {
            try {
                Thread.sleep(100L);
            } catch (InterruptedException var2) {
                throw new AssertionError();
            }
        }
    };
複製代碼

第三行代碼爲手動觸發GC，緊接着線程睡100毫秒，給系統回收的時間，隨後經過System.runFinalization()手動調用已經失去引用對象的finalize方法。經過手動GC該對象還不能被回收的話，則存在內存泄漏，調用heapDumper.dumpHeap()生成.hprof文件目錄，並經過heapdumpListener回調到analyze()方法，後面關於dump文件的分析這邊就不介紹了，感興趣的能夠自行去看。

微信搜索【程序員小安】「面試系列（java&andriod）」文章將在公衆號同步發佈。