1. 从Madeira这个名字说起一个跨平台兼容层的真实需求第一次看到Madeira这个项目名加上关键词里那一串 Wine、FEX-Emu、DXMT、iOS、x86-64我大概能猜到这背后想解决的是什么问题在非 x86 架构的设备上把原本为 Windows/x86 环境编译的程序跑起来。这不是一个新话题但每次有人认真去做都会踩出一堆新坑。Madeira 是葡萄牙的一个群岛以葡萄酒闻名。项目用这个名字多少有点向 Wine 致敬的意思——Wine 本身就是 Wine Is Not an Emulator 的递归缩写。而 Madeira 要做的是在 Wine 的基础上再叠一层把 x86-64 的指令翻译成 ARM64 能执行的指令同时把 DirectX 调用翻译成 Metal 或 Vulkan最终让 Windows 程序在 ARM 设备尤其是 Apple Silicon 的 Mac 和 iOS 设备上跑起来。这个链条其实很长Windows 程序 → Wine 提供 Win32 API → FEX-Emu 做 x86-64 到 ARM64 的指令翻译 → DXMT 把 D3D 调用转成 Metal → 最终在 macOS 或 iOS 上渲染出画面。每一层都有各自的坑叠在一起之后排查问题的难度是指数级上升的。我写这篇东西不是要给你一个一键跑通的教程——因为这种东西根本不存在。我想做的是把这个技术栈的每一层拆开讲清楚它到底在干什么、为什么会出问题、出问题之后从哪里开始查。如果你正在折腾类似的东西或者只是好奇为什么 Windows 游戏能在 Mac 上跑这篇应该能给你一些实在的参考。2. Wine 层Windows API 的翻译官到底在翻译什么2.1 Wine 不是模拟器那它到底是什么很多人第一次接触 Wine 会误以为它是个虚拟机或者模拟器。不是。Wine 做的事情是当 Windows 程序调用CreateWindowExW的时候Wine 提供一个同名的函数内部把它翻译成 X11、Wayland 或者 macOS 的 Cocoa 调用。程序本身还是原生指令在 CPU 上跑只是它调用的那些 Windows 系统函数被替换成了 Linux/macOS 上的等价实现。这就解释了为什么 Wine 对硬件的要求不高——它没有指令翻译的开销。但也解释了为什么 Wine 的兼容性永远做不到 100%Windows API 太多了而且很多行为没有公开文档只能靠逆向和试错来补。Wine 的核心组件大致分这么几块ntdll最底层的系统调用接口负责内存管理、线程调度、异常处理这些kernel32文件操作、进程管理、同步对象user32窗口、消息循环、输入处理gdi32图形设备接口画线画字画图d3d11/d3d12Direct3D 的实现这部分通常是转发给底层图形 API当你运行一个 Windows 程序时它加载的是 Wine 提供的这些 DLL而不是真正的 Windows DLL。程序以为自己在一个 Windows 系统上实际上每个系统调用都被 Wine 截获并转译了。2.2 Wine 乱码问题的根因和修复思路热词里出现了wine 乱码和wine 栏是乱码这几乎是每个 Wine 用户都会遇到的第一课。乱码的本质是字符编码和字体缺失的叠加问题。Windows 程序通常假设系统里有宋体、微软雅黑这些字体并且默认使用 GBK 或者 UTF-16 编码来处理中文。Wine 在 Linux 环境下如果系统没有安装对应的中文字体或者 locale 设置不对就会显示成一堆方块或者问号。修复的思路分三步确认系统 locale 支持中文。运行locale -a | grep zh看看有没有zh_CN.UTF-8。如果没有需要生成对应的 locale。安装中文字体并注册到 Wine。把 Windows 的字体文件或者开源的思源黑体、文泉驿复制到 Wine 的字体目录通常是~/.wine/drive_c/windows/Fonts/。修改注册表里的字体替换规则。Wine 有一个FontSubstitutes键可以把程序请求的字体名映射到实际存在的字体上。# 查看当前 Wine 前缀的字体配置 wine reg query HKCU\Software\Wine\Fonts\Replacements # 添加字体替换把宋体映射到 Noto Sans CJK wine reg add HKCU\Software\Wine\Fonts\Replacements /v SimSun /t REG_SZ /d Noto Sans CJK SC /f注意字体替换只解决字体找不到的问题。如果程序本身用的是点阵字体或者自绘文字那 Wine 层面基本无能为力只能等程序自己更新或者找替代方案。还有一个容易被忽略的点Wine 的winecfg里有一个模拟 Windows 版本的设置。有些程序会根据这个版本号来决定用哪套 API设成 Windows 10 和设成 Windows 7 的行为可能完全不同。遇到奇怪的渲染问题时不妨切换一下试试。2.3 麒麟、统信这些国产系统上的 Wine 助手热词里出现了麒麟wine助手和统信wine windows兼容组件下载这说明国内的信创环境对 Wine 的需求很旺盛。麒麟和统信都基于 Linux它们各自维护了一套 Wine 的发行版和配套工具。这些助手本质上做的事情是预配置好 Wine 前缀省去用户手动调教的麻烦集成常用的运行库VC Redist、.NET Framework 等提供图形化的安装界面降低使用门槛针对特定软件做兼容性补丁但这类工具的通病是版本更新滞后。Wine 上游的更新频率很高而发行版集成的版本往往落后半年甚至一年。如果你遇到某个程序在助手版里跑不起来可以试试手动安装上游的最新版 Wine很多时候问题就解决了。3. FEX-Emux86-64 到 ARM64 的指令翻译是怎么做到的3.1 为什么需要指令翻译层Wine 解决的是 API 层面的兼容问题但它假设程序本身的指令能在当前 CPU 上直接执行。在 x86 的 PC 上这没问题但 Apple Silicon 是 ARM64 架构指令集完全不同。这时候就需要一层指令翻译。FEX-Emu 就是干这个的。它把 x86-64 的指令动态翻译成 ARM64 指令然后交给 CPU 执行。这个过程叫动态二进制翻译Dynamic Binary TranslationDBT。和传统的模拟器比如 QEMU不同FEX-Emu 不是逐条解释执行而是把一段 x86 代码翻译成对应的 ARM64 代码块缓存起来下次遇到同样的代码直接执行缓存。这样性能损失会小很多通常在 20% 到 50% 之间具体取决于程序的指令模式。3.2 FEX-Emu 的核心机制拆解FEX-Emu 的工作流程大致是这样的加载 x86-64 的 ELF 文件解析它的代码段和数据段遇到新的代码块时进行翻译。把 x86-64 指令解码生成中间表示IR再从 IR 生成 ARM64 指令缓存翻译结果。同一个代码块第二次执行时直接用缓存处理自修改代码。有些程序会在运行时修改自己的指令这时候缓存就失效了需要重新翻译这里最麻烦的是第 4 点。x86 架构允许程序在运行时修改代码段的内容而 ARM64 对代码段有更严格的保护需要显式刷新指令缓存。FEX-Emu 必须检测到这种修改然后做相应的处理否则程序行为就会出错。另一个难点是 x86 和 ARM 在内存模型上的差异。x86 是强内存模型Total Store OrderARM 是弱内存模型。这意味着在多线程环境下两个架构对内存访问顺序的保证是不一样的。FEX-Emu 需要在翻译时插入适当的内存屏障指令才能保证程序的行为和原生 x86 一致。这会带来额外的性能开销。3.3 实际使用中的性能观察我在 Apple Silicon 的 Mac 上跑过一些通过 FEX-Emu 翻译的 x86-64 程序感受比较明显的是计算密集型任务性能损失大概在 30% 左右比如编译代码、压缩文件这类I/O 密集型任务性能损失很小因为瓶颈不在 CPU图形密集型任务取决于图形翻译层的效率FEX-Emu 本身不是瓶颈有一个反直觉的现象有些程序在 FEX-Emu 下跑得比预期快。原因是 FEX-Emu 的 JIT 编译器在某些情况下能生成比原始 x86 代码更优化的 ARM64 代码尤其是当原始代码是多年前编译的、没有针对现代 CPU 优化的时候。提示如果你在调试 FEX-Emu 相关的问题可以设置环境变量FEX_DEBUG1来输出详细的翻译日志。不过日志量很大建议只在你怀疑某个特定代码块有问题时才开启。4. DXMT把 Direct3D 调用翻译成 Metal 的桥梁4.1 DirectX 到 Metal 的翻译为什么难Windows 游戏和图形程序大量使用 Direct3D 来做渲染。在 macOS 上对应的图形 API 是 Metal。DXMT 要做的事情就是把 D3D 的调用翻译成 Metal 的调用。这个翻译的难点在于两个 API 的设计哲学不同D3D11是状态机式的你设置一堆状态混合模式、深度测试、剔除模式等然后提交绘制命令Metal是命令缓冲式的你需要显式地编码每个渲染命令状态切换的粒度更细DXMT 需要在两者之间做映射。比如 D3D11 的OMSetBlendState在 Metal 里对应的是设置渲染管线状态对象Render Pipeline State Object而创建这个对象是有开销的不能每次状态切换都重新创建。DXMT 需要缓存这些状态对象在状态不变时复用。另一个难点是着色器的翻译。D3D 用的是 HLSL编译成 DXBC 或者 DXIL 字节码Metal 用的是 MSLMetal Shading Language。DXMT 需要把 DXBC 反编译成中间表示再生成 MSL 代码最后用 Metal 的编译器编译成 GPU 能执行的机器码。这个链条上任何一步出问题都会导致渲染错误或者崩溃。4.2 DXMT 和 DXVK、MoltenVK 的关系在 DXMT 出现之前macOS 上跑 D3D 程序的常见方案是 DXVK MoltenVKDXVK 把 D3D 翻译成 VulkanMoltenVK 把 Vulkan 翻译成 Metal这条路径多了一层翻译性能损失更大而且 MoltenVK 对 Vulkan 的支持也不是 100% 完整。DXMT 直接做 D3D 到 Metal 的翻译少了一层中间环节理论上效率更高。但 DXMT 的成熟度目前还不如 DXVK MoltenVK 的组合。如果你遇到某个游戏在 DXMT 下渲染异常可以试试切换回 DXVK 方案虽然性能差一点但兼容性可能更好。4.3 图形问题的排查思路图形问题是最难排查的因为症状和原因之间往往没有直接的对应关系。我总结了一个从外到内的排查顺序排查层级检查内容常用工具应用层程序日志、错误提示程序自带的日志、Console.appWine 层DLL 加载、API 调用WINEDEBUGd3d11翻译层着色器编译、状态映射DXMT 的调试输出驱动层Metal 命令提交、GPU 状态Xcode 的 Metal Debugger硬件层GPU 占用、温度Activity Monitor、powermetrics大部分问题出在翻译层和驱动层的交界处。比如着色器编译失败DXMT 可能只是静默地跳过了那个绘制调用程序看起来能跑但画面是黑的。这时候需要打开 DXMT 的调试日志看看有没有编译错误。5. iOS 上的 Wine为什么这件事比 macOS 难得多5.1 iOS 的沙箱限制和 JIT 困境在 macOS 上跑 Wine FEX-Emu DXMT虽然折腾但至少系统允许你做这些事情。iOS 的情况完全不同。iOS 的应用运行在严格的沙箱里每个 App 只能访问自己的数据目录不能随意加载外部的可执行代码。更关键的是iOS 默认不允许 JITJust-In-Time Compilation。FEX-Emu 的核心就是 JIT没有 JIT 它就没法动态翻译指令。这就是为什么在 iOS 上跑 Wine 需要开发者模式——开发者模式下系统会放宽一些限制允许 App 使用特定的权限来分配可执行内存。但即便如此苹果对这方面的限制依然很严而且不同 iOS 版本的行为可能不一样。热词里出现了ios开发者模式和ios 26.3.1怎么开发者模式说明很多人卡在了第一步。开启开发者模式的常规路径是设置 → 隐私与安全性 → 开发者模式然后重启设备。但这个选项只有在设备连接过 Xcode 或者安装了特定的开发者描述文件之后才会出现。5.2 iOS 上的图形栈Metal 是唯一选择在 iOS 上图形 API 只有 Metal。没有 Vulkan没有 OpenGL虽然有一个兼容层但性能很差。这意味着 DXMT 在 iOS 上的工作方式和 macOS 上类似但需要针对 iOS 的 Metal 特性做适配。iOS 的 Metal 和 macOS 的 Metal 有一些差异iOS 的 GPU 是统一内存架构CPU 和 GPU 共享内存这简化了一些数据传输的操作iOS 对纹理格式的支持更有限某些 D3D 格式在 iOS 上没有直接对应的 Metal 格式iOS 的后台限制更严格App 切到后台后 GPU 工作会被暂停这些差异意味着即使 DXMT 在 macOS 上工作正常移植到 iOS 也需要不少调整。5.3 实际能跑什么不能跑什么根据我的观察和社区反馈iOS 上的 Wine 方案目前能跑的东西很有限简单的 2D 程序有可能跑起来但性能不一定好老旧的 3D 游戏如果对 D3D 特性要求不高有机会现代 3D 游戏基本没戏要么崩溃要么帧率个位数生产力软件取决于它用了多少 Windows 特有的 API越简单越容易成功注意在 iOS 上折腾这些东西设备发热和耗电会非常明显。建议在充电状态下操作并且注意设备温度避免过热降频甚至损伤电池。6. 从证书到上架iOS 开发的完整链路里那些容易卡住的点6.1 证书配置为什么这一步总是出问题热词里出现了xcode从证书配置到上架全流程和免费证书ios说明证书问题是 iOS 开发者的常见痛点。iOS 的代码签名体系分几层开发者证书证明你是谁由 Apple 签发App ID标识你的应用可以是通配符也可以是具体的 Bundle ID设备列表哪些设备可以安装你的开发版本描述文件把证书、App ID、设备列表打包在一起Xcode 用它来签名最常见的错误是证书过期或者描述文件不匹配。前者需要重新生成证书后者需要检查描述文件里包含的 App ID 和实际使用的 Bundle ID 是否一致。免费证书个人开发者账号的限制是证书有效期只有 7 天到期后需要重新签名。这对于自己测试来说够用但没法用于长期分发的场景。6.2 Xcode 打包突然变慢的排查xcode打包ios突然很慢如何解决这个问题我遇到过几次原因各不相同索引重建Xcode 的索引文件损坏或者过期会导致每次编译都重新索引。解决方法是删除~/Library/Developer/Xcode/DerivedData目录让 Xcode 重建。依赖解析如果项目用了 Swift Package Manager 或者 CocoaPods依赖解析可能会因为网络问题变慢。可以试试清理缓存或者换用镜像源。代码签名如果证书或者描述文件有问题Xcode 会反复尝试签名导致打包时间变长。检查一下签名设置确保用的是正确的证书。磁盘空间Xcode 需要大量临时空间如果磁盘快满了编译速度会明显下降。# 清理 Xcode 的派生数据 rm -rf ~/Library/Developer/Xcode/DerivedData # 清理 Swift Package Manager 缓存 rm -rf ~/Library/Caches/org.swift.swiftpm # 查看磁盘空间 df -h6.3 上架流程中的常见拒绝原因App Store 的审核拒绝理由五花八门但有几类是高频的崩溃审核员打开就闪退直接拒不完整的元数据截图不对、描述不清、隐私政策缺失使用了私有 API调用了 Apple 没有公开的接口引导用户到外部支付绕过了 Apple 的内购系统内容违规这个不用多说我的经验是提交之前一定要在真机上完整跑一遍尤其是那些需要登录或者特定权限的功能。审核员不会帮你调试遇到问题就是直接拒。7. 那些绕不开的调试工具和技巧7.1 抓包iOS 上怎么连 Fiddlerios怎么连接fiddler是个经典问题。Fiddler 是 Windows 上的抓包工具iOS 要连它需要确保 iOS 设备和运行 Fiddler 的电脑在同一个局域网在 Fiddler 的设置里开启允许远程连接在 iOS 的 Wi-Fi 设置里配置 HTTP 代理指向电脑的 IP 和 Fiddler 的端口默认 8888在 iOS 上安装并信任 Fiddler 的根证书最后一步是关键。iOS 对证书的信任管理很严格你需要在设置 → 通用 → 关于本机 → 证书信任设置里手动开启对 Fiddler 证书的完全信任。否则 HTTPS 流量会解密失败。提示抓包只能用于调试自己的应用或者你有权限测试的目标。未经授权抓取他人数据是违规行为。7.2 WebView 自动播放问题抖音 ios webview 不能自动播放这个问题根源在于 iOS 的 Safari 和 WebView 对自动播放有严格限制。默认情况下只有满足以下条件之一才允许自动播放视频没有音轨用户已经与页面有过交互视频是通过用户手势触发的对于内嵌在 App 里的 WebView可以通过设置mediaTypesRequiringUserActionForPlayback属性来放宽限制。但这需要 App 开发者主动配置网页本身无法绕过。7.3 模拟器和真机的差异ios设备模拟和银行模拟器ios这两个热词提醒我一件事模拟器和真机的行为差异比很多人想象的大。性能模拟器跑在 Mac 的 CPU 上性能特征和真机完全不同传感器模拟器没有真实的陀螺仪、加速度计、GPS摄像头模拟器只能用 Mac 的摄像头或者用预设的测试画面推送通知模拟器上的推送行为和真机不一样Metal 特性模拟器支持的 Metal 特性集和真机可能有差异所以任何涉及图形渲染、性能敏感、或者依赖特定硬件的功能都必须在真机上测试。模拟器只能用来验证逻辑正确性。8. 关于这套技术栈的一些个人判断折腾 Wine FEX-Emu DXMT 这套东西有一段时间了说几点自己的感受。这套方案的复杂度决定了它不可能成为普通用户的选择。每一层都有自己的 bug 和限制叠在一起之后能跑通是运气跑不通是常态。如果你只是想玩某个 Windows 游戏买个 Windows 设备或者用云游戏方案可能更省心。但如果你是对底层技术感兴趣想搞清楚指令翻译到底是怎么做的、图形 API 之间的映射有哪些坑那这套东西是很好的学习材料。每一层都是开源的你可以看到真实的工程实现而不是教科书上的简化模型。另外这个领域变化很快。FEX-Emu 和 DXMT 都在活跃开发中今天跑不起来的程序可能下个月更新之后就支持了。如果你遇到了问题先去项目的 GitHub Issues 里搜一下很可能已经有人遇到并解决了。最后说一个实际的经验在调试这类跨层问题时二分法是最有效的策略。先确定问题出在哪一层然后在那层里继续二分。不要试图一次性理解整个系统那样只会把自己绕晕。把每一层单独测通再组合起来成功率会高很多。