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查看。
这二者的不同特点在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系统版本，查看源码。
参考：http://blog.csdn.net/jiangwei0910410003/article/details/17679823
