Android中Context理解

最新推荐文章于 2024-07-12 03:57:56 发布

快乐-学习

最新推荐文章于 2024-07-12 03:57:56 发布

阅读量9.6k

点赞数 7

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源码分析
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;
}

分析：

step1 这里也是通过Instrumentation类的newActivity方法来创建一个Activity对象，跟上面创建Application对象基本类似，这里就不贴源码了。
step2 之后在调用本地方法 createBaseContextForActivity去创建ContextImpl对象，该对象将作为参数传递到Activity#attach方法中。
step3 调用Activity#attach方法对刚创建好的Activity进行初始化操作。后面会分析Activity#attach方法。
step4 获取当前应用的主题资源，然后调用Activity#setTheme方法给刚创建好的Activity对象设置主题。
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

……………………….

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);
}
...........

该方法也很简单，还是调用父类的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小节一样的问题—内存泄漏。所以我们同样可以将代码修改成如下：

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总结

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

在创建与UI相关的地方，比如创建一个Dialog，或者在代码中创建一个TextView，都用Activity的Context去创建。然而在引用静态资源，创建静态方法，单例模式等情况下，使用生命周期更长的Application的Context才不会导致内存泄漏。

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

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