1. 从“Madeira”这个名字说起它到底是个什么东西第一次看到“Madeira”这个词大多数人脑子里蹦出来的可能是那座葡萄牙的度假海岛或者是一种叫马德拉的加强葡萄酒。但在我这个常年折腾跨平台兼容层的人眼里Madeira 是另一码事——它是一套围绕 Wine 生态构建的、面向移动端和桌面端的 Windows 应用兼容方案核心目标就一个让原本只能在 Windows 上跑的程序在别的系统上也能正常启动、正常显示、正常交互。你可能会问Wine 不是早就有了吗怎么又冒出来一个 Madeira这里得把关系理清楚。Wine 本身是一个兼容层它把 Windows 的系统调用翻译成宿主系统能理解的调用从而让 exe 文件不需要虚拟机就能跑起来。但 Wine 在移动端的表现一直不太理想尤其是触屏交互、图形渲染、输入法适配这几块坑特别多。Madeira 做的事情就是在 Wine 的基础上做了一层“移动端友好”的封装把 FEX-Emu、DXMT 这些组件整合进来解决 x86-64 指令集在 ARM 设备上的翻译问题以及 DirectX 到 Metal 的图形转换问题。所以当你看到热搜词里同时出现 Wine、FEX-Emu、DXMT、iOS、x86-64 这几个词的时候它们其实指向的是同一个技术栈的不同层次。Wine 负责 API 翻译FEX-Emu 负责指令集翻译DXMT 负责图形层转换iOS 是目标平台之一x86-64 是需要被翻译的源指令集。Madeira 就是把这几个东西串起来的那根线。这篇文章适合谁看如果你是在移动设备上折腾 Windows 应用的人或者你在做跨平台兼容性测试又或者你只是好奇为什么有些 exe 能在手机上跑起来那这篇内容应该能给你一些实在的参考。我会从整体设计思路讲到具体实操再到踩过的坑尽量把每个环节都说明白。2. 整体架构拆解为什么是这套组合拳2.1 Wine 做 API 翻译但它不是万能的Wine 的核心思路是“不模拟硬件只翻译调用”。Windows 程序运行时需要调用大量的系统 DLL比如 kernel32.dll、user32.dll、gdi32.dll 这些。Wine 自己实现了一套兼容的 DLL当程序调用这些函数时Wine 把它转换成宿主系统的对应操作。这样做的好处是性能损耗小因为不需要模拟整个 CPU 指令集。但 Wine 有个前提宿主系统的 CPU 架构必须和程序一致。也就是说x86 的 Wine 只能跑 x86 的程序ARM 的 Wine 只能跑 ARM 的程序。这就引出了下一个问题——现在大量移动设备是 ARM 架构而大量 Windows 应用是 x86-64 编译的怎么让它们对上2.2 FEX-Emu 补上指令集翻译这一环FEX-Emu 就是干这个的。它是一个 x86-64 到 ARM64 的指令集翻译层工作方式有点像 Rosetta 2但它是开源的而且专门为游戏和图形密集型应用做了优化。FEX-Emu 会把 x86-64 的机器码动态翻译成 ARM64 的机器码然后交给宿主 CPU 执行。这里有个关键点FEX-Emu 的翻译是“块级”的不是一条一条翻译。它会把一段连续的 x86 指令翻译成一个翻译块缓存起来下次执行到同一段代码时直接复用。这样做的好处是减少了翻译开销但代价是首次执行会有延迟。实测下来对于大多数应用来说这个延迟在可接受范围内但如果是对帧率极其敏感的游戏可能会有轻微卡顿。2.3 DXMT 解决图形 API 的鸿沟Windows 应用大量使用 DirectX 来做图形渲染而 iOS 和 macOS 用的是 Metal。这两套 API 的差异很大不是简单的一对一映射就能解决的。DXMT 的作用就是把 DirectX 的调用转换成 Metal 的调用让 Windows 游戏和应用能在 Apple 的图形栈上跑起来。DXMT 的实现方式是基于 D3D11 和 D3D12 做了一层翻译把着色器、纹理、渲染状态这些概念映射到 Metal 的对应概念上。这个过程比 API 翻译要复杂得多因为图形管线的状态管理方式完全不同。DXMT 目前对 D3D11 的支持比较成熟D3D12 还在完善中部分高级特性可能还不支持。2.4 为什么这套组合能在 iOS 上跑起来iOS 的系统限制比 macOS 严格得多尤其是对动态代码生成和 JIT 的限制。FEX-Emu 需要 JIT 权限才能工作而 iOS 默认不允许应用申请 JIT 权限除非是 Safari 或者特定的系统组件。所以 Madeira 在 iOS 上的运行方式通常有两种一种是通过开发者模式配合特定的签名方式获取 JIT 权限另一种是使用 AOT 预编译的方式把 x86-64 代码提前翻译成 ARM64 代码但这种方式灵活性差很多。热搜词里出现的“ios开发者模式”、“ios 26.3.1怎么开发者模式”这些其实就是在解决 JIT 权限的问题。开发者模式允许设备运行未签名的代码配合特定的工具链可以让 FEX-Emu 获得必要的权限。但这个过程比较繁琐而且不同 iOS 版本的操作方式可能不一样。3. 核心组件实操从安装到跑通第一个程序3.1 环境准备与依赖检查在开始之前你需要确认几件事。第一你的设备架构是什么。如果是 ARM64 的设备那 FEX-Emu 是必须的如果是 x86-64 的设备那可以跳过 FEX-Emu直接用 Wine 就行。第二你的系统版本是否支持 JIT。iOS 上需要开发者模式macOS 上相对宽松一些Linux 上一般没有限制。依赖清单大概是这样Wine 本体建议用较新的版本老版本对 DXMT 的支持不好FEX-EmuARM 设备必需DXMT需要跑图形应用的话一个合适的 Wine prefix建议单独建一个不要和系统默认的混用安装顺序上我建议先装 Wine再装 FEX-Emu最后装 DXMT。因为 DXMT 需要依赖 Wine 的某些组件顺序反了可能会出问题。3.2 Wine prefix 的创建与配置Wine prefix 是 Wine 用来模拟 Windows 环境的目录里面包含了注册表、DLL、驱动等文件。创建一个干净的 prefix 很重要因为不同的应用可能需要不同的配置混在一起容易冲突。创建命令大概是这样的WINEPREFIX~/.madeira/wineprefix WINEARCHwin64 winecfg这里WINEARCHwin64指定了 64 位环境因为现在大多数 Windows 应用都是 64 位的。如果你要跑的是老旧的 32 位程序可以把win64改成win32但不建议在同一个 prefix 里混用。创建完之后你会看到一个模拟的 Windows 配置界面。这里有几个关键设置一是把 Windows 版本设成 Win10 或 Win11因为很多新应用会检查系统版本二是关闭不必要的桌面特效减少图形层的负担三是把音频驱动设成 PulseAudio 或者 CoreAudio取决于你的宿主系统。3.3 FEX-Emu 的配置要点FEX-Emu 的配置主要在~/.fex-emu/Config.json这个文件里。几个关键参数RootFS指向一个包含 x86-64 库文件的根文件系统FEX-Emu 需要这些库来解析动态链接。ThunkHostLibs指定宿主系统的库路径让 FEX-Emu 知道去哪里找 ARM64 的库。JIT是否启用 JIT 编译iOS 上需要特殊权限才能开。配置好之后你可以用FEXLoader来启动 x86-64 的二进制文件。比如FEXLoader /path/to/wine/bin/wine64 application.exe这里FEXLoader会先把wine64这个 x86-64 的二进制翻译成 ARM64然后再由 Wine 去加载application.exe。整个链条是FEX-Emu 翻译 WineWine 翻译 Windows APIDXMT 翻译图形调用。3.4 DXMT 的安装与验证DXMT 的安装相对简单把编译好的d3d11.dll、dxgi.dll这些文件放到 Wine prefix 的system32目录下就行。但要注意版本匹配DXMT 的版本要和 Wine 的版本对应否则可能出现符号找不到的问题。验证 DXMT 是否生效可以跑一个简单的 D3D11 测试程序比如dxdiag或者一些轻量级的游戏。如果画面能正常渲染说明 DXMT 工作正常如果黑屏或者崩溃可能需要检查 Metal 的兼容性或者降低 D3D 特性等级。4. 常见问题与排查技巧实录4.1 Wine 乱码问题热搜词里“wine 乱码”、“wine 栏是乱码”出现的频率很高说明这是个普遍问题。乱码的根源通常是字体缺失或者编码不匹配。Wine 默认的字体渲染依赖宿主系统的字体如果宿主系统没有安装对应的中文字体就会显示成方块或者乱码。解决方法有几个一是安装winetricks然后用它来安装corefonts、cjkfonts这些字体包二是手动把中文字体复制到 Wine prefix 的Fonts目录下三是修改注册表里的字体替换规则把默认字体映射到宿主系统已有的中文字体。我个人的习惯是先用winetricks装一遍常用字体然后再手动补几个。实测下来winetricks corefonts cjkfonts这一条命令能解决大部分乱码问题。4.2 FEX-Emu 启动失败FEX-Emu 启动失败的原因比较多常见的有这几种一是 RootFS 路径不对FEX-Emu 找不到必要的 x86-64 库二是 JIT 权限不足iOS 上没开开发者模式三是宿主系统的库版本太老FEX-Emu 依赖的一些符号找不到。排查的时候先看 FEX-Emu 的日志输出通常会提示具体是哪个环节出了问题。如果是 RootFS 的问题检查路径是否正确库文件是否完整如果是 JIT 权限的问题确认开发者模式是否开启签名是否有效如果是库版本的问题可能需要升级宿主系统或者手动编译 FEX-Emu。4.3 DXMT 渲染异常DXMT 渲染异常的表现形式很多比如画面撕裂、纹理错乱、帧率骤降等。这些问题通常和 Metal 的特性支持有关。比如某些 D3D11 的特性在 Metal 上没有直接对应DXMT 需要用近似的方式模拟模拟得不好就会出现渲染错误。排查的时候可以先降低 D3D 特性等级比如把Feature Level设成10_0而不是11_0看看问题是否消失。如果消失了说明是某个高级特性导致的。然后可以逐个开启特性定位到具体是哪个特性出了问题。另外DXMT 的日志也很有用它会记录哪些调用被转换、哪些被忽略根据日志可以判断问题出在哪个环节。4.4 常见问题速查表问题现象可能原因排查方向解决思路Wine 界面乱码字体缺失或编码不匹配检查 prefix 的 Fonts 目录安装 corefonts 和 cjkfontsFEX-Emu 启动报错RootFS 路径错误或 JIT 权限不足查看 FEX-Emu 日志修正路径或开启开发者模式DXMT 黑屏Metal 特性不支持降低 D3D 特性等级逐个排查高级特性程序启动后闪退DLL 缺失或版本冲突用wine的调试模式运行补全 DLL 或调整版本音频无声音频驱动配置错误检查 winecfg 的音频设置切换 PulseAudio/CoreAudio5. 性能调优与进阶技巧5.1 减少翻译开销FEX-Emu 的翻译开销主要来自首次执行的翻译过程。如果你经常运行同一个程序可以考虑把翻译结果缓存起来下次直接复用。FEX-Emu 支持把翻译块持久化到磁盘具体是在配置里开启Cache选项并指定缓存目录。另外FEX-Emu 的Multiblock选项也值得关注。开启后它会把多个基本块合并成一个更大的翻译单元减少翻译次数但会增加单次翻译的时间。对于长时间运行的程序这个选项通常能提升整体性能。5.2 图形层的优化DXMT 的性能瓶颈通常在着色器编译和状态切换上。Metal 的着色器编译是异步的但 DXMT 的转换过程可能是同步的导致首次渲染时卡顿。一个缓解办法是提前编译着色器或者在程序启动时预加载常用的着色器。另外Metal 的渲染状态切换比 D3D 要重一些DXMT 在这方面做了一些优化比如合并相似的状态、减少不必要的切换。但如果程序本身的状态切换就很频繁那优化空间有限只能靠降低画质或者分辨率来缓解。5.3 内存管理Wine 和 FEX-Emu 都会占用额外的内存。Wine 需要维护一套模拟的 Windows 环境FEX-Emu 需要缓存翻译块这些都会消耗内存。在移动设备上内存本来就紧张所以需要合理配置。一个建议是限制 FEX-Emu 的缓存大小避免它无限增长。另一个建议是关闭 Wine 的不必要服务比如打印服务、网络服务这些减少内存占用。实测下来这些调整能省出几百 MB 的内存对于内存紧张的设备来说很有帮助。6. 从 Madeira 看跨平台兼容的未来Madeira 这套方案的本质是在不同的系统之间架桥。Wine 架的是 API 的桥FEX-Emu 架的是指令集的桥DXMT 架的是图形的桥。每一座桥都有自己的局限但组合起来就能让原本互不相通的两个世界产生连接。我在实际使用中发现这套方案的成熟度已经比几年前好很多了。以前跑一个简单的 Windows 程序都要折腾半天现在很多程序开箱即用偶尔遇到问题也能通过日志快速定位。当然距离完美还有距离尤其是图形密集型的应用性能和兼容性都还有提升空间。如果你也在折腾类似的东西我的建议是先从简单的程序开始跑通了再逐步增加复杂度。遇到问题先看日志日志里通常有足够的线索。另外社区的力量很重要很多坑别人已经踩过了搜一下往往能找到答案。最后分享一个小技巧如果你在 iOS 上跑 Madeira记得把设备的自动锁定关掉因为 JIT 权限在锁屏后可能会失效导致程序崩溃。这个坑我踩过好几次后来养成习惯跑之前先检查一下设置。