public ClassLoader getClassLoader() {
        return mPackageInfo != null ?
                mPackageInfo.getClassLoader() : ClassLoader.getSystemClassLoader();
}

我们看到如果mPackageInfo不为null，就调用它的getClassLoader()方法，否则调用ClassLoader.getSystemClassLoader()，这里我们看到了ClassLoader的getSystemClassLoader()方法，但是这里还不是重点，重点是mPackageInfo这个对象，这是什么呢，它是一个LoadedAPK对象。它又是什么呢？

Local state maintained about a currently loaded .apk.

LoaderAPK对象是apk在内存中的表示。通过这个LoaderApk对象可以拿到apk中代码和资源，甚至里面Activity和Service等信息。

public final LoadedApk getPackageInfoNoCheck(ApplicationInfo ai,
        CompatibilityInfo compatInfo) {
    return getPackageInfo(ai, compatInfo, null, false, true, false);
}

private LoadedApk getPackageInfo(ApplicationInfo aInfo, CompatibilityInfo compatInfo,
        ClassLoader baseLoader, boolean securityViolation, boolean includeCode,
        boolean registerPackage) {
        // 获取userid信息
    final boolean differentUser = (UserHandle.myUserId() != UserHandle.getUserId(aInfo.uid));
    synchronized (mResourcesManager) {
    // 尝试获取缓存信息
        WeakReference<LoadedApk> ref;
        if (differentUser) {
            // Caching not supported across users
            ref = null;
        } else if (includeCode) {
            ref = mPackages.get(aInfo.packageName);
        } else {
            ref = mResourcePackages.get(aInfo.packageName);
        }

        LoadedApk packageInfo = ref != null ? ref.get() : null;
        if (packageInfo == null || (packageInfo.mResources != null
                && !packageInfo.mResources.getAssets().isUpToDate())) {
                // 缓存没有命中，直接new
            packageInfo =
                new LoadedApk(this, aInfo, compatInfo, baseLoader,
                        securityViolation, includeCode &&
                        (aInfo.flags&ApplicationInfo.FLAG_HAS_CODE) != 0, registerPackage);

        // 省略。。更新缓存
        return packageInfo;
    }
}

下面看上面使用到的LoadedApk的构造函数，其实LoadedApk还有一个构造函数，在ContextImpl创建自己的实例的同时创建其LoadedApk的成员变量的时候使用了。

108    public LoadedApk(ActivityThread activityThread, ApplicationInfo aInfo,
109            CompatibilityInfo compatInfo,
110            ActivityThread mainThread, ClassLoader baseLoader,
111            boolean securityViolation, boolean includeCode) {
<span style="white-space:pre">	</span>   .......(省略)
126
127        if (mAppDir == null) {
128            if (ActivityThread.mSystemContext == null) {//这个context很重要，一个ActivityThread只有这一个，是静态全局的
129                ActivityThread.mSystemContext =
130                    ContextImpl.createSystemContext(mainThread);
131                ActivityThread.mSystemContext.getResources().updateConfiguration(
132                         mainThread.getConfiguration(),
133                         mainThread.getDisplayMetricsLocked(compatInfo, false),
134                         compatInfo);
135                //Slog.i(TAG, "Created system resources "
136                //        + mSystemContext.getResources() + ": "
137                //        + mSystemContext.getResources().getConfiguration());
138            }
139            mClassLoader = ActivityThread.mSystemContext.getClassLoader();//这个ClassLoader就是最后返回的那个ClassLoader
140            mResources = ActivityThread.mSystemContext.getResources();
141        }
142    }
143

看到这里，我们只要最终这个CLassLoader的来源是从Context那里后去的，也就是ActivityThread的mSystemContext里面的ClassLoader，我们来看一下这个mSystemContext的创建过程，代码如下：

1458    static ContextImpl createSystemContext(ActivityThread mainThread) {
1459        ContextImpl context = new ContextImpl();
1460        context.init(Resources.getSystem(), mainThread);//这个init操作也没有创建他里面LoadedApk成员变量
1461        return context;
1462    }

所以最终调用的代码，就是最开始的ContextImpl的getClassLoader()方法，并且mPackageInfo（LoadedAPK对象）为null，所以最终调用的是ClassLoader.getSystemClassLoader()，所以最终结论就是系统ClassLoader是通过ClassLoader.getSystemClassLoader()创建。

其代码如下：

public static ClassLoader getSystemClassLoader() {
     return SystemClassLoader.loader;
}

static private class SystemClassLoader {
        public static ClassLoader loader = ClassLoader.createSystemClassLoader();
}

    private static ClassLoader createSystemClassLoader() {
        String classPath = System.getProperty("java.class.path", ".");
        return new PathClassLoader(classPath, BootClassLoader.getInstance());
    }

对于最有一个核心方法createSystemClassLoader(),官方说明如下：

Create the system class loader. Note this is NOT the bootstrap class
loader (which is managed by the VM). We use a null value for the parent
to indicate that the bootstrap loader is our parent.

创建系统的ClassLoader。注释：这不是bootstrap ClassLoader(被虚拟机管理的ClassLoader)。我们使用null作为我们系统ClassLoader的parent来表明bootstrap就是我们的系统ClassLoader的parent。这里也就是充分说明了Android系统不是使用的java原生的bootstrap来加载，而是使用自己的创建的套机制。取代bootstrap的是用null（bootstrap不是一个ClassLoader对象，所以他的子级ClassLoader调用getParent()返回的是null），而取代java中第二级的ClassLoader使用Android中创建的最基层的BootClassLoader（也就是上面的PathClassLoader的parent）。

这个BootClassLoader是单例的，所以全局只有一个，我们也可以得出，系统所有执行装载类的操作，都会执行到这个对象。代码如下：

public BootClassLoader() {
     super(null, true);//他的parent为null(模拟它的parent是bootstrap)
}

还有我们看到上面PathClassLoader构造函数中传递的第一个参数classPath，这个就是我们之前打印出来的dexPath。为什么系统的ClassLoader.getSystemClassLoader()返回的PathClassLoader 的dexPath指向的是当前apk的安装路径；但是我们自己创建的返回的PathClassLoader的dexPath却是.  我们发现是由上面的System.getProperty("java.class.path",".");决定的，看到get操作，相对的也就会有set操作，那么这个值是什么时候设置的呢。这我们就要追溯到Android framwork中System中的initSystemProperty()方法中，调用VMRuntime.getRuntime().classPath()的值，这个值应该就是当前apk的安装路径。

代码如下： 路径：/libcore/luni/src/main/java/java/lang/System.java（4.0.4）

private static void initSystemProperties() {
        VMRuntime runtime = VMRuntime.getRuntime();
        Properties p = new Properties();

        String projectUrl = "http://www.android.com/";
        String projectName = "The Android Project";

        p.put("java.boot.class.path", runtime.bootClassPath());
        p.put("java.class.path", runtime.classPath());
}

但是，为什么我们自己调用，获取这个值就是. 我的猜想就是 系统创建完对应的ClassLoader之后，就将这个值修改成了.（当然这仅仅是我个人的猜想，希望了解的大神能帮我解答一下，因为我实在是找不到原因，困惑好久了）。

5.总结