dex & oat & ELF & art

dex - Android平台上可执行文件的类型。
    对于Android DEX文件进行优化，需要注意的一点是DEX文件的结构是紧凑的，但是我们还是要想方设法的进行提高程序的运行速度，我们就仍然需要对DEX文件进行进一步优化。
调整所有字段的字节序（LITTLE_ENDIAN）和对齐结构中的每一个域 验证DEX文件中的所有类 对一些特定的类进行优化，对方法里的操作码进行优化 。优化后的文件大小会有所增加，应该是原Android DEX文件的1-4倍。 优化发生的时机有两个：对于预置应用，可以在系统编译后，生成优化文件，以ODEX结尾。
这样在发布时除APK文件（不包含DEX）以外，还有一个相应的Android DEX文件；对于非预置应用，包含在APK文件里的DEX文件会在运行时被优化，优化后的文件将被保存在缓存中。
每一个Android应用都运行在一个Dalvik虚拟机实例里，而每一个虚拟机实例都是一个独立的进程空间。虚拟机的线程机制，内存分配和管理，Mutex等等都是依赖底层操作系统而实现的。
所有Android应用的线程都对应一个Linux线程，虚拟机因而可以更多的依赖操作系统的线程调度和管理机制。
不同的应用在不同的进程空间里运行，加之对不同来源的应用都使用不同的Linux用户来运行，可以最大程度的保护应用的安全和独立运行。
Zygote是一个虚拟机进程，同时也是一个虚拟机实例的孵化器，每当系统要求执行一个 Android应用程序，Zygote就会FORK出一个子进程来执行该应用程序。这样做的好处显而易见：Zygote进程是在系统启动时产生的，它会完成虚拟机的初始化，库的加载，预置类库的加载和初始化等等操作，而在系统需要一个新的虚拟机实例时。
Zygote通过复制自身，最快速的提供个系统。另外，对于一些只读的系统库，所有虚拟机实例都和Zygote共享一块内存区域，大大节省了内存开销。Android应用开发和Dalvik虚拟机Android应用所使用的编程语言是Java语言，和Java SE一样，编译时使用Sun JDK将Java源程序编程成标准的Java字节码文件（.class文件）。
而后通过工具软件DX把所有的字节码文件转成Android DEX文件（classes.dex）。最后使用Android打包工具（aapt）将DEX文件，资源文件以及AndroidManifest.xml文件（二进制格式）组合成一个应用程序包（APK）。应用程序包可以被发布到手机上运行。

-- 来自百度百科
链接：http://blog.csdn.net/kakaxi1o1/article/details/46867539

oat:
OAT文件是一种Android私有ELF文件格式，它不仅包含有从DEX文件翻译而来的本地机器指令，还包含有原来的DEX文件内容。APK在安装的过程中，会通过dex2oat工具生成一个OAT文件。这使得我们无需重新编译原有的APK就可以让它正常地在ART里面运行，也就是我们不需要改变原来的APK编程接口。oat 文件在 /data/dalvik-cache/*@classes.dex。

ELF
  elf是一种文件格式，用于存储Linux程序. 它内部都有一些什么信息呢？大概包括编制好的计算机指令，数据，计算机在需要的时候把这个文件读取到内存中，cpu就可以从内存中一条一条的读取指令来执行了。
-- elf格式分析  http://blog.csdn.net/hhhbbb/article/details/6855004
https://en.wikipedia.org/wiki/Executable_and_Linkable_Format


ART
Kitkat最令人兴奋、却也最少见诸报端的特性之一就是ART，这个处于试验阶段的最新运行时。Google并没有发布太多有关ART的信息（http://goo.gl/9Jzgdo），尽管事实上它已经出现了。然而，我觉得这个特性可能对未来的发布产生巨大的影响，因为有了ART后Android将不再理会执行过的dalvik字节码，转而使用一种平台特有的、提前编译（AOT，ahead-of-time）二进制码。

Dalvik虚拟机遵循传统Java虚拟机的运行方式：源码编译成平台无关的字节码，随后字节码立即编译成机器码（JIT-Just in time编译）。ART使用了另一种实现方式：它使用AOT范例将代码编译成前期执行的本地代码。但是，这是如何实现的呢？

鉴于在Android市场上基于当前三大不同的体系结构（MIPS，x86，ARM）催生了多种多样的平台，应用程序之间相互可移植性（inter-portability）变得十分重要。他们不得不找到一种方式整合两个世界：互相可移植性和执行本地二进制代码。就目前所知，他们的解决方案在移动领域是独一无二的：将中间字节码装运成可执行代码，然后在目标设备上执行最后的编译步骤——“提前编译”。

对ART进一步的观察显示：他们在最后的编译步骤中使用了LLVM。这种对本地代码的编译处理过程在安装应用时可以流畅地完成。

除此之外，Android小组还面临着一个额外的挑战：兼容业已存在的Dalvik虚拟机/DEX技术。为了处理这个问题，他们引入了一种把dex格式转变成新的oat格式的方法。

-- http://www.importnew.com/8822.html
http://blog.csdn.net/luoshengyang/article/details/39307813
http://blog.csdn.net/luoshengyang/article/details/39256813
http://blog.csdn.net/zylc369/article/details/39452053
http://blog.csdn.net/cosmoslhf/article/details/40380559