Android ART介紹

1、ART之是以會比Dalvik快，是因為ART執行的是本地機器指令，而Dalvik執行的是Dex位元組碼，通過通過解釋器執行。盡管Dalvik也會對頻繁執行的代碼進行JIT生成本地機器指令來執行，但畢竟在應用程式運作的過程中将Dex位元組碼翻譯成本地機器機器指令也會影響到應用程式本身的執行，是以即使Dalvik使用了JIT，也在一定程度上也比不上直接就可以執行本地機器指令的運作時。

Zygote程序在啟動的過程中，正是通過圖1所示的接口建立Dalvik或者ART虛拟機的，這樣看來，ART雖然執行的本地機器指令，但是它表面看來，又是一個不折不扣的虛拟機。也正是因為這樣，ART才可以在不重新編譯APK的基礎上，直接可以加載和運作APK。這也是ART運作時可以無縫替換Dalvik運作時的原理。是以，我們就可以得出一個結論：ART是一個執行本地機器指令的虛拟機。這個結論似乎有點沖突，既然是執行本地機器指令，為什麼又稱為虛拟機呢？從接下來的文章分析可以知道，ART除了實作Java虛拟機接口之外，其内部還有垃圾收集機制，同時還有Java核心類庫調用。

 上面提到，ART才可以在不重新編譯APK的基礎上，直接對其進行加載和運作，這是由于APK在安裝時被執行了AOT。AOT（Ahead Of Time）是相對JIT（Just In Time）而言的。也就是在APK運作之前，就對其包含的Dex位元組碼進行翻譯，得到對應的本地機器指令，于是就可以在運作時直接執行了。這種技術不但使得我們可以不對原有的APK作任何修改，還可以使得這些APK隻需要在安裝時翻譯一次，就可以無數次以本地機器指令的形式運作。這種技術與我們用C/C++語言編寫一個程式，然後用GCC編譯得到一個可執行程式，最後這個可執行程式就可以無數次地加載到系統執行，是差不多的。

  在ART中，打包在APK裡面的Dex位元組碼是通過LLVM翻譯成本地機器指令的。LLVM是一個用來快速開發自己的編譯器的架構系統，

如果我們沒有忘記，在Dalvik運作時中，APK在安裝的時候，安裝服務PackageManagerService會通過守護程序installd調用一個工具dexopt對打包在APK裡面包含有Dex位元組碼的classes.dex進行優化，優化得到的檔案儲存在/data/dalvik-cache目錄中，并且以.odex為字尾名，表示這是一個優化過的Dex檔案。在ART運作時中，APK在安裝的時候，同樣安裝服務PackageManagerService會通過守護程序installd調用另外一個工具dex2oat對打包在APK裡面包含有Dex位元組碼進翻譯。這個翻譯器實際上就是基于LLVM架構實作的一個編譯器，它的前端是一個Dex文法分析器。翻譯後得到的是一個ELF格式的oat檔案，這個oat檔案同樣是以.odex字尾結束，并且也是儲存在/data/dalvik-cache目錄中。

ART的運作原理都簡要地介紹了，總結如下：

  1. 在Android系統啟動過程中建立的Zygote程序利用ART運作時導出的Java虛拟機接口建立ART虛拟機。

   2. APK在安裝的時候，打包在裡面的classes.dex檔案會被工具dex2oat翻譯成本地機器指令，最終得到一個ELF格式的oat檔案。

    3. APK運作時，上述生成的oat檔案會被加載到記憶體中，并且ART虛拟機可以通過裡面的oatdata和oatexec段找到任意一個類的方法對應的本地機器指令來執行。

摘至：http://blog.csdn.net/luoshengyang/article/details/39256813