首先我們來看下Application的繼承關(guān)系

package android.app;
public class Application extends ContextWrapper implements ComponentCallbacks2 {
}

從這里可以看出Application繼承自ContextWrapper，所以當我們在調(diào)用Application的getApplicationContext時，實際上調(diào)用的是ContextWapper的getApplicationContext

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

那這個mBase.getApplicationContext()獲取的是啥？因為mBase是個接口，它的實現(xiàn)類是ContextImpl，所以我們來具體看看mBase.getApplicationContext()的實現(xiàn)

package android.app;
class ContextImpl extends Context {
    final @NonNull LoadedApk mPackageInfo;
    @Override
    public Context getApplicationContext() {
        return (mPackageInfo != null) ? mPackageInfo.getApplication() : mMainThread.getApplication();
    }
}

看到這里疑問又來了，這完全是俄羅斯套娃??！mPackageInfo.getApplication()獲取的又是啥？

package android.app;
public final class LoadedApk {
    private Application mApplication;
    Application getApplication() {
        return mApplication;
    }
}

搜嘎，原來getApplicationContext()獲取到的就是Application??！

休息會兒讓我喝口水歇歇......

上面講到getApplicationContext()獲取到的就是Application的，那為啥在attachBaseContext方法中獲取getApplicationContext()為空呢？嘿嘿，我也想問......

接下來我們繼續(xù)來分析看看attachBaseContext是在什么時候調(diào)用的

package android.app;
public class Application extends ContextWrapper implements ComponentCallbacks2 {
    public LoadedApk mLoadedApk;
    final void attach(Context context) {
        attachBaseContext(context);
        mLoadedApk = ContextImpl.getImpl(context).mPackageInfo;
    }
}

最后根據(jù)上面一步步的分析，getApplicationContext()獲取到的就是Application對象，而Application對象是通過mPackageInfo.getApplication()獲取的，而mPackageInfo(mLoadedApk)是在attachBaseContext之后才被賦值的，所以你在attachBaseContext方法中獲取getApplicationContext()當然是null啦！?。?/p>