Context類，時刻的在與它打交道，例如：Service、BroadcastReceiver、Activity等都會利用到Context的相關方法。
但是不懂Context的原理、類結構關系。一個簡單的問題是，一個應用程序App中存在多少個Context實例對象呢？
Context，中文直譯為“上下文”，SDK中對其說明如下：
Interface to global information about an application environment. This is an abstract class whose implementation
is provided by theAndroidsystem. It allows access to application-specific resources and classes, as well as up-calls
for application-level operations such as launching activities, broadcasting and receiving intents, etc
從上可知一下三點,即：
1、它描述的是一個應用程序環境的信息，即上下文。
2、該類是一個抽象(abstract class)類，Android提供了該抽象類的具體實現類(后面我們會講到是ContextIml類)。
3、通過它我們可以獲取應用程序的資源和類，也包括一些應用級別操作，例如：啟動一個Activity，發送廣播，接受Intent
信息 等。。
應用程序創建Context實例的情況有如下幾種情況：
1、創建Application 對象時， 而且整個App共一個Application對象
2、創建Service對象時
3、創建Activity對象時
因此應用程序App共有的Context數目公式為：
總Context實例個數 = Service個數 + Activity個數 + 1（Application對應的Context實例）
具體創建Context的時機
1、創建Application對象的時機
每個應用程序在第一次啟動時，都會首先創建Application對象。如果對應用程序啟動一個Activity(startActivity)流程比較
清楚的話，創建Application的時機在創建handleBindApplication()方法中
2、創建Activity對象的時機
通過startActivity()或startActivityForResult()請求啟動一個Activity時，如果系統檢測需要新建一個Activity對象時，就會
回調handleLaunchActivity()方法，該方法繼而調用performLaunchActivity()方法，去創建一個Activity實例，并且回調
onCreate()，onStart()方法等。
3、創建Service對象的時機
通過startService或者bindService時，如果系統檢測到需要新創建一個Service實例，就會回調handleCreateService()方法，
完成相關數據操作。
Android中context可以作很多操作，但是最主要的功能是加載和訪問資源。在android中常用兩種context，一種是application context，一種是activity context，通常我們在各種類和方法間傳遞的是activity context。
繼承關系：
區別聯系：
public class MyActivity extends Activity {
public void method() {
mContext = this; // since Activity extends Context
mContext = getApplicationContext();
mContext = getBaseContext();
}
}
this 是Activity 的實例，擴展了Context，其生命周期是Activity 創建到銷毀。getApplicationContext()返回應用的上下文，生命周期是整個應用，應用摧毀它才摧毀。Activity.this的context 返回當前activity的上下文，屬于activity ，activity摧毀他就摧毀
getBaseContext() 返回由構造函數指定或setBaseContext()設置的上下文，SDK文檔很少，不推薦使用
搞清楚了生命周期就會在使用過程中犯錯誤，比如有一個全局的數據操作類用到了context，這個時候就要getApplicationContext 而不是用ACtivity，這就保證了數據庫的操作與activity無關（不會一直引用Activity的資源，防止內存泄漏）
應用場景：
比如一個activity的onCreate：
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this); //??context?view c
ontrol
label.setText("Leaks are bad");
setContentView(label);
}
把activity context傳遞給view，意味著view擁有一個指向activity的引用，進而引用activity占有的資源：view hierachy, resource等。這樣如果context發生內存泄露的話，就會泄露很多內存。這里泄露的意思是gc沒有辦法回收activity的內存。
Leaking an entire activity是很容易的一件事。當屏幕旋轉的時候，系統會銷毀當前的activity，保存狀態信息，再創建一個新的activity。
比如我們寫了一個應用程序，它需要加載一個很大的圖片，我們不希望每次旋轉屏幕的時候都銷毀這個圖片重新加載。
實現這個要求的簡單想法就是定義一個靜態的Drawable，這樣Activity類創建銷毀它始終保存在內存中。
實現示例：
public class myactivity extends Activity {
private static Drawable sBackground;
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
if (sBackground == null) {
P 2 / 3
Android Context 詳解
sBackground = getDrawable(R.drawable
.large_bitmap);
}
label.setBackgroundDrawable(sBackground);//dra
wable attached to a view
setContentView(label);
}
}
這段程序看起來很簡單，但是卻問題很大。當屏幕旋轉的時候會有leak（即gc沒法銷毀activity）。我們剛才說過，屏幕旋轉的時候系統會銷毀當前的activity。但是當drawable和view關聯后，drawable保存了view的reference，即sBackground保存了label的引用，而label保存了activity的引用。既然drawable不能銷毀，它所引用和間接引用的都不能銷毀，這樣系統就沒有辦法銷毀當前的activity，于是造成了內存泄露。gc對這種類型的內存泄露是無能為力的。避免這種內存泄露的方法是避免activity中的任何對象的生命周期長過activity，避免由于對象對activity的引用導致activity不能正常被銷毀。我們可以使用application context。application context伴隨application的一生，與activity的生命周期無關。application context可以通過Context.getApplicationContext()或者Activity.getApplicationContext()方法獲取。
定制一個自己的Application：首先創建一個MyApplication類繼承自Application
public class MyApplication extends Application
{
private static Context context;
public void onCreate()
{
context=getApplicationContext();
}
public static Context getContext()
{
return context;
}
}
注意：當程序啟動的時候應該初始化MyApplication類，而不是默認的Application類。在AndroidMainifest.xml文件的標簽下進行指定就可以了。
android:name="com.example.hl.MyApplication"
這樣就已經實現了一種全局獲取Context的機制，之后想在項目中使用Application的Context時，只需調用一下MyApplication.getContext()就可以了。
避免context相關的內存泄露，記住以下幾點：
1. 不要讓生命周期長的對象引用activity context，即保證引用activity的對象要與activity本身生命周期是一樣的
2. 對于生命周期長的對象，可以使用application context
3. 避免非靜態的內部類，盡量使用靜態類，避免生命周期問題，注意內部類對外部對象引用導致的生命周期變化
