Context详解

原文

为了更好的使用Context,翻译了一篇介绍Context的文章,原文链接:Context, What Context?

---

什么是Context

Context可能是Android应用中最经常使用的对象成员,但是也可能是最被错误使用的对象成员.

Context对象在Android应用中太常见了,而且在应用中经常作为参数传来传去,甚至是不经验间就创造出一个调用者并不想创造的上下文环境出来.Context的应用范围极广,例如:加载资源,启动一个Activity,获取系统服务,获取文件路径或者创建一个View.
接下来,会讲解一下如何在你的应用中更高效的使用Context对象.

---

Context Types

Context分为几种类型,而且这几种类型并不是等价的.Context类型如下:

• Application: Application在应用程序中是单例运行.可以在Activity或者Service中通过getApplication()方法获取,或者在任何继承Context的类中通过getApplicationContext()方法获取.不过无论是通过哪种方法获取Application的实例,Application的实例都是唯一的,相同的.
• Activity/Service: Activity/Service都继承自ContextWrapper,因为具有相同的Context API.每当Framework创建一个新的Activity或者Service实例的时候,同时会创建一个新的ContextImpl对象,ContextImpl就是最终处理所有Context API方法的内部对象.不同的Activity或者Service的Context都是不一样的.
• BroadcastReceiver: BroadcastReceiver本身不是Context,但是Framework在每次发布它监听的broadcast event事件的时候,会给它的onReceive函数中传递了一个Context对象.这个Context对象是ReceiverRestrictedContext对象的实例,但是有两个方法是无法使用的:registerReceiver()和bindService().每次BroadcastReceiver通过onReceive()函数收到一个broadcast evnent时,传递过来的Context对象都是一个新的实例.
• ContentProvider: ContentProvider本身不是Context,但是内部可以通过getContext()方法获取Context对象.如果ContentProvider的调用者和ContentProvider处于同一进程中,通过getContext()获取的就是当前进程唯一的Application Context.如果不在同一进程中,通过getContext()方法就会创建一个ContentProvider所在包的一个Context实例.

---

保存Context对象

第一个问题: 当我们将一个Context的引用保存到一个存活时间比Context本身生命周期还长的对象时,问题就来了.例如,创建一个自定义的单例对象,在单例对象中要求使用Context来加载资源或者获取ContentProvider,并且传入的Context对象是Activity或者Service的实例.

错误单例

public class CustomManager {
    private static CustomManager sInstance;

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

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

之所以是错误的单例代码,是因为单例中保存的Context对象,我们并不知道它是什么的实例.如果Context是Activity或者Service的实例,那这种写法是非常不安全的.之所以不安全,是因为:
CustomManager是一个单例类,并且被一个静态对象持有,那CustomManager的生命周期是跟类相关的,不会被回收.如果保存的Context对象是Activity/Service,那Activity/Service始终被强引用,哪怕生命周期已经结束也没法被回收,这样导致了内存泄露.

正确单例

public class CustomManager {
    private static CustomManager sInstance;

    public static CustomManager getInstance(Context context) {
        if (sInstance == null) {
            // Always pass in the Application Context
            sInstance = new CustomManager(context.getApplicationContext());
        }
        return sInstance;
    }

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

在上面的例子中,由于我们使用保存的是Application Context,这样我们就不需要关心Context是谁的实例了.因为Application生命周期是跟当前应用进程一致的,也就不存在内存泄露的风险了.这个处理技巧在后台线程或者Handler处理中同样有效.

但是为什么我们不能一直使用Application Context呢?这样我们永远不用担心因为Application导致的内存泄露了?
之所以不能一直用Application Context,是因为每个Context实例都不是相同的,它们的功能也是不同的,例如Application Context就没法startActivity.

---

Context 功能列表

下面的表格描述了5中Context实例的功能(非常重要):

行为	Application	Activity	Service	ContentProvider	BroadcastReceiver
Show a Dialog	NO	YES	NO	NO	NO
Start an Activity	NO	YES	NO	NO	NO
Layout Inflation	NO	YES	NO	NO	NO
Start a Service	YES	YES	YES	YES	YES
Bind to a Service	YES	YES	YES	YES	NO
Send a Broadcast	YES	YES	YES	YES	YES
Register BroadcastReceiver	YES	YES	YES	YES	NO
Load Resource Values	YES	YES	YES	YES	YES

---

用户界面

读者可以从上面的表格中看出Application还是有很多不适合场景的.这些不适合的场景基本都和用户界面相关.实际上,也只有Activity的Context能够处理UI相关例子,其它Context的功能基本相同.

幸运的是,启动一个Dialog,启动一个Activity,实例化一个LayoutInflation这三个行为只有Activity能够操作,其他的Context类型都不能操作.Framework这么设计,也是为了最大限度的避免Context误用.

---

规则冲突

一定要人会说上面的规则存在了矛盾,例如:应用中需要一个长期存在的Context,并且这个Context是需要能操纵UI的,因此只能长期保存Activity句柄.

本文原创作者对这个矛盾的回应是:请重新设计你们的需要,代码和架构

---

Context使用技巧

大多数情况下,在组件的生命周期之内可以直接使用组件自身的Context,一旦需要在超出组件生命周期之外的对象中使用Context,就应该只用Application context,哪怕只是临时的引用,也是如此.