类加载器

Android有两种虚拟机，分别是Dalvik和ART。而Java有自己的虚拟机，是大家熟知的JVM。Dalvik和ART不是标准的JVM，在类加载机制上，Android和Java是有区别的。（复习扩展可点http://www.jianshu.com/p/e3abb3556e7e）

我们的apk要在设备上跑起来，首先需要将对应的类加载到设备内存中。那Android中是怎么实现的呢？

首先在Android中，ClassLoader是专门用来处理类加载工作的，被称作类加载器。我们去看源码，会发现ClassLoader是一个抽象类。实际开发过程中，我们一般是使用其具体的子类DexClassLoader、PathClassLoader这些类加载器来加载类的。它们的不同之处是：

DexClassLoader可以加载jar、apk及dex文件，可以从SD卡中加载未安装的apk，并且会在指定的outpath路径释放出dex文件。
PathClassLoader：不能主动从zip包中释放出dex，所以只支持直接操作dex格式文件，或者已经安装的apk。

多说两句。已经安装的apk会在设备data/dalvik目录中缓存的dex文件。怎么查看呢？设备用USB连上电脑，在AS中打开Android Device Monitor（不懂的自己百度），找到data/dalvik目录，就可以看到PathClassLoader加载的就是该目录下的dex文件。如果你的设备是已经Root过的，那直接可以在设备文件目录下查看，否则只能通过Device Monitor查看。

image.png

这二者的不同特点在Android系统源码中也有说明，大家可以看系统源码注释说明。英文我就不翻译了。

/**
 * A class loader that loads classes from {@code .jar} and {@code .apk} files
 * containing a {@code classes.dex} entry. This can be used to execute code not
 * installed as part of an application.
 *
 */
public class DexClassLoader extends BaseDexClassLoader {
  
    public DexClassLoader(String dexPath, String optimizedDirectory,
            String librarySearchPath, ClassLoader parent) {
        super(dexPath, new File(optimizedDirectory), librarySearchPath, parent);
    }
}

DexClassLoader的构造函数参数。
第一个参数：dex压缩文件的路径。
第二个参数：将jar、apk文件解压出的dex文件存放的目录。
第三个参数：是C/C++依赖的本地库文件目录，可以为null。
第四个参数：上一级的类加载器。在Android中以context.getClassLoader()作为父装载器。

/**
 * Provides a simple {@link ClassLoader} implementation that operates on a list
 * of files and directories in the local file system, but does not attempt to
 * load classes from the network. Android uses this class for its system class
 * loader and for its application class loader(s).
 */
public class PathClassLoader extends BaseDexClassLoader {
   
    public PathClassLoader(String dexPath, ClassLoader parent) {
        super(dexPath, null, null, parent);
    }
    public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
        super(dexPath, null, librarySearchPath, parent);
    }
}

我们已经说过了，PathClassLoader只能直接操作dex文件，所以当我们看到PathClassLoader构造函数第二个参数直接为null就很明白，PathClassLoader不像DexClassLoader 需要解压出dex文件，而是直接操作，就不用专门再将指定的outpath路径释放出dex文件。

还有一点需要强调：optimizedDirectory必须是一个内部存储路径，加载的可执行文件，即dex文件，一定要存放在内部存储。DexClassLoader可以指定自己的optimizedDirectory，所以它可以加载外部的dex，因为这个dex会被复制到内部路径的optimizedDirectory；而PathClassLoader没有optimizedDirectory，所以它只能加载内部的dex，这些大都是存在系统中已经安装过的apk里面的。

眼尖的朋友应该早发现，DexClassLoader 和PathClassLoader 的父类是BaseDexClassLoader，并不是ClassLoader。对的。不过BaseDexClassLoader也是继承自ClassLoader。DexClassLoader 和PathClassLoader 两者只是简单的对BaseDexClassLoader做了一下封装，具体的实现还是在父类里。我们先看BaseDexClassLoader的构造函数。

public BaseDexClassLoader(String dexPath, File optimizedDirectory,
            String librarySearchPath, ClassLoader parent) {

        super(parent);
        this.pathList = new DexPathList(this, dexPath, librarySearchPath, optimizedDirectory);

    }

BaseDexClassLoader的构造函数做了两件事：1、super，2、构造了一个 DexPathList 实例保存在 pathList 中。点击DexPathList 进去看看。

public DexPathList(ClassLoader definingContext, String dexPath,
            String librarySearchPath, File optimizedDirectory) {
        ...//省去一些判空等源码
        // save dexPath for BaseDexClassLoader
        this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,
                                           suppressedExceptions, definingContext);

    }

DexPathList 构造函数的第二个参数指的是优化后的 dex 存放目录。实际上，dex 其实并不能被虚拟机直接加载，它需要系统的优化工具优化后才能真正被利用。优化之后的 dex 文件我们把它叫做 odex （optimized dex，说明这是被优化后的 dex）文件。其实从 class 到 dex 也算是经历了一次优化，这种优化的是机器无关的优化，也就是说不管将来运行在什么机器上，这种优化都是遵循固定模式的，因此这种优化发生在 apk 编译。而从 dex 文件到 odex 文件，是机器相关的优化，它使得 odex 适配于特定的硬件环境，不同机器这一步的优化可能有所不同，所以这一步需要在应用安装等运行时期由机器来完成。
总而言之，BaseDexClassLoader中的pathList中包含一个DexFile的数组dexElements，dexPath传入的原始dex(.apk、.zip、.jar等)文件在optimizedDirectory文件夹中生成相应的优化后的odex文件，dexElements数组就是这些odex文件的集合，如果不分包一般这个数组只有一个Element元素，也就只有一个DexFile文件。

加载类的过程

Android中，ClassLoader用loadClass方法来加载我们需要的类。例如：

String dexPath = Environment.getExternalStorageDirectory().toString() + File.separator + "Dynamic.apk";  
String dexOutputDirs = Environment.getExternalStorageDirectory().toString(); 
DexClassLoader cl = new DexClassLoader(dexPath,dexOutputDirs,null,getClassLoader());  
Class libProviderClazz = cl.loadClass("com.dynamic.impl.Dynamic");  

那我们来看看ClassLoader类的这个loadClass方法。

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
            // First, check if the class has already been loaded
            Class c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                }
            }
            return c;
    }

从源码中我们也可以看出，loadClass方法在加载一个类的实例的时候，会先查询当前ClassLoader实例是否加载过此类，有就返回；
如果没有。查询Parent是否已经加载过此类，如果已经加载过，就直接返回Parent加载的类；
如果继承路线上的ClassLoader都没有加载，才由Child执行类的加载工作；
这种现象被称作：双亲代理模型。
这样做有个明显的特点，如果一个类被位于树根的ClassLoader加载过，那么在以后整个系统的生命周期内，这个类永远不会被重新加载。

loadClass方法调用了findClass方法，而BaseDexClassLoader重载了这个方法，得到BaseDexClassLoader看看。

@Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
        Class c = pathList.findClass(name, suppressedExceptions);
        if (c == null) {
            ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);
            for (Throwable t : suppressedExceptions) {
                cnfe.addSuppressed(t);
            }
            throw cnfe;
        }
        return c;
    }

结果还是调用了DexPathList的findClass。

public Class findClass(String name, List<Throwable> suppressed) {
        for (Element element : dexElements) {
            DexFile dex = element.dexFile;

            if (dex != null) {
                Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
                if (clazz != null) {
                    return clazz;
                }
            }
        }
        if (dexElementsSuppressedExceptions != null) {
            suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
        }
        return null;
    }

发现又调用了DexFile 的loadClassBinaryName方法。

public Class loadClassBinaryName(String name, ClassLoader loader, List<Throwable> suppressed) {
        return defineClass(name, loader, mCookie, this, suppressed);
    }

private static Class defineClass(String name, ClassLoader loader, Object cookie,
                                     DexFile dexFile, List<Throwable> suppressed) {
        Class result = null;
        try {
            result = defineClassNative(name, loader, cookie, dexFile);
        } catch (NoClassDefFoundError e) {
            if (suppressed != null) {
                suppressed.add(e);
            }
        } catch (ClassNotFoundException e) {
            if (suppressed != null) {
                suppressed.add(e);
            }
        }
        return result;
    }

private static native Class defineClassNative(String name, ClassLoader loader, Object cookie,
                                                  DexFile dexFile)
            throws ClassNotFoundException, NoClassDefFoundError;

loadClassBinaryName最终是调用了native defineClassNative方法。到此，Android的加载过程我们终于看完了。

如果大家看不到DexClassLoader 和PathClassLoader 等源码，那你需要下载Android系统源码，或者http://androidxref.com/在线选择Android系统版本，查看源码。

image.png image.png

参考：http://blog.csdn.net/jiangwei0910410003/article/details/17679823