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 的ADDx86 的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-Emux86-64 到 ARM64 指令翻译项目仓库预编译二进制WineWindows API 兼容层需使用 iOS 适配分支DXMTD3D 到 Metal 转译项目仓库预编译动态库MoltenVKVulkan 到 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_SIZE512 export FEX_MULTIBLOCK1 export FEX_ROOTFS/path/to/rootfs export FEX_APP_CONFIG/path/to/appconfigFEX_TCG_CACHE_SIZE单位是 MB512 是一个比较平衡的值。设太小比如 128会导致翻译缓存频繁淘汰程序运行卡顿设太大比如 2048会挤占 Wine 和 DXMT 的内存空间在 4GB 设备上容易触发系统杀进程。FEX_MULTIBLOCK1开启多块并行翻译能显著加快程序冷启动速度代价是启动瞬间 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_ALLzh_CN.UTF-8和export LANGzh_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_LEVELwarn export DXMT_MAX_FRAME_LATENCY2DXMT_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 的启动脚本里通常会设置WINEDEBUGall来输出详细日志。但all日志量太大建议先用WINEDEBUGloaddll,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_ENABLED1或者降低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] TextureFormatOverrideBGRA把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和程序路径两个地方。这样能省下大量重复劳动的时间。
Madeira项目：在iOS上通过FEX-Emu、Wine和DXMT运行x86-64 Windows应用
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 的ADDx86 的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-Emux86-64 到 ARM64 指令翻译项目仓库预编译二进制WineWindows API 兼容层需使用 iOS 适配分支DXMTD3D 到 Metal 转译项目仓库预编译动态库MoltenVKVulkan 到 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_SIZE512 export FEX_MULTIBLOCK1 export FEX_ROOTFS/path/to/rootfs export FEX_APP_CONFIG/path/to/appconfigFEX_TCG_CACHE_SIZE单位是 MB512 是一个比较平衡的值。设太小比如 128会导致翻译缓存频繁淘汰程序运行卡顿设太大比如 2048会挤占 Wine 和 DXMT 的内存空间在 4GB 设备上容易触发系统杀进程。FEX_MULTIBLOCK1开启多块并行翻译能显著加快程序冷启动速度代价是启动瞬间 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_ALLzh_CN.UTF-8和export LANGzh_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_LEVELwarn export DXMT_MAX_FRAME_LATENCY2DXMT_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 的启动脚本里通常会设置WINEDEBUGall来输出详细日志。但all日志量太大建议先用WINEDEBUGloaddll,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_ENABLED1或者降低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] TextureFormatOverrideBGRA把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和程序路径两个地方。这样能省下大量重复劳动的时间。
