轉至：http://www.android100.org/html/201510/05/187714.html

如果我們在Activity A中或者其他地方使用Foo.getInstance()時，我們總是會順手寫一個『this』或者『mContext』（這個變數也是指向this）。試想一下，當前我們所用的Foo是單例，意味著被初始化後會一直存在與記憶體中，以方便我們以後呼叫的時候不會在此次建立Foo物件。但Foo中的『mContext』變數一直都會持有Activity A中的『Context』，導致Activity A即使執行了onDestroy方法，也不能夠將自己銷燬。但『applicationContext』就不同了，它一直伴隨著我們應用存在（中途也可能會被銷燬，但也會自動reCreate），所以就不用擔心Foo中的『mContext』會持有某Activity的引用，讓其無法銷燬。

看使用的週期是否在activity週期內，如果超出，必須用application；常見的情景包括：AsyncTask，Thread，第三方庫初始化等等。

還有些情景，只能用activity：比如，對話方塊，各種View，需要startActivity的等。

Activity.this 返回當前的Activity例項，如果是UI控制元件需要使用Activity作為Context物件，但是預設的Toast實際上使用ApplicationContext也可以。

大家注意看到有一些NO上添加了一些數字，其實這些從能力上來說是YES，但是為什麼說是NO呢？下面一個一個解釋：

數字1：啟動Activity在這些類中是可以的，但是需要建立一個新的task。一般情況不推薦。

數字2：在這些類中去layout inflate是合法的，但是會使用系統預設的主題樣式，如果你自定義了某些樣式可能不會被使用。

數字3：在receiver為null時允許，在4.2或以上的版本中，用於獲取黏性廣播的當前值。（可以無視）

注：ContentProvider、BroadcastReceiver之所以在上述表格中，是因為在其內部方法中都有一個context用於使用。

好了，這裡我們看下錶格，重點看Activity和Application，可以看到，和UI相關的方法基本都不建議或者不可使用Application，並且，前三個操作基本不可能在Application中出現。實際上，只要把握住一點，凡是跟UI相關的，都應該使用Activity做為Context來處理；其他的一些操作，Service,Activity,Application等例項都可以，當然了，注意Context引用的持有，防止記憶體洩漏。

轉至：http://blog.csdn.net/vincent_czz/article/details/8663871

在使用context的時候，小心記憶體洩露，防止記憶體洩露，注意一下幾個方面：

　1. 不要讓生命週期長的物件引用activity context，即保證引用activity的物件要與activity本身生命週期是一樣的

　2. 對於生命週期長的物件，可以使用application context

　3. 避免非靜態的內部類，儘量使用靜態類，避免生命週期問題，注意內部類對外部物件引用導致的生命週期變化