探索Dalvik移植技術秘密所在

其實Dalvik是基於寄存器，而JVM 卻是基於棧的，Dalvik移植技術可以將 Java .class 轉換成 .dex 格式. 一個dex檔通常會有多個.class。由於dex有時必須進行最佳化，會使檔案大小增加1-4倍，以ODEX結尾。）

本文檔指導讀者如何把Dalvik虛擬機移植到一個Linux平台上，本文檔假定我們要移植的平台和目前android平台在代碼架構上有一定的相似性，可以進行移植。核心庫的移植核心庫的源代碼主要在Dalvik/libcore和dalvik/vm/native這兩個文件夾中。核心庫的源代碼是用C語言和C++寫成的。

因此在Linux環境下不需要更改。核心庫的代碼很多都是來自apache Harmony項目，但是也有一些是來自OpenSSL、zlb和ICU等項目，因此，為了虛擬機的運行，這些項目需要被移植到新平台上。

JNI Call Bridge 的移植DVM的運行庫絕大部分都是用portable C編寫的，其中的一個例外是JNI call bridge。簡單來說，它的作用是把一系列的整型值轉變成各種類型的函數參數，並且調用函數。這個調用過程必須符合C函數調用的約定。

為了簡化移植，JNI Call Bridge在新平台上通常會使用開源的FFI庫（我覺得，這種庫，大概類似於Java一樣，具有通用性吧）。但是，Dalvik移植技術運行不夠快，也沒有對平台做專門優化，所以，移植JNI Call Bridge首先應該重新寫一個FFI庫。

JNI Call Bridge代碼在dalvik/vm/arch/*這個位置上，同時，基於FFI的版本（我覺得大概是在移植的時候的通用版本）在“generic”目錄下。每一種架構都有兩個源文件，其中一個是定義了JNI Call Bridge函數，函數如下。dvmPlatformInvoke是把argv所指向的值轉化為符合C類型調用的值，而後調用我上面指出的函數，再把得到的返回值放入JValue* pReturn所指向的地方。

再用./rebuild重新生成文件，看一下在dalvik/vm/mterp/out目錄下的InterpAsm-myarch.S文件，可以看到在dvmAsmInstructionStart後面的一個單塊內有stub函數的256個拷貝 。如果你不用匯編的話，系統就會一直使用stub.S。

注意一下，每一個塊開頭都有一個a.balign 64 指令。這個指令把處理程序擴展到64個字節。同時也要注意到${opcode} text變成了操作碼的名字，它是用來調用C執行的（就是dvmMterp_${opcode}）

stub.S的實際內容由你自己來定義。看看armv5t或者x86項目實例下的entry.S和stub.S你就知道了。如果你將要移植的系統和我們說的有些不一樣，但大體相似，目前的大部分代碼你都可以使用，只是需要修改一下某些指令。具體可以看一下armv4t的移植你就清楚了。

該函數可能使用方法簽名來決定如何處理函數中的相關值。至於方法簽名，它是一個短小的DEX簽名，用一個字符對應一個返回值和一個參數。而另外一個源文件（前面提過有兩個源文件）則定義了一個32位的“hint”。當相應的方法類型被加載時，hint值就會被計算出來。

作為“arginfo”參數進入dvmPlatformInvoke函數，hint可以用來dvmPlatformInvoke停止例如掃面函數的返回值、總體參數的大小，以及整形參數64字節條件測試的限制等的ASCII方法簽名。（我想hint應該是決定函數是否對返回值或者參數進行方法簽名掃描）。

解釋器的移植Dalvik移植技術虛擬機運行庫含有兩個解釋器，分別是標以“移動型”和“快速型”。移動型主大體上就是一個C函數，在任何裝有GCC的系統上都應該可以被編譯出來。（如果你的機器沒裝有GCC，那麼你應該停用“threaded”模塊，因為這個模塊依賴於GCC的goto語句的目錄來執行的。不清楚的話可以查找THREADED_INTERP的定義。

快速型使用手工匯編導致的碎片（？？這裡不懂）。如果目前系統裡沒有解釋器可用，那麼系統就會從C stubs中生成一個解釋器，這個解釋器運行速度比移動型慢了很多，說它是快速解釋器，實在是名不符實。

快速型在系統裡是被默認使能的，如果源代碼不支持快速型。那麼該如何默認使能移動型呢？這可以通過dalvik.vm.execution-mode system來實現。例如。你打入如下一行：如果用匯編語言重寫解釋器的話，解釋器的效能應該會有一個明顯的提高再加上相應平台專用架構的優化，dalvik可以用一個指令一次執行完畢（？？這裡也不懂）