Android的Context总结

---

这是四大组件的第一篇（其他还没整理好：) ）,之前有个习惯，就是把一些笔记记在书上，但是随着书越来越多，翻阅的时候比较麻烦，尤其是一段时间不用之后，想要翻阅某个知识点太费劲，这里就打算统一整理在一起，方便查看。

其中有很多内容参照了网上的博文，但是时间比较久，忘记出处了。另外就是参照Android developer的相关文档，加上自己的理解，如果有错误，欢迎指出啊。

分类

Application的Context

Application对象以单例的形式出现，代表正在运行的APP，Application继承了ContextWrapper，所以可以认为它也是一个Context，此处将其称为“Application的Context”。

获取方式：

• 在Activity或Service中，可通过调用getApplication()函数获取。

• 可以通过context.getApplicationContext()获取。

Activity、Service的Context

Activity和Service同样都继承于ContextWrapper，所以也可以认为它们是Context。

BroadcastReceiver的Context

BroadcastReceiver本身不是Context，其内部也不含有Context，但在onReceive(Context context, Intent intent)中有context参数。这个context随着receiver的注册方式的不同而不同：

• 静态注册：context为ReceiverRestrictedContext，bindService和registerReceiver被禁用

• 动态注册：context为Activity的context

• LocalBroadcastManager的动态注册： context为Application的context

ContentProvider的Context

ContentProvider本身不是Context，但可以通过getContext()获取一个context对象（该对象代表的是当前provider运行的context）。具体来讲：

• 如果provider和调用者在同一个process中，context就是Application的context

• 如果provider和调用者分属不同的进程，getContext将创建一个新的context代表此provider所运行的包。

getContext()必须在onCreate调用之后才可用，在构造器中调用将返回null。

能力

	Application	Activity	Service	Content Provider	Broadcast Receiver（静态）
显示对话框	No	Yes	No	No	No
启动Activity	No1	Yes	No1	No1	No1
填充布局	No2	Yes	No2	No2	No2
启动Service	Yes	Yes	Yes	Yes	Yes
绑定Service	Yes	Yes	Yes	Yes	No
发送Broadcast	Yes	Yes	Yes	Yes	Yes
注册Broadcast-Receiver	Yes	Yes	Yes	Yes	No3
加载资源值	Yes	Yes	Yes	Yes	Yes

注意：

• No¹表示Application的Context确实可以启动一个Activity，但是它需要创建一个新的task，会造成APP中存在不标准的回退栈，不推荐。
• No²表示这是非法的，填充虽然可以完成，但使用的系统默认的theme，而非APP的theme。
• No³在4.2以上，如果receiver是null（用于粘性广播，已被标注为过时），是允许的。

综上：与UI相关的功能只能由Activity的Context去处理。

注意事项

当需要保存一个context的引用时，如果它超过了你的Activity或Service的生命周期（即便只是暂时的），需要保存Application的context。

比较典型的：单例。

错误的例子：

public class CustomManager{
    private static CustomManager sInstance;
    private Context mContext;
    private CustomManager(Context context){
        mContext = context;
    }

    public static CustomManager getInstance(Context context){
        if( sInstance == null ){
            sInstance = new CustomManager(context);
        }
        return sInstance;
    }
}

原因：如果传入的context是一个Activity，则由于它在单例的实现中被引用，导致该Activity对象及其所引用的对象永远不能被垃圾回收，有内存泄漏的风险。

更好的实现：

public class CustomManager{
    private static CustomManager sInstance;

    private Context mContext;
    private CustomManager(Context context){
        mContext = context;
    }

    public static CustomManager getInstance(Context context){
        if( sInstance == null ){
            sInstance = new CustomManager(context.getApplicationContext());
        }
        return sInstance;
    }
}

另一个比较典型的例子：在后台线程或一个等待的Handler中如果需要保存Context的引用，也请使用Application的context。