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