150款安卓游戏跑上iPhone,靠的不是模拟器

IT之家推了一条消息:开源项目 Husk 2.0 能让 iPhone 直接跑安卓游戏,兼容 150 多款,APK、XAPK、APKM、APKS 四种包都能导入,要求 iOS 16 以上,不需要越狱。

评论区的第一反应几乎一致:iPhone 什么时候能装安卓应用了。

能跑不新鲜,越狱还流行的年代就有人试过。做法不一样的地方在这儿:项目作者 Leviidev 没有模拟一台安卓手机,他把游戏自带的 64 位原生代码直接加载进普通 iOS 应用进程里执行。QEMU 那种整机模拟要开机、加载内核、拉起系统服务,画面出来常常要等几分钟;这套做法下,部分游戏几秒就进屏。

真正值得看的不是它能玩什么,而是省掉了哪一段活儿、又卡在哪条规则上。后一个问题的答案,和端侧 AI 眼下的处境是同一个。

「不是模拟器」这四个字,省掉的是一整台安卓机

模拟器得同时模拟硬件和系统,两样都不能省。QEMU 这类方案把 CPU 指令、内存布局、外设寄存器一样样搬过去,再在上面装一个完整的 Android,启动慢、发热、耗电,都是这条路自带的账。

Husk 绕开的是整机这一段。它把游戏的 DEX 文件和 .so 动态库加载进 iOS 应用进程,再从这个进程外部把 Android 那一侧的环境补齐,于是程序对着"安卓"说话,回话的其实是 iPhone。

这里有个容易被漏掉的事实:iOS 设备和安卓手机的 CPU 都是 ARM64,安卓安装包里那套 arm64-v8a 动态库,编译目标写的是 aarch64-linux-android,指令集和 iPhone 是同一套。真正对不上的地方在操作系统那一侧:代码以为自己能调 bionic 的 libc、能读 /proc、能走 Linux 那套系统调用,结果被塞进 XNU 的环境里。

要做的是把这些期待重新接一遍线,不是把指令逐条翻译。线接得干净,程序就察觉不到自己换了家。这解释了为什么它能跑在实体 CPU 上,而不用像模拟器那样在软件层面逐条搬运。

一层薄地基,四块砖

最重的一块是把 Android Runtime 编译成 iOS 版本。安卓应用里大量 Java 和 Kotlin 代码不是原生机器码,得靠 ART 加载 dex 再执行,Husk 需要的是一份能在 iOS 上启动、能加载 dex 的 ART。

bionic 那层是另一件事。它是安卓的 C 库,open、read、malloc、pthread 这些名字两边都有,参数语义和失败时的行为却经常不一样,得有一层垫在中间做转换。

加载器也只能自己写。iOS 的 dyld 只认 Mach-O,不认安卓的 ELF,想把 libunity.so 这类文件喂进去,得自己解析依赖关系、做重定位、把段映射到内存。

图形走两条转换通道:OpenGL ES 的调用经 ANGLE 转成苹果平台的图形接口,Vulkan 经 MoltenVK 转成 Metal。音频、触控和手柄输入一并接管,不然画面出来了也玩不了。

四块拼起来,得到的是一层薄地基,不模拟整台机器,只把程序脚下的地面铺平。好处是快,代价是容错低:安装包必须是 64 位、必须有原生代码、依赖的库得落在已知范围内。项目公开支持 Unity、虚幻 4、Godot 3 和 4,外加 cocos2d-x 与 SDL2/SDL3。名单里那款《GTA:圣安地列斯》值得单独提一句,它的引擎不在上面任何一家之列,能进名单说明地基的通用性比引擎清单看起来更好。早期的验收标准定得很具体:Flappy Bird 满速、地铁跑酷稳在 60 帧,后来公开的演示视频里最高跑到过 120 帧。

苹果只把 JIT 许可证发给调试器

"免越狱"这四个字容易让人误解,它说的是不用破解系统,不是说装起来省事。

Husk 依赖即时编译。iOS 对这件事管得很死,进程默认不能一边写内存一边执行内存,想动态生成机器码,得靠调试器附着把 JIT 权限打开。这是苹果的设计取向,不是疏漏,它挡的正是"运行时造代码"这一整类工具。

第一次上手就得先过这道门:iOS 26 起可以用项目自带的 StikJIT 自己开,更老的系统要绕 TrollStore 或者越狱。装也只能侧载,GPL-2.0 的授权摆在那儿,这条本身就断了上架 App Store 的路。还有两条会直接影响体验的限制:一次只能跑一款应用,换游戏要彻底关掉 Husk 再重开;翻译层兜不住的时候,项目会退回去用 LineageOS 起一个完整的安卓环境,那又回到模拟整机的老路上去了。

它此刻的位置很清楚,是给爱好者用的试验场,不是普通用户的产品。名单上那 150 多款是一遍遍试出来的结果,不是一份"支持全部安卓应用"的承诺;它给开发者的信号也不是"安卓应用可以无成本搬上 iOS",而是移植的成本结构变了,不必替对方重写一份客户端,却得替它找一层运行环境。

两个最容易被说错的地方

第一个说法是"既然免越狱,装起来应该很省事"。这话不是没道理,不破解系统,保修和账号风险确实小得多。但它说不清上手成本到底落在哪里:签名、侧载、JIT 授权、单实例运行,每一步都要人守着,哪一步卡住,前面的功夫全白费。免越狱降的是合规风险,不是操作门槛,这两件事常被混成一件。

第二个说法是"兼容 150 款,等于安卓应用都能跑"。名单覆盖了 Unity、虚幻、Godot 这些主流引擎,听起来确实像通用。可一旦追问细节就露出边界:为什么必须 64 位,为什么只认这几种引擎,为什么兜不住还要退回完整系统。答案指向同一处,薄地基只撑得住依赖可枚举的程序,依赖一旦超出范围,就得把整台机器搬回来。它是一条快路径,不是一层万能胶。

端侧 AI 正在走同一条窄门

把 Husk 这一套拆下来,能留下的东西不多:语言运行时、系统接口的映射、图形或计算后端,三样。谁想在自己的平台上跑别人的程序,都得先把这三样补齐,差别只在补在哪一层。

端侧模型今天面对的是同一道题。模型的权重文件本身是跨平台的,难的是外面那层:算子谁来写、内存怎么摆、后端认不认。llama.cpp 能在 iPhone 上跑,靠的是把 Metal 着色器提前编译好、把内核按硬件写死;Core ML 走得更远,直接把模型编译到神经网络引擎上。两条路的共同点都落在"提前编译"。

Husk 没有这个选项。它要跑的是任意一个 .so,不可能把别人的代码提前编译好再发版,于是只能要求 JIT。同一台 iPhone,跑模型能成,跑安卓游戏得先找调试器,差别就在这里。

我更愿意把这件事记成一条判断:跨端能不能成,取决于谁拿着编译权,而不是芯片跑分。苹果不开放 JIT,Husk 就只能拿侧载和调试器去换;苹果把 Metal 的离线编译放出来,推理框架就活得下去。规则没有改,改的是你站在规则的哪一侧。

Leviidev 的工程量倒着看更清楚:加载器自己写,bionic 那层接口一个个对,两个 APK 解析程序跑了 30 万次模糊测试没崩过一次;名单上那 150 多个名字,是一遍遍测试攒出来的。平台不肯给的接口,自己补一层是可行的,只是底下那层得跟着重写一遍。

想试就先查两样东西:安装包是不是 64 位,系统版本够不够 iOS 16;再去翻项目文档里 JIT 那一段,门槛写在那里,不在下载页上。真装上了,说说你第一个跑起来的是哪款游戏。

作者提示含AI生成内容。作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～