前言
在寫 Android 程序的過程中，總是遇到一些很細節的問題，如果不深入的瞭解以下，可能會導致一些隱藏漏洞。比如在獲取上下文的過程中，有時候使用 activity.this 與 getApplicationContext() ，但是一直都是模糊不清楚的，只有到運行出錯的時候，纔會考慮到換下，然後解決了問題，但是不知道原因 ：( 所以寫了這篇，以供參考。。。
Application類
getApplicationContext()是通過以下方法返回一個 Application對象,所以進一步瞭解這個類。
/** Return the application that owns this activity. */
public final Application getApplication() {
return mApplication;
}
定義
android.app.Application 類代表當前運行的應用程序。應用程序啓動時，系統會自動創建對應的 Application 類的實例，並一直伴隨應用程序的生命週期，而且始終維持一個實例。對於同一個應用程序，由於系統只會保證存在一個 Application 實例，即在所有組件中獲取的是同一個 Application 對象，因此 Application 特別適合保存應用程序中多個組件都需要訪問的對象
通過擴展 Application 類，可以完成以下3種任務：
- 對 Android 運行時廣播的應用程序及事件做出反應
- 在應用程序組件中傳遞對象
- 管理和維護多個應用程序組件所需要的資源
生命週期事件
Application 類爲應用程序的創建和終止、低可用內存和配置的改變提供了時間處理程序，通過重寫以下方法，可以實現上述幾種情況的應用程序行爲
1. onCreate()
在創建應用程序時調用該方法。通過重寫來實例化應用程序單態，也可以創建和實例化任何應用程序狀態變量或共享資源
2. onLowMemory()
一般只會在後臺進程已經終止但前臺應用程序依然缺少內存資源時會被調用，通過重寫來清空緩存或者釋放不必要的資源
3. onTrimMemory()
作爲onLowMemory的一個特定應用程序的替代選擇，在 Android 4.0 （API level 13）中引入。當運行時決定當前應用程序是否嘗試減少其內存開銷。該方法包含一個 level 參數，用於提供請求的上下文
4. onConfigurationChanged()
與 Activity 不同，當配置發生改變時，應用程序對象不會被終止和重啓；如果應用程序使用的值依賴於特定的配置，則重寫該方法來重新加載這個值，或者在應用程序級別處理配置的改變
兩者區別
-
對於
getApplicationContext()，我們可以假定它是一個父類，它屬於整個應用程序共有，Activity.this可以假定爲其的一個子類，該子類包含了一些特定的引用。所以，一般可以用 getApplicationContext 的地方都可以用特定的 Activity.this 代替。 -
在生命週期上，通過
getApplicationContext()得到的上下文對象們只要當前的應用程序還存在，那麼該對象就會一直存在，對於Activity.this上下文來說，只要當前的 activity 執行了 onDestory 方法，這個上下文對象就會一起被系統收回。 -
在應用場景上，如果我們通過一個上下文對象來執行某個動作，且希望一直處於活躍狀態，那麼應該用 getApplicationContext 來獲取上下文，如數據庫的操作。此時，如果採用 Activity.this，那麼當前 Activity 調用 onDestory 方法時，數據庫就會關閉，應用程序會產生錯誤。
總結
getApplicationContext()返回應用的上下文，生命週期是整個應用，應用摧毀它才摧毀Activity.this的context返回當前 activity 的上下文，屬於activity，activity摧毀他就摧毀- 和 UI 操作相關的不建議使用
getApplicationContext()，一般都使用和 activity 相關的 context，其餘的操作，看具體情況，根據存在的生命週期的長度作出選擇