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