1.Context概述

• Context是一個抽象類，其通用實現在ContextImpl類中。它的主要作用是一個訪問application環境全域性資訊的介面，通過它可以訪問application的資源和相關的類，其主要功能如下：
  1. 啟動Activity
  • 啟動和停止Service
  • 傳送廣播 訊息
  • 註冊廣播訊息接受者
  • 訪問APK中各種資源
  • 訪問Package的相關資訊
  • APK的各種許可權管理

簡單的說：Context負責Activity，Service，Intent，資源，Package和許可權。

2.Context家族關係

• 第一層：
  一個Context抽象類，
• 第二層
  一個ContextImpl的實現類，裡面擁有一個PackageInfo類的例項，PackageInfo類是關於整個包資訊的類。
  一個ContextWraper是Context的一個包裝類，裡面有一個ContextImpl類的例項，通過整個例項去呼叫ContextImpl裡面的方法。
• 第三層
  Service和Application直接繼承ContextWrapper，但是Activity需要先引入主題，所以有了ContextThemeImpl類。

3.Context使用

• 應用程式在以下幾種情況下建立Context例項：

  • 建立Application 物件時， 而且整個App共一個Application物件
  • 建立Service物件時
  • 建立Activity物件時

• 所以Context個數=Activity數+Service數+1(Application)
  每個Context各有不同。

4.Context記憶體洩露問題

• 靜態資源導致的記憶體洩漏
  有時候旋轉螢幕時候，會先銷燬原來的Activity，重新建立一個Activity，這時候圖片我們並不想重新載入，所以將圖片設定為靜態物件。
  但是靜態物件的view.setBackgroundDrawable();方法很容易造成記憶體洩露。

public class MyCustomResource {
    //靜態變數drawable
    private static Drawable drawable;
    private View view；
    public MyCustomResource(Context context) {
        Resources resources = context.getResources();
        drawable = resources.getDrawable(R.drawable.ic_launcher);
        view = new View(context);
        view.setBackgroundDrawable(drawable);
    }
}

public void setBackgroundDrawable(Drawable background) {
         ..........
         /**此處的this就是當前View物件，而View物件又是有Context物件獲得
         因此，變數background持有View物件的引用，View持有Context的引用，
         所有background間接持有Context物件的引用了*/
         background.setCallback(this);
         .......
    }

這時候想要銷燬原來的Activity時，發現靜態物件Drawable間接持有Context物件的引用，導致Activity的記憶體無法完全釋放記憶體，這時候就造成了記憶體洩露。
因此，Android系統在在3.0版本之後修改了setBackgroundDrawable內部方法中的 background.setCallback(this);方法，裡面的實現使用了弱引用來持有View物件的引用，從而避免了記憶體洩漏隱患。所以，以後程式碼中避免使用靜態資源，或者使用弱引用來解決相應的問題也是可以的。

• 單例模式導致記憶體洩漏

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

這樣單例，有記憶體洩露的隱患，如果是在Activity中建立這個單例的話，傳入的context為Activity的context，如果想要銷燬Activity，但是單例的生命週期是整個APP，導致Activity的記憶體釋放不完全。
所以需要修改成如下：

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

將context改為整個Application的Context，這時候單例與Activity就無關了，Activity釋放的時候就不會出現記憶體洩露的問題了。

• 總結
  以後在使用Context物件獲取靜態資源，建立單例物件或者靜態方法的時候，請多考慮Context的生命週期，一定要記得不要使用Activity的Context，切記要使用生命週期長的Application的Context物件。但是並不是所有情況使用Application的Context物件，在建立Dialog，View控制元件的時候都必須使用Activity的Context物件。

根據生命週期選擇適合的Context型別。