探索Dalvik移植技術(shù)秘密所在
其實Dalvik是基于寄存器，而JVM 卻是基于棧的，Dalvik移植技術(shù)可以將 Java .class 轉(zhuǎn)換成 .dex 格式. 一個dex檔通常會有多個.class。由于dex有時必須進行最佳化，會使檔案大小增加1-4倍，以O(shè)DEX結(jié)尾。）
本文檔指導(dǎo)讀者如何把Dalvik虛擬機移植到一個Linux平臺上，本文檔假定我們要移植的平臺和目前android平臺在代碼架構(gòu)上有一定的相似性，可以進行移植。核心庫的移植核心庫的源代碼主要在Dalvik/libcore和dalvik/vm/native這兩個文件夾中。核心庫的源代碼是用C語言和C++寫成的。
因此在Linux環(huán)境下不需要更改。核心庫的代碼很多都是來自Apache Harmony項目，但是也有一些是來自O(shè)penSSL、zlb和ICU等項目，因此，為了虛擬機的運行，這些項目需要被移植到新平臺上。
JNI Call Bridge 的移植DVM的運行庫絕大部分都是用portable C編寫的，其中的一個例外是JNI call bridge。簡單來說，它的作用是把一系列的整型值轉(zhuǎn)變成各種類型的函數(shù)參數(shù)，并且調(diào)用函數(shù)。這個調(diào)用過程必須符合C函數(shù)調(diào)用的約定。
為了簡化移植，JNI Call Bridge在新平臺上通常會使用開源的FFI庫（我覺得，這種庫，大概類似于java一樣，具有通用性吧）。但是，Dalvik移植技術(shù)運行不夠快，也沒有對平臺做專門優(yōu)化，所以，移植JNI Call Bridge首先應(yīng)該重新寫一個FFI庫。
JNI Call Bridge代碼在dalvik/vm/arch/*這個位置上，同時，基于FFI的版本（我覺得大概是在移植的時候的通用版本）在“generic”目錄下。每一種架構(gòu)都有兩個源文件，其中一個是定義了JNI Call Bridge函數(shù)，函數(shù)如下。dvmPlatformInvoke是把argv所指向的值轉(zhuǎn)化為符合C類型調(diào)用的值，而后調(diào)用我上面指出的函數(shù)，再把得到的返回值放入JValue* pReturn所指向的地方。
再用./rebuild重新生成文件，看一下在dalvik/vm/mterp/out目錄下的InterpAsm-myarch.S文件，可以看到在dvmAsmInstructionStart后面的一個單塊內(nèi)有stub函數(shù)的256個拷貝 。如果你不用匯編的話，系統(tǒng)就會一直使用stub.S。
注意一下，每一個塊開頭都有一個a.balign 64 指令。這個指令把處理程序擴展到64個字節(jié)。同時也要注意到${opcode} text變成了操作碼的名字，它是用來調(diào)用C執(zhí)行的（就是dvmMterp_${opcode}）
stub.S的實際內(nèi)容由你自己來定義。看看armv5t或者x86項目實例下的entry.S和stub.S你就知道了。如果你將要移植的系統(tǒng)和我們說的有些不一樣，但大體相似，目前的大部分代碼你都可以使用，只是需要修改一下某些指令。具體可以看一下armv4t的移植你就清楚了。
該函數(shù)可能使用方法簽名來決定如何處理函數(shù)中的相關(guān)值。至于方法簽名，它是一個短小的DEX簽名，用一個字符對應(yīng)一個返回值和一個參數(shù)。而另外一個源文件（前面提過有兩個源文件）則定義了一個32位的“hint”。當(dāng)相應(yīng)的方法類型被加載時，hint值就會被計算出來。
作為“arginfo”參數(shù)進入dvmPlatformInvoke函數(shù)，hint可以用來dvmPlatformInvoke停止例如掃面函數(shù)的返回值、總體參數(shù)的大小，以及整形參數(shù)64字節(jié)條件測試的限制等的ASCII方法簽名。（我想hint應(yīng)該是決定函數(shù)是否對返回值或者參數(shù)進行方法簽名掃描）。
解釋器的移植Dalvik移植技術(shù)虛擬機運行庫含有兩個解釋器，分別是標以“移動型”和“快速型”。移動型主大體上就是一個C函數(shù)，在任何裝有GCC的系統(tǒng)上都應(yīng)該可以被編譯出來。（如果你的機器沒裝有GCC，那么你應(yīng)該停用“threaded”模塊，因為這個模塊依賴于GCC的goto語句的目錄來執(zhí)行的。不清楚的話可以查找THREADED_INTERP的定義。
快速型使用手工匯編導(dǎo)致的碎片（？？這里不懂）。如果目前系統(tǒng)里沒有解釋器可用，那么系統(tǒng)就會從C stubs中生成一個解釋器，這個解釋器運行速度比移動型慢了很多，說它是快速解釋器，實在是名不符實。
快速型在系統(tǒng)里是被默認使能的，如果源代碼不支持快速型。那么該如何默認使能移動型呢？這可以通過dalvik.vm.execution-mode system來實現(xiàn)。例如。你打入如下一行：如果用匯編語言重寫解釋器的話，解釋器的效能應(yīng)該會有一個明顯的提高再加上相應(yīng)平臺專用架構(gòu)的優(yōu)化，dalvik可以用一個指令一次執(zhí)行完畢（？？這里也不懂）
【編輯推薦】
