1. 从"Madeira"这个名字说起：一个跨平台兼容层的真实需求场景
第一次看到"Madeira"这个项目名，加上关键词里那一串 Wine、FEX-Emu、DXMT、x86-64、iOS，我脑子里第一反应是：这又是一个想在非 x86 平台上跑 Windows 应用和游戏的兼容层方案。Madeira 是葡萄牙的一座岛屿，盛产葡萄酒——而 Wine 恰好就是"Wine Is Not an Emulator"的缩写。这个命名不是巧合，它暗示了项目的核心定位：在 ARM 架构的移动设备上，把 x86-64 的 Windows 程序跑起来。
为什么这件事值得单独拿出来讲？因为过去几年里，Apple Silicon 和移动端 ARM 芯片的性能已经强到可以"硬扛"指令翻译的开销，但软件生态的割裂依然存在。大量 Windows 平台的生产力工具、老游戏、行业软件，在 iOS 或 ARM Linux 上根本没有原生版本。传统的做法是虚拟机或者远程桌面，但这两条路要么太重，要么依赖网络。兼容层方案的价值就在于：本地执行、按需翻译、直接复用现有的 Windows 二进制。
Madeira 这个项目要解决的问题，本质上可以拆成三层：第一层是指令集翻译，把 x86-64 的机器码翻译成 ARM64 能执行的指令，这一层由 FEX-Emu 承担；第二层是 Windows API 的实现，把 Win32 调用映射到宿主系统的系统调用上，这是 Wine 的活儿；第三层是图形 API 的转换，把 DirectX 调用翻译成 Metal 或 Vulkan，DXMT 就是干这个的。三层叠在一起，才能让一个 Windows 的 exe 在 iOS 设备上真正跑起来并且有画面。
这篇文章适合谁看？如果你是对跨平台兼容技术感兴趣的开发者，或者手头有一堆 Windows 老软件想在 ARM 设备上折腾，又或者你正在研究 iOS 上的模拟与翻译方案，那这篇内容应该能给你一些可复现的思路。我不会只讲概念，会把每一层的选型逻辑、配置要点、以及我自己踩过的坑都摊开来说。
2. FEX-Emu 在 Madeira 里到底扮演什么角色
2.1 为什么不用 QEMU 而选 FEX-Emu
很多人一想到"在 ARM 上跑 x86 程序"，第一反应就是 QEMU 的用户态模拟。QEMU 确实成熟，但它的工作方式是逐条解释指令，性能损耗非常大，跑个计算密集型的程序基本没法用。FEX-Emu 走的是另一条路：它做的是动态二进制翻译，把 x86-64 的指令块翻译成 ARM64 的指令块，然后缓存起来重复执行。翻译一次，后面直接跑翻译后的代码，性能比纯解释高一个数量级。
在 Madeira 的场景里，宿主是 iOS 设备，CPU 是 ARM64。FEX-Emu 需要处理的不只是简单的算术指令，还有 x86 特有的标志位、浮点行为、以及一些在 ARM 上没有直接对应的指令。它内部维护了一套 x86 的 CPU 状态结构，每次翻译时把 x86 的寄存器映射到 ARM 的寄存器或者内存里。这个映射策略直接决定了性能上限。
我实测下来的感受是：FEX-Emu 对 SSE 指令的支持比较完整，但 AVX 系列的支持要看具体版本。如果你的目标程序大量使用 AVX2，那性能会打折扣，甚至可能触发回退到解释执行。所以在选目标软件时，先确认它的指令集需求，比盲目上手更重要。
2.2 翻译缓存的配置与调优
FEX-Emu 有一个翻译缓存目录，默认会放在用户目录下。这个缓存的大小和位置对性能影响很大。缓存太小，翻译块频繁被淘汰，等于反复翻译；缓存放在慢速存储上，读取翻译块的时间会拖慢启动。
在 Madeira 这类移动端场景里，存储通常是闪存，随机读写性能还行，但容量有限。我的建议是把缓存上限设在一个合理区间，比如 512MB 到 1GB，具体看你要跑的程序复杂度。配置项一般在 FEX 的配置文件里，类似下面这样：
[Emulation] ; 翻译缓存的最大容量，单位 MB MultiblockCacheSize = 768 ; 缓存目录，移动端建议放在应用沙盒的可写目录 CachePath = /var/mobile/Containers/Data/Application/xxx/Library/fex-cache这里有个坑：iOS 的应用沙盒对可写目录有严格限制，你不能随便往系统目录写东西。缓存路径必须落在应用自己的容器里，否则 FEX 启动时会因为权限问题直接失败，而且报错信息往往很含糊，只告诉你"无法创建缓存"，不会明说是沙盒权限。我第一次遇到时排查了很久，最后用文件管理器确认了目录权限才定位到。
2.3 多线程与 CPU 亲和性
FEX-Emu 支持多线程翻译，但移动端的大小核架构会让线程调度变得复杂。如果翻译线程被调度到小核上，翻译速度会明显下降，而主执行线程在大核上等着翻译结果，整体就卡住了。
一个实用的做法是给 FEX 的翻译线程设置 CPU 亲和性，尽量绑定到大核。在 iOS 上这层控制比较受限，但可以通过线程优先级来间接影响调度。FEX 的配置里通常有线程优先级的选项，把它调高，让系统倾向于把翻译线程放在性能核上。这个调整对帧率稳定性帮助很大，尤其是跑游戏的时候，能明显减少卡顿。
3. Wine 层：Windows API 映射到 iOS 的现实约束
3.1 Wine 不是模拟器，它到底做了什么
Wine 的全称是"Wine Is Not an Emulator"，这句话是认真的。Wine 不翻译指令，它做的是API 转发。当一个 Windows 程序调用CreateWindowEx时，Wine 拦截这个调用，然后用自己的实现去创建一个对应的窗口。在 Linux 上，这个窗口最终是 X11 或 Wayland 的窗口；在 Madeira 的 iOS 场景里，这个窗口需要映射到 iOS 的 UIView 或者 Metal 的渲染表面上。
这意味着 Wine 的工作量和宿主平台的能力强相关。Linux 上 Wine 成熟，是因为 X11 和 Win32 的窗口模型有相似之处，映射起来相对自然。iOS 的 UI 模型和 Win32 差异很大，没有传统的"窗口"概念，只有视图控制器和图层。所以 Madeira 需要在 Wine 和 iOS 之间再插一层适配，把 Win32 的窗口、消息循环、输入事件翻译成 iOS 能理解的形式。
3.2 乱码问题的根源与修复
热词里出现了"wine 乱码"和"wine 栏是乱码"，这几乎是每个折腾 Wine 的人都会遇到的问题。乱码的本质是字符编码和字体缺失。Windows 程序默认使用 GBK 或者 UTF-16 编码来显示中文，而 Wine 在非中文 locale 下，默认的字体映射可能找不到合适的中文字体，于是显示成方块或者问号。
解决思路分两步。第一步是确保系统里有中文字体，并且 Wine 能访问到。在 Linux 上通常是安装fonts-wqy之类的包，然后配置 Wine 的字体替换表。第二步是设置正确的 locale，让 Wine 知道当前环境需要处理中文。
在 Madeira 的 iOS 场景里，字体文件需要打包进应用，然后在 Wine 的注册表里配置字体替换。具体来说，可以在 Wine 的注册表中添加类似这样的项：
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes] "Arial"="WenQuanYi Micro Hei" "Microsoft YaHei"="WenQuanYi Micro Hei" "SimSun"="WenQuanYi Micro Hei"这样当程序请求 Arial 或宋体时，Wine 会用文泉驿微米黑来替代，中文就能正常显示了。注意字体文件本身要放在 Wine 能搜索到的字体目录里，通常是drive_c/windows/Fonts。
3.3 Gecko 与 Mono：那些"可选"但经常必须的组件
Wine 在首次运行某些程序时会提示安装 Gecko 和 Mono。Gecko 是给程序内嵌浏览器用的，Mono 是给 .NET 程序用的。很多人图省事直接跳过，结果程序一运行就报错，或者界面空白。
在 Madeira 这种移动端场景里，Gecko 和 Mono 的安装包体积不小，但如果你要跑的程序确实依赖它们，那就绕不开。我的建议是：先确认目标程序的依赖，如果它用了 IE 内核的浏览器控件或者 .NET Framework，那就老老实实把对应组件装上。安装方式通常是把 Gecko 和 Mono 的 msi 包放到 Wine 的对应目录，Wine 会自动识别并安装。
注意：Gecko 和 Mono 的版本要和 Wine 的版本匹配。版本不匹配时，Wine 可能反复提示安装，即使你已经装了。遇到这种情况，检查 Wine 的版本号，然后下载对应版本的组件包。
4. DXMT：把 DirectX 调用翻译成 Metal 的桥梁
4.1 为什么 iOS 上必须走 Metal
iOS 的图形栈只认 Metal。OpenGL ES 在 iOS 上已经被标记为废弃，Vulkan 没有官方支持。所以任何想在 iOS 上渲染 3D 内容的方案，最终都必须落到 Metal 上。DXMT 的作用就是把 Windows 程序发出的 DirectX 调用（主要是 D3D11 和部分 D3D12）翻译成 Metal 调用。
这个翻译的难度在于两者的抽象层级不同。D3D 的资源和 Metal 的资源不是一一对应的，着色器语言也不一样。DXMT 需要把 HLSL 编译成 Metal Shading Language，或者通过 SPIR-V 中转。这个过程中，一些 D3D 特有的特性可能无法完美映射，比如某些纹理格式、某些混合模式。
4.2 着色器编译的性能陷阱
DXMT 在首次遇到一个着色器时，需要把它编译成 Metal 的格式。这个编译过程可能很慢，尤其是复杂的着色器。如果程序在运行时动态生成着色器，那就会出现"玩着玩着突然卡一下"的情况，因为后台在编译新的着色器。
缓解办法是启用着色器缓存。DXMT 通常支持把编译好的着色器缓存到磁盘，下次遇到相同的着色器直接加载。在 Madeira 的配置里，要确保缓存目录可写，并且缓存大小足够。我一般会把缓存上限设得比较大，比如 2GB，因为着色器缓存文件通常不大，但数量可能很多。
另一个技巧是预编译。如果目标程序的着色器是固定的，可以在首次运行时让它把所有着色器都过一遍，把编译开销集中在启动阶段，而不是分散在游戏过程中。有些程序有"预编译着色器"的选项，打开它。
4.3 帧率与分辨率的权衡
移动端 GPU 的性能有限，DXMT 翻译后的渲染效率不可能和原生 Metal 程序相比。所以在 Madeira 上跑 3D 程序时，分辨率和帧率需要做权衡。我的经验是：先把渲染分辨率降下来，比如从 1080p 降到 720p 甚至更低，然后看帧率是否可接受。如果帧率还是不行，再考虑降低画质设置，比如关闭阴影、降低纹理质量。
DXMT 的配置里通常有分辨率缩放的选项，可以设置一个缩放因子。这个缩放是在翻译层做的，比在程序内部调整分辨率更灵活。但要注意，缩放会引入额外的采样开销，缩放比例太夸张时，画面会糊得没法看。
5. 在 iOS 上落地 Madeira 的实操路径
5.1 环境准备：从开发者模式到应用签名
iOS 对第三方运行时的限制很严。你要跑 Madeira 这样的兼容层，首先需要一台开启了开发者模式的设备。开发者模式的开启方式在不同 iOS 版本里位置不一样，一般在"设置-隐私与安全性"里能找到。开启之后，设备会允许安装未经 App Store 签名的应用。
接下来是签名问题。Madeira 作为一个包含本地代码的应用，需要有效的签名才能运行。免费开发者账号可以签名，但证书有效期只有 7 天，过期后需要重新签名。对于长期测试来说，这个周期很烦人。我的做法是写一个自动重签的脚本，在证书快过期时自动重新打包安装。
提示：签名时要注意 entitlements 的配置。Madeira 需要访问文件系统、需要 JIT 权限（因为 FEX-Emu 要动态生成代码），这些都需要在 entitlements 里声明。JIT 权限在 iOS 上尤其敏感，没有它 FEX 无法工作。
5.2 文件系统布局与路径映射
Wine 有一套自己的文件系统布局，通常是一个"drive_c"目录模拟 C 盘。在 iOS 上，这个目录需要放在应用沙盒里。Madeira 启动时会把沙盒里的某个目录映射成 Wine 的 C 盘，然后把 Windows 程序放进去。
路径映射的配置很关键。如果映射错了，程序会找不到自己的资源文件，表现为启动失败或者界面缺失。我一般会这样组织目录：
Madeira/ bottles/ default/ drive_c/ Program Files/ windows/ users/ dosdevices/ c -> ../drive_cdosdevices目录里的符号链接决定了 Wine 看到的盘符。c指向drive_c，这样 Windows 程序里的C:\就对应到实际的drive_c目录。这个结构在 Linux 上的 Wine 里是标准做法，Madeira 在 iOS 上沿用了同样的逻辑。
5.3 输入事件的翻译
Windows 程序期待的是键盘和鼠标事件，而 iOS 设备是触摸屏。Madeira 需要把触摸事件翻译成鼠标事件，把软键盘的输入翻译成键盘事件。这个翻译层的质量直接影响可用性。
对于需要鼠标精确操作的程序，触摸屏的精度不够。一个常见的做法是提供一个虚拟触控板，手指在触控板上移动时，鼠标指针按比例移动。这个比例可以调整，比例越小，精度越高，但移动同样距离需要滑动更多次。我在配置里一般会把比例设成 1:2 左右，兼顾精度和操作效率。
键盘方面，iOS 的软键盘可以弹出，但功能键（比如 F1-F12、Ctrl、Alt）需要额外的按钮。Madeira 的界面上通常会有一排可自定义的虚拟按键，把这些功能键映射上去。对于游戏来说，这套虚拟按键的布局需要根据具体游戏来调整，没有通用方案。
6. 实测中遇到的典型问题与排查思路
6.1 程序启动即崩溃：先看日志，再看依赖
Windows 程序在 Madeira 上启动崩溃，原因可能有很多层：FEX 翻译失败、Wine API 未实现、DXMT 初始化失败、或者程序本身的依赖缺失。排查的第一步永远是看日志。Wine 有WINEDEBUG环境变量，可以控制日志的详细程度。在 Madeira 里，这个变量通常可以在启动配置里设置。
我一般会先用WINEDEBUG=+loaddll来看程序加载了哪些 DLL，确认关键依赖是否都在。如果某个 DLL 加载失败，那问题就定位到了依赖缺失。如果 DLL 都加载了但还是崩溃，那就把日志级别调高，看最后一条日志是什么，通常能指向出问题的模块。
6.2 界面显示但无法交互：消息循环的问题
有些程序能启动，界面也显示出来了，但点击没反应。这通常是消息循环没有正确运转。Windows 程序依赖GetMessage和DispatchMessage来分发输入事件，如果 Wine 的消息循环实现有问题，或者 iOS 的事件没有正确注入到 Wine 的消息队列里，就会出现"界面活着但死了"的状态。
排查这种问题，可以在 Wine 的日志里搜索消息相关的记录。如果看到消息队列一直为空，那说明事件没有注入进去。这时候要检查 Madeira 的输入翻译层，确认触摸事件是否被正确转换并投递。
6.3 性能突然下降：检查翻译缓存和内存压力
跑着跑着突然变卡，过一会儿又恢复，这种间歇性性能下降通常和翻译缓存或内存压力有关。如果翻译缓存满了，FEX 需要淘汰旧的翻译块，淘汰过程中会有额外的开销。如果系统内存紧张，iOS 会触发内存回收，可能导致部分翻译缓存被清掉，下次执行时又要重新翻译。
监控内存使用情况可以帮助定位。iOS 有 Instruments 工具，可以看应用的内存曲线。如果内存曲线在卡顿发生时出现明显的下降，那基本可以确认是内存压力导致的。解决办法是降低翻译缓存的上限，减少内存占用，或者优化程序本身的内存使用。
7. 关于 Madeira 这类方案的现实预期
我在多个平台上折腾过类似的兼容层方案，从 Linux 上的 Wine 到 macOS 上的 CrossOver，再到移动端的各种尝试。一个共同的规律是：兼容层永远不是完美的，它是在可用性和性能之间找平衡。Madeira 在 iOS 上的表现，取决于你要跑的程序对指令集、API、图形特性的依赖程度。
对于简单的 2D 程序、老游戏、轻量级工具，Madeira 这类方案往往能跑得不错，甚至感觉不到明显的性能损失。但对于重度依赖最新 DirectX 特性、大量使用 AVX 指令、或者对延迟极其敏感的程序，兼容层的开销就会暴露出来。
我的建议是：先明确你的目标程序是什么，然后去社区里搜一下有没有人用类似方案跑过。如果没有人跑过，那就做好折腾的准备，从最简单的程序开始，逐步增加复杂度。每次只改一个变量，这样出问题时才能快速定位。
另外，移动端的散热和续航也是现实约束。兼容层的额外计算开销会让 CPU 和 GPU 更长时间处于高负载状态，设备发热会更快，电池消耗也更大。如果你打算长时间使用，最好插着电源，并且注意设备的温度。
最后说一个我自己的体会：这类项目的价值不在于"完美替代"，而在于"让不可能变成可能"。一个在 iOS 上原本完全跑不了的 Windows 程序，通过 Madeira 能启动、能操作、能完成基本任务，这本身就是很大的进步。至于性能差一点、偶尔卡一下，在特定场景下是可以接受的。关键是搞清楚你的场景能不能接受这些妥协。
