源码分析 getApplication和getApplicati
本文打算从原理出发，通过分析源码，找到Activity的成员变量Application的出处，以此分析俩个方法的区别。
背景知识
Context关系图.png
首先上一张老生常谈的图。
由图的继承关系可知，Activity、Application、Service都继承自ContextWrapper；
ContextWrapper是个代理类，它的部分源码截图如下：
public class ContextWrapper extends Context {
Context mBase;
public ContextWrapper(Context base) {
mBase = base;
}
protected void attachBaseContext(Context base) {
if (mBase != null) {
throw new IllegalStateException("Base context already set");
}
mBase = base;
}
public Context getBaseContext() {
return mBase;
}
@Override
public AssetManager getAssets() {
return mBase.getAssets();
}
@Override
public Resources getResources() {
return mBase.getResources();
}
...
}
从源码可以看出，ContextWrapper的方法都是通过代理"另一个"Context实现的。这里暂时给出结论：这个代理类就是ContextImpl，它是Context的真正实现类。稍后我们会用源码验证结论。
也就是说，Activity内部有成员变量ContextImpl的实例，以此实现我们常用的Context的方法。
源码分析
了解了上述背景知识之后，下面来正式开始分析Activity的方法：getApplication()和getApplicationContext()的区别。
getApplication
我们先来看getApplication()的源码：
public final Application getApplication() {
return mApplication;
}
Activity内部有成员变量mApplication，getApplication()直接返回的就是它，那么它的来源是哪呢？
这里为了使流程更加清晰，我将从源码源头分析，正推出结果，实际学习则是通过结果逆向反推出源头的。
ActivityThread是Activity的启动类，通过调用ActivityThread.performLaunchActivity()，即可生成要启动的Activity实例，本文不会专程去分析应用程序或Activity的启动原理，只需要知道它是Activity实例的创建方法就可以了。下面我们来看下这个方法的部分源码：
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
ActivityInfo aInfo = r.activityInfo;
...
ContextImpl appContext = createBaseContextForActivity(r);
Activity activity = null;
try {
java.lang.ClassLoader cl = appContext.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
...
} catch (Exception e) {
...
}
try {
Application app = r.packageInfo.makeApplication(false, mInstrumentation); #1
...
if (activity != null) {
...
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, window, r.configCallback);#2
...
注释1处，调用r.packageInfo.makeApplication生成了Application实例；注释2处，调用activity.attch，将Application传给了Activity。来看下``
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,
Window window, ActivityConfigCallback activityConfigCallback) {
attachBaseContext(context);
...
mApplication = application; #1
注释1处，直接将application赋值给了mApplication，看来这就是我们要找的源头。
回到上一步，r.packageInfo.makeApplication生成了Application实例，这里，r.packageInfo实际是LoadedApk对象，故名思义，它通过ClassLoader去加载APK文件，以此来获取我们需要的类。不明白ClassLoader可以稍微去了解下，不了解也没关系，只需要知道通过ClassLoader可以将类文件转化为类就可以了。
下面来看LoadedApk.makeApplication()源码：
public Application makeApplication(boolean forceDefaultAppClass,
Instrumentation instrumentation) {
if (mApplication != null) {
return mApplication;
}
...
Application app = null;
String appClass = mApplicationInfo.className;
if (forceDefaultAppClass || (appClass == null)) {
appClass = "android.app.Application";
}#1
try {
java.lang.ClassLoader cl = getClassLoader(); #2
...
ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this); #3
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);#4
...
} catch (Exception e) {
...
}
...
mApplication = app;
...
return app;
}
这里为了理清流程，省略了部分无关主题的代码。
注释1处，获取要创建的Application的ClassName，如果没有自定义的Application，则使用系统原生"android.app.Application"；
注释2处，获取ClassLoader，它可以通过ClassName获取需要的Class。
注释3处，获取ContextImpl，上文说过Application继承自ContextWrapper，它仅仅是Context的代理，真正的实现类是ContextImpl。这一结论很快将得到证实。
在得到必要的三个参数之后，就可以创建Application了，注释4处执行了创建Application的方法：
public Application newApplication(ClassLoader cl, String className, Context context)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
return newApplication(cl.loadClass(className), context);
}
通过ClassLoader和ClassName，获取到Class<Application>实例，然后执行下一步：
static public Application newApplication(Class<?> clazz, Context context)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
Application app = (Application)clazz.newInstance(); #1
app.attach(context); #2
return app;
}
注释1处，通过class反射创建了Application实例。这就是getApplication()的最终源头。
但是还没有完，注释2处调用了app.attach(context);，联系上下文可以知道这个context就是之前创建的ContextImpl，而attach最终调用的是ContextWrapper.attachBaseContext，还记得文章开头的ContextWrapper源码吗？找一下这个方法，你就会发现，Application作为ContextWrapper，其真实调用的Context就是这里传过来的ContextImpl！
讲到这里，我们已经找到了getApplication()的源头。同时也会发现：ContextImpl从始至终都没有与getApplication()有任何关联，那为什么还要大费周章的讲它呢？别急，还有一个方法getApplicationContext()没说呢。
getApplicationContext
先来看一下Activity.getApplicationContext()源码，该方法是Activity的父类：ContextWrapper实现的。
@Override
public Context getApplicationContext() {
return mBase.getApplicationContext();
}
通过上文可知，mBase即是ContextImpl（但是注意不是上文Application的ContextImpl，下文会有分析），来看下ContextImpl.getApplicationContext()的源码：
@Override
public Context getApplicationContext() {
return (mPackageInfo != null) ?
mPackageInfo.getApplication() : mMainThread.getApplication();
}
mPackageInfo就是LoadedApk实例，ContextImpl.LoadedApk.getApplication()直接返回了LoadedApk的成员变量mApplication。从这里还无从得知mApplication的来源，所以我们可以先分析ContextImpl实例的来源。
回到上文中Activity实例的创建方法performLaunchActivity：
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
ActivityInfo aInfo = r.activityInfo;
...
ContextImpl appContext = createBaseContextForActivity(r); #1
Activity activity = null;
try {
java.lang.ClassLoader cl = appContext.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
...
} catch (Exception e) {
...
}
try {
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
...
if (activity != null) {
...
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, window, r.configCallback);#2
...
注释1处，创建了ContextImpl实例。
注释2处，调用了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,
Window window, ActivityConfigCallback activityConfigCallback) {
attachBaseContext(context); #1
...
mApplication = application;
注释1处，ContextImpl被赋值给了Activity，看来这就是ContextImpl的最初源头。
回到上一步注释1处，来看下ContextImpl实例的创建过程createBaseContextForActivity(r)：
private ContextImpl createBaseContextForActivity(ActivityClientRecord r) {
...
ContextImpl appContext = ContextImpl.createActivityContext(
this, r.packageInfo, r.activityInfo, r.token, displayId, r.overrideConfig);
...
return appContext;
}
第二个参数r.packageInfo就是LoadedApk对象，它在这里赋值给了ContextImpl。联系上下文，也就是说，getApplicationContext()的application，就来自r.packageInfo的成员变量mApplication。
那么，r.packageInfo的成员变量mApplication，又是什么时候赋值的呢？
还记得上文Application是怎么创建的吗？
r.packageInfo.makeApplication(false, mInstrumentation);
再来回顾一遍LoadedApk.makeApplication源码，这次只需要关注注释1处：
public Application makeApplication(boolean forceDefaultAppClass,
Instrumentation instrumentation) {
if (mApplication != null) {
return mApplication;
}
...
Application app = null;
String appClass = mApplicationInfo.className;
if (forceDefaultAppClass || (appClass == null)) {
appClass = "android.app.Application";
}
try {
java.lang.ClassLoader cl = getClassLoader();
...
ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);
...
} catch (Exception e) {
...
}
...
mApplication = app; #1
...
return app;
}
在上文中创建的Application，在赋值给Activity的成员变量mApplication的同时，还赋值给了LoadedApk的mApplication，之后LoadedApk又作为了ContextImpl的成员变量之一传给了Activity。
至此得知，对于Activity而言，getApplication()和getApplicationContext()返回的是同一个Application，它们都是LoadedApk通过ClassLoader创建的，只不过赋值给了不同的成员变量而已。
流程图
下面梳理下它们的创建与赋值流程。
getApplication
getApplication流程图.png
getApplicationContext
getApplicationContext流程图.png
由流程图可以看出，Application的来源均是LoadedApk.makeApplication()，故俩个方法返回的是同一个Application。
写在最后
分析俩个方法的区别，旨在理清Android的启动流程，加深对Android系统的理解，重在过程，而非结论。
