Android应用Context详解及源码解析，android游戏开发入门视频

最新推荐文章于 2024-11-24 20:14:08 发布

原创最新推荐文章于 2024-11-24 20:14:08 发布 · 2.2k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#面试 #移动开发 #android

程序员专栏收录该内容

74 篇文章

订阅专栏

本文详细剖析了Android中Context的实现（ContextImpl）、Activity、Service和Application的继承关系，以及Context的实例化过程。重点讲解了不同组件的Context数量和资源访问的一致性。通过源码解析，揭示了getApplication与getApplicationContext的差异，并总结了关键技术和标签.

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

/**

Proxying implementation of Context that simply delegates all of its calls to
another Context. Can be subclassed to modify behavior without changing
the original Context.

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;

}

…

}

该类的构造函数包含了一个真正的Context引用（ContextImpl对象），然后就变成了ContextImpl的装饰着模式。

再来看看ContextWrapper的子类ContextThemeWrapper源码注释：

/**

A ContextWrapper that allows you to modify the theme from what is in the
wrapped context.

public class ContextThemeWrapper extends ContextWrapper {

…

}

该类内部包含了主题Theme相关的接口，即android:theme属性指定的。

再来看看Activity、Service、Application类的继承关系源码：

public class Activity extends ContextThemeWrapper

implements LayoutInflater.Factory2,

Window.Callback, KeyEvent.Callback,

OnCreateContextMenuListener, ComponentCallbacks2,

Window.OnWindowDismissedCallback {

…

}

public abstract class Service extends ContextWrapper implements ComponentCallbacks2 {

…

}

public class Application extends ContextWrapper implements ComponentCallbacks2 {

…

}

看见没有？他们完全符合上面我们绘制的结构图与概述。

2-3 解决应用Context个数疑惑

有了上面的Context继承关系验证与分析之后我们来看下一个应用程序到底有多个Context？

Android应用程序只有四大组件，而其中两大组件都继承自Context，另外每个应用程序还有一个全局的Application对象。所以在我们了解了上面继承关系之后我们就可以计算出来Context总数，如下：

APP Context总数 = Application数(1) + Activity数(Customer) + Service数(Customer);

到此，我们也明确了Context是啥，继承关系是啥样，应用中Context个数是多少的问题。接下来就有必要继续深入分析这些Context都是怎么来的。

【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重分享成果】

3 各种Context在ActivityThread中实例化过程源码分析

在开始分析之前还是和《Android异步消息处理机制详解及源码分析》的3-1-2小节及《Android应用setContentView与LayoutInflater加载解析机制源码分析》的2-6小节一样直接先给出关于Activity启动的一些概念，后面会写文章分析这一过程。

Context的实现是ContextImpl，Activity与Application和Service的创建都是在ActivityThread中完成的，至于在ActivityThread何时、怎样调运的关系后面会写文章分析，这里先直接给出结论，因为我们分析的重点是Context过程。

3-1 Activity中ContextImpl实例化源码分析

通过startActivity启动一个新的Activity时系统会回调ActivityThread的handleLaunchActivity()方法，该方法内部会调用performLaunchActivity()方法去创建一个Activity实例，然后回调Activity的onCreate()等方法。所以Activity的ContextImpl实例化是在ActivityThread类的performLaunchActivity方法中，如下：

private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {

…

//已经创建好新的activity实例

if (activity != null) {

//创建一个Context对象

Context appContext = createBaseContextForActivity(r, activity);

…

//将上面创建的appContext传入到activity的attach方法

activity.attach(appContext, this, getInstrumentation(), r.token,

r.ident, app, r.intent, r.activityInfo, title, r.parent,

r.embeddedID, r.lastNonConfigurationInstances, config,

r.referrer, r.voiceInteractor);

…

}

…

return activity;

}

看见上面performLaunchActivity的核心代码了吗？通过createBaseContextForActivity(r, activity);创建appContext，然后通过activity.attach设置值。

具体我们先看下createBaseContextForActivity方法源码，如下：

private Context createBaseContextForActivity(ActivityClientRecord r,

final Activity activity) {

//实质就是new一个ContextImpl对象，调运ContextImpl的有参构造初始化一些参数

ContextImpl appContext = ContextImpl.createActivityContext(this, r.packageInfo, r.token);

//特别特别留意这里！！！

//ContextImpl中有一个Context的成员叫mOuterContext，通过这条语句就可将当前新Activity对象赋值到创建的ContextImpl的成员mOuterContext（也就是让ContextImpl内部持有Activity）。

appContext.setOuterContext(activity);

//创建返回值并且赋值

Context baseContext = appContext;

…

//返回ContextImpl对象

return baseContext;

}

再来看看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, String referrer, IVoiceInteractor voiceInteractor) {

//特别特别留意这里！！！

//与上面createBaseContextForActivity方法中setOuterContext语句类似，不同的在于：

//通过ContextThemeWrapper类的attachBaseContext方法，将createBaseContextForActivity中实例化的ContextImpl对象传入到ContextWrapper类的mBase变量，这样ContextWrapper（Context子类）类的成员mBase就被实例化为Context的实现类ContextImpl

attachBaseContext(context);

…

}

通过上面Activity的Context实例化分析再结合上面Context继承关系可以看出：

Activity通过ContextWrapper的成员mBase来引用了一个ContextImpl对象，这样，Activity组件以后就可以通过这个ContextImpl对象来执行一些具体的操作（启动Service等）；同时ContextImpl类又通过自己的成员mOuterContext引用了与它关联的Activity，这样ContextImpl类也可以操作Activity。

SO，由此说明一个Activity就有一个Context，而且生命周期和Activity类相同（记住这句话，写应用就可以避免一些低级的内存泄漏问题）。

3-2 Service中ContextImpl实例化源码分析

写APP时我们通过startService或者bindService方法创建一个新Service时就会回调ActivityThread类的handleCreateService()方法完成相关数据操作（具体关于ActivityThread调运handleCreateService时机等细节分析与上面Activity雷同，后边文章会做分析）。具体handleCreateService方法代码如下：

private void handleCreateService(CreateServiceData data) {

…

//类似上面Activity的创建，这里创建service对象实例

Service service = null;

try {

java.lang.ClassLoader cl = packageInfo.getClassLoader();

service = (Service) cl.loadClass(data.info.name).newInstance();

} catch (Exception e) {

…

}

try {

…

//不做过多解释，创建一个Context对象

ContextImpl context = ContextImpl.createAppContext(this, packageInfo);

//特别特别留意这里！！！

//ContextImpl中有一个Context的成员叫mOuterContext，通过这条语句就可将当前新Service对象赋值到创建的ContextImpl的成员mOuterContext（也就是让ContextImpl内部持有Service）。

context.setOuterContext(service);

Application app = packageInfo.makeApplication(false, mInstrumentation);

//将上面创建的context传入到service的attach方法

service.attach(context, this, data.info.name, data.token, app,

ActivityManagerNative.getDefault());

service.onCreate();

…

} catch (Exception e) {

…

}

再来看看service.attach，也就是Service中的attach方法，如下：

public final void attach(

Context context,

ActivityThread thread, String className, IBinder token,

Application application, Object activityManager) {

//特别特别留意这里！！！

//与上面handleCreateService方法中setOuterContext语句类似，不同的在于：

//通过ContextWrapper类的attachBaseContext方法，将handleCreateService中实例化的ContextImpl对象传入到ContextWrapper类的mBase变量，这样ContextWrapper（Context子类）类的成员mBase就被实例化为Context的实现类ContextImpl

attachBaseContext(context);

…

}

可以看出步骤流程和Activity的类似，只是实现细节略有不同而已。

SO，由此说明一个Service就有一个Context，而且生命周期和Service类相同（记住这句话，写应用就可以避免一些低级的内存泄漏问题）。

3-3 Application中ContextImpl实例化源码分析

当我们写好一个APP以后每次重新启动时都会首先创建Application对象（每个APP都有一个唯一的全局Application对象，与整个APP的生命周期相同）。创建Application的过程也在ActivityThread类的handleBindApplication()方法完成相关数据操作（具体关于ActivityThread调运handleBindApplication时机等细节分析与上面Activity雷同，后边文章会做分析）。而ContextImpl的创建是在该方法中调运LoadedApk类的makeApplication方法中实现，LoadedApk类的makeApplication()方法中源代码如下：

public Application makeApplication(boolean forceDefaultAppClass,

Instrumentation instrumentation) {

//只有新创建的APP才会走if代码块之后的剩余逻辑

if (mApplication != null) {

return mApplication;

}

//即将创建的Application对象

Application app = null;

String appClass = mApplicationInfo.className;

if (forceDefaultAppClass || (appClass == null)) {

appClass = “android.app.Application”;

}

try {

java.lang.ClassLoader cl = getClassLoader();

if (!mPackageName.equals(“android”)) {

initializeJavaContextClassLoader();

}

//不做过多解释，创建一个Context对象

ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);

//将Context传入Instrumentation类的newApplication方法

app = mActivityThread.mInstrumentation.newApplication(

cl, appClass, appContext);

//特别特别留意这里！！！

//ContextImpl中有一个Context的成员叫mOuterContext，通过这条语句就可将当前新Application对象赋值到创建的ContextImpl的成员mOuterContext（也就是让ContextImpl内部持有Application）。

appContext.setOuterContext(app);

} catch (Exception e) {

…

}

…

return app;

}

接着看看Instrumentation.newApplication方法。如下源码：

public Application newApplication(ClassLoader cl, String className, Context context)

throws InstantiationException, IllegalAccessException,

ClassNotFoundException {

return newApplication(cl.loadClass(className), context);

}

继续看重载两个参数的newApplication方法，如下：

static public Application newApplication(Class<?> clazz, Context context)

throws InstantiationException, IllegalAccessException,

ClassNotFoundException {

…

//继续传递context

app.attach(context);

return app;

}

继续看下Application类的attach方法，如下：

final void attach(Context context) {

//特别特别留意这里！！！

//与上面makeApplication方法中setOuterContext语句类似，不同的在于：

//通过ContextWrapper类的attachBaseContext方法，将makeApplication中实例化的ContextImpl对象传入到ContextWrapper类的mBase变量，这样ContextWrapper（Context子类）类的成员mBase就被实例化为Application的实现类ContextImpl

attachBaseContext(context);

…

}

可以看出步骤流程和Activity的类似，只是实现细节略有不同而已。

SO，由此说明一个Application就有一个Context，而且生命周期和Application类相同（然而一个App只有一个Application，而且与应用生命周期相同）。

4 应用程序APP各种Context访问资源的唯一性分析

你可能会有疑问，这么多Context都是不同实例，那么我们平时写App时通过context.getResources得到资源是不是就不是同一份呢？下面我们从源码来分析下，如下：

class ContextImpl extends Context {

…

private final ResourcesManager mResourcesManager;

private final Resources mResources;

…