Madeira 项目解析：在 iOS 上运行 x86-64 Windows 程序的三层架构实践

1. 从“Madeira”这个名字说起它到底是什么第一次看到“Madeira”这个词很多人第一反应是葡萄牙那个盛产葡萄酒的海岛或者是一杯带着焦糖风味的马德拉酒。但如果你混迹于移动端模拟器、跨平台兼容层或者 iOS 开发圈这个名字大概率指向的是另一回事——一个围绕Wine、FEX-Emu、DXMT构建的、目标直指在 iOS 设备上运行 x86-64 Windows 程序的实验性项目。我接触这个方向有一段时间了最初是从“iOS 上能不能跑 Windows 软件”这个朴素问题开始的。市面上能查到的资料要么是零散的论坛帖子要么是语焉不详的仓库 README真正把 Wine、FEX-Emu、DXMT 这三者串起来讲清楚的材料少得可怜。所以这篇内容我打算把“Madeira”这个项目背后的技术脉络、实操路径、踩坑记录一次性摊开来讲适合以下几类人想在 iOS 上折腾 Windows 程序的技术爱好者、对 Wine 兼容层原理感兴趣但一直没找到系统入口的开发者、以及正在做跨平台方案选型、需要评估“ARM 设备跑 x86 程序”可行性的工程人员。先把核心结论摆出来Madeira 的本质是一套“翻译 兼容 图形转换”的三层架构。最底层是 FEX-Emu负责把 x86-64 指令翻译成 ARM64 指令中间层是 Wine负责把 Windows 的 API 调用翻译成 POSIX 调用最上层是 DXMT负责把 DirectX 调用翻译成 Metal 调用。三层叠加才能让一个原本为 Windows x86-64 编译的 exe 文件在 iOS 的 ARM 芯片上跑起来。这个链条里任何一环出问题程序都跑不起来这也是为什么这类项目调试起来格外折磨人。需要提前说明的是这类方案目前仍处于相当早期的阶段性能、兼容性、稳定性都远谈不上“可用产品”的级别。我写这篇的目的不是告诉你“照着做就能爽玩 3A 大作”而是把技术原理和实操路径讲透让你在动手之前对难度和预期有清醒的认知。下面进入正题。2. 三层架构拆解为什么必须是 FEX-Emu Wine DXMT2.1 指令集鸿沟x86-64 与 ARM64 的根本矛盾要理解为什么需要 FEX-Emu得先搞清楚一个基本事实Windows 程序绝大多数是为 x86-64 架构编译的而 iOS 设备无论是 iPhone 还是 iPad用的是 ARM64 架构。这两套指令集完全不兼容x86-64 的机器码在 ARM64 芯片上根本无法直接执行。解决这个矛盾有两条路。第一条是重新编译把源码针对 ARM64 重新构建一遍但问题是绝大多数 Windows 程序你拿不到源码这条路直接堵死。第二条是动态二进制翻译在运行时把 x86-64 指令一条条翻译成等价的 ARM64 指令FEX-Emu 走的就是这条路。FEX-Emu 的工作方式可以类比成“同声传译”程序执行到哪条指令它就现场翻译哪条翻译结果缓存起来下次遇到相同指令直接查缓存。这个缓存机制很关键因为翻译本身是有开销的如果每条指令都重新翻译性能会惨不忍睹。FEX-Emu 会把翻译过的代码块block存进一个缓存区热代码反复执行时命中缓存开销就降下来了。注意动态翻译的性能损耗是客观存在的。根据我的实测经验纯计算密集型任务在 FEX-Emu 下的性能大约是原生的 40% 到 70%具体取决于代码特征。浮点运算密集的程序损耗更大整数运算为主的程序相对好一些。2.2 Wine 的角色不是模拟器是 API 翻译层很多人误以为 Wine 是“Windows 模拟器”这个理解是错的。Wine 的全称是“Wine Is Not an Emulator”它不模拟硬件也不翻译指令它做的是API 层面的翻译。一个 Windows 程序运行时会调用大量的 Windows API比如CreateWindow、ReadFile、RegOpenKey等等。这些 API 在 Linux、macOS、iOS 上原本是不存在的。Wine 的工作就是提供一套自己的实现把这些 Windows API 调用映射到底层操作系统的对应功能上。比如 Windows 的ReadFile最终会被 Wine 转换成 POSIX 的read调用。在 Madeira 这套架构里Wine 跑在 FEX-Emu 之上。也就是说Wine 本身也是被翻译执行的 x86-64 代码。这就带来一个有意思的细节Wine 的翻译开销和用户程序的翻译开销是叠加的。不过实际使用中Wine 的很多核心模块会被 FEX-Emu 缓存得很充分所以这部分开销在稳定运行后占比不算大。2.3 DXMT把 DirectX 调用接到 Metal 上图形是另一个大坑。Windows 程序画图靠的是 DirectX主要是 D3D11、D3D12而 iOS 的图形 API 是 Metal。这两者之间的鸿沟需要 DXMT 来填。DXMT 的思路是把 D3D 的调用翻译成 Metal 的调用。比如程序调用CreateTexture2D创建一张纹理DXMT 会在 Metal 侧创建对应的MTLTexture程序调用DrawIndexed绘制DXMT 会转换成 Metal 的 draw call。这个翻译过程比指令翻译要复杂得多因为 D3D 和 Metal 的抽象模型、资源管理方式、同步机制都有差异。目前 DXMT 对 D3D11 的支持相对成熟一些D3D12 的支持还在完善中。这意味着那些依赖 D3D12 的新游戏在 Madeira 上跑起来的概率要低不少。如果你主要想跑的是老一点的、基于 D3D9 或 D3D11 的程序成功率会高很多。层级组件职责类比指令层FEX-Emux86-64 到 ARM64 的动态翻译同声传译API 层WineWindows API 到 POSIX API 的映射转接头图形层DXMTDirectX 到 Metal 的转换制式转换器这三层缺一不可而且顺序不能乱。FEX-Emu 在最底下因为它要处理的是最原始的机器码Wine 在中间它依赖 FEX-Emu 提供的执行环境DXMT 在最上面它依赖 Wine 提供的 Windows 运行时环境。理解这个层次关系后面排查问题时就能快速定位是哪一层出了毛病。3. 实操环境搭建从零到跑起第一个程序3.1 前置条件与设备选择先说清楚硬件和系统要求。Madeira 这类方案对设备是有门槛的不是随便一台 iOS 设备都能跑。芯片方面建议 A14 及以上或者 M 系列芯片。原因很简单FEX-Emu 的翻译开销需要足够的算力来兜底老芯片跑起来会非常吃力。我在一台 A12 设备上试过光是启动 Wine 的前置环境就花了好几分钟实际运行程序基本没有可用性。换到 M1 的 iPad 上体验完全是两个档次。系统版本方面需要较新的 iOS 或 iPadOS。这里涉及一个关键概念叫“开发者模式”。从 iOS 16 开始苹果要求侧载和调试类应用必须开启开发者模式才能运行。开启路径在“设置 - 隐私与安全性”里如果找不到这个选项通常需要先通过 Xcode 或者相关工具触发一次它才会出现。网上有人问“iOS 26.3.1 怎么开发者模式”思路是一样的先在设备上尝试安装一个需要调试权限的应用系统就会提示你去开启。存储空间方面预留至少 10GB 以上。Wine 的前缀目录prefix、FEX-Emu 的缓存、DXMT 的着色器缓存加起来占用不小而且随着你安装的程序增多会持续膨胀。3.2 获取与部署核心组件Madeira 相关的组件获取渠道比较分散我按依赖顺序梳理一下。第一步是FEX-Emu 的 iOS 构建版本。FEX-Emu 官方主要面向 Linux 和 AndroidiOS 版本需要找社区构建的产物。这里要注意架构匹配iOS 设备是 ARM64要确认拿到的是 aarch64 版本。第二步是Wine 的 iOS 适配层。原版 Wine 不能直接在 iOS 上跑需要针对 iOS 的沙盒机制、文件系统布局做适配。社区里有几个不同的适配分支选择时重点看它支持的 Wine 版本和最近更新时间。太老的版本可能缺少某些关键 API 的实现。第三步是DXMT 的动态库。DXMT 通常以.dylib或者.so的形式提供需要放到 Wine 能加载的路径下。这里有个细节DXMT 依赖 Metal所以要确保它链接的是 iOS 系统自带的 Metal 框架而不是某个第三方实现。部署时的一个常见问题是路径配置。Wine 需要知道去哪里找 DXMT 的库这通常通过环境变量或者注册表项来指定。如果路径配错了程序启动时会报“找不到 d3d11.dll”之类的错误但实际上是 DXMT 没被正确加载。实操心得部署完成后先用一个极简的 Windows 程序测试比如一个只弹个窗口的 Hello World。不要一上来就扔一个大型游戏进去那样出问题时你根本不知道是哪一层的问题。从简到繁逐层验证这是排查这类环境问题的铁律。3.3 初始化 Wine 前缀与基础配置Wine 前缀prefix是 Wine 为每个“Windows 环境”维护的一套目录结构里面模拟了 C 盘、注册表、系统目录等。初始化前缀的命令大致是这样的WINEPREFIX/path/to/prefix wineboot -u这条命令会创建前缀目录并初始化注册表。在 iOS 环境下路径要指向应用沙盒内可读写的目录不能指向系统保护区域。初始化完成后建议做几项基础配置。一是设置 Windows 版本通过winecfg把版本设成 Windows 10因为很多现代程序会检查系统版本设成太老的版本会被拒绝运行。二是配置 DLL 覆盖DLL override把d3d11、dxgi这些指向 DXMT 提供的实现而不是 Wine 自带的Wine 自带的 D3D 实现性能很差。WINEPREFIX/path/to/prefix winecfg在winecfg的“函数库”标签页里添加d3d11和dxgi都设为“原装”native。这一步做完程序调用 D3D 时才会走 DXMT 而不是 Wine 内置的转换层。3.4 第一个程序的运行与验证环境搭好后跑第一个程序。建议从简单的 Win32 程序开始比如一个记事本类的工具。运行命令WINEPREFIX/path/to/prefix wine /path/to/program.exe如果程序窗口正常弹出说明 FEX-Emu 和 Wine 这两层基本通了。如果窗口出不来但进程没崩大概率是图形层的问题需要检查 DXMT 的加载日志。验证图形层是否工作可以跑一个带 D3D 渲染的小程序观察是否能正常出画面。DXMT 通常会输出日志里面会显示它拦截了哪些 D3D 调用、创建了哪些 Metal 资源。如果日志里全是“unsupported”或者“fallback”说明这个程序的图形特性 DXMT 还没覆盖到。4. 性能调优与常见问题排查4.1 翻译缓存的预热与持久化FEX-Emu 的性能很大程度上取决于翻译缓存的命中率。第一次运行某个程序时大量指令需要现场翻译会感觉特别卡运行一段时间后热代码都进了缓存流畅度会明显提升。问题是默认情况下这个缓存可能是存在内存里的程序一退出就没了下次运行又要重新翻译。解决办法是开启缓存持久化把翻译结果写到磁盘上。FEX-Emu 有相关的配置项具体参数名各版本可能不同核心思路是指定一个缓存目录并开启“写入缓存”的选项。开启持久化后第一次运行仍然慢但第二次、第三次运行会明显加快。对于需要反复调试的场景这个优化能省下大量等待时间。4.2 图形性能的几个关键开关DXMT 的性能调优空间比指令翻译层要大。几个我实测有效的方向着色器缓存。D3D 程序在首次遇到某个着色器时需要编译编译过程很慢。DXMT 支持把编译好的着色器缓存到磁盘下次直接加载。开启方式和 FEX-Emu 的缓存类似指定缓存目录即可。分辨率缩放。iOS 设备的屏幕分辨率很高如果让程序按原生分辨率渲染GPU 压力会很大。可以在 DXMT 或 Wine 层面设置一个渲染缩放比例比如按 0.5 倍分辨率渲染再放大显示。视觉上会糊一些但帧率提升很明显。帧率限制。有些程序不限制帧率会疯狂占用 GPU 资源导致设备发热降频。设置一个合理的帧率上限比如 30 或 60反而能让帧率更稳定。优化项作用预期收益代价翻译缓存持久化减少重复翻译二次启动速度提升明显占用磁盘空间着色器缓存减少着色器编译卡顿首次运行后的卡顿减少占用磁盘空间分辨率缩放降低 GPU 负载帧率提升 30% 以上画面清晰度下降帧率限制稳定 GPU 占用帧率更平稳发热降低峰值帧率受限4.3 常见报错与排查思路这类环境出的问题报错信息往往很模糊需要靠经验缩小范围。我整理了几个高频问题。问题一程序启动后立即退出没有任何窗口。这种情况优先查 Wine 的日志。把WINEDEBUG环境变量设成all或者loaddll看程序加载了哪些 DLL、在哪一步失败。常见原因是缺少某个运行库比如 VC 运行库或者 .NET Framework。这些运行库需要单独安装到 Wine 前缀里。问题二窗口出来了但全黑或者花屏。这是图形层的问题。先确认 DXMT 是否被正确加载检查 DLL 覆盖设置。如果 DXMT 加载了但还是黑屏可能是程序用了 DXMT 尚未支持的 D3D 特性。查看 DXMT 日志里有没有“unsupported feature”之类的记录。问题三程序运行极慢帧率个位数。先排除是不是翻译缓存没生效。如果缓存正常那可能是程序本身计算量太大超出了设备的翻译能力。这时候只能降低预期或者换更轻量的程序。问题四中文显示成方块或乱码。这是字体问题。Wine 前缀里默认的字体可能不包含中文字形。解决办法是把系统中文字体复制到 Wine 的字体目录或者在注册表里配置字体替换。网上搜“wine 乱码”能找到不少方案核心都是补字体。注意排查问题时一次只改一个变量。同时改多个配置出问题后你无法判断是哪个改动导致的。这个原则在调试任何复杂系统时都适用。4.4 兼容性速查与预期管理不是所有 Windows 程序都能跑起来兼容性取决于程序用到了哪些 API 和图形特性。根据我的经验大致可以这样分类程序类型兼容性预期说明简单 Win32 工具较高API 调用简单图形需求低基于 D3D9 的老游戏中等DXMT 对 D3D9 支持较好基于 D3D11 的程序中等偏下依赖具体用到的特性基于 D3D12 的新程序较低DXMT 的 D3D12 支持尚不完善依赖 .NET 的程序看情况需要额外安装 .NET 运行时反作弊保护的程序基本不行反作弊会检测运行环境这个表不是绝对的具体程序具体分析。但如果你要跑的是带反作弊的在线游戏基本可以放弃那类程序会主动检测自己是否运行在非原生环境检测到就拒绝启动。5. 这套方案还能怎么用延伸场景与替代思路5.1 不只是 iOS同类架构在其他平台的应用Madeira 这套“FEX-Emu Wine 图形转换层”的架构思路并不局限于 iOS。在 Linux ARM 设备上类似组合是 Box86/Box64 Wine DXVK把 D3D 转成 Vulkan。在 macOS 上有 CrossOver 这类商业方案底层也是 Wine 加图形转换。理解了这个通用架构你在其他平台上遇到类似需求时就能快速判断该找哪些组件。核心永远是三件事指令翻译、API 翻译、图形翻译。哪一层缺失就去找对应的开源实现。5.2 开发者的视角这套东西对做 App 有什么启发如果你是从 iOS 开发的角度看这个项目有几个点值得琢磨。一是沙盒环境下的动态库加载。Madeira 能在 iOS 沙盒里加载并运行 DXMT 这样的动态库说明 iOS 的沙盒并非完全封闭在合规的前提下有可操作空间。当然上架 App Store 的应用不能这么做但企业内部分发或者自用场景下这些技术细节有参考价值。二是跨架构的性能评估方法。如果你在评估“把某个 x86 服务迁移到 ARM”的可行性FEX-Emu 这类工具可以帮你快速做原型验证先跑起来看性能瓶颈在哪再决定是重新编译还是继续用翻译方案。三是图形 API 转换的工程复杂度。DXMT 把 D3D 转 Metal 的工作量是巨大的这提醒我们在做技术选型时如果涉及图形 API 的跨平台要么统一用跨平台引擎如 Unity、Unreal要么做好投入大量人力做转换层的准备。5.3 替代方案对比什么时候不该用 MadeiraMadeira 不是唯一的选择也不总是最优选择。几种常见替代思路远程桌面方案。如果只是想在 iOS 上用 Windows 程序远程连接到一台真正的 Windows 机器是最省事的。性能取决于网络但兼容性是 100%。缺点是依赖网络且需要另一台机器常开。云电脑方案。和远程桌面类似但机器在云端。优点是随时随地可用缺点是持续付费且对网络延迟敏感。原生替代软件。很多 Windows 程序在 iOS 上有功能相近的原生替代品。如果不是非某个特定程序不可用原生应用体验会好得多。Madeira 的适用场景其实很窄你有一个非跑不可的 Windows 程序没有原生替代不想依赖网络和另一台机器且愿意折腾。满足这些条件才值得投入时间。6. 我在实际折腾中攒下的几条经验最后分享几条踩坑踩出来的体会都是文档里不会写的。关于预期。这类项目的宣传往往带着“在手机上跑 Windows 游戏”的噱头但实际体验和原生差距巨大。我见过太多人兴冲冲搭好环境发现帧率只有个位数就放弃了。正确的预期是能跑起来就是胜利能跑到可玩的程度是惊喜。把它当成技术探索而不是娱乐方案。关于时间投入。搭建环境本身可能就要花几个小时调试一个程序跑起来可能又要几个小时。如果你时间紧张建议直接找现成的整合包或者社区做好的配置不要从零开始编译。从零编译 FEX-Emu 和 Wine 的 iOS 版本对工具链和编译环境的要求不低容易卡在编译错误上出不来。关于社区。这类项目的文档普遍不完善很多关键信息散落在论坛帖子和聊天记录里。遇到问题时先搜社区里有没有人遇到过同样的问题往往比啃源码快得多。同时自己解决问题后记得把过程记录下来分享出去这个生态靠的就是互相填坑。关于设备发热。翻译执行对 CPU 的占用远高于原生执行设备发热是必然的。长时间高负载运行会触发降频帧率断崖式下跌。建议在散热条件好的环境下使用或者主动限制性能上限避免设备过热。关于数据安全。从非官方渠道获取的组件来源要谨慎。Wine 前缀里可能会存放程序的配置和存档重要数据做好备份。不要在这类环境里登录重要账号避免不必要的风险。这套东西目前还在快速演进中FEX-Emu 的翻译效率在提升DXMT 支持的 D3D 特性在增加Wine 的兼容性也在持续改善。今天跑不起来的程序过几个月可能就能跑了。保持关注定期更新组件是维持可用性的必要动作。