其实，说白了，学过JavaWeb的应该知道域，我感觉这个Context就跟域相似，存在于整个应用中

 

 

Context字面意思上下文，位于framework package的android.content.Context中，其实该类为LONG型，类似Win32中的Handle句柄，很多方法需要通过Context才能识别调用者的实例，比如说Toast的第一个参数就是Context，一般在Activity中我们直接用this代替，代表调用者的实例为Activity，而到了一个button的onClick(View view)等方法时，我们用this时就会报错，所以我们可能使用ActivityName.this来解决，主要原因是因为实现Context的类主要有Android特有的几个模型，Activity、Service以及BroadcastReceiver。

  常规需要Context实例的方法主要有各种Service实现的类，比如说SensorManager在实例化时需要getSystemService(String)方法就必须由Context的实例执行，还有一些私有的文件系统I/O比如说openFileInput以及常用的Toast的makeText方法。

 

 

你的构造函数里面不是传入了一个上下文的对象吗？用它就行了啊。
Context是一个抽象对象，它的子类比较多，Activity就是它的子类，Service也是。

 

这样理解就很简单了：

一个APK进程只有一个Context： 这个Context就是ApplicationContext，从Context继承过来。

ApplicationContext可以看做是针对整个系统的全局处理接口,因为：
它负责和系统服务打交道
RPC通信由他通过那些XXXServiceManager和XXXService来处理。

其他一些模块，比如Activity，Service等，也是从Context继承而来的。
比如Acitivity在attach到主线程(ActivityThread)时，会用ApplicationContext来初始化这个Activity，这样就OK了。



比如Activity中StartService，调用过程如下：
Activity.StartService
（Activity继承自ContextWraper，实际会执行 ContextWraper中的）
public ComponentName startService(Intent service) {
        return mBase.startService(service);
    }

这里面的mBase实际就是ApplicationContext


ApplicationContext中的实现如下：
@Override
    public ComponentName startService(Intent service) {
        try {
            ComponentName cn = ActivityManagerNative.getDefault().startService(
                mMainThread.getApplicationThread(), service,
                service.resolveTypeIfNeeded(getContentResolver()));
            if (cn != null && cn.getPackageName().equals("!")) {
                throw new SecurityException(
                        "Not allowed to start service " + service
                        + " without permission " + cn.getClassName());
            }
            return cn;
        } catch (RemoteException e) {
            return null;
        }
    }

通过系统服务来做的。

总之：context就是将这些系统服务提供的功能，完美的包装起来了，其中的RPC过程，用户无需关心。好像这些功能就是在那，自己可以随便使用（要知道跨进程通信和调用，是非常难和麻烦的事情）。