我們在今年八月中旬的 COSCUP 研討會中，很榮幸地向與會的朋友介紹 0xlab 若干新的開放原始碼專案，本文稍作整理回顧。0xdroid 是 0xlab 最早的一項整合性開放原始碼專案，目的是建構於 Beagleboard 開放的硬體之上，提供 Android 的參考實做環境，經過一年多的累積，裡頭的成果被帶到不同的移動裝置中，比方說手機與 Tablet。今年二月份，有幸在 Mobile World Congress 2010 展示基於 Android 的移動裝置，Tieto 也在 TI OMAP3 平台展示 0xdroid，這些都讓我們更有信心，擴展到多元的應用。

這半年間，延續 0xdroid 的經驗，我們發展 / 貢獻以下專案：

• 0xRobocat : 與 CATCAN 合作的專案，目的是打造一組控制伺服馬達與相關零組件的軟體框架，可提供給 Android 或 GNU/Linux 使用，以 Apache License 2.0 授權釋出。除了用於打造機器人外 (是真的可走動的 "Android")，本專案可用於 Android 裝置 (如手機) 的自動測試
  
• 0xBench : 有鑑於 Android 上的系統效能評比程式，不是不完整，就是非開放原始碼，所以我們決定重新打造一個。0xBench 可從 C 函式庫/系統呼叫的層面，一路從 Dalvik VM 評測到 Android framework，仍持續擴充，並且我們提供 Web service，允許貢獻評測的結果，用互動的方式來分析。程式主體是 Apache License 2.0 授權
• android-toolchain : 0xlab 特製的 GNU Toolchain，以 Android team 的成果為基礎，整合來自 Linaro Toolchain Working Group 的改善。這些主要是 GNU GPLv3 授權
  
• Android Open Source Project (AOSP) : 提交 0xlab 過去在 TI OMAP 與 Qualcomm 72xx 平台的一些修改，經過公開的 Review 機制，慢慢整合到 AOSP
• CyanogenMod : 社群版本的 Android，在 Nexus One, HTC Dream 等裝置有相當優越的表現，收錄若干來自 0xlab 的改良，比方說 Bluetooth HID profile
  

• build - 調整 Android build system、修正工具程式的瑕疵
• bionic - 提供 ARM optimizations，針對 ARMv6/ARMv7
• PixelFlinger - 基本的 refactoring，以及 ARM 實做的改良
• libpng / libz - 利用 GCC visibility，進一步縮減 code size
• elfcopy - ELF 工具的調整
• bionic / apriori / build - 支援 DT_GNU_HASH，加快動態連結的速度
• toolchain - 加強 build system 的彈性

延續筆者去年的紀錄「當 Compiler 遇上 Mobile」，最近我們又獲得一些進展，是在 Android 的 Dalvik 虛擬機器環境中，引入 pre-compiled class 的實驗，除了可改善執行時期的效能、記憶體使用量外，另外就是避免在「反組譯並修改 Android 應用程式實例」一文可見的資訊保護議題。

其實十幾年前，在 Java 平台中就有相當多團隊提出可行的方案，而世界上第一個開放原始碼的 Kaffe 虛擬機器專案，早在 1999 年即提出實做 "Kaffe/GCJ integration"，成功地將 GCJ (GCC for Java) 自 Java class/source 編譯得到的機械碼，當作 pre-compiled shared library，讓 Kaffee VM 讀取，預期可有效改善執行效能並縮減起始時間。GNU Classpath 專案主持人 Mark Wielaard 在 LWN 的文章 "GCJ - past, present, and future" 提到相關的歷史與技術背景，最早可回溯到 Cygnus solutions 時期 (RedHat 尚未併購) 的 GCJ 計畫提案 -- "A Gcc-based Java Implementation"。

為了降低實做的複雜度，筆者最早採用 LLVM 與 IcedTea 作為系統框架，不過一直到今年春節，整體進度還是陷入膠著的狀態。現在則引入 Java2C 搭配 PGO (Profile-Guided Optimization) 與統計模型，嘗試分析運行於 Dalvik VM 的 Android activity / system server，佔用系統資源最頻繁的項目，並預先編譯 (pre-compile) 這些 class/method，居中透過 JNI (Java Native Interface) 讓 Dalvik VM 存取。不過，實務上來說，不是將所有 class/method 都編譯為原生機械碼，就會帶來效能提昇，相反地，後者往往讓系統陷入更差的效能。目前 Eclair 裡面的 Dalvik VM 雖然沒有完整的 JIT compiler，但其 fast interpreter for ARM 的確做了頗多 threaded interpreter 的改進，考量到 I-cache, paging, 與 branch prediction，若我們不思量 Java / Android Dalvik 應用程式的執行時期行為，只是一味作編譯轉換，很可能只是編譯極少被執行，或者完全不會被執行到的程式碼，因此加重執行時期的負擔，而最該被優化的部份，受限於不完整的 source-to-source 轉換，有顧此失彼的疑慮。

於是，找出系統中最該被優化的部份，並考量到正確性與相容度，就是我們的首要研究議題，筆者採用知名的 SciMark 2.0 作為量化分析的指標。以下是在 Qualcomm MSM7x25 硬體平台 (arm1136j-s) 的效能評比，ARM11 的時脈是 528 MHz，ARM Linux 版本為 2.6.29.6-0xlab：
由上可見，在 SciMark 2.0 的各項評比中，Pre-compiled class 執行效能都較 Android Dalvik fast interpreter for ARM 給予一定程度的改良，並且透過 FDO (Feedback Directed Optimization)，大多可進一步給予提昇。這僅是初步的整合實驗數據，還需要更多分析與進行實做。

為了某個實驗的動機，我們評估反編譯 Android 應用程式的可行性，本文即是筆者的心得與實際的範例，僅供參考。就筆者的認知，目前還沒有針對 Android 的 DEX to Java source 反編譯工具，可實際處理一般的 Android 應用程式，多半要繞幾圈，還會得到不甚理想的結果，不過，smali 這個反組譯工具，已是可用了，只是得對付類似 Jasmin 語法的 Dalvik 組合語言。筆者打包了 smali 與 Frozen Bubble for Android，作為示範：

以下是執行畫面：
當然，沒必要讓筆者置喙談如何玩這個經典遊戲，不過我們倒是想更改原本的行為。在進行之前，我們先來複習 Android APK 的建立，參考 "How to build Android application package (.apk) from the command line using the SDK tools + continuously integrated using CruiseControl." 一文，我們可從以下圖表知悉細部的流程：

假設我們完全無法取得原始程式碼，該如何進行呢？沒錯，就透過 smali，簡化繁瑣的流程，筆者包裝為 Makefile，所以只要先解開並反組譯：

$ make extract

這時候會看到兩個目錄：

• smali-src : 存放反組譯的程式檔輸出
• workspace : 原本 Frozen Bubble 的 Android resource files

二話不說，當然是觀察反組譯的結果：

smali-src$ find
./org/jfedor/frozenbubble/FrozenBubble.smali
./org/jfedor/frozenbubble/R$id.smali
./org/jfedor/frozenbubble/GameView.smali
./org/jfedor/frozenbubble/SoundManager.smali
./org/jfedor/frozenbubble/LaunchBubbleSprite.smali
./org/jfedor/frozenbubble/Compressor.smali
./org/jfedor/frozenbubble/R$attr.smali
./org/jfedor/frozenbubble/BubbleFont.smali
./org/jfedor/frozenbubble/PenguinSprite.smali
./org/jfedor/frozenbubble/GameView$GameThread.smali
./org/jfedor/frozenbubble/BubbleSprite.smali./org/jfedor/frozenbubble/R$string.smali
./org/jfedor/frozenbubble/R$drawable.smali
./org/jfedor/frozenbubble/ImageSprite.smali
./org/jfedor/frozenbubble/BubbleManager.smali
./org/jfedor/frozenbubble/GameScreen.smali
./org/jfedor/frozenbubble/R.smali
./org/jfedor/frozenbubble/R$layout.smali
./org/jfedor/frozenbubble/BmpWrap.smali./org/jfedor/frozenbubble/FrozenGame.smali
./org/jfedor/frozenbubble/Sprite.smali
./org/jfedor/frozenbubble/LevelManager.smali
./org/jfedor/frozenbubble/R$raw.smali

就忠實地依據 Java package 的方式呈現，檔名結尾是 ".smali"。筆者的修改目標是，讓一開始的關卡 (Level) 從第一關直接跳躍到第五關。在 smali 原始程式碼 (注意：這完全不同於 Java 原始程式碼，而是極為貼近 Dalvik VM 所接受的 DEX 檔案的組合語言形式) 搜尋 "Level" 字眼，可發現主要的分佈就落於兩個檔案：

• ./org/jfedor/frozenbubble/GameView$GameThread.smali
• ./org/jfedor/frozenbubble/LevelManager.smali

前者就是 org/jfedor/frozenbubble/GameView.java 的編譯輸出，因為是 inner class，獨立編譯出 org/jfedor/frozenbubble/GameView.class$GameThread.smali，由這個 class 命名方式大概就可猜出其重要性，基本上只要能夠控制此 class 的實做，就掌握此 Android 應用程式的行為。而 class LevelManager 顧名思義，看來掌握了遊戲進行的程序控制。先觀察其 method 列表：

smali-src$ grep "\.method" org/jfedor/frozenbubble/LevelManager.smali
.method public constructor <init>([BI)V
.method private getLevel(Ljava/lang/String;)[[B
.method public getCurrentLevel()[[B
.method public getLevelIndex()I
.method public goToFirstLevel()V
.method public goToNextLevel()V.method public restoreState(Landroid/os/Bundle;)V
.method public saveState(Landroid/os/Bundle;)V

倘若我們以 "goToFirstLevel" 一類的關鍵字，在 org/jfedor/frozenbubble/GameView$GameThread.smali 檔案中搜尋，可找出有具體的呼叫行為：

smali-src$ grep -r goToFirstLevel *
org/jfedor/frozenbubble/GameView$GameThread.smali: invoke-virtual {v2}, Lorg/jfedor/frozenbubble/LevelManager;->goToFirstLevel()V
org/jfedor/frozenbubble/LevelManager.smali:.method public goToFirstLevel()V

由此更確定我們之前的猜想。其中組合語言寫為以下：

move-object/from16 v0, p0

iget-object v0, v0, Lorg/jfedor/frozenbubble/GameView$GameThread;->mLevelManager:Lorg/jfedor/frozenbubble/LevelManager;

move-object v2, v0

invoke-virtual {v2}, Lorg/jfedor/frozenbubble/LevelManager;->goToFirstLevel()V

不要被貌似複雜的語法嚇到了，基本上掌握 Java 程式語言的原則 "Everything is Object" (不過仍有提供 primitive type)，組合語言仍會作 Java Object 的實體化 (instantialization)，Dalvik 本身是 Register-based Virtual Machine，而扣除 static/class method 外，Java 中所有的 method invocation 多為 virtual function (對應於 C++ 的觀點，才能更具體用機械方式思考)，所以組合語言的指令為 "invoke-virtual" (注意有連字號，此與 Java bytecode 不同)，"{v2}" 表示第一受者的 Register，此為 Object 本體。接著，與 Java bytecode 一樣，"Lorg/jfedor/frozenbubble/LevelManager;" 就表示 Java 層面的 class "org.jfedor.frozenbubble.LevelManager"，字母 "L" 即為 class 的識別，而 "->" 就很直觀了，自然是 method invocation，所以連貫來看，這一段組合語言的 Java 意思為：

objectLevelManager.goToFirstLevel();

其中 objectLevelManager 是一個 class LevelManager 的實例/實體 (instance)。倘若需要在 method invocation 時，帶入參數，那麼前述的 "{v2}" 一般會被替換為 "{v0, v1, v2, ...} 的 register 列表。關於詳細的狀況，可參考 Dalvik 非官方說明，另外 smali 的 wiki 也提供一些範例，可多加利用。

回到筆者剛剛設定的目標，我們既然知道 class org.jfedor.frozenbubble.GameView$GameThread 掌控了程式處理邏輯，自然一堆變數的傳遞、method 呼叫，都在此進行，那我們先試著用 "level" 字串去搜尋，想辦法找出常數定義，後者在 Dalvik 中，會集中保存於 constant pool 中，而 smali 的組合語言寫法大致是 "const" 開頭的宣告，端看其類型而定。以程式追蹤的目的來說，我們專注於以下兩種：

• const-string : primitive string (不同於 java.lang.String) 表示
• const/4 : 長度為 4 bytes (32 bit) 的整數表示

字串何其多，依據之前的推測來說，我們要找接近 "LevelManager" 字眼的組合語言程式碼，道理很明顯，從一般 Java programmer 的寫作邏輯去反推。經過一番搜尋，我們找到以下的反組譯程式碼： (位於檔案 org/jfedor/frozenbubble/GameView$GameThread.smali中)

const-string v3, "level"
const/4 v4, 0x0
move-object/from16 v0, v25 move-object v1, v3
move v2, v4
invoke-interface {v0, v1, v2}, Landroid/content/SharedPreferences;->getInt(Ljava/lang/String;I)I
move-result p4
new-instance v3, Lorg/jfedor/frozenbubble/LevelManager;
move-object v0, v3
move-object/from16 v1, v22
move/from16 v2, p4 invoke-direct {v0, v1, v2}, Lorg/jfedor/frozenbubble/LevelManager;-><init>([BI)V

在上述程式碼列表中，"Lorg/jfedor/frozenbubble/LevelManager;-><init>" 表示呼叫 class LevelManager 的 constructor，也就是 "<init>"。注意到 method invocation 方式就不同了，是 "invoke-direct"，表示 class constructor，而這之前要有 "new-instance v3, Lorg/jfedor/frozenbubble/LevelManager;" 的組合語言指令宣告。

前面談過「倘若需要在 method invocation 時，帶入參數，一般會被替換為 "{v0, v1, v2, ...} 的 register 列表」這樣的概念，我們可推知，Register v1 與 v2 就是實際上 class org.jfedor.frozenbubble.LevelManager 的 constructor 參數。就程式設計的邏輯來看，class GameView 就是依據某個流程，要求 LevelManager 去改變狀態，所以這裡的兩個參數，其實就是初始值，非常的重要。

與 Register v1 相關的組合語言指令有這幾行：(用粗體字標示)

const-string v3, "level"
const/4 v4, 0x0
move-object/from16 v0, v25
move-object v1, v3
move v2, v4
invoke-interface {v0, v1, v2}, Landroid/content/SharedPreferences;->getInt(Ljava/lang/String;I)I
move-result p4
new-instance v3, Lorg/jfedor/frozenbubble/LevelManager;
move-object v0, v3
move-object/from16 v1, v22
move/from16 v2, p4
invoke-direct {v0, v1, v2}, Lorg/jfedor/frozenbubble/LevelManager;-><init>([BI)V

顯然，Register v1 還被帶入到 android.content.Shared.Preference.getInt() method，而更早以前，其內含值被設定為 Register v3 的值，也就是常數字串 (const-string) "level"，這好像與我們的焦點不同。另外，像是 Register v22 這個編號較大的 register，表示 local variable，這點需要多留意，因為 Java 程式設計的規範來說，往往會將程式切割為若干 method，而 method 實做體中，又有極多的 local variable，於是往往可從組合語言反推 Java 原始碼的型態。

那麼，看看 Register v2 吧，同樣用粗體字標示相關的指令：

const-string v3, "level"
const/4 v4, 0x0
move-object/from16 v0, v25
move-object v1, v3
move v2, v4
invoke-interface {v0, v1, v2}, Landroid/content/SharedPreferences;->getInt(Ljava/lang/String;I)I
move-result p4
new-instance v3, Lorg/jfedor/frozenbubble/LevelManager;
move-object v0, v3
move-object/from16 v1, v22
move/from16 v2, p4
invoke-direct {v0, v1, v2}, Lorg/jfedor/frozenbubble/LevelManager;-><init>([BI)V

這個 Register v4 的內含值 "0x0" 會指派到 Register v2 中，而讓我們似乎找到方向了，回頭看看 class org.jfedor.frozenbubble.LevelManager 的 constructor 宣告方式： (之前 grep 結果的第一行)

smali-src$ grep "\.method" org/jfedor/frozenbubble/LevelManager.smali
.method public constructor <init>([BI)V

其中 "public" 是 ACL (存取權限) 的宣告，而 constructor 的符號規範為 "<init>"，注意到括號 "(" 與 ")" 裡面的兩個大寫字母，表示接受兩個參數，對應的型態為：

• B : byte
• I : int

在 Java 與 Dalvik virtual machine 皆以同樣的形式作宣告，看到這裡，我們實在忍不住要動手修改了，當然，一切都是實驗性質。既然一開啟遊戲，畫面就顯示 Level 1，表示 LevelManager 一開始接受的 level 參數會是 "0"，然後依據 GameView 的邏輯，逐一升級或中斷遊戲進行，那麼，如果要讓遊戲一起動就是 Level 5，是不是要把內含值改為 0x4 即可？也就是 "invoke-direct {v0, v1, v2}, Lorg/jfedor/frozenbubble/LevelManager;-><init>([BI)V" 的 Register v2 當時內含值該為 0x4，不就任務達成了嗎？想到此，不禁會心一笑。

不過，回顧稍早 Register v2 的相關程式碼輸出，其中有兩行需要留意 (以粗體字為主)：

invoke-interface {v0, v1, v2}, Landroid/content/SharedPreferences;->getInt(Ljava/lang/String;I)I
move-result p4
new-instance v3, Lorg/jfedor/frozenbubble/LevelManager;
move-object v0, v3
move-object/from16 v1, v22
move/from16 v2, p4

"p4" 用以保存 method invocation 之後的回傳值，顯然，Register v2 受到 p4 的指派，也就是被更動為 android.content.Shared.Preference.getInt() method 的回傳值，這存在不確定性，於是，我們乾脆一口氣改掉： (修改的部份會用井字號 "#" 作註解)

# Modified from 0x0 to 0x4"
const/4 v4, 0x4
move-object/from16 v0, v25
move-object v1, v3
move v2, v4
# Modified: removed the following 2 lines
# invoke-interface {v0, v1, v2}, Landroid/content/SharedPreferences;->getInt(Ljava/lang/String;I)I
# move-result p4
new-instance v3, Lorg/jfedor/frozenbubble/LevelManager;
move-object v0, v3
move-object/from16 v1, v22
# Modified: removed the following 1 line
# move/from16 v2, p4
invoke-direct {v0, v1, v2}, Lorg/jfedor/frozenbubble/LevelManager;-><init>([BI)V

改好程式，當然要驗證，回到上一層目錄，透過 smali 提供的組譯器，重新產生 Dalvik DEX 輸出，為了簡化流程，筆者把 smali, apkbuilder, aapt, adb install 都一次整合進去，所以會直接讓 Android Emulator 生效，來看看我們的戰果吧：
注意到左下角，這表示我們成功了，完全不用取得 Java 原始程式碼，就可以作反組譯並且修改的動作。

Android 2.0 (Eclair) 原始程式碼已於一個月前釋出，在目錄 system/core 下有個 libacc 的子項目，這是開發者修改自 Fabrice Bellard 的大作 OTCC (Obfuscated Tiny C Compiler)，以 C++ 與 Android 的執行時期函式庫重寫。libacc 的功能是提供給 Android 2.0 的 RenderScript 一個 C-like 語法的描述，如此一來，開發者可撰寫高效能的視覺效果與動畫，不過這部份並未完成，詳情可參考 "Android renderscript, more info' and an example application" 一文。

關於 libacc 的整合部份，可參考 frameworks/base/libs/rs 目錄下的兩個檔案：

• rsScriptC.cpp
• rsScriptC_Lib.cpp
  

libacc$ make
g++ -I./include -DHAVE_PTHREADS -c acc.cpp
gcc -I./include -DHAVE_PTHREADS -c hashmap.c
gcc -I./include -DHAVE_PTHREADS -c logd_write.c
g++ -I./include -DHAVE_PTHREADS -c tests/main.cpp
g++ -I./include -DHAVE_PTHREADS -c tests/runtimeTest.cpp
g++ -o main \
  acc.o \
  hashmap.o \
  logd_write.o \
  main.o \
  -ldl
g++ -o runtimeTest \
  acc.o \
  hashmap.o \
  logd_write.o \
  runtimeTest.o \
  -ldl

• x86 / IA32
• x86_64
• ARMv5

libacc$ ./main -R tests/data/hello.c
Executing compiled code:
Hello, world
result: 0

libacc$ cat tests/data/hello.c
int main() {
printf("Hello, world\n");
return 0;
}

const char* text = "void op_int(int a);\n"
   "void op_float12(float a, float b, float c, float d,\n"                   
   "           float e, float f, float g, float h,\n"
   "           float i, float j, float k, float l);\n"
   "void script() {\n"
   "  globalVar += 3;\n"
   "  op_int(123);\n"
   "  op_float12(1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 11.0, 12.0);\n"
   "}\n";

libacc$ ./runtimeTest
Executing script:
op_int(123)
op_float12(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)
After script globalVar = 20

前文「對 String 操作的改進」與「Android Dalvik VM vs. Java VM」談及基於 CVM 引擎的 Java VM 與 Dalvik 的效能差異後，最近 0xlab 內部也因為挑選硬體平台，持續分析 Embedded CaffeineMark 一類量化效能的報告。參考的硬體組態是 OMAP3/ARMv7 500 MHz，粗略的效能評比如下圖：

Dalvik 取自 0xdroid (cupcake + backported from donut)，而 CVM-jit 則源自 phoneME CVM svn r19264，整體分數為：

• Dalvik VM : 1034
• CVM + jit : 7526

• cached constant
• cached constant inlining
• array init bounds check elimination
• Hardware fpu = NEON
• AAPCS

Four String methods -- charAt, compareTo, equals, and length -- are
"inlined" by the VM, and are not going to get much faster.

There are probably a few others that could benefit from this
treatment, but I'm guessing that most string-centric processing in
Java will likely be dominated by the cost of String allocations. (The
above weren't inlined because of a measured performance need -- the
inlining was an experiment that needed a test subject.)

過去我們很難聯想進階的編譯器 (compiler) 技術到底與移動平台何涉，但隨著基礎建設的突破，我們就該有不同的思維。

從1960 年代發展至今，編譯器技術已是電腦科學最成熟的基礎之一，不斷地成長與蛻變，而透過 open source，GNU GCC 與 LLVM (Low Level Virtual Machine) 計畫獲得空前的成功，累積了驚人的編譯器技術。儘管 parser 仍是 compiler 的關鍵技術，但今日，我們會著重於打通任督二脈的技術展現，過去耳熟能詳卻貌似獨立的項目，比方說 virtual machine, binary translator, JIT compiler, HotSpot JVM, 等等，如今好似整合了金庸書中的武功精髓、淬湅出武術菁華，形成一套獨到的武功系統，透過 LLVM 一類的整合性技術而一瀉千里。

幾年前，知名的遊戲設計公司 id Software 在該公司靈魂人物 John Carmack 的主導下，將 Doom (毀滅戰士) 核心的遊戲引擎以 GNU GPL 開放授權釋出，自此開啟廣泛的平台移植與功能強化的的濫觴。早期的 Doom GPL 程式碼被 Sam Lantinga 移植到 SDL 圖形函式庫，藉由 SDL 優異的可攜性，眾多硬體環境得以運行 Doom 遊戲，儘管遊戲的資料檔並非自由軟體。另一方面，現在最火熱的移動平台，就屬 Google Android 開放源碼平台，為了迴避 Sun Microsystems 對 Java 的控制權 (logo + patent)，該平台整合大部分 Apache Harmony 專案的成果，建立了一套貌似 Java 語言但執行環境大異於 Java 的嶄新虛擬機器 -- Dalvik，將原本 stack-based VM (JVM) 轉換為 register-based VM (Dalvik VM)，而無論這裡頭有多少玄機，就 Android 的程式設計來說，Java 是唯一可用的程式語言，要不得搭配 Android framework / class library，不然就是透過 JNI 去呼叫 C/C++ 撰寫的動態函式庫。作為一個「慣 C 魔人」， 筆者反覆思考，是否能將以 C 語言搭配 SDL 函式庫撰寫的 Doom，透過編譯器轉換為 Android 平台可運作的 Dalvik bytecode 呢？此舉不僅讓 C/C++ 程式跨平台執行，還為移動平台提供了新的附加價值，於是，筆者就開始一系列的 hacking，現在有初步的成果，日前已發表於 OSDC.tw 2009 的「窮得只剩下 Compiler」議程中，請參考以下螢幕快照：
這可不是紙老虎或單純貼圖，電動玩具當然是設計來玩的：
詳細的資訊可參閱發表於 OSDC.tw 的議程簡報：