Klepton 開源專案：把 Android ARM64 VR 應用跑上 Apple Vision Pro，無需 JIT

編按：本文綜合整理自 GitHub: shinyquagsire23/Klepton 專案 README 與 Hacker News 討論串 (id=49238818)，並加入 Siami 編輯部觀點與分析。開發者 LorenDB 週末丟出一個讓 VR 圈炸鍋的開源專案 Klepton——一套能把 Android ARM64 VR 應用直接搬上 Apple Vision Pro 的「Android→Apple 二進位翻譯層」，而且不需要依賴 JIT（just-in-time 編譯）。這對售價 3,499 美元起跳、App Store 上 VR 內容始終稀薄的 Vision Pro 來說，等於社群自己動手補上 Apple 沒做的生態缺口。

Klepton 的運作原理

Klepton 不是模擬器，而是二進位翻譯器：把 Android 的 .so 函式庫重新打包成 Apple 的 .dylib 與 .framework，再串接到 Klepton 自製的 runtime 上。根據專案 README 與架構圖，整個翻譯堆疊分三層：

Guest 層（被翻譯的 Mach-O）：原始 ARM64 指令幾乎原封不動，包括 libil2cpp、libunity、libunityopus、libmain、Burst 編譯器等遊戲核心函式庫都在這層。
Klepton Runtime 層：負責把 Android 的 Bionic libc、NDK 介面（ALooper、ANativeWindow、ASensor、AAsset）、合成 JNI（JavaVM / JNIEnv）、以及 Oculus VR runtime（ovrp_*）重新實作成 Apple 可呼叫的版本。
前端平台層（mains）：用 MoltenVK 翻譯 Vulkan→Metal、用 ANGLE（GLES 3.0 + Metal backend）處理 OpenGL ES，再串接 visionOS 的 Compositor Services、ARKit、GameController、AVAudioEngine。簡單說，Klepton 讓 Android 端的遊戲以「接近原生的速度」在 visionOS 裡跑，而不是用一台 ARM 版 QEMU 慢吞吞模擬整個系統。

「klepton-ld translates Android .so libraries into loadable Apple .dylib and .framework libraries」—— GitHub 專案首頁原句

為何 x18 暫存器要全部修補

Klepton README 特別點出一個會讓移植直接 crash 的硬體陷阱：x18 暫存器的慣例衝突。

Android 與 macOS 都把 x18 當保留暫存器，但很多老 Android app 把 x18 當 Thread-Local Storage（TLS）slot 用；macOS 在 context switch 與 timer interrupt 時會把 x18 清零。這代表一個 Quest app 連一個排程週期都撐不過。解法是 klepton-ld 在靜態連結時把所有 x18 引用 patch 成「per-library TLS slot」，並透過 mmap 提供 runtime patch 能力（macOS 上才有實際用處，因為 visionOS 禁 JIT）。這也是為什麼 README 強調 no JIT required——把整條 JIT 路徑拿掉後，剩下的二進位翻譯對 Apple 的 code-signing 與 App Store 政策都友善得多。

目前實作狀態

項目	狀態
Beat Saber 在 macOS	✅ 可運作，有輕微圖形瑕疵
Beat Saber 在 visionOS	✅ 可運作
Steam VR Link（macOS 客戶端）	🚧 WIP
通用性 / 編譯工具�改善	🚧 WIP
LuaJIT / V8 等需要 scripting runtime 的 app	�️ 仍需 JIT，可能無法直接跑

README 同時列出三個一鍵腳本：

./build_run_viewer.sh   # macOS 版 Beat Saber 前端
./build_run_vpro.sh     # Vision Pro 版 Beat Saber 前端
./build_run_slink.sh --shell --view  # macOS Steam VR Link（WIP）

為什麼這件事重要

Apple Vision Pro 上市以來最大的爭論之一，就是「為什麼這麼貴的裝置沒有原生 VR 遊戲生態」。Klepton 證明了問題不在硬體，而是 Apple 的封閉政策——3,500 美元的 M2/R1 晶片效能跑得動 Quest 級別的 VR，但 visionOS App Store 把開發者鎖在 SwiftUI + RealityKit 框架內，逼他們從零重寫整個 VR 引擎。從工程角度，Klepton 揭露了二進位翻譯 + 圖形 API 對接是跨平台 VR 移植的可行捷徑，不需要完整模擬器（像 Wine 那種）。同樣的手法未來可應用於：

把 Android Automotive 搬到 CarPlay Ultra
把 WebAssembly 遊戲塞進 visionOS
把 Linux 桌面 GUI app 翻譯到 iPadOS（呼應 HN 留言 terhechte 提到的 iPad 社群困境）如果 Klepton 的「不需要 JIT」設計能被社群擴展到更多 Android app 類別（不只遊戲），Apple 對 visionOS 的封閉策略會更難自圓其說。

Siami 數據解讀 / 質疑幾個值得追蹤的數字與疑點：

131 分 / 37 則留言：在 HN 屬於「爆款」等級（門檻約 50 分），但 8 小時內的 score 曲線顯示擴散仍在進行，這是開源 VR 專案少見的熱度。
「no JIT」是行銷話術還是工程限制？Apple 在 iOS / iPadOS / visionOS 都禁止 JIT，這對 Unity IL2CPP 遊戲沒問題（IL2CPP 已預編譯），但任何依賴 LuaJIT、V8、SpiderMonkey 的 app 都會 crash。README 自己也承認這點——所以「no JIT」應理解為「Klepton 不會自己生成新程式碼」，而不是「所有 Android app 都能跑」。
Apple 會出手 DMCA 嗎？Klepton 不包含任何 Apple 專有程式碼（只呼叫公開 framework + MoltenVK + ANGLE），法律風險比早年 iOS 模擬器低。但若 Apple 認定 ovrp_* reimplementation 侵犯 Oculus SDK 著作權，Meta 也可能介入。
與 visionOS 2 的 RealityKit 4 路線衝突：Apple 自己的策略是讓開發者用 SwiftUI 寫「空間 app」，Klepton 走的是相反方向——直接移植現有遊戲。這兩條路在 2026-2027 年的勝負將決定 Vision Pro 是「開發者平台」還是「高價 iPad」。

HN 社群反應