GitHub上出现了一个叫Klepton的项目,作者是shinyquagsire23。它做的事听起来有点离谱:不用JIT,把安卓ARM64架构的VR游戏APK,直接搬到苹果的Vision Pro和macOS上跑起来。目前唯一验证过能跑的是Beat Saber的安卓版,画面有些小问题,但确实能玩。
这件事反常的地方在于,visionOS出于安全策略,系统级禁止JIT编译——而市面上大多数安卓模拟方案,恰恰离不开JIT做指令加速。Klepton选的路子是绕开这道墙,不模拟,直接翻译。
怎么绕开JIT的
Klepton的核心组件叫klepton-ld,干的事是把安卓的.so动态库,静态翻译成苹果能加载的.dylib和.framework,再接进Klepton自己写的运行时。这不是虚拟机式的实时模拟,更接近一次性的二进制搬家。
图形层的处理更直接:GLES 3.2的调用被转译成内置的ANGLE(GLES 3.0,走Metal后端),Vulkan调用交给MoltenVK处理。这两个转译层不是Klepton原创,但把它们塞进一套完整的安卓运行时兼容层里,是这个项目的巧劲所在。
还有一个细节值得记一下:不少老旧的安卓应用会误用x18寄存器,而macOS在线程上下文切换时会把x18清零,两者一撞就出问题。klepton-ld的做法是给每个库单独打补丁,把x18的用途换成per-library的TLS槽位,绕开这个冲突。项目目前只支持"Java-thin"应用,也就是不带ART、不带JVM的那类,覆盖面还很窄。
Beat Saber能跑,但别急着高兴
项目状态写得很直白:Beat Saber在macOS和visionOS上能跑,有轻微图形瑕疵;SteamVR Link和通用构建工具链都还是WIP。构建流程也不轻松——用户得自己用apktool解包APK,再跑make check做回归测试,不是点一下就能玩的成品。
这里有个容易被忽略的对比。Vision Pro上现在主流的VR内容通道是ALVR一类的流式传输方案:PC端跑SteamVR,画面和追踪数据实时传过来。Klepton走的是完全相反的路——本地原生运行,不依赖PC、不依赖网络。
- 结论.两条路谁也替代不了谁,Klepton补的是"本地跑"这块空白,不是要取代流式传输。
代价也摆在那儿:Quest应用普遍绑定Meta专有的OpenXR扩展、账号权限、Horizon商店DRM,这些安卓指令集能翻译,专有API翻译不了。Beat Saber能跑通,不代表下一个游戏也能。
检索空白,和一个容易被搞混的名字
写这类项目最诚实的说法是:目前找不到任何独立于GitHub仓库之外的第三方验证——没有社区实测反馈,没有性能数据,没有版权争议的公开讨论。它还停留在极小众的技术社区内部流传阶段,没进过主流科技媒体的视野。
网上流传的一些说法把Klepton和一个叫"Lepton"的项目搞混了,说是Valve面向某种假想硬件的安卓兼容容器。这两者压根不是一回事:如果那类项目存在,走的是容器化路线,ARM64指令集和硬件原生匹配,不需要做二进制翻译;Klepton要在苹果的Mach-O层面做静态重链接,难度完全不在一个量级。这类张冠李戴的信息不能当作对Klepton的佐证,读者遇到类似说法时该多留一分警惕。
苹果和Meta都没点头的事,民间先把它跑通了。
谁会紧张,接下来看什么
对Vision Pro用户来说,这是一条绕开内容匱乏的野路子,但风险自己扛——解包APK、sideloading,都不在苹果的官方许可范围内。对Meta和Beat Games这样的发行商来说,自家APK被搬到竞品硬件上运行,版权和服务条款层面的态度值得留意,目前还没看到任何官方回应。
- 风险.项目仍是个人维护的早期仓库,能否扩展到ART/JVM应用、能跑通多少款主流Quest游戏、苹果是否会用系统更新方式堵死这条路,都是未知数。
接下来该盯的,是它能不能跑出Beat Saber这一个样本,以及苹果和Meta会不会真的出手。技术上凿开一道缝不难,能不能守住这道缝,才是问题。