什麼時候用Application的Context，什麼時候用Activity的Context

標籤：

單例模式用application的context

如果我們在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引用的持有，防止記憶體流失。

什麼時候用Application的Context，什麼時候用Activity的Context