Android中編譯工具鍊的改動----LLVM份量的增加

作者：史甯甯

-----------------------------------------------------------------------------------轉載請注明出處---------------------------------------------------------------------------------

       最近，Android中的編譯工具鍊發生了改動，這個改動是Android的runtime（也可以說是VM，這兩種說法在Google官方文檔中也多次互動出現）改動引發的。之前Android采用的是Dalvik VM，在Android2.2之前，連JIT都沒有使用，隻是解釋執行，是以速度很慢，從Android2.2之後加入了JIT之後，一直用了相當長的時間。直到ART（Android

Runtime）的出現,ART的出現也是為了進一步提高運作速度，據早期的測試結果表明，ART上的執行速度可以比Dalvik上的執行速度快一倍。是以總的來說，不管是添加JIT支援，還是現在的ART，都是為了速度更快。

         ART是在Android4.4正式出現的，就是它引起了Android中編譯工具鍊的改動。之前Dalvik拿到.dex或者優化過的.odex檔案，是使用JIT然後執行的。現在ART是直接使用LLVM去做AOT（Ahead of Time），這樣的話，執行速度自然就上來了，帶來的犧牲是應用的安裝速度會降下來，因為AOT編譯是在安裝的時候做的，後續的啟動和執行，都使用的是AOT之後的結果。是以等于是用一次時間犧牲，換來之後的多次時間節省。

       ART目前是和Dalvik同時存在系統中的，使用者也可以自己選擇。在系統中它們分别以Dalvik runtime (libdvm.so) 和 ART (libart.so)這兩個庫的形式存在，ART的源碼位置也是在和Dalvik的同級位置，直接在Android目錄下有個art目錄。目前art目錄下的設定基本上也是參照Dalvik的形式來的，幾個工具也都是類似，隻是把與原來的dexopt工具給換成了dex2oat，然後引入了LLVM去做編譯的工作。到這個程度，LLVM等于已經參與了Android上的所有應用的編譯工作，在art出現之前，LLVM隻是處理Android

Renderscript中的rs檔案。

       ART目前所帶來的缺點就是占用空間增大和首次安裝時間延長，這都是由AOT導緻的，目前看來是沒有辦法避免的。還有一個問題就是目前為了同時支援Dalvik和ART，依然采用dex格式檔案作為輸入，但是dex格式本身就是給Dalvik所設計的可執行格式，是以如果将來真的丢掉Dalvik的話，這個dex格式就有點不倫不類了，可能到那時候這個dex格式也終将作出改變。

參考資料：