何時用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引用的持有，防止內存泄漏。