android的安装包是个apk文件，其中包含dex、资源及签名文件。其中dex是包含程序运行的类代码，而android是运行在dalvik(5.0之前)上的。本篇我们就来看下dalvik是如何把dex载入并运行的。
先看整体脉络(重点照顾解析步骤，优化自行查找资料)：
android在安装apk时会验证dex文件是否符合规范，并优化dex生成odex；接着会将odex文件解析成易于被dalvik加载和执行的dexFile结构体。下面我们就跟随源码看下dex的心路历程吧。
apk的安装在java层由Installer类执行，但最终通过socket由C层的installd来实现。dex的优化是由installd的do_dexopt函数调用dexopt来完成操作。dex优化后生成odex后就要被拉去解析啦。odex解析成dexFile结构体后，类加载器可以通过该结构体实现对Dex文件中各类数据的查找和获取(由此可知，dexFile和dex文件有对应关系)。看解析流程：
ok，得到dexFile，至此类加载器的索引文件得到了。在dalvik代码执行中2个数据结构很重要：ClassObject、Method。总所周知java是面向对象的语言，代码是组合在类中的。故虚拟机的加载机制可以通过按代码执行流程来逐渐加载相关类(apk加壳方案？)；类加载通过类描述符在dexFile(所以它叫dex在内存中的描述)结构体得到其在dex文件的地址，并对其解析和加载：
执行流程：
上面表述了类加载流程，其实质在是在内存中得到类的ClassObejct ！其实这也是FindClass函数(FindClass还是调用findClassNoInit)需要去做的流程。所以说类加载和findclass都只是为了在dalvik中得到该类的ClasssObject。类说完了，但dalvik是执行代码，我怎么执行你的类方法呢？记得上面说的Method结构(ClassObject结构里指向它的指针，ClassObject里当然包括方法咯)，它才是dalvik的执行单元，ClassObject只是描述，类似于odex和dexFile吧。具体可以看：android dalvik浅析一：解释器及其执行
void dvmCallMethodV(Thread* self, const Method* method, Object* obj, bool fromJni, JValue* pResult, va_list args)
下面我们来看下在dalvik在加载过程中使用到的数据结构(Method、ClassObject的结构体见源码Object.h)：
Method: java方法在dalvik中的结构体，是dalvik的执行单位；拥有指向ClassObject的指针
ClassObject: java类在dalvik中的结构体，包含多个Method结构；拥有指向DvmDex的指针；拥有指向加载该类的ClassLoader指针
DvmDex: 拥有指向dexFile的指针
dexFile: dex在dalvik的描述结构
一目了然，我们可以通过Method追踪到odex文件。
ClassLoader：
android的类加载分析了，但在android其实存在2类ClassLoader。在分析之前先看Android系统下的动态Dex加载这篇文章，ContextClassLoader就是PathClassLoader(有个重要的概念:一种向上传递，向下分发的机制,理解下)。看android开发手册就一目了然：http://developer.android.com/reference/dalvik/system/BaseDexClassLoader.html
类DexClassLoader、PathClassLoader都属于符合双亲委派模型的类加载器且继承至BaseDexClassLoader。接下来就看看这2个类各自承担的责任：
看到咯是用来系统类和app类的加载(即组件)。
通常情若没有指定ClassLoader，loadAPK的ClassLoader就是PathClassLoader。这里再加深下ClassLoader的parent概念，这是逻辑而不是指父类！
断断续续的有点乱，有疑问大家来交流。
注：有些概念不清楚的话，可以看下java的ClassLoader。
资料：
1 android虚拟机解析