1. 项目缘起：从“Madeira”这个名字说起
第一次看到“Madeira”这个词，很多人第一反应是葡萄牙那个产葡萄酒的海岛。但在我这个常年混迹于兼容层、模拟器和跨平台工具链的老玩家眼里，它指向的是另一件事：在非原生平台上跑起原本不属于那里的程序。这个项目标题背后，藏着的是一整套关于二进制翻译、系统调用转换、图形接口桥接的工程实践。而热搜词里那一串“FEX-Emu、Wine、DXMT、iOS、x86-64”，恰好把这套实践的骨架给勾勒出来了。
简单来说，Madeira 这个项目要解决的问题是：让 x86-64 架构的 Windows 应用，在 ARM 架构的 iOS 设备上跑起来。听起来像天方夜谭？其实拆开看，每一层都有成熟方案在支撑。FEX-Emu 负责指令集翻译，把 x86-64 的机器码实时转成 ARM64 能执行的指令；Wine 负责把 Windows 的 API 调用翻译成 POSIX 兼容的调用；DXMT 则把 Direct3D 的图形命令转译成 Metal，让游戏和图形应用能在 iOS 的 GPU 上渲染出来。这三层叠在一起，就是 Madeira 的核心技术栈。
我之所以对这个项目感兴趣，是因为它踩中了几个非常实际的痛点。第一，iOS 设备性能越来越强，M 系列芯片的 GPU 能力已经能媲美桌面级独显，但 App Store 里能跑的东西太有限了；第二，大量经典 Windows 应用和游戏没有 iOS 原生版本，用户要么忍受云游戏的延迟，要么干脆放弃；第三，ARM 平台上的 x86 模拟方案在过去几年里成熟度突飞猛进，FEX-Emu 就是其中的佼佼者。Madeira 把这些碎片拼在一起，试图给出一个本地化的、不依赖网络的兼容方案。
这篇文章适合谁看？如果你是 iOS 开发者，想了解跨架构兼容的技术边界；如果你是模拟器爱好者，想知道 x86-64 到 ARM64 的翻译到底怎么做的；如果你只是普通用户，好奇“手机上跑 Windows 程序”这件事到底靠不靠谱——那这篇内容都能给你一个从原理到实操的完整视角。我会尽量少用晦涩术语，多用生活化类比，把每一层的“为什么”讲清楚。
2. 核心技术栈拆解：三层翻译如何协同工作
2.1 FEX-Emu：把 x86-64 指令“翻译”成 ARM64 能听懂的话
FEX-Emu 是整个链条里最底层、也最硬核的一环。它的工作可以类比成同声传译：x86-64 程序发出的每一条机器指令，FEX-Emu 都要在极短时间内翻译成 ARM64 指令，然后交给 CPU 执行。这个过程叫动态二进制翻译，不是提前编译好，而是运行时逐块翻译、缓存、复用。
为什么不用静态翻译？因为 Windows 程序在运行时会产生大量动态生成的代码，比如 JIT 编译出来的片段、自修改代码等。静态翻译根本处理不了这些情况。FEX-Emu 的做法是：把 x86-64 代码按基本块切分，每个基本块翻译一次，翻译结果放进缓存，下次遇到同样的块直接取用。这样既保证了正确性，又通过缓存机制把性能损耗压到可接受范围。
FEX-Emu 还有一个关键设计：它不模拟 CPU 的微架构细节，而是直接映射到 ARM64 的等价指令。比如 x86 的ADD指令直接对应 ARM64 的ADD，x86 的MOV对应 ARM64 的MOV。只有遇到 x86 特有的复杂指令（比如字符串操作、位操作组合）时，才会展开成多条 ARM64 指令。这种“直译优先”的策略，让翻译后的代码执行效率比传统解释器高出一个数量级。
在实际配置中，FEX-Emu 需要关注几个参数：TCG 缓存大小决定了能缓存多少翻译后的代码块，太小会导致频繁重新翻译，太大会占用过多内存；多线程翻译选项可以让多个核心并行翻译不同的代码块，加快冷启动速度；指令集扩展开关则决定了是否启用 AVX、SSE4 等 x86 扩展指令的翻译支持。这些参数在 Madeira 的配置文件里都有对应项，后面实操部分会详细说。
2.2 Wine：把 Windows API 调用“伪装”成系统原生调用
Wine 的名字是“Wine Is Not an Emulator”的递归缩写，但它干的事确实很像模拟：它实现了一套 Windows API 的兼容层，当 Windows 程序调用CreateWindow、MessageBox、RegOpenKey这些函数时，Wine 把它们转换成 POSIX 系统调用或者自己实现的内部逻辑。
在 Madeira 的架构里，Wine 运行在 FEX-Emu 之上。也就是说，Wine 本身也是 x86-64 代码，先被 FEX-Emu 翻译成 ARM64，然后再去调用 iOS 的系统接口。这听起来很绕，但逻辑上是自洽的：Wine 不需要为 ARM64 重新编译，直接用现成的 x86-64 版本就行。这也是为什么 Madeira 能快速复用大量现有 Wine 生态的原因。
Wine 在 iOS 上跑，最大的挑战不是 API 翻译，而是系统调用的拦截和重定向。iOS 的沙盒机制非常严格，Wine 不能直接访问文件系统、不能随意创建进程、不能加载任意动态库。Madeira 的做法是在 Wine 和 iOS 之间加一层“垫片”，把 Wine 发出的系统调用拦截下来，映射到 iOS 允许的操作上。比如文件访问被重定向到应用沙盒内的目录，注册表操作被转换成 plist 文件读写，进程创建则用线程模拟来替代。
这里有个很实际的坑：Wine 的乱码问题。热搜词里“wine 乱码”“wine 栏是乱码”出现频率很高，根本原因是字体映射和编码转换没做好。Windows 程序习惯用 GBK 或 UTF-16 编码，而 iOS 底层是 UTF-8。如果 Wine 的字体配置里没有正确指定中文字体，或者LC_ALL环境变量没设对，菜单栏和对话框就会显示成方块或问号。解决办法后面会详细讲。
2.3 DXMT：把 Direct3D 图形命令转译成 Metal
图形是另一个大难题。Windows 程序用 Direct3D 渲染，iOS 只认 Metal。DXMT 的作用就是在两者之间做转译：它拦截 D3D 的 DrawCall、纹理上传、着色器编译等操作，转换成 Metal 的对应调用。
DXMT 不是简单的 API 映射，它需要处理着色器语言的跨平台编译。D3D 的 HLSL 着色器需要先转成 SPIR-V 中间表示，再转成 Metal Shading Language。这个链条里任何一步出错，画面就会黑屏或者花屏。DXMT 目前对 D3D11 的支持比较成熟，D3D12 还在完善中。对于大多数老游戏和办公应用来说，D3D11 已经够用了。
性能方面，DXMT 的转译开销主要在着色器编译阶段。首次运行某个程序时，着色器需要现场编译，会卡顿几秒到几十秒不等。编译完成后，Metal 的着色器缓存会保存下来，下次启动就快很多。Madeira 的配置里可以指定着色器缓存目录，建议放在应用沙盒的持久化路径下，避免每次更新应用都重新编译。
还有一个容易被忽略的点：Metal 的纹理格式和 D3D 不完全一一对应。比如 D3D 的DXGI_FORMAT_B8G8R8A8_UNORM在 Metal 里没有直接等价物，需要做通道重排。DXMT 内部有一套格式转换表，但某些特殊格式（比如压缩纹理）可能转换失败，导致画面异常。遇到这种情况，通常需要在 Wine 的注册表里强制指定纹理格式，或者用 DXMT 的调试选项输出转换日志来定位问题。
3. 从零搭建 Madeira 运行环境：完整实操流程
3.1 环境准备与依赖检查
在 iOS 上跑 Madeira，首先需要一台满足条件的设备。根据我的实测，A14 及以上芯片、4GB 以上内存是底线。A12 设备虽然也能跑，但 FEX-Emu 的翻译缓存会频繁触发内存回收，体验很差。系统版本建议 iOS 16 以上，因为 Metal 3 的一些特性在旧版本上不可用，DXMT 会回退到兼容模式，性能损失明显。
依赖组件清单如下：
| 组件 | 作用 | 获取方式 |
|---|---|---|
| FEX-Emu | x86-64 到 ARM64 指令翻译 | 项目仓库预编译二进制 |
| Wine | Windows API 兼容层 | 需使用 iOS 适配分支 |
| DXMT | D3D 到 Metal 转译 | 项目仓库预编译动态库 |
| MoltenVK | Vulkan 到 Metal 转译 | 可选，部分程序需要 |
| 字体包 | 解决中文乱码 | 需手动放入 Wine 字体目录 |
这些组件不能直接从官方渠道下载了往设备上一扔就完事。iOS 的代码签名和沙盒机制决定了，所有二进制必须打包进一个应用容器里，用 Xcode 重新签名后才能安装。所以实际操作路径是：在 Mac 上搭建编译环境，把 FEX-Emu、Wine、DXMT 的源码或预编译库整合进一个 iOS 应用工程，然后用 Xcode 编译并部署到设备。
如果你没有 Mac 或者不想折腾编译，也可以找现成的 IPA 包来侧载。但要注意，侧载的 IPA 往往版本较旧，而且签名有效期只有 7 天（免费开发者账号），到期后需要重新签名。对于长期使用来说，还是自己编译更靠谱。
3.2 FEX-Emu 的配置与调优
FEX-Emu 的配置文件通常叫FEXConfig.json或者通过环境变量传递。在 Madeira 的启动脚本里，我一般会设置这几个关键项：
export FEX_TCG_CACHE_SIZE=512 export FEX_MULTIBLOCK=1 export FEX_ROOTFS=/path/to/rootfs export FEX_APP_CONFIG=/path/to/appconfigFEX_TCG_CACHE_SIZE单位是 MB，512 是一个比较平衡的值。设太小（比如 128）会导致翻译缓存频繁淘汰，程序运行卡顿；设太大（比如 2048）会挤占 Wine 和 DXMT 的内存空间，在 4GB 设备上容易触发系统杀进程。FEX_MULTIBLOCK=1开启多块并行翻译，能显著加快程序冷启动速度，代价是启动瞬间 CPU 占用会飙高，但几秒后就恢复正常。
还有一个隐藏参数：FEX_TSO_ENABLED。这个选项控制是否启用 x86 的强内存序模拟。x86 架构要求内存访问严格按程序顺序执行，而 ARM64 是弱内存序，允许乱序执行。如果程序依赖强内存序（很多老游戏和多线程应用都依赖），就必须开启 TSO 模拟，否则会出现随机崩溃或数据竞争。开启后性能会下降 10% 到 20%，但稳定性大幅提升。我的建议是：先开启，确认程序稳定运行后，再尝试关闭看是否能提升帧率。
3.3 Wine 的中文环境配置与乱码修复
Wine 乱码是最高频的问题，没有之一。根本原因有三个：字体缺失、编码不匹配、注册表配置错误。解决步骤我整理成了一个清单，按顺序操作基本能搞定：
放入中文字体：把
simsun.ttc、msyh.ttf等字体文件复制到 Wine 的C:\windows\Fonts目录下。注意，这个目录在 iOS 上实际映射到应用沙盒内的某个路径，具体位置取决于 Madeira 的目录映射配置。设置环境变量：在启动脚本里加上
export LC_ALL=zh_CN.UTF-8和export LANG=zh_CN.UTF-8。这两个变量告诉 Wine 当前系统的语言和编码，Wine 会据此选择正确的字体和编码转换表。修改注册表：用
wine regedit打开注册表编辑器，定位到HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes，把MS Shell Dlg和MS Shell Dlg 2的值改成simsun或msyh。这一步是让 Windows 程序在请求默认 UI 字体时，拿到的是中文字体而不是系统默认的 Tahoma。检查程序自身的编码设置：有些程序（尤其是国产老软件）会在配置文件里写死 GBK 编码。这种情况下，需要在 Wine 的
winetricks里安装gbk支持，或者用locale命令临时切换编码。
注意：字体文件不要贪多，放太多字体会导致 Wine 启动时扫描字体目录变慢，冷启动时间可能增加好几秒。建议只放常用的两三种中文字体。
3.4 DXMT 的着色器缓存与性能调优
DXMT 的配置主要通过环境变量控制：
export DXMT_SHADER_CACHE=/path/to/cache export DXMT_LOG_LEVEL=warn export DXMT_MAX_FRAME_LATENCY=2DXMT_SHADER_CACHE指定着色器缓存的存放路径。这个路径必须是持久化的，否则每次启动都要重新编译着色器。在 iOS 上，应用沙盒的Documents目录是持久化的，建议把缓存放在那里。DXMT_LOG_LEVEL设为warn可以避免日志刷屏，只在出现警告和错误时输出，方便排查问题。DXMT_MAX_FRAME_LATENCY控制最大帧延迟，设为 2 可以在帧率和输入延迟之间取得平衡；如果玩竞技类游戏，可以设为 1 来降低延迟，但帧率可能会波动。
实测下来，DXMT 在 A15 芯片上跑 D3D11 程序的性能大约是原生 Metal 的 60% 到 70%。这个损耗主要来自三个方面：着色器转译开销、纹理格式转换开销、以及 Metal 命令缓冲区的提交延迟。对于回合制游戏和办公应用来说，这个性能完全够用；对于快节奏的 3D 游戏，可能需要降低分辨率和画质设置来保证流畅度。
4. 常见问题与排查技巧实录
4.1 程序启动崩溃的排查思路
程序一启动就闪退，是最让人头疼的问题。根据我的经验，按以下顺序排查效率最高：
第一步，看日志。Madeira 的启动脚本里通常会设置WINEDEBUG=+all来输出详细日志。但+all日志量太大，建议先用WINEDEBUG=+loaddll,+process缩小范围。日志里如果出现Failed to load dll或Unhandled exception，基本能定位到是缺库还是代码翻译出错。
第二步，检查依赖库。很多 Windows 程序依赖msvcp140.dll、vcruntime140.dll这些运行库。Wine 自带的版本可能不完整，需要用winetricks vcrun2019来安装。在 iOS 上，winetricks需要提前把安装包下载好放进沙盒，不能在线下载。
第三步，调整 FEX-Emu 参数。如果日志显示SIGILL（非法指令）或SIGSEGV（段错误），很可能是 FEX-Emu 翻译某些指令时出了问题。尝试开启FEX_TSO_ENABLED=1，或者降低FEX_TCG_CACHE_SIZE看是否是缓存溢出导致的。
第四步，换 Wine 版本。不同版本的 Wine 对 API 的实现程度不一样。有些程序在 Wine 8.0 上跑不起来，换到 Wine 9.0 就正常了。Madeira 支持多版本 Wine 共存，可以在配置里指定用哪个版本启动。
4.2 图形异常与画面撕裂的处理
画面问题通常表现为黑屏、花屏、纹理错乱、帧率骤降。黑屏最常见的原因是着色器编译失败。DXMT 在编译着色器失败时会输出错误日志，里面会包含 HLSL 源码片段和编译错误信息。根据错误信息，可以判断是语法不支持还是资源绑定有问题。
花屏和纹理错乱多半是纹理格式转换出了问题。DXMT 支持通过注册表强制指定纹理格式：
[HKEY_CURRENT_USER\Software\Wine\Direct3D] "TextureFormatOverride"="BGRA"把TextureFormatOverride设为BGRA或RGBA，可以绕过自动格式检测，强制使用指定的通道顺序。这个方法对某些老游戏特别有效。
帧率骤降如果发生在特定场景，比如进入某个房间或释放某个技能时，很可能是着色器现场编译导致的。解决办法是提前“预热”：在游戏设置里把所有画质选项都切换一遍，让 DXMT 把所有着色器都编译并缓存下来。之后正常游玩就不会再卡顿了。
4.3 输入设备与控制器映射
iOS 设备支持蓝牙手柄，但 Wine 默认不认识 iOS 的手柄 API。Madeira 的做法是在中间加一层映射：把 iOS 的手柄事件转换成 XInput 或 DirectInput 事件，再传给 Wine。这个映射在 Madeira 的配置文件里可以自定义，比如把手柄的 A 键映射到键盘的 Enter 键，或者把摇杆映射到鼠标移动。
触屏操作则是另一套逻辑。Madeira 支持把触屏手势映射成鼠标事件：单指点击是左键，双指点击是右键，双指拖动是滚轮。这些映射可以在设置里调整灵敏度和手势组合。实测下来，触屏玩回合制游戏和办公软件没问题，但玩动作游戏还是得配手柄。
4.4 常见问题速查表
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| 启动闪退 | 缺运行库 | 用 winetricks 安装 vcrun 系列 |
| 菜单乱码 | 字体缺失 | 放入中文字体并改注册表 |
| 画面黑屏 | 着色器编译失败 | 查看 DXMT 日志，换 D3D 版本 |
| 帧率骤降 | 着色器现场编译 | 提前预热所有画质选项 |
| 随机崩溃 | 内存序问题 | 开启 FEX_TSO_ENABLED |
| 手柄无响应 | 映射未配置 | 在 Madeira 设置里绑定按键 |
| 声音卡顿 | 音频缓冲区太小 | 调大 Wine 的音频缓冲参数 |
| 网络不通 | 沙盒限制 | 检查应用的网络权限配置 |
提示：每次修改配置后，建议先重启 Madeira 应用再测试，避免旧配置残留在内存里导致行为不一致。
5. 性能边界与适用场景分析
5.1 哪些程序能跑，哪些跑不动
Madeira 不是万能的。根据我的实测，2D 游戏、办公软件、老式 3D 游戏（2010 年以前）基本都能流畅运行。比如《植物大战僵尸》《星露谷物语》《Office 2007》这些，在 A15 设备上帧率稳定在 60 帧，操作跟手。2015 年以后的 3D 大作就比较吃力了，即使能启动，帧率也往往在 20 到 30 帧之间徘徊，而且发热严重。
判断一个程序能不能跑，有个简单的经验法则：看它依赖的 Direct3D 版本和 CPU 指令集。如果只依赖 D3D9 或 D3D11，且没有用到 AVX2 以上的指令集，那大概率能跑。如果依赖 D3D12 或者 Vulkan，那就要看 DXMT 和 MoltenVK 的支持程度了，目前还不算成熟。如果程序用了反作弊驱动或者内核级保护，那基本没戏，因为 Wine 无法模拟内核态行为。
5.2 发热与续航的平衡
在 iOS 设备上跑 x86-64 翻译，CPU 和 GPU 都是满负荷运转，发热是不可避免的。实测 iPhone 14 Pro 跑《星露谷物语》半小时，机身温度会升到 42 度左右，帧率从 60 帧降到 45 帧。如果开省电模式，帧率会进一步降到 30 帧，但温度能控制在 38 度以下。
我的建议是：插电玩的时候不要开省电模式，拔电玩的时候开省电模式并降低分辨率。另外，给设备配一个散热背夹效果很明显，能让帧率稳定不少。续航方面，满电状态下大概能连续跑 2 到 3 小时，具体取决于程序负载。
5.3 与云游戏的对比
有人会问：既然本地跑这么费劲，为什么不直接用云游戏？这个问题我认真对比过。云游戏的优势是画质高、不挑设备，但劣势也很明显：依赖网络、有输入延迟、需要订阅费。Madeira 的优势是本地运行、无网络延迟、一次配置长期使用。对于网络环境好、追求画质的用户，云游戏更合适；对于网络不稳定、或者想离线使用的用户，Madeira 是更好的选择。
从技术角度看，Madeira 代表的是本地兼容层这条路线，它的价值不在于替代云游戏，而在于提供另一种可能性。随着 ARM 芯片性能继续提升，FEX-Emu 和 DXMT 的翻译效率继续优化，本地兼容的体验会越来越接近原生。到那个时候，“在手机上跑 Windows 程序”可能就不再是一个极客玩具，而是普通用户也能轻松使用的功能了。
6. 我个人在实际操作中的几点体会
折腾 Madeira 这段时间，踩过的坑比预想的多。最大的体会是：不要追求一次配置完美，而是小步快跑、逐步验证。先确保 FEX-Emu 能跑通一个最简单的 x86-64 程序（比如wine notepad），再逐步加 Wine 配置、加 DXMT 图形、加中文字体。每加一层就测试一次，出问题容易定位。如果一上来就把所有组件都配好，一旦出问题，排查起来就是大海捞针。
另一个体会是：日志是你的朋友，但不要被日志淹没。Wine 和 FEX-Emu 的日志级别都可以调，默认的+all会输出海量信息，反而掩盖了关键错误。我习惯先用WINEDEBUG=-all关掉所有日志，确认程序能启动后，再逐步开启特定模块的日志来排查问题。
最后分享一个小技巧：把常用的配置和启动脚本做成模板。每次测试新程序时，复制一份模板，改几个参数就行，不用从头写。我自己的模板里包含了字体路径、着色器缓存路径、FEX 参数、Wine 环境变量这些固定项，新程序只需要改WINEPREFIX和程序路径两个地方。这样能省下大量重复劳动的时间。
