Android Context 是什么？

【转载请注明出处：http://blog.csdn.net/feiduclear_up CSDN 废墟的树】
PS:修该了一些有误区的地方。

引言

Context对于Android开发人员来说并不陌生，项目中我们会常常使用Context来获取APP资源。创建UI，获取系统Service服务，启动Activity，绑定Service。发送广播，获取APP信息等等。

那么Context究竟是什么？Context又是怎么来实现以上功能的？在什么场景下使用不同的Context？一个APP中总共同拥有多少个Context？这篇博客将从源代码角度带你分析Android Context究竟是个啥。

1.Context是什么

相信非常多人多会问Context究竟是什么？

  • 我们能够理解为“上下文”：它贯穿整个应用。
  • 也能够理解成“执行环境”：它提供了一个应用执行所须要的信息。资源。系统服务等；
  • 相同能够理解成“场景”：用户操作和系统交互这一过程就是一个场景，比方Activity之间的切换。服务的启动等都少不了Context。

然而以上这些都是我们从抽象角度去理解Context的作用，那么从Code代码来看Context究竟是什么呢？Activity是一个Context。Application是一个Context。Service也是一个Context你信么？不信的话。相同还是那句话“look the fuck resource code”。

public abstract class Context {
..............................
 /** Return an AssetManager instance for your application's package. */
    public abstract AssetManager getAssets();

    /** Return a Resources instance for your application's package. */
    public abstract Resources getResources();

    /** Return PackageManager instance to find global package information. */
    public abstract PackageManager getPackageManager();

    /** Return a ContentResolver instance for your application's package. */
    public abstract ContentResolver getContentResolver();

...................
//获取系统服务
public abstract Object getSystemService(@ServiceName @NonNull String name);
//发送广播
public abstract void sendBroadcast(Intent intent);
//启动Activity
public abstract void startActivity(Intent intent);
//启动服务，绑定服务
public abstract ComponentName startService(Intent service);
public abstract boolean bindService(Intent service, @NonNull ServiceConnection conn,
            @BindServiceFlags int flags);

................
}

从源代码看Context就是一个抽象类，里面定义了各种抽象方法。包含获取系统资源，获取系统服务，发送广播，启动Activity,Service等。

所以从源代码角度看Context就是抽象出一个App应用全部功能的集合，因为Context是一个纯的抽象类。所以它的详细的方法实现是在其之类ContextImpl中实现了。稍后分析。我们平时在MainActivity中会这么给mContext = this赋值。其言外之意就是当前Activity类就是Context，那说明Activity是Context的子类。通过Android Studio查看Context的子类图例如以下：

这里写图片描写叙述

有图可知。Context的子类非常多，我们主要分析以上红色矩形框内的就可以。接下来就分析Android系统中Context的继承关系。

2.Android系统中Context的继承关系

有上一节我们知道。Activity是一个Context，Service也是一个Context等等。那么这些类跟Context详细什么关系呢？接下来有一幅图Context继承关系图来说明：
这里写图片描写叙述
Context类是一个抽象类。详细实如今ContextImpl类中；而ContextWrapper是Context的一个包装类，其里面全部的方法实现都是调用其内部mBase变量的方法，而mBase就是ContextImpl对象，稍后分析。然而ContextWrapper另一个ContextThemeWrapper子类。该类中扩展了主题相关的方法。

有继承关系图能够看出，Application和Service是继承自ContextWrapper。而Activity是继承自ContextThemeWrapper。是不是有点奇怪？事实上一点都不奇怪，Activity在启动的时候系统都会载入一个主题。也就是我们平时在AndroidManifest.xml文件中面写的android:theme=”@style/AppTheme”属性啦！然而Service和Applicaton都和UI界面并没有卵关系！

因此他们继承自ContextWrapper。所以Activity，Application，Service事实上都关联着一个mBase变量。而mBase变量是ContextImpl对象的赋值，也是真正实现抽象类Context的地方。

尽管Activity。Application。Service都有一个共同的祖先Context，可是他们自己本身持有的Context对象是不同的，接下来我们从源代码角度分析以上几个类的实现。

3.不同Context源代码分析

3.1ContextImpl—真正实现Context功能的类

从源代码看出Context类仅仅是定义了一组抽象方法的抽象类。其内部的方法真正实现的地方都在ContextImpl类中。

class ContextImpl extends Context {
    //整个App的主线程
    final ActivityThread mMainThread;
    //整个App的相关信息
    final LoadedApk mPackageInfo;
    //资源解析器
    private final ResourcesManager mResourcesManager;
    //App资源类
    private final Resources mResources;
    //外部Context的引用
    private Context mOuterContext;
    //默认主题
    private int mThemeResource = 0;
    private Resources.Theme mTheme = null;
    //包管理器
    private PackageManager mPackageManager;

    ................................
//下面是静态区注冊系统的各种服务，多大五六十种系统服务，因此每一个持有Context引用的对象都能够随时通过getSystemService方法来轻松获取系统服务。

static {
        registerService(ACCESSIBILITY_SERVICE, new ServiceFetcher() {
                public Object getService(ContextImpl ctx) {
                    return AccessibilityManager.getInstance(ctx);
                }});

        registerService(CAPTIONING_SERVICE, new ServiceFetcher() {
                public Object getService(ContextImpl ctx) {
                    return new CaptioningManager(ctx);
                }});

        registerService(ACCOUNT_SERVICE, new ServiceFetcher() {
                public Object createService(ContextImpl ctx) {
                    IBinder b = ServiceManager.getService(ACCOUNT_SERVICE);
                    IAccountManager service = IAccountManager.Stub.asInterface(b);
                    return new AccountManager(ctx, service);
                }});
        ........................

       }

.................
//启动Activity的地方
 @Override
    public void startActivity(Intent intent, Bundle options) {
        warnIfCallingFromSystemProcess();
        if ((intent.getFlags()&Intent.FLAG_ACTIVITY_NEW_TASK) == 0) {
            throw new AndroidRuntimeException(
                    "Calling startActivity() from outside of an Activity "
                    + " context requires the FLAG_ACTIVITY_NEW_TASK flag."
                    + " Is this really what you want?");
        }
        mMainThread.getInstrumentation().execStartActivity(
            getOuterContext(), mMainThread.getApplicationThread(), null,
            (Activity)null, intent, -1, options);
    }

..........
//启动服务的地方
@Override
    public ComponentName startService(Intent service) {
        warnIfCallingFromSystemProcess();
        return startServiceCommon(service, mUser);
    }
...............     
}

分析：ContextImpl实现了抽象类Context里面的全部方法，获取资源，启动Activity，Service等。值得注意的是在ContextImpl创建的时候就会利用静态区来注冊系统的各种服务，因此每一个持有Context引用的类都能够通过getSystemService来轻松的获取系统服务了。比方我们平时LayoutInflater类来载入一个XML布局时时这么写的

LayoutInflater inflater = LayoutInflater.from(mContext);
View layout = inflater.inflate(R.layout.activity_main,null);

事实上源代码内部是这样实现的：

 /**
     * Obtains the LayoutInflater from the given context.
     */
    public static LayoutInflater from(Context context) {
        LayoutInflater LayoutInflater =
                (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
        if (LayoutInflater == null) {
            throw new AssertionError("LayoutInflater not found.");
        }
        return LayoutInflater;
    }

能够看出LayoutInflater布局载入器也是调用context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);来获取系统服务得到的。因此我们以后在代码中也能够这么来载入一个XML布局：

 //获取服务
LayoutInflater inflater = (LayoutInflater) mContext.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
View layout = inflater.inflate(R.layout.activity_main,null);

因为ContextImpl是抽象类Context的详细实现。而Application，Activity，Service的祖先又都是Context类。那么它们都关联着一个ContextImpl对象来真正实现Context里面全部的方法。如今来分析下不同子类创建的Context对象。

3.2ContextWrapper

public class ContextWrapper extends Context {
    Context mBase;

    public ContextWrapper(Context base) {
        mBase = base;
    }

    /**
     * Set the base context for this ContextWrapper.  All calls will then be
     * delegated to the base context.  Throws
     * IllegalStateException if a base context has already been set.
     * 
     * @param base The new base context for this wrapper.
     */
    protected void attachBaseContext(Context base) {
        if (mBase != null) {
            throw new IllegalStateException("Base context already set");
        }
        mBase = base;
    }

    /**
     * @return the base context as set by the constructor or setBaseContext
     */
    public Context getBaseContext() {
        return mBase;
    }
 ...................
  @Override
    public AssetManager getAssets() {
        return mBase.getAssets();
    }

    @Override
    public Resources getResources()
    {
        return mBase.getResources();
    }

    @Override
    public PackageManager getPackageManager() {
        return mBase.getPackageManager();
    }
...............
}

分析：从ContextWrapper源代码能够看到，这个类仅仅是一个装饰类，其内部全部方法的实现都指向mBase成员变量，而然谁给mBase成员变量赋值呢？结论是Context的真正实现类ContextImpl对象。后面会分析到。该类中通过attachBaseContext方法将ContextImpl对象赋值给mBase成员变量。

每一个App应用都是由ASM通过Binder机制创建一个新的进程然后调用ActivityThread类中的main方法開始的。非常多人可能会感到奇怪为啥Android也是基于Java实现的，为啥没有看到main方法呢？事实上整个App应用的入口在ActivityThread.main方法里面啦！

关于Activity启动过程请參考大神级别人物老罗的这篇博客：Android应用程序的Activity启动过程简要介绍和学习计划。全部有关Application，Activity，Service的创建都是在ActivityThread类中，事实上该类就是我们App的主线程。

3.3Application中的Context

每一个应用在启动的时候都会创建一个Application对象，该对象是全局的，开发人员能够实现一个子类MyApplication类来继承Application，然后实现一些全局的方法或者数据。

应用入口ActivityThread#main

 public static void main(String[] args) {
        ................
        //初始化Looper
        Looper.prepareMainLooper();
        //创建一个APP主线程ActivityThread对象
        ActivityThread thread = new ActivityThread();
        //初始化App应用信息
        thread.attach(false);
        //获得主线程也就是UI线程的handler对象
        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        }
        //此处值得注意了，在Android4.1版本号之后加入了这么一个方法，目的就是为了能让AsyncTask能在子线程创建，
        //在之前的版本号是不能在子线程中创建初始化AsyncTask的。

        //对AsyncTask感兴趣的童鞋能够參考这篇博客[ Android异步任务处理框架AsyncTask源代码分析](http://blog.csdn.net/feiduclear_up/article/details/46860015)
        AsyncTask.init();
        //启动Looper循环。进入消息循环。
        Looper.loop();
    }

分析：main方法主要工作就是创建一个App应用的主线程ActivityThread并初始化。且构建一个消息循环机制用于处理UI交互。代码第6-8行，创建了一个应用的主线程ActivityThread而且调用attach方法来初始化。

进入attach方法：
ActivityThread#attach

private void attach(boolean system) {
    //整个应用的Application对象
    Application mInitialApplication;
    //整个应用的后台管家
    Instrumentation mInstrumentation;
        ................
            try {
                mInstrumentation = new Instrumentation();
                ContextImpl context = ContextImpl.createAppContext(
                        this, getSystemContext().mPackageInfo);
                //利用ContextImpl创建整个应用的Application对象
                mInitialApplication = context.mPackageInfo.makeApplication(true, null);
                //调用Application对象的onCreate方法
                mInitialApplication.onCreate();
            } 
       ................
    }

代码第13行：通过调用LoadedApk#makeApplication方法创建应用程序的Application对象。
LoadedApk#makeApplication

 public Application makeApplication(boolean forceDefaultAppClass,
            Instrumentation instrumentation) {
        //第一次进来mApplication==null条件不满足，之后创建Activity的时候条件满足直接返回当前Application对象
        if (mApplication != null) {
            return mApplication;
        }

        Application app = null;

        try {

            //为Appliaction创建ContextImpl对象
            ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
            //调用Instrumentation类中的newApplication方法创建Application
            app = mActivityThread.mInstrumentation.newApplication(
                    cl, appClass, appContext);
            //给ContextImpl设置外部引用
            appContext.setOuterContext(app);
        } 
      ....................
        return app;
    }

分析：
1.代码第4-6行：推断当前应用是否是第一次创建Application对象，假设不是则直接返回Application对象，否则去创建第一个Application对象。目的是确保当前应用之创建了一个全局的Application对象。
2.代码第13行：创建了一个ContextImpl对象。然后作为參数用于创建Application对象。
3.代码第15行：调用Instrumentation类中的newApplication方法来创建Application对象。
4.代码第18行：将创建好的Application对象赋值给ContextImpl类的mOuterContext成员变量。目的是让ContextImpl持有外部Application类的引用用于注冊系统服务或者其它方法。

Instrumentation#newApplication

public Application newApplication(ClassLoader cl, String className, Context context)
            throws InstantiationException, IllegalAccessException, 
            ClassNotFoundException {
        return newApplication(cl.loadClass(className), context);
    }

    static public Application newApplication(Class<?> clazz, Context context)
            throws InstantiationException, IllegalAccessException, 
            ClassNotFoundException {
        Application app = (Application)clazz.newInstance();
        app.attach(context);
        return app;
    }

分析：以上代码通过类载入器来创建Application对象，而且调用app.attach（context）方法来初始化Application对象。

这里的context就是上面传下来的ContextImpl对象了。进入Application源代码
Application#attach

public class Application extends ContextWrapper implements ComponentCallbacks2 {
..................
/**
     * @hide
     */
    /* package */ final void attach(Context context) {
        attachBaseContext(context);
        mLoadedApk = ContextImpl.getImpl(context).mPackageInfo;
    }
...............
}

分析：Application类是继承自ContextWrapper类。在attach方法中调父类也就是ContextWrapper中的attachBaseContext方法来对ContextWrapper的成员变量mBase赋值成ContextImpl对象。详细能够參考3.2小节。因此Application通过父类ContextWrapper类的成员变量mBase指向了ContextImpl。让Application类真正实现了其祖父类Context抽象类中的全部抽象方法。

3.4Activity中的Context

当Application创建完毕之后，ASM会通过Binder机制通知ActivityThread去创建须要的Activity了。最后会辗转到ActivityThread类中的performLaunchActivity方法来创建Activity。

ActivityThread#performLaunchActivity

private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
        ........................

        Activity activity = null;
        try {
        //通过Instrumentation类的newActivity方法来创建一个Activity对象
            java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
            activity = mInstrumentation.newActivity(
                    cl, component.getClassName(), r.intent);
           ..........................
        }
        try {
            //获取当前应用的Application对象，该对象的唯一作用就是作为參数传递到Activity里，
            然后在Activity类中能够获得调用getApplication方法来获取Application对象
            Application app = r.packageInfo.makeApplication(false, mInstrumentation);

          .............................
            if (activity != null) {
                //为Activity创建ContextImpl对象
                Context appContext = createBaseContextForActivity(r, activity);
                //为Activity赋值初始化
                 activity.attach(appContext, this, getInstrumentation(), r.token,
                        r.ident, app, r.intent, r.activityInfo, title, r.parent,
                        r.embeddedID, r.lastNonConfigurationInstances, config,
                        r.voiceInteractor);
               ...................
                //获取当前应用的主题资源
                int theme = r.activityInfo.getThemeResource();
                if (theme != 0) {
                //设置主题
                    activity.setTheme(theme);
                }

                activity.mCalled = false;
                if (r.isPersistable()) {
                //辗转到Activity，调用Activity的生命周期onCreate方法
                    mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
                } else {
                    mInstrumentation.callActivityOnCreate(activity, r.state);
                }
                .............
                r.activity = activity;
                r.stopped = true;
                if (!r.activity.mFinished) {
                //调用Activity的生命周期onStart方法
                    activity.performStart();
                    r.stopped = false;
                }
                ......................

        return activity;
    }

分析：

  1. step1 这里也是通过Instrumentation类的newActivity方法来创建一个Activity对象，跟上面创建Application对象基本相似，这里就不贴源代码了。
  2. step2 之后在调用本地方法 createBaseContextForActivity去创建ContextImpl对象，该对象将作为參数传递到Activity#attach方法中。
  3. step3 调用Activity#attach方法对刚创建好的Activity进行初始化操作。

    后面会分析Activity#attach方法。

  4. step4 获取当前应用的主题资源。然后调用Activity#setTheme方法给刚创建好的Activity对象设置主题。
  5. setp5 一次调用Activity的生命周期方法onCreate，onStart。

step2
如今来分析下ActivityThread#createBaseContextForActivity方法。

ActivityThread#createBaseContextForActivity

private Context createBaseContextForActivity(ActivityClientRecord r,
            final Activity activity) {
        ContextImpl appContext = ContextImpl.createActivityContext(this, r.packageInfo, r.token);
        appContext.setOuterContext(activity);
        Context baseContext = appContext;
   .............
   return baseContext；
}

分析：该方法里面的确创建了一个ContextImpl对象。而且返回该对象。

同一时候也调用了ContextImpl#setOuterConexet方法让ContextImpl持有外部Activity对象的引用，目的是在ContextImpl类中注冊一些服务，设置主题等都须要外部Activity对象的引用。

setp3
因为Activity没有重写构造方法，因此创建出来的Activity并没有初始化。

为了对Activity初始化。以上代码调用了Activity#attach方法来进行初始化操作。

Activity#attach

public class Activity extends ContextThemeWrapper
        implements LayoutInflater.Factory2,
        Window.Callback, KeyEvent.Callback,
        OnCreateContextMenuListener, ComponentCallbacks2,
        Window.OnWindowDismissedCallback {

............................

final void attach(Context context, ActivityThread aThread,
            Instrumentation instr, IBinder token, int ident,
            Application application, Intent intent, ActivityInfo info,
            CharSequence title, Activity parent, String id,
            NonConfigurationInstances lastNonConfigurationInstances,
            Configuration config, IVoiceInteractor voiceInteractor) {
        //调用父类方法对mBase变量赋值
        attachBaseContext(context);
        //创建一个Activity的窗体
        mWindow = PolicyManager.makeNewWindow(this);
        //给Window窗体设置回调事件
        mWindow.setCallback(this);
        mWindow.setOnWindowDismissedCallback(this);
        mWindow.getLayoutInflater().setPrivateFactory(this);
        //设置键盘弹出状态
        if (info.softInputMode != WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) {
            mWindow.setSoftInputMode(info.softInputMode);
        }
        if (info.uiOptions != 0) {
            mWindow.setUiOptions(info.uiOptions);
        }
        mUiThread = Thread.currentThread();

        mMainThread = aThread;
        mInstrumentation = instr;
        mToken = token;
        mIdent = ident;
        //此处注意，将整个应用的Application对象赋值给Activity的mApplication成员变量。
        //目的是为了能在Activity中通过getApplication方法来直接获取Application对象
        mApplication = application;
       ......................
    }
    //在Activity中返回当前应用的Application对象
/** Return the application that owns this activity. */
    public final Application getApplication() {
        return mApplication;
    }

.......................

分析：attach方法一进来就调用了父类的attachBaseContext方法将ContextImpl对象注冊到Activity里面去。因为Activity的父类是ContextThemeWrapper。进入该类查看attachBaseContext方法

ContextThemeWrapper#attachBaseContext

public class ContextThemeWrapper extends ContextWrapper {
   ............

    @Override protected void attachBaseContext(Context newBase) {
        super.attachBaseContext(newBase);
    }
    ...........

该方法也非常easy，还是调用父类的attachBaseContext方法注冊ContextImpl，然而该类的父类就是ContextWrapper类。


ContextWrapper#attachBaseContext

public class ContextWrapper extends Context {
..............
 protected void attachBaseContext(Context base) {
        if (mBase != null) {
            throw new IllegalStateException("Base context already set");
        }
        mBase = base;
    }
..........
}

在ContextWrapper类中调用attachBaseContext方法将ContextImpl对象（真正实现Context抽象类里面各种方法的类）赋值给mBase成员变量，而ContextWrapper仅仅是一个装饰类。里面全部方法的实现都是调用mBase的方法。

此时mBase方法被赋值成ContextImpl对象，这么一来Activity的祖父类就实现了里面的全部Context抽象方法。那么在Activity中能够调用Context里面的不论什么方法了。

3.5 Service中的Context

相同创建Service也是有ASM通过Binder机制通知ActivityThread类去创建一个Service服务了。最后会辗转到ActivityThread#handleCreateService方法中来创建一个Service服务。

ActivityThread#handleCreateService

private void handleCreateService(CreateServiceData data) {

        LoadedApk packageInfo = getPackageInfoNoCheck(
                data.info.applicationInfo, data.compatInfo);
        Service service = null;
        try {
            //通过类载入器创建Service服务
            java.lang.ClassLoader cl = packageInfo.getClassLoader();
            service = (Service) cl.loadClass(data.info.name).newInstance();
        } 
    .............
        try {
          ............
          //此处为Service创建一个ContextImpl对象
            ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
            //相同为ContextImpl类设置外部对象，目的还是让ContextImpl持有外部类的引用
            //在ContextImpl类中的很多方法须要使用到外部Context对象引用
            context.setOuterContext(service);
    ................
            //获得当前应用的Applicaton对象。该对象在整个应用中仅仅有一份，是共享的。

            Application app = packageInfo.makeApplication(false, mInstrumentation);
            //将ContextImpl对象和Application对象作为attach方法參数来初始化Service
            service.attach(context, this, data.info.name, data.token, app,
                    ActivityManagerNative.getDefault());
            //Service初始化完毕之后系统自己主动调用onCreate生命周期方法
            service.onCreate();
     ................
    }

分析：
跟以上Activity和Application创建相似。通过类载入器来创建Service对象。然后在创建一个ContextImpl对象，而且为ContextImpl类设置外部Service对象Context的引用。目的之在ContextImpl类中的很多方法都须要使用到外部Context引用。

其次和Activity一样调用packageInfo.makeApplication方法去获得当前应用的Application对象。然后将Application对象和ContextImpl对象作为Service#attach方法去初始化Service。当Service初始化完毕之后，系统调用Service的生命周期方法onCreate方法。该方法是创建Service过程中最早暴露给开发人员的。全部开发人员在实现自己的Service时能够重写onCreate方法来进行一些初始化工作。

如今我们来分析下Service#attach方法

Service#attach

public abstract class Service extends ContextWrapper implements ComponentCallbacks2 {
    //默认构造方法调用父类构造方法而且參数为null。意味着构造方法里并没有对Service初始化
    public Service() {
        super(null);
    }

//在Service中返回整个应用的Application对象
    /** Return the application that owns this service. */
    public final Application getApplication() {
        return mApplication;
    }
    ..............
 /**
     * @hide
     */
    public final void attach(
            Context context,
            ActivityThread thread, String className, IBinder token,
            Application application, Object activityManager) {
        //调用父类方法去注冊ContextImpl对象
        attachBaseContext(context);
        mThread = thread;           // NOTE:  unused - remove?

        mClassName = className;
        mToken = token;
        //将整个应用的Applicaton对象赋值给Service类的成员变量mApplication
        mApplication = application;
        mActivityManager = (IActivityManager)activityManager;

    }

分析：
Service的父类是ContextWrapper。在attach方法中调用了父类中attachBaseContext方法去注冊CotextImpl对象，这一操作和创建Application一样，详细參考前面分析。

3.6总结

至此，一个Android应用可能创建Context的地方基本分析结束。

全部有关创建Context对象的地方都是在ActivityThread类中，该类就是整个应用的入口，也是整个应用的主线程。每一个应用首先会创建一个Application对象，且一个应用仅仅有唯一一个Application对象。之后再依据需求创建Activity或者Service。

且在创建Activity或者Service的时候都会持有一份当前应用的Application对象。通过getApplication方法就可以获得。

无论在创建Application。Activity还是Service的时候都会去创建一个ContextImpl对象（真正实现抽象类Context功能的类就是ContextImpl）。然后将该对象注冊到相应的Application，Activity，Service中，之后在Application，Activity，Service类中就能够使用Context的全部功能了。所以Application，Activity，Service的祖先都是抽象类Context，相当于Context给了他们身体，让他们有了一个躯壳有思想，但真正让他们思想得到执行的类还是ContextImpl类。因此我们能够这么来理解：抽象类Context给了Application。Activity，Service思想。而ContextImpl类给了他们去执行思想的功能。

有以上分析我们知道，每创建一个Application。Activity还是Service都会创建一个ContextImpl类（真正实现Context类功能）。且一个应用仅仅会创建一个Application对象。因此：一个App中Context的个数=1个Application+Activity的个数+Service的个数。

【转载请注明出处：http://blog.csdn.net/feiduclear_up CSDN 废墟的树】

4.Context应用场景

尽管Application。Activity，Service的祖先都是Context，并非每一个Context对象都是相同的。

  • Application：一个应用在创建的时候仅仅会创建一个ActivityThread主线程。而在初始化ActivityThread主线程的时候就会创建一个Application对象。

    Application是全局的，在Activity和Service里都能够调用getApplication方法来获得一个应用的Application对象。Application的父类是ContextWrapper类。

  • **Service：**Service父类是ContextWrapper，一个应用每创建一个Service，都会创建一个ContextImpl类去关联Service。

  • **Activity：**Activity父类是ContextThemeWrapper。而ContextThemeWrapper父类是ContextWrapper。

    ContextThemeWrapper类是其父类的扩张。里面额外加入了关于主题设置的一些方法。在ActivityThread主线程中创建Activity的时候我们知道，创建完了Activity之后会立刻调用Activity#setTheme设置Activity的主题。

不同Context的应用场景例如以下图标

功能 Application Service Activity
Start an Activity NO1 NO1 YES
Show a Dialog NO NO YES
Layout Inflation YES YES YES
Start a Service YES YES YES
Bind to a Service YES YES YES
Send a Broadcast YES YES YES
Register BroadcastReceiver YES YES YES
Load Resource Values YES YES YES

解释:

  • NO1表示Application和Service能够启动一个Activity。可是须要创建一个新的task。比方你在Application中调用startActivity（intent）时系统会报例如以下错误：
java.lang.RuntimeException: Unable to create application 
com.xjp.toucheventdemo.MyApplication: android.util.AndroidRuntimeException: Calling 
startActivity() from outside of an Activity  context requires the FLAG_ACTIVITY_NEW_TASK 
flag. Is this really what you want?

意思就是当在Activity以外的环境启动一个新的Activity的时候须要给Intent加入一个FLAG_ACTIVITY_NEW_TASK标记。该标记的作用就是为当前须要启动的Activity创建一个新的task任务队列。

  • 除了Activity能够创建一个Dialog。其它都不能够创建Dialog。比方在Application中创建Dialog会报例如以下错误：
Caused by: java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity.

原因是因为在创建Dialog的时候会使用到Context对象去获取当前主题信息。可是我们知道Application和Service是继承自ContextWrapper，没有实现关于主题的功能，然而Activity是继承自ContextThemeWrapper，该类是实现了关于主题功能的，因此创建Dialog的时候必须依附于Activity的Context引用。

5.getApplication和getApplicationContext差别

非常多人对getApplication方法和getApplicationContext感到疑惑。这两个方法返回值有什么不同？什么场合使用什么样的方法？这里我们从源代码角度告诉大家：这两个方法返回值都是指向同一个Application对象，仅仅是返回类型和实现方法的地方不同而已。

5.1 getApplication

public class Activity extends ContextThemeWrapper
        implements LayoutInflater.Factory2,
        Window.Callback, KeyEvent.Callback,
        OnCreateContextMenuListener, ComponentCallbacks2,
        Window.OnWindowDismissedCallback {
..............
/** Return the application that owns this activity. */
    public final Application getApplication() {
        return mApplication;
    }
...........

getApplication方法实现是在Activity类中。且返回值是当前应用的Application对象。该对象是在ActivityThread类创建Activity时传递下来的。

详细能够參考3.4小节。

5.2 getApplicationContext

public class ContextWrapper extends Context {
.............
 @Override
    public Context getApplicationContext() {
        return mBase.getApplicationContext();
    }
.............
}

getApplicationContext方法是在ContextWrapper类中实现。因为mBase变量指向的是ContextImpl对象，因此真正实现的地方是ContextImpl类中

class ContextImpl extends Context {
................
 @Override
    public Context getApplicationContext() {
        return (mPackageInfo != null) ?
                mPackageInfo.getApplication() : mMainThread.getApplication();
    }
..........
}

该方法返回的是Context类型，且返回值也是调用mPackageInfo.getApplication()或者mMainThread.getApplication()。

public final class LoadedApk {
............
Application getApplication() {
        return mApplication;
    }
..........
}

能够看出返回的是当前应用的Application对象，因为一个应用仅仅有一份LoadedApk对象，此处返回的也是系统的唯一Application对象。

public final class ActivityThread {
.................
public Application getApplication() {
        return mInitialApplication;
    }
................
}

能够看出返回值也是当前应用的Application对象，因为一个应用仅仅有一个主线程，此处返回的也是系统的唯一Application对象。

因此：getApplication和getApplicationContext方法返回的对象都是指向当前应用的Application对象，是同一个Application对象，仅仅是返回值类型不同而已。

查看源代码会发现getApplication方法是在Activity。Service类中实现的；而getApplicationContext方法是在ContextWrapper类中实现的。

也就是getApplication方法是在Context子类中实现的，而getApplicationContext是在父类中实现的。从而导致两个方法的使用范围是不一样的。

你能够这么调用

context.getApplicationContext();

可是却不能够这么调用

context.getApplication();

因为getApplication方法是Context子类中实现的，所以你必须这样调用

((Activity)context).getApplication();

6.Context内存泄漏问题

在项目中。我们常常会遇到使用单例模式或者静态static变量，尽管使用静态类或者静态变量非常方便，可是也潜在非常多的内存泄漏问题。

6.1静态资源导致的内存泄漏

你可能遇到下面这段代码：

public class MyCustomResource {
    //静态变量drawable
    private static Drawable drawable;
    private View view。

    public MyCustomResource(Context context) {
        Resources resources = context.getResources();
        drawable = resources.getDrawable(R.drawable.ic_launcher);
        view = new View(context);
        view.setBackgroundDrawable(drawable);
    }
}

请问，这段代码有什么问题？乍一看貌似没啥问题，挺好的啊。事实上不然，基本的问题在于view.setBackgroundDrawable方法里面。我们知道静态变量在整个应用的内存里仅仅保存一份，一旦创建就不会释放该变量的内存，直到整个应用都销毁才会释放static静态变量的内存。

public class View implements Drawable.Callback, KeyEvent.Callback,
        AccessibilityEventSource {
    ...........
    public void setBackgroundDrawable(Drawable background) {
         ..........
         /**此处的this就是当前View对象，而View对象又是有Context对象获得
         因此，变量background持有View对象的引用，View持有Context的引用，
         全部background间接持有Context对象的引用了*/
         background.setCallback(this);
         .......
    }
    ..........
}

setBackgroundDrawable方法内部调用了background.setCallback(this)回调方法，而该參数this就是View的对象。因为background是一个静态变量。会一直持有View对象的引用，而然View对象又是由Context对象创建出来的。因此background会间接持有Context的对象的引用。也就意味着假设该Context相应的Activity退出finish掉的时候事实上该Activity是不能全然释放内存的。因为静态变量drawable持有该Activity的Context对象的间接引用。从而导致该Activity内存无法回收，导致内存泄漏隐患。因为Activity就是Context，全部Context的生命周期和Activity是一样长的。我们希望Activity退出时Context也释放内存，这样才不会导致内存泄漏隐患。那么以上这段代码是不安全的。值得注意的是：以上代码是因为静态资源drawable持有View对象的引用导致内存泄漏隐患的，并非因为context.getResource导致内存泄漏。因此假设你想通过context.getApplicaitonContext来获取getResource是解决不了内存泄漏的。因此。Android系统在在3.0版本号之后改动了setBackgroundDrawable内部方法中的 background.setCallback(this);方法。里面的实现使用了弱引用来持有View对象的引用，从而避免了内存泄漏隐患。所以，以后代码中避免使用静态资源。或者使用弱引用来解决相应的问题也是能够的。

6.2 单例模式导致内存泄漏

相信单例模式对开发人员非常有诱惑力吧！或多或少在项目中都实用过单例模式。你也可能见过一下这段代码：

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对象的引用，假设你是在Application中创建以上单例的话是木有不论什么问题的。

因为Application的Context生命周期是整个应用，和单例的生命周期一样，因此不会导致内存泄漏。

可是。假设你是在Activity中创建以上单例的话，就会导致和6.1小节一样的问题—内存泄漏。所以我们相同能够将代码改动成例如以下：

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

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

6.3 总结

以后在使用Context对象获取静态资源，创建单例对象或者静态方法的时候。请多考虑Context的生命周期，一定要记得不要使用Activity的Context，切记要使用生命周期长的Application的Context对象。

可是并非全部情况使用Application的Context对象，比方第4小节，在创建Dialog，View控件的时候都必须使用Activity的Context对象。

Context总结

  1. Context是什么？Context是”执行上下文环境“，从代码角度看Application，Service。Activity都是Context。
  2. 全部Context都是在应用的主线程ActivityThread中创建的。因为Application，Service，Activity的祖先都是Context抽象类，所以在创建它们的同一时候也会为每一个类创建一个ContextImpl类，ContextImpl是Context的之类，真正实现Context功能方法的类。因此Application。Service。Activity都关联着一个ContextImpl对象。
  3. 尽量少用Context对象去获取静态变量，静态方法，以及单例对象。

    以免导致内存泄漏。

  4. 在创建与UI相关的地方，比方创建一个Dialog，或者在代码中创建一个TextView，都用Activity的Context去创建。

    然而在引用静态资源。创建静态方法，单例模式等情况下。使用生命周期更长的Application的Context才不会导致内存泄漏。

    【转载请注明出处：http://blog.csdn.net/feiduclear_up CSDN 废墟的树】

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/yjbjingcha/p/7297499.html