先来个总结
java源码经过编译后，得到很多个class文件， 考虑到手机的内存较小，google改进了字节码的组织形式，将一个app中的所有class文件合到了一起构成dex文件，当然并不是简单的拼接在一起，而是遵从dex的格式重新组织。
dex文件最终会和资源文件等一起打包成为apk，签名后安装到手机上。
PackageManager在安装apk的时候，做了一件事：优化dex文件为odex，存放在/data/dalvik-cache目录下。
dex文件是遵从于dalvik虚拟机标准的文件，它具有跨dalvik虚拟机的特点，而odex是在特定dalvik虚拟机上优化得到的，通常不能跨dalvik虚拟机运行。
程序执行体现在方法的执行上，因为我们重点关注下方法的组织形式。
在dex文件中，方法体里面的内容最终存储在classData区域，方法体里面存储的是二进制的字节码。
在说字节码之前，先来说说什么是dalvik虚拟机，dalvik虚拟机说白了就是用c/c++写的一套复杂的程序，它定义了一堆的smali指令（256个），这些字节码指令高度抽象，组合这些指令可以完成我们想要的功能。你可以等同于汇编指令理解，但它们在语言级别要高于汇编（在虚拟机里面执行的，虚拟机又是c/c++写的，自然看出高于汇编）。
字节码是用简单的二进制数字表示的，与可阅读的smali指令存在对应关系，具体对应方法参考google的官方文档：
http://source.android.com/devices/tech/dalvik/instruction-formats.htmlhttp://source.android.com/devices/tech/dalvik/dalvik-bytecode.html
虚拟机又是如何执行这些字节码的呢？
答案在AOSP中（开源就是好），原来虚拟机对于每一个字节码，都写了一段代码来解释执行（你可以等价理解为API调用一样，调用某个API，后面一堆逻辑来实现这个API），只是不同cpu结构，实现方式不一样，比如arm使用了arm汇编来实现，x86使用了x86的汇编来实现，google提供了一个c/c++的实现方式来兼容一些未知的cpu结构，见：
https://android.googlesource.com/platform/dalvik2/+/master/vm/mterp/out/InterpC-portable.cpp
虚拟机在加载了odex（虚拟机总是使用odex文件，第一次使用时会先生成odex）, 会将整个odex文件的内容mmap到内存中，之后就和odex文件没有关系了。
虚拟机在加载了odex（虚拟机总是使用odex文件，第一次使用时会先生成odex）, 会将整个odex文件的内容mmap到内存中，之后就和odex文件没有关系了。
虚拟机在load一个Class的时候（参见DexClassLoader源码），根据类的描述符，在内存中的odex区域，查询到对应的数据，构建出ClassObject对象，以及这个ClassObject关联的Method。
Method分为两种，dalvik虚拟机在处理的时候有区别，一种是directMethod，即Java世界里面实现的方法，一种是nativeMethod，即在c/c++里面实现的方法。
一些apk加固厂商就是在这块做的手脚，这里衍生开来说一下：
梆梆加固的实现方式为：将原始dex中的内容加密处理，在app运行时，解密出dex，mmap到内存，还原了内存结构。
爱加密的方法则是，将方法体里面的字节码从dex中抠出来，加密到了自己的so中，在app运行时，从so中解密出方法体，然后修改mmap对应的内存，还原内存结构。
这些加固方法说白了就是将原始dex做加固处理，在运行时还原内存结构。所以光从静态分析反编译加固后的dex文件，将得不到有用信息。
但有一个基于xposed的zjdroid脱壳工具，可以在运行时dump出内存（odex结构的内存），保存为本地odex文件，再利用smali/baksmali还原出原始dex文件。
Xposed hook原理
在Android系统中，应用程序进程都是由Zygote进程孵化出来的，而Zygote进程是由Init进程启动的。Zygote进程在启动时会创建一个Dalvik虚拟机实例，每当它孵化一个新的应用程序进程时，都会将这个Dalvik虚拟机实例复制到新的应用程序进程里面去，从而使得每一个应用程序进程都有一个独立的Dalvik虚拟机实例。这也是Xposed选择替换app_process的原因。
Zygote进程在启动的过程中，除了会创建一个Dalvik虚拟机实例之外，还会将Java运行时库加载到进程中来，以及注册一些Android核心类的JNI方法来前面创建的Dalvik虚拟机实例中去。注意，一个应用程序进程被Zygote进程孵化出来的时候，不仅会获得Zygote进程中的Dalvik虚拟机实例拷贝，还会与Zygote一起共享Java运行时库。这也就是可以将XposedBridge这个jar包加载到每一个Android应用程序中的原因。XposedBridge有一个私有的Native（JNI）方法hookMethodNative，这个方法也在app_process中使用。这个函数提供一个方法对象利用Java的Reflection机制来对内置方法覆写。具体的实现可以看下文的Xposed源代码分析。
Xposed 框架中真正起作用的是对方法的hook。在Repackage技术中，如果要对APK做修改，则需要修改Smali代码中的指令。而另一种动态修改指令的技术需要在程序运行时基于匹配搜索来替换smali代码，但因为方法声明的多样性与复杂性，这种方法也比较复杂。
在Android系统启动的时候，zygote进程加载XposedBridge将所有需要替换的Method通过JNI方法hookMethodNative指向Native方法xposedCallHandler，xposedCallHandler在转入handleHookedMethod这个Java方法执行用户规定的Hook Func。
XposedBridge这个jar包含有一个私有的本地方法：hookMethodNative，该方法在附加的app_process程序中也得到了实现。它将一个方法对象作为输入参数（你可以使用Java的反射机制来获取这个方法）并且改变Dalvik虚拟机中对于该方法的定义。它将该方法的类型改变为native并且将这个方法的实现链接到它的本地的通用类的方法。换言之，当调用那个被hook的方法时候，通用的类方法会被调用而不会对调用者有任何的影响。在hookMethodNative的实现中，会调用XposedBridge中的handleHookedMethod这个方法来传递参数。handleHookedMethod这个方法类似于一个统一调度的Dispatch例程，其对应的底层的C++函数是xposedCallHandler。而handleHookedMethod实现里面会根据一个全局结构hookedMethodCallbacks来选择相应的hook函数，并调用他们的before, after函数。
有前面这些知识后，再理解Xposed的hook原理就不难了。
前面已经知道，一个java方法在虚拟机里面对应的Method为directMethod，其insns指向了字节码位置。
Xposed在对java方法进行hook时，先将虚拟机里面这个方法的Method改为nativeMethod(其实就是一个标识字段)，然后将该方法的nativeFunc指向自己实现的一个native方法，这样方法在调用时，就会调用到这个native方法，接管了控制权。
在这个native方法中，xposed直接调用了一个java方法，这个java方法里面对原方法进行了调用，并在调用前后插入了钩子，于是就hook住了这个方法。
Xposed的hook原理就是这么简单，但它有其他的问题要解决：如何将hook的代码注入到目标app的进程中？
Xposed的实现是依赖与root，重写android的zygote代码，加入自身的加载逻辑。zygote是android 系统最最初运行的程序，之后的进程都是通过它fork（你把它理解为复制吧）出来的。 于是zygote中加载的代码，在所有fork出来的子进程都含有（app进程也是fork出来的）。 所以xposed是一个可以hook android系统中任意一个java方法的 hook框架。
而淘宝根据xposed改造出来的dexposed，仅仅是注入hook代码的方式不同而已，hook逻辑完全一致。
dexposed不依赖与root，但需要开发者主动集成进来（我们集合了别人的广告sdk，其实也是让别人的程序跑到我们的进程里面，所以得小心点，给我一个入口，我也能hook住你的任何方法）。所以其hok的范围仅仅是被集成的应用（对于淘宝的AOP框架定义，这个效果刚刚好）
