如果所有的物件都可以被順利回收就沒有本文的誕生了，舉個簡單的例子，我們在開發中經常使用單例模式，單例的靜態特性導致其生命週期同應用一樣長。有時建立單例時如果我們需要Context物件，如果傳入的是Application的Context那麼不會有問題。如果傳入的是Activity的Context物件，那麼當Activity生命週期結束時，該Activity的引用依然被單例持有，所以不會被回收，而單例的生命週期又是跟應用一樣長，這個情況就叫做記憶體洩露(Memory Leak)。它指的是當你不再需要某個例項後，但是這個物件卻仍然被引用，防止被垃圾回收(Prevent from being bargage collected)。

public class Util {
private Context mContext;
    private static Util sInstance;    private Util(Context context) {
this.mContext = context;
}
public static Util getInstance(Context context) {
if (sInstance == null) {
sInstance = new Util(context);
}
return sInstance;
}
}

圖示一程式碼

基於Android系統的裝置一般來說記憶體就不大，特別是早期的Android裝置，記憶體洩漏是很致命的，記憶體洩漏積攢到一定程度會引發記憶體溢位（OOM），如果處理不當直接導致程式崩潰退出。

二.常見記憶體洩漏

一般來說在開發中我們經常會犯下下面幾個錯誤，導致記憶體洩漏。這幾個都是前人踩坑總結出來的，非常有參考價值，至少我在排查解決記憶體洩漏的時候是這樣的。

1.單例造成的記憶體洩漏

Android的單例模式非常受開發者的喜愛，不過使用的不恰當的話也會造成記憶體洩漏。因為單例的靜態特性使得單例的生命週期和應用的生命週期一樣長，這就說明了如果一個物件已經不需要使用了，而單例物件還持有該物件的引用，那麼這個物件將不能被正常回收，這就導致了記憶體洩漏。見圖示一程式碼。

2.非靜態內部類建立靜態例項造成的記憶體洩漏

有的時候我們可能會在啟動頻繁的Activity中，為了避免重複建立相同的資料資源，在Activity內部建立了一個非靜態內部類的單例，每次啟動Activity時都會使用該單例的資料，這樣雖然避免了資源的重複建立，不過這種寫法卻會造成記憶體洩漏，因為非靜態內部類預設會持有外部類的引用，而又使用了該非靜態內部類建立了一個靜態的例項，該例項的生命週期和應用的一樣長，這就導致了該靜態例項一直會持有該Activity的引用，導致Activity的記憶體資源不能正常回收。例子如下：

public class MainActivity extends AppCompatActivity {

private static TestResource mResource = null;

    @Override

    protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_main);

        if (mManager == null) {

            mManager = new TestResource();

        }

//...

    }

class TestResource {

//...

    }

}

圖示二程式碼

3.Handler造成的記憶體洩漏

Handler的使用造成的記憶體洩漏問題應該說最為常見了，平時在處理網路任務或者封裝一些請求回撥等api都應該會藉助Handler來處理，我們經常在Activity裡面這樣定義一個私有的Handler物件並初始化，這種建立Handler的方式會造成記憶體洩漏，由於mHandler是Handler的非靜態匿名內部類的例項，所以它持有外部類Activity的引用，我們知道訊息佇列是在一個Looper執行緒中不斷輪詢處理訊息，那麼當這個Activity退出時訊息佇列中還有未處理的訊息或者正在處理訊息，而訊息佇列中的Message持有mHandler例項的引用，mHandler又持有Activity的引用，所以導致該Activity的記憶體資源無法及時回收，引發記憶體洩漏。

private Handler mHandler = new Handler() {

@Override

    public void handleMessage(Message msg) {

//...

    }

};

4.資源未關閉造成的記憶體洩漏

對於使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等資源的使用，應該在Activity銷燬時及時關閉或者登出，否則這些資源將不會被回收，造成記憶體洩漏。

三.檢測記憶體洩漏的高效工具

從Eclipse時代走過來的開發者，以為我一要開始貼那張像**一樣的MAT記憶體模型圖或者AndroidStudio中Monitors下的實時記憶體佔用圖，又要開始分析那一條條剪不斷理還亂的記憶體引用鏈，然後費盡九牛二虎之力去查詢專案中無數的記憶體洩漏中的一個。但是，我要告訴你，你錯了。其實，以前我看到記憶體洩漏分析文章的時候也是這樣的想法，看著恐怖的MAT記憶體模型圖，覺得記憶體洩漏的排查和解決簡直是Android開發中登峰造極的技能。直到我遇到了她——LeakCanary，我才直到原來記憶體洩漏的排查和解決可以那麼的優雅。LeakCanary是Square開源了一個記憶體洩露自動探測神器 。這是專案的github倉庫地址：https://github.com/square/leakcanary  。使用非常簡單，在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'

在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啟動後一會，系統通知到了，點選通知，跳轉到洩漏的詳情頁面進行檢視：

//去掉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);
}

這只是個極簡單的例子，但方法是一樣的。順便提一句，其實無論是MAT工具的記憶體分析，還是AndroidStudio中自帶的分析工具亦或是LeakCanary，原理都是一樣的，都是dump java heap出來進行分析，找到洩漏的問題，只是LeakCanary幫我們把分析的工作做了罷了。