概述
作为一名Android开发人员，每天使用最多的类中，恐怕Context可以排的上一号了。因为Context对象在我们的项目中实在是太常见了，我们在加载资源，启动Activity，获取Service，发送Broadcast，创建View时都需要Context的参与。总之，Context是为一个Android程序提供各种功能，资源，服务的一个环境，Context的资源在系统中只有一套，因为它的子类（Application，Activity，Service）对这同一块资源处理方式的不同，让Context对象在功能上表现出各自之间的差异。
保存Context引用
在编写工具类时，我们经常会编写成单例的模式，而这些工具类大都会访问资源，也就是说需要Context的参与。这时就会涉及到Context的引用问题。比如下面工具类的写法：
|
public class Util { private Context context; private static Util util; private Util(Context context){ this.context = context; } public static Util getInstance(Context context){ if(null == util){ synchronized (Util.class) { if(null == util){ util = new Util(context); } } } return util; } } |
上面的工具类中，使用单例模式，内部保存了一个Context引用，表面上看这样的写法是没有问题的，但是实际应用中可能会造成内存的泄露。因为我们不能够确定传入的Context来自哪里，如果是在某个Activity中，直接传入的是this，这时这个Util类中是一个static修饰且强引用的是常驻内存的，它内部会一直持有这个Activity作为Context引用，这就会导致即使这个Activity被销毁掉，这个Activity还是没有办法进行内存回收。所以就造成了内存泄漏。
为了避免上面的问题，我们可以对getInstance方法进行优化，如下：
|
public static Util getInstance(Context context){ if(null == util){ synchronized (Util.class) { if(null == util){ util = new Util(context.getApplicationContext()); } } } return util; } |
采用上面的方式可以理解为引用的是ApplicationContext，它的生命周期与单例对象一致，只要这个应用还在运行这个Context就会一直存在。所以说当Application的Context能解决的情况下，优先使用Application的Context，这样能避免内存泄漏。
Context的应用场景
但是上面的解决方案并不是万能的，在涉及到UI加载操作，启动Activity等，使用Application的Context时，程序无法运行的。这主要是因为Activity和Application所代表的Context返回的不是同一个对象，它们各自的使用场景也是不同的。下面是它们各自的使用场景，可以进行比较。
大家注意看到有一些NO上添加了一些数字，其实这些从能力上来说是YES，但是为什么说是NO呢？下面一个一个解释：
数字1：启动Activity在这些类中是可以的，但是需要创建一个新的task。一般情况不推荐。
数字2：在这些类中去layout inflate是合法的，但是会使用系统默认的主题样式，如果你自定义了某些样式可能不会被使用。
数字3：在receiver为null时允许，在4.2或以上的版本中，用于获取黏性广播的当前值。（可以无视）
注：ContentProvider、BroadcastReceiver之所以在上述表格中，是因为在其内部方法中都有一个context用于使用。
从上面的表格中可以看出，和UI相关的方法都不可使用Application，都应该使用Activity作为Context来处理；然后再配合工具类中Context引用的持有，防止内存泄漏，这是便能达到好的应用效果。