見到這個標題有經驗的開發者可能要吐槽我是標題黨了，特別是從Eclipse時代走過來的開發者，以為我一要開始貼那張像**一樣的MAT記憶體模型圖或者AndroidStudio中Monitors下的實時記憶體佔用圖，又要開始分析那一條條剪不斷理還亂的記憶體引用鏈，然後費盡九牛二虎之力去查詢專案中無數的記憶體洩漏中的一個。但是，我要告訴你，你錯了。其實，以前我看到記憶體洩漏分析文章的時候也是這樣的想法，看著恐怖的MAT記憶體模型圖，覺得記憶體洩漏的排查和解決簡直是Android開發中登峰造極的技能。直到我遇到了她——LeakCanary，我才直到原來記憶體洩漏的排查和解決可以那麼的優雅。LeakCanary

 dependencies {
   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'
 

 }

在Application中的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);

整合後什麼都不用做，按照正常測試，當有記憶體洩漏發生後，應用會通過系統通知欄發出通知，點選通知就可以進入檢視記憶體洩漏的具體資訊。在這裡舉個實踐中的例子。把LeakCanary整合到專案中後，等App啟動後一會，系統通知到了，點選通知，跳轉到洩漏的詳情頁面進行檢視：

很明顯，WebSiteQueryActivity洩露了。首先，static 的MaskHeadView.fLayout變數引用了FrameLayout.mContext物件，這個物件的引用就是指向了WebSiteQueryActivity的例項，導致了它的洩漏，在第二節中我們說過static物件是內部的static物件是比較容易造成記憶體洩漏的，檢查程式碼發現，MaskHeadView直接在WebSiteQueryActivity的xml檔案中使用了，因此持有WebSiteQueryActivity的例項，因為fLayout物件是靜態的，因此它的生命週期與Application同樣長，因此WebSiteQueryActivity退出後，它的例項引用依然被fLayout持有，導致它無法被回收從而記憶體洩露了。仔細檢查程式碼，發現fLayout並沒有被外部使用到，應該是之前的開發者手抖加了個static欄位上去或者是現在不用了，但是沒有去掉，在這裡我直接去掉了這個修飾符，在此build程式碼，這個記憶體洩漏的現象消失了。

//去掉static修飾符，避免static物件引起的記憶體洩漏
private static FrameLayout fLayout;


public MaskHeadView(Context context, AttributeSet attrs) {
super(context, attrs);
   this.context=context;
   initView(context);
}

private void initView(Context context2) {
view = LayoutInflater.from(context).inflate(R.layout.
mask_head_view, this);
   fLayout=(FrameLayout) view.findViewById(R.id.
mask_container);
}