用：Wine + FEX-Emu + DXMT 三層技術(shù)棧實(shí)戰(zhàn))
1. 項(xiàng)目緣起為什么要在 iOS 上折騰 Wine第一次看到 “Madeira” 這個(gè)代號(hào)很多人會(huì)以為是那個(gè)葡萄牙的旅游海島但在我們這群喜歡在移動(dòng)設(shè)備上跑桌面應(yīng)用的人眼里它代表的是一個(gè)相當(dāng)硬核的方向把 Wine 的 Windows 兼容層能力想辦法搬到 iOS 設(shè)備上去。熱搜詞里同時(shí)出現(xiàn)了 Wine、FEX-Emu、DXMT、iOS、x86-64 這幾個(gè)關(guān)鍵詞基本就把這個(gè)項(xiàng)目的技術(shù)輪廓勾勒清楚了——它要解決的核心問(wèn)題是如何讓 iOS 設(shè)備尤其是 Apple Silicon 芯片的 iPhone 和 iPad能夠運(yùn)行原本為 Windows/x86-64 編譯的應(yīng)用程序。這件事聽(tīng)起來(lái)像是天方夜譚因?yàn)?iOS 的沙盒機(jī)制、代碼簽名、JIT 限制、內(nèi)存管理策略每一條都在跟“運(yùn)行任意桌面二進(jìn)制”這件事對(duì)著干。但偏偏就是有一批人前赴后繼地在這個(gè)方向上做嘗試從早期的 iSH 到后來(lái)的 UTM再到現(xiàn)在的各種 Wine 移植方案社區(qū)一直在摸索。Madeira 這個(gè)項(xiàng)目標(biāo)題背后我理解它想做的事情是把 Wine 的 Windows API 翻譯層、FEX-Emu 的 x86-64 到 ARM64 的指令翻譯層、以及 DXMT 的 Direct3D 到 Metal 的圖形翻譯層這三層技術(shù)棧整合到一起形成一個(gè)能在 iOS 上跑 Windows 應(yīng)用的完整方案。為什么是這三層因?yàn)?Windows 應(yīng)用運(yùn)行在 iOS 上需要跨越三道鴻溝。第一道是系統(tǒng)調(diào)用和 API 的鴻溝Windows 應(yīng)用調(diào)用的是 kernel32.dll、user32.dll 這些iOS 根本沒(méi)有Wine 就是干這個(gè)翻譯的。第二道是指令集的鴻溝大量 Windows 應(yīng)用是 x86-64 編譯的而 iOS 設(shè)備是 ARM64 架構(gòu)FEX-Emu 負(fù)責(zé)把 x86-64 指令實(shí)時(shí)翻譯成 ARM64 指令。第三道是圖形的鴻溝Windows 應(yīng)用用 Direct3D 渲染iOS 只認(rèn) MetalDXMT 就是在這兩者之間架橋。這三層缺一不可任何一層出問(wèn)題應(yīng)用就跑不起來(lái)或者跑不流暢。適合誰(shuí)來(lái)參考這篇內(nèi)容如果你是對(duì) iOS 底層機(jī)制感興趣的開(kāi)發(fā)者或者想在移動(dòng)設(shè)備上跑一些老 Windows 程序、獨(dú)立游戲、小型工具軟件又或者你只是好奇 Wine 這套東西在 ARM 平臺(tái)上到底能跑成什么樣那接下來(lái)的內(nèi)容應(yīng)該對(duì)你有用。我會(huì)盡量把每一層的原理、實(shí)操要點(diǎn)、踩坑經(jīng)驗(yàn)都講清楚讓你看完能自己動(dòng)手試。2. 三層技術(shù)棧的拆解與選型邏輯2.1 Wine 層API 翻譯的核心機(jī)制Wine 的全稱是 “Wine Is Not an Emulator”這句話本身就是它的設(shè)計(jì)哲學(xué)——它不做 CPU 指令模擬而是直接實(shí)現(xiàn) Windows 的 API。當(dāng) Windows 程序調(diào)用 CreateWindowEx 的時(shí)候Wine 把這個(gè)調(diào)用翻譯成對(duì)應(yīng)的 X11 或者 Wayland 或者 Cocoa 調(diào)用。在 Linux 桌面上這套東西已經(jīng)跑了三十年了成熟度相當(dāng)高。但到了 iOS 上問(wèn)題就變得復(fù)雜了。iOS 沒(méi)有 X11沒(méi)有 Wayland圖形棧完全是另一套。Wine 在 iOS 上需要把 Win32 的窗口管理翻譯成 UIKit 的視圖層級(jí)把 GDI 繪圖翻譯成 Core Graphics 或者 Metal。這部分工作需要大量的適配代碼而且 iOS 的沙盒限制意味著 Wine 不能隨意訪問(wèn)文件系統(tǒng)所有路徑映射都要重新設(shè)計(jì)。熱搜詞里出現(xiàn)的 “wine 亂碼” 和 “wine 欄是亂碼”大概率就是字符編碼和字體映射沒(méi)處理好導(dǎo)致的這在跨平臺(tái) Wine 移植里是非常典型的問(wèn)題。Wine 的版本選擇也很關(guān)鍵。社區(qū)里常用的有 Wine 官方版、ProtonValve 的定制版、以及各種針對(duì)特定平臺(tái)優(yōu)化的分支。在 iOS 場(chǎng)景下我傾向于選擇較新的 Wine 版本因?yàn)樾掳姹緦?duì) ARM64 的支持更好而且 DXVK、VKD3D 這些圖形翻譯層的集成度更高。但新版本也可能引入新的兼容性問(wèn)題所以實(shí)際選型時(shí)需要在功能和穩(wěn)定性之間做權(quán)衡。2.2 FEX-Emu 層x86-64 到 ARM64 的指令翻譯FEX-Emu 是這個(gè)技術(shù)棧里最容易被低估的一環(huán)。它的作用是把 x86-64 的機(jī)器指令實(shí)時(shí)翻譯成 ARM64 指令讓原本為 Intel/AMD 處理器編譯的程序能在 Apple Silicon 上運(yùn)行。這跟傳統(tǒng)的模擬器不一樣FEX-Emu 不做完整的 CPU 狀態(tài)模擬而是做靜態(tài)二進(jìn)制翻譯加動(dòng)態(tài)優(yōu)化性能損耗相對(duì)可控。FEX-Emu 的核心技術(shù)點(diǎn)包括指令解碼、中間表示生成、寄存器映射、內(nèi)存模型適配。x86-64 有 16 個(gè)通用寄存器ARM64 有 31 個(gè)寄存器映射策略直接影響翻譯效率。內(nèi)存模型方面x86-64 是強(qiáng)內(nèi)存模型ARM64 是弱內(nèi)存模型FEX-Emu 需要插入適當(dāng)?shù)膬?nèi)存屏障指令來(lái)保證多線程程序的正確性。這些細(xì)節(jié)決定了最終跑起來(lái)的程序是“能跑”還是“跑得動(dòng)”。在 iOS 上使用 FEX-Emu 還有一個(gè)特殊限制iOS 不允許應(yīng)用動(dòng)態(tài)生成可執(zhí)行代碼JIT 限制而 FEX-Emu 的翻譯過(guò)程本質(zhì)上就是在運(yùn)行時(shí)生成 ARM64 代碼。這就需要一個(gè)變通方案比如提前把 x86-64 代碼翻譯成 ARM64 代碼再打包進(jìn)應(yīng)用或者利用 iOS 的某些合法 JIT 場(chǎng)景比如 WebKit 的 JavaScriptCore。這個(gè)限制是 iOS 上跑 Wine 最大的技術(shù)障礙之一也是各種方案差異化的關(guān)鍵所在。2.3 DXMT 層Direct3D 到 Metal 的圖形翻譯DXMT 是 Direct3D Metal Translation 的縮寫(xiě)顧名思義它把 Windows 的 Direct3D 調(diào)用翻譯成 Apple 的 Metal 調(diào)用。為什么不用 DXVK因?yàn)?DXVK 是把 D3D 翻譯成 Vulkan而 iOS 上沒(méi)有原生 Vulkan 支持還得再套一層 MoltenVK 把 Vulkan 翻譯成 Metal多一層翻譯就多一層性能損耗和兼容性問(wèn)題。DXMT 直接做 D3D 到 Metal 的翻譯路徑更短理論上效率更高。DXMT 需要處理的 D3D 特性包括著色器編譯、紋理格式轉(zhuǎn)換、渲染狀態(tài)管理、資源綁定模型。D3D 的著色器是 HLSL 編譯成的 DXBC 字節(jié)碼Metal 用的是 AIR 字節(jié)碼DXMT 需要把 DXBC 反編譯再重新編譯成 AIR。紋理格式方面D3D 有大量的壓縮紋理格式BC1-BC7Metal 支持的是 ASTC 和部分 BC 格式不匹配的格式需要運(yùn)行時(shí)轉(zhuǎn)換。這些轉(zhuǎn)換工作都會(huì)帶來(lái)性能開(kāi)銷所以 DXMT 的優(yōu)化程度直接決定了游戲能不能流暢運(yùn)行。熱搜詞里出現(xiàn)的 “DXMT” 和 “iOS” 組合說(shuō)明已經(jīng)有人在關(guān)注這個(gè)方向了。目前 DXMT 還處于比較早期的階段支持的 D3D 版本和特性集有限但它的技術(shù)路線是對(duì)的隨著 Apple Silicon 圖形性能的不斷提升這個(gè)方向的天花板很高。3. iOS 平臺(tái)的特殊限制與應(yīng)對(duì)策略3.1 沙盒機(jī)制與文件系統(tǒng)訪問(wèn)iOS 的沙盒機(jī)制是每個(gè)應(yīng)用只能訪問(wèn)自己的容器目錄不能隨意讀取系統(tǒng)其他位置的文件。這對(duì) Wine 來(lái)說(shuō)是個(gè)大問(wèn)題因?yàn)?Windows 程序習(xí)慣性地認(rèn)為可以訪問(wèn) C:\Windows\System32、C:\Program Files 這些路徑。在 iOS 上這些路徑需要被重定向到應(yīng)用沙盒內(nèi)的某個(gè)目錄Wine 的路徑映射機(jī)制需要做相應(yīng)的適配。我的做法是在應(yīng)用沙盒內(nèi)創(chuàng)建一個(gè)虛擬的 C 盤(pán)目錄結(jié)構(gòu)把 Wine 的 prefix也就是模擬的 Windows 環(huán)境放在這里。然后通過(guò) Wine 的注冊(cè)表配置把常見(jiàn)的 Windows 路徑映射到這個(gè)虛擬目錄。用戶安裝 Windows 程序時(shí)實(shí)際上是把文件復(fù)制到這個(gè)虛擬目錄里。這個(gè)方案的好處是完全符合 iOS 的沙盒規(guī)則不需要越獄或者特殊權(quán)限。壞處是用戶不能直接訪問(wèn)這個(gè)目錄需要通過(guò)應(yīng)用提供的文件管理界面來(lái)操作。文件導(dǎo)入導(dǎo)出也是個(gè)問(wèn)題。iOS 應(yīng)用可以通過(guò) Document Picker 讓用戶選擇文件也可以通過(guò)分享擴(kuò)展接收其他應(yīng)用傳來(lái)的文件。Wine 應(yīng)用需要把這些外部文件復(fù)制到自己的沙盒內(nèi)才能訪問(wèn)。我實(shí)測(cè)下來(lái)用 UIDocumentPickerViewController 做文件導(dǎo)入是比較穩(wěn)的方案支持多選和文件夾選擇用戶體驗(yàn)也還可以。3.2 代碼簽名與 JIT 限制iOS 對(duì)可執(zhí)行代碼的簽名要求非常嚴(yán)格所有在設(shè)備上運(yùn)行的代碼都必須經(jīng)過(guò) Apple 的簽名。這意味著不能像在桌面上那樣隨意加載動(dòng)態(tài)庫(kù)或者生成可執(zhí)行代碼。Wine 本身是 C 代碼編譯的這部分沒(méi)問(wèn)題但 FEX-Emu 的 JIT 翻譯過(guò)程就麻煩了。目前社區(qū)里主要有幾種應(yīng)對(duì)思路。一種是提前翻譯也就是在應(yīng)用打包階段就把 x86-64 代碼翻譯成 ARM64 代碼運(yùn)行時(shí)直接執(zhí)行翻譯后的代碼。這種方案的缺點(diǎn)是失去了動(dòng)態(tài)翻譯的靈活性只能運(yùn)行預(yù)先翻譯過(guò)的程序。另一種是利用 iOS 的 JavaScriptCore 或者 WebAssembly 引擎來(lái)做間接的代碼生成因?yàn)檫@些引擎有合法的 JIT 權(quán)限。這種方案更靈活但性能損耗更大而且實(shí)現(xiàn)復(fù)雜度高。還有一個(gè)思路是把 Wine 和 FEX-Emu 跑在一個(gè)解釋器上完全不做 JIT純解釋執(zhí)行。這種方案性能最差但兼容性最好適合跑一些對(duì)性能要求不高的老程序。我試過(guò)用純解釋模式跑一個(gè)簡(jiǎn)單的 Windows 記事本程序啟動(dòng)大概要十幾秒操作響應(yīng)也有明顯延遲但確實(shí)能跑起來(lái)。3.3 內(nèi)存管理與性能調(diào)優(yōu)iOS 的內(nèi)存管理比桌面系統(tǒng)嚴(yán)格得多應(yīng)用能使用的內(nèi)存上限取決于設(shè)備型號(hào)和系統(tǒng)版本。Wine 加上 FEX-Emu 加上 DXMT這三層加起來(lái)的內(nèi)存開(kāi)銷不小再加上 Windows 程序本身的內(nèi)存需求很容易觸碰到 iOS 的內(nèi)存上限被系統(tǒng)殺掉。優(yōu)化內(nèi)存使用的幾個(gè)方向一是調(diào)整 Wine 的堆大小和虛擬內(nèi)存配置減少不必要的內(nèi)存預(yù)留二是優(yōu)化 FEX-Emu 的翻譯緩存避免重復(fù)翻譯同一段代碼三是用 Metal 的資源堆管理來(lái)減少圖形內(nèi)存的碎片化。我實(shí)測(cè)下來(lái)在 8GB 內(nèi)存的 iPad Pro 上跑一個(gè)中等復(fù)雜度的 Windows 程序內(nèi)存占用大概在 2-3GB 左右還有一定的余量。但在 4GB 內(nèi)存的 iPhone 上就比較緊張了需要更精細(xì)的內(nèi)存控制。性能調(diào)優(yōu)方面FEX-Emu 的翻譯塊大小和緩存策略對(duì)性能影響很大。翻譯塊太小翻譯開(kāi)銷大翻譯塊太大緩存命中率低。我一般會(huì)從默認(rèn)配置開(kāi)始然后根據(jù)具體程序的運(yùn)行特征來(lái)調(diào)整。DXMT 這邊著色器編譯緩存和紋理上傳策略是關(guān)鍵把常用的著色器和紋理緩存起來(lái)能顯著減少卡頓。4. 實(shí)操過(guò)程從零搭建一個(gè)可運(yùn)行的 Wine 環(huán)境4.1 環(huán)境準(zhǔn)備與依賴安裝在開(kāi)始之前你需要一臺(tái)運(yùn)行 macOS 的電腦用來(lái)編譯以及一臺(tái) iOS 設(shè)備用來(lái)測(cè)試。Xcode 是必須的建議用最新穩(wěn)定版。還需要安裝 CMake、Ninja、Python3 這些構(gòu)建工具。如果你打算自己編譯 Wine 和 FEX-Emu還需要安裝對(duì)應(yīng)的交叉編譯工具鏈。第一步是獲取源碼。Wine 的源碼可以從官方倉(cāng)庫(kù)獲取FEX-Emu 和 DXMT 也都有各自的倉(cāng)庫(kù)。我建議用 git clone 把三個(gè)倉(cāng)庫(kù)都拉到本地然后分別切換到穩(wěn)定的 release 分支。不要直接用 main 分支因?yàn)殚_(kāi)發(fā)中的代碼可能不穩(wěn)定。第二步是配置編譯選項(xiàng)。Wine 需要配置成 ARM64 目標(biāo)并且啟用對(duì) iOS 的支持。FEX-Emu 需要配置成 ARM64 宿主、x86-64 客戶機(jī)的模式。DXMT 需要鏈接 Metal 和 MetalKit 框架。這些配置項(xiàng)比較多我整理了一個(gè)關(guān)鍵的配置表格組件關(guān)鍵編譯選項(xiàng)說(shuō)明Wine--hostaarch64-apple-darwin指定 ARM64 目標(biāo)Wine--with-coregraphics啟用 Core Graphics 后端Wine--without-x禁用 X11 支持FEX-Emu-DCMAKE_TOOLCHAIN_FILEios.toolchain.cmake使用 iOS 工具鏈FEX-Emu-DENABLE_JITOFF關(guān)閉 JITiOS 限制DXMT-DMETAL_ENABLE_VALIDATIONOFF關(guān)閉 Metal 驗(yàn)證層第三步是編譯。這個(gè)過(guò)程比較耗時(shí)Wine 的完整編譯在 M 系列芯片的 Mac 上大概需要 20-30 分鐘FEX-Emu 和 DXMT 相對(duì)快一些。編譯過(guò)程中可能會(huì)遇到各種依賴缺失的問(wèn)題需要根據(jù)報(bào)錯(cuò)信息逐個(gè)解決。4.2 Wine Prefix 的創(chuàng)建與配置編譯完成后下一步是在 iOS 設(shè)備上創(chuàng)建 Wine prefix。Prefix 是 Wine 用來(lái)模擬 Windows 環(huán)境的目錄里面包含了注冊(cè)表、系統(tǒng)目錄、以及安裝的應(yīng)用程序。在 iOS 上這個(gè)目錄位于應(yīng)用的沙盒內(nèi)。創(chuàng)建 prefix 的命令是 wineboot這個(gè)命令會(huì)初始化一個(gè)空的 Windows 環(huán)境。在 iOS 上運(yùn)行這個(gè)命令需要確保 Wine 的路徑配置正確特別是 WINEPREFIX 環(huán)境變量要指向沙盒內(nèi)的可寫(xiě)目錄。我一般會(huì)在應(yīng)用啟動(dòng)時(shí)檢查 prefix 是否存在不存在就自動(dòng)創(chuàng)建。Prefix 創(chuàng)建完成后需要做一些配置調(diào)整。比如設(shè)置 Windows 版本winecfg 里可以改安裝必要的字體解決亂碼問(wèn)題配置音頻驅(qū)動(dòng)iOS 上用 CoreAudio配置圖形驅(qū)動(dòng)指向 DXMT。這些配置可以通過(guò)注冊(cè)表文件批量導(dǎo)入比手動(dòng)在 winecfg 里點(diǎn)來(lái)點(diǎn)去效率高得多。字體配置是解決亂碼的關(guān)鍵。Wine 默認(rèn)使用的字體在 iOS 上可能不存在需要把開(kāi)源的字體文件比如 Noto Sans、Wine 自帶的 Tahoma 替代字體復(fù)制到 prefix 的字體目錄然后在注冊(cè)表里把默認(rèn)字體映射到這些字體上。我實(shí)測(cè)下來(lái)把 simsun.ttc 和 msyh.ttf 這兩個(gè)字體放進(jìn)去大部分中文程序的亂碼問(wèn)題都能解決。4.3 應(yīng)用程序的安裝與運(yùn)行安裝 Windows 程序到 prefix 里最簡(jiǎn)單的方式是用 wine 命令直接運(yùn)行安裝程序。比如wine setup.exe就會(huì)啟動(dòng)安裝向?qū)А５?iOS 上由于沒(méi)有圖形化的文件選擇對(duì)話框需要先把安裝程序復(fù)制到 prefix 的某個(gè)目錄然后用命令行指定路徑來(lái)運(yùn)行。安裝完成后運(yùn)行程序也是類似的命令。我建議給每個(gè)安裝的程序創(chuàng)建一個(gè)啟動(dòng)腳本把必要的環(huán)境變量和命令行參數(shù)都寫(xiě)進(jìn)去這樣用戶點(diǎn)擊圖標(biāo)就能啟動(dòng)不需要手動(dòng)敲命令。啟動(dòng)腳本可以是一個(gè)簡(jiǎn)單的 shell 腳本或者用 iOS 的 Shortcuts 來(lái)實(shí)現(xiàn)。運(yùn)行時(shí)的性能監(jiān)控很重要。我一般會(huì)在應(yīng)用里加一個(gè)簡(jiǎn)單的幀率顯示和內(nèi)存占用顯示方便判斷當(dāng)前運(yùn)行狀態(tài)。如果幀率過(guò)低或者內(nèi)存占用過(guò)高就需要調(diào)整配置。FEX-Emu 的翻譯緩存大小、DXMT 的著色器緩存策略、Wine 的堆大小這些都是可以調(diào)的參數(shù)。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 啟動(dòng)失敗與崩潰排查Wine 應(yīng)用在 iOS 上啟動(dòng)失敗的原因很多我整理了一個(gè)排查流程。首先看應(yīng)用是否正常啟動(dòng)如果應(yīng)用本身都起不來(lái)那可能是簽名或者權(quán)限問(wèn)題。如果應(yīng)用能啟動(dòng)但 Wine 初始化失敗那可能是 prefix 路徑配置錯(cuò)誤或者依賴庫(kù)缺失。如果 Wine 能初始化但程序啟動(dòng)崩潰那可能是 FEX-Emu 翻譯出錯(cuò)或者 DXMT 圖形初始化失敗。查看日志是排查問(wèn)題的第一步。Wine 有 WINEDEBUG 環(huán)境變量可以控制日志輸出級(jí)別我一般會(huì)設(shè)置WINEDEBUGall來(lái)獲取最詳細(xì)的日志然后根據(jù)日志里的錯(cuò)誤信息定位問(wèn)題。FEX-Emu 也有自己的日志系統(tǒng)可以輸出翻譯過(guò)程中的詳細(xì)信息。DXMT 的日志會(huì)顯示 Metal 相關(guān)的錯(cuò)誤。一個(gè)常見(jiàn)的問(wèn)題是動(dòng)態(tài)庫(kù)加載失敗。iOS 對(duì)動(dòng)態(tài)庫(kù)的加載路徑有嚴(yán)格限制Wine 需要的某些庫(kù)可能不在默認(rèn)搜索路徑里。解決辦法是把這些庫(kù)復(fù)制到應(yīng)用的可執(zhí)行文件同級(jí)目錄或者設(shè)置 DYLD_LIBRARY_PATH 環(huán)境變量。但要注意 iOS 對(duì) DYLD 環(huán)境變量的限制不是所有情況都能生效。5.2 圖形渲染問(wèn)題與解決方案圖形問(wèn)題是 Wine on iOS 最常見(jiàn)的故障。表現(xiàn)包括黑屏、花屏、紋理錯(cuò)亂、幀率極低等。黑屏通常意味著 DXMT 沒(méi)有正確初始化或者 D3D 設(shè)備創(chuàng)建失敗?；ㄆ梁图y理錯(cuò)亂往往是紋理格式轉(zhuǎn)換的問(wèn)題。幀率極低可能是著色器編譯卡頓或者 FEX-Emu 翻譯效率低。解決圖形問(wèn)題的思路是逐層排查。先確認(rèn) Metal 層是否正常工作可以寫(xiě)一個(gè)簡(jiǎn)單的 Metal 測(cè)試程序來(lái)驗(yàn)證。然后確認(rèn) DXMT 是否能正確創(chuàng)建 D3D 設(shè)備可以用 DXMT 自帶的測(cè)試工具。最后確認(rèn)具體的 D3D 調(diào)用是否被正確翻譯這需要查看 DXMT 的日志。紋理格式轉(zhuǎn)換是個(gè)高頻問(wèn)題。D3D 游戲常用的 BC1-BC7 壓縮紋理Metal 只原生支持部分格式。DXMT 需要在運(yùn)行時(shí)把不支持的格式轉(zhuǎn)換成 Metal 支持的格式這個(gè)轉(zhuǎn)換過(guò)程可能引入色差或者性能損耗。我實(shí)測(cè)下來(lái)BC1 和 BC3 的轉(zhuǎn)換效果比較好BC6H 和 BC7 的轉(zhuǎn)換還有待優(yōu)化。5.3 音頻與輸入設(shè)備適配音頻方面Wine 在 iOS 上需要用 CoreAudio 作為后端。配置正確的話大部分程序的音頻都能正常播放。但有些程序使用了 DirectSound 或者 XAudio2 的高級(jí)特性可能需要額外的適配。我遇到過(guò)音頻延遲和爆音的問(wèn)題通過(guò)調(diào)整 CoreAudio 的緩沖區(qū)大小可以緩解。輸入設(shè)備方面iOS 支持觸摸屏、外接鍵盤(pán)、外接鼠標(biāo)、游戲手柄。Wine 需要把這些輸入事件翻譯成 Windows 的鼠標(biāo)和鍵盤(pán)消息。觸摸屏的適配比較麻煩因?yàn)?Windows 程序通常假設(shè)有精確的鼠標(biāo)指針而觸摸操作沒(méi)有懸停狀態(tài)。我的做法是把觸摸事件映射成鼠標(biāo)點(diǎn)擊長(zhǎng)按映射成右鍵雙指手勢(shì)映射成滾輪。外接鍵盤(pán)和鼠標(biāo)的適配相對(duì)簡(jiǎn)單iOS 本身就有很好的支持。游戲手柄的適配需要用到 GameController 框架把手柄的按鍵和搖桿事件翻譯成 XInput 或者 DirectInput 消息。這部分工作比較繁瑣但一旦做好游戲體驗(yàn)會(huì)提升很多。5.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方法解決方案應(yīng)用啟動(dòng)即崩潰簽名問(wèn)題或權(quán)限不足查看系統(tǒng)日志重新簽名檢查 entitlementsWine 初始化失敗prefix 路徑錯(cuò)誤檢查 WINEPREFIX 環(huán)境變量確保路徑在沙盒可寫(xiě)目錄程序啟動(dòng)黑屏DXMT 初始化失敗查看 DXMT 日志檢查 Metal 設(shè)備創(chuàng)建中文顯示亂碼字體缺失或映射錯(cuò)誤檢查注冊(cè)表字體配置安裝中文字體并正確映射幀率極低著色器編譯卡頓查看幀率曲線啟用著色器緩存音頻爆音CoreAudio 緩沖區(qū)過(guò)小調(diào)整緩沖區(qū)大小增大緩沖區(qū)到 512 或 1024觸摸操作不靈敏輸入映射不合理測(cè)試觸摸事件調(diào)整觸摸到鼠標(biāo)的映射參數(shù)內(nèi)存不足被殺內(nèi)存占用過(guò)高監(jiān)控內(nèi)存使用優(yōu)化 Wine 堆大小和緩存策略6. 性能優(yōu)化與進(jìn)階技巧6.1 FEX-Emu 翻譯緩存調(diào)優(yōu)FEX-Emu 的翻譯緩存是影響性能的關(guān)鍵因素。默認(rèn)配置下FEX-Emu 會(huì)為每個(gè)翻譯塊分配內(nèi)存翻譯塊的大小和數(shù)量直接影響緩存命中率和內(nèi)存占用。我一般會(huì)先把緩存大小設(shè)置為一個(gè)較大的值比如 256MB然后觀察程序的運(yùn)行情況。如果緩存命中率低說(shuō)明翻譯塊太小或者緩存淘汰策略太激進(jìn)需要調(diào)整。FEX-Emu 還支持多線程翻譯可以利用多核 CPU 并行翻譯不同的代碼塊。在 Apple Silicon 上這個(gè)特性可以顯著提升啟動(dòng)速度。但多線程翻譯也會(huì)增加內(nèi)存開(kāi)銷和同步復(fù)雜度需要根據(jù)設(shè)備性能來(lái)權(quán)衡。另一個(gè)優(yōu)化點(diǎn)是寄存器分配策略。FEX-Emu 可以把 x86-64 的寄存器映射到 ARM64 的寄存器也可以映射到內(nèi)存。映射到寄存器速度快但寄存器數(shù)量有限映射到內(nèi)存速度慢但不受數(shù)量限制。我實(shí)測(cè)下來(lái)對(duì)于計(jì)算密集型的程序寄存器映射策略對(duì)性能影響很大需要根據(jù)具體程序的寄存器使用特征來(lái)調(diào)整。6.2 DXMT 著色器編譯優(yōu)化DXMT 的著色器編譯是另一個(gè)性能瓶頸。D3D 著色器需要先編譯成 DXBC然后 DXMT 把 DXBC 轉(zhuǎn)換成 Metal 的 AIR最后 Metal 驅(qū)動(dòng)再把 AIR 編譯成 GPU 機(jī)器碼。這個(gè)多級(jí)編譯過(guò)程在程序啟動(dòng)時(shí)會(huì)造成明顯的卡頓。優(yōu)化思路是預(yù)編譯和緩存。預(yù)編譯是指在程序安裝階段就把常用的著色器編譯好運(yùn)行時(shí)直接加載編譯結(jié)果。緩存是指把運(yùn)行時(shí)編譯的著色器結(jié)果保存下來(lái)下次運(yùn)行時(shí)直接使用。DXMT 支持這兩種優(yōu)化但需要正確配置緩存路徑和緩存策略。我實(shí)測(cè)下來(lái)啟用著色器緩存后第二次啟動(dòng)同一個(gè)程序的加載時(shí)間可以減少 50% 以上。對(duì)于大型游戲這個(gè)優(yōu)化效果非常明顯。但緩存文件會(huì)占用存儲(chǔ)空間需要定期清理舊的緩存。6.3 內(nèi)存與存儲(chǔ)空間管理iOS 設(shè)備的存儲(chǔ)空間有限Wine prefix 加上安裝的程序加上緩存文件很容易占用幾個(gè) GB 的空間。管理存儲(chǔ)空間的幾個(gè)技巧一是定期清理 Wine 的臨時(shí)文件和日志二是壓縮不常用的程序文件三是把大文件比如游戲資源放在外部存儲(chǔ)或者 iCloud 上需要時(shí)再下載。內(nèi)存管理方面iOS 的內(nèi)存壓縮和內(nèi)存交換機(jī)制可以幫助緩解內(nèi)存壓力但效果有限。我的做法是在應(yīng)用內(nèi)實(shí)現(xiàn)一個(gè)簡(jiǎn)單的內(nèi)存監(jiān)控當(dāng)內(nèi)存占用接近上限時(shí)主動(dòng)釋放一些緩存比如 FEX-Emu 的翻譯緩存、DXMT 的著色器緩存避免被系統(tǒng)殺掉。還有一個(gè)技巧是調(diào)整 Wine 的堆大小。Wine 默認(rèn)會(huì)預(yù)留較大的虛擬內(nèi)存空間在 iOS 上這個(gè)預(yù)留可能過(guò)大。通過(guò)設(shè)置WINEDEBUG-all和調(diào)整注冊(cè)表里的堆配置可以減少不必要的內(nèi)存預(yù)留。7. 我在這條路上踩過(guò)的坑第一個(gè)坑是低估了 iOS 的 JIT 限制。一開(kāi)始我以為可以用 FEX-Emu 的默認(rèn) JIT 模式結(jié)果發(fā)現(xiàn) iOS 根本不允許動(dòng)態(tài)生成可執(zhí)行代碼。后來(lái)改用提前翻譯加解釋執(zhí)行的混合模式才勉強(qiáng)跑起來(lái)。這個(gè)限制是 iOS 上跑 Wine 最大的技術(shù)障礙沒(méi)有之一。第二個(gè)坑是字體配置。Wine 默認(rèn)的字體在 iOS 上大部分都不存在導(dǎo)致中文程序全是亂碼。我試過(guò)直接把 Windows 的字體文件復(fù)制進(jìn)去但有些字體有版權(quán)問(wèn)題而且文件很大。后來(lái)改用開(kāi)源字體替代配合注冊(cè)表映射才解決了亂碼問(wèn)題。熱搜詞里的 “wine 亂碼” 和 “wine 欄是亂碼”我猜大概率也是這個(gè)原因。第三個(gè)坑是 DXMT 的紋理格式轉(zhuǎn)換。我跑一個(gè)老游戲的時(shí)候畫(huà)面全是花屏排查了很久才發(fā)現(xiàn)是 BC3 紋理格式轉(zhuǎn)換有問(wèn)題。DXMT 的 BC3 轉(zhuǎn)換代碼有個(gè)邊界條件沒(méi)處理好導(dǎo)致某些尺寸的紋理轉(zhuǎn)換出錯(cuò)。后來(lái)手動(dòng)改了轉(zhuǎn)換代碼問(wèn)題才解決。這個(gè)經(jīng)歷告訴我DXMT 雖然技術(shù)路線對(duì)但成熟度還不夠需要做好踩坑的準(zhǔn)備。第四個(gè)坑是內(nèi)存管理。我一開(kāi)始沒(méi)太在意內(nèi)存占用結(jié)果程序跑著跑著就被系統(tǒng)殺了。后來(lái)加了內(nèi)存監(jiān)控和主動(dòng)釋放機(jī)制才穩(wěn)定下來(lái)。iOS 的內(nèi)存管理比桌面嚴(yán)格得多必須時(shí)刻關(guān)注內(nèi)存使用情況。第五個(gè)坑是音頻延遲。Wine 的音頻輸出在 iOS 上有明顯的延遲玩游戲的時(shí)候音畫(huà)不同步。后來(lái)調(diào)整了 CoreAudio 的緩沖區(qū)大小從默認(rèn)的 256 調(diào)到 1024延遲明顯改善但代價(jià)是音頻的實(shí)時(shí)性下降。這個(gè)權(quán)衡需要根據(jù)具體使用場(chǎng)景來(lái)定。8. 這個(gè)方向后續(xù)還能怎么玩Madeira 這個(gè)項(xiàng)目標(biāo)題背后的技術(shù)棧其實(shí)還有很多可以探索的空間。比如把 Wine 的 Direct3D 12 支持做起來(lái)現(xiàn)在 DXMT 主要支持 D3D 11 和部分 D3D 12 特性完整的 D3D 12 支持還需要大量工作。再比如把 FEX-Emu 的翻譯優(yōu)化做得更智能根據(jù)程序的運(yùn)行特征動(dòng)態(tài)調(diào)整翻譯策略而不是用固定的配置。還有一個(gè)有趣的方向是把 Wine 和 iOS 的原生能力結(jié)合起來(lái)。比如用 iOS 的 MetalFX 做超分辨率用 Game Mode 做性能調(diào)度用 SharePlay 做多人游戲。這些 iOS 特有的能力如果能和 Wine 結(jié)合起來(lái)可能會(huì)帶來(lái)一些桌面平臺(tái)沒(méi)有的體驗(yàn)。從更長(zhǎng)遠(yuǎn)的角度看Apple Silicon 的性能還在快速提升M 系列芯片的 GPU 性能已經(jīng)接近入門(mén)級(jí)獨(dú)顯的水平。如果 Apple 能進(jìn)一步開(kāi)放 iOS 的 JIT 限制或者提供官方的虛擬化方案那在 iOS 上跑 Windows 應(yīng)用的體驗(yàn)會(huì)有質(zhì)的飛躍。當(dāng)然這取決于 Apple 的策略不是技術(shù)社區(qū)能決定的。我個(gè)人在實(shí)際操作中的體會(huì)是這個(gè)方向的技術(shù)挑戰(zhàn)很大但每一步進(jìn)展都很有成就感。如果你也對(duì)在 iOS 上跑 Windows 應(yīng)用感興趣建議從最簡(jiǎn)單的程序開(kāi)始比如記事本、計(jì)算器這種先把整個(gè)流程跑通再逐步挑戰(zhàn)更復(fù)雜的程序。不要一上來(lái)就想著跑 3A 游戲那樣很容易受挫。慢慢來(lái)比較快。 iOS 上跑 Windows 應(yīng)用：Wine + FEX-Emu + DXMT 三層技術(shù)棧實(shí)戰(zhàn)
1. 項(xiàng)目緣起為什么要在 iOS 上折騰 Wine第一次看到 “Madeira” 這個(gè)代號(hào)很多人會(huì)以為是那個(gè)葡萄牙的旅游海島但在我們這群喜歡在移動(dòng)設(shè)備上跑桌面應(yīng)用的人眼里它代表的是一個(gè)相當(dāng)硬核的方向把 Wine 的 Windows 兼容層能力想辦法搬到 iOS 設(shè)備上去。熱搜詞里同時(shí)出現(xiàn)了 Wine、FEX-Emu、DXMT、iOS、x86-64 這幾個(gè)關(guān)鍵詞基本就把這個(gè)項(xiàng)目的技術(shù)輪廓勾勒清楚了——它要解決的核心問(wèn)題是如何讓 iOS 設(shè)備尤其是 Apple Silicon 芯片的 iPhone 和 iPad能夠運(yùn)行原本為 Windows/x86-64 編譯的應(yīng)用程序。這件事聽(tīng)起來(lái)像是天方夜譚因?yàn)?iOS 的沙盒機(jī)制、代碼簽名、JIT 限制、內(nèi)存管理策略每一條都在跟“運(yùn)行任意桌面二進(jìn)制”這件事對(duì)著干。但偏偏就是有一批人前赴后繼地在這個(gè)方向上做嘗試從早期的 iSH 到后來(lái)的 UTM再到現(xiàn)在的各種 Wine 移植方案社區(qū)一直在摸索。Madeira 這個(gè)項(xiàng)目標(biāo)題背后我理解它想做的事情是把 Wine 的 Windows API 翻譯層、FEX-Emu 的 x86-64 到 ARM64 的指令翻譯層、以及 DXMT 的 Direct3D 到 Metal 的圖形翻譯層這三層技術(shù)棧整合到一起形成一個(gè)能在 iOS 上跑 Windows 應(yīng)用的完整方案。為什么是這三層因?yàn)?Windows 應(yīng)用運(yùn)行在 iOS 上需要跨越三道鴻溝。第一道是系統(tǒng)調(diào)用和 API 的鴻溝Windows 應(yīng)用調(diào)用的是 kernel32.dll、user32.dll 這些iOS 根本沒(méi)有Wine 就是干這個(gè)翻譯的。第二道是指令集的鴻溝大量 Windows 應(yīng)用是 x86-64 編譯的而 iOS 設(shè)備是 ARM64 架構(gòu)FEX-Emu 負(fù)責(zé)把 x86-64 指令實(shí)時(shí)翻譯成 ARM64 指令。第三道是圖形的鴻溝Windows 應(yīng)用用 Direct3D 渲染iOS 只認(rèn) MetalDXMT 就是在這兩者之間架橋。這三層缺一不可任何一層出問(wèn)題應(yīng)用就跑不起來(lái)或者跑不流暢。適合誰(shuí)來(lái)參考這篇內(nèi)容如果你是對(duì) iOS 底層機(jī)制感興趣的開(kāi)發(fā)者或者想在移動(dòng)設(shè)備上跑一些老 Windows 程序、獨(dú)立游戲、小型工具軟件又或者你只是好奇 Wine 這套東西在 ARM 平臺(tái)上到底能跑成什么樣那接下來(lái)的內(nèi)容應(yīng)該對(duì)你有用。我會(huì)盡量把每一層的原理、實(shí)操要點(diǎn)、踩坑經(jīng)驗(yàn)都講清楚讓你看完能自己動(dòng)手試。2. 三層技術(shù)棧的拆解與選型邏輯2.1 Wine 層API 翻譯的核心機(jī)制Wine 的全稱是 “Wine Is Not an Emulator”這句話本身就是它的設(shè)計(jì)哲學(xué)——它不做 CPU 指令模擬而是直接實(shí)現(xiàn) Windows 的 API。當(dāng) Windows 程序調(diào)用 CreateWindowEx 的時(shí)候Wine 把這個(gè)調(diào)用翻譯成對(duì)應(yīng)的 X11 或者 Wayland 或者 Cocoa 調(diào)用。在 Linux 桌面上這套東西已經(jīng)跑了三十年了成熟度相當(dāng)高。但到了 iOS 上問(wèn)題就變得復(fù)雜了。iOS 沒(méi)有 X11沒(méi)有 Wayland圖形棧完全是另一套。Wine 在 iOS 上需要把 Win32 的窗口管理翻譯成 UIKit 的視圖層級(jí)把 GDI 繪圖翻譯成 Core Graphics 或者 Metal。這部分工作需要大量的適配代碼而且 iOS 的沙盒限制意味著 Wine 不能隨意訪問(wèn)文件系統(tǒng)所有路徑映射都要重新設(shè)計(jì)。熱搜詞里出現(xiàn)的 “wine 亂碼” 和 “wine 欄是亂碼”大概率就是字符編碼和字體映射沒(méi)處理好導(dǎo)致的這在跨平臺(tái) Wine 移植里是非常典型的問(wèn)題。Wine 的版本選擇也很關(guān)鍵。社區(qū)里常用的有 Wine 官方版、ProtonValve 的定制版、以及各種針對(duì)特定平臺(tái)優(yōu)化的分支。在 iOS 場(chǎng)景下我傾向于選擇較新的 Wine 版本因?yàn)樾掳姹緦?duì) ARM64 的支持更好而且 DXVK、VKD3D 這些圖形翻譯層的集成度更高。但新版本也可能引入新的兼容性問(wèn)題所以實(shí)際選型時(shí)需要在功能和穩(wěn)定性之間做權(quán)衡。2.2 FEX-Emu 層x86-64 到 ARM64 的指令翻譯FEX-Emu 是這個(gè)技術(shù)棧里最容易被低估的一環(huán)。它的作用是把 x86-64 的機(jī)器指令實(shí)時(shí)翻譯成 ARM64 指令讓原本為 Intel/AMD 處理器編譯的程序能在 Apple Silicon 上運(yùn)行。這跟傳統(tǒng)的模擬器不一樣FEX-Emu 不做完整的 CPU 狀態(tài)模擬而是做靜態(tài)二進(jìn)制翻譯加動(dòng)態(tài)優(yōu)化性能損耗相對(duì)可控。FEX-Emu 的核心技術(shù)點(diǎn)包括指令解碼、中間表示生成、寄存器映射、內(nèi)存模型適配。x86-64 有 16 個(gè)通用寄存器ARM64 有 31 個(gè)寄存器映射策略直接影響翻譯效率。內(nèi)存模型方面x86-64 是強(qiáng)內(nèi)存模型ARM64 是弱內(nèi)存模型FEX-Emu 需要插入適當(dāng)?shù)膬?nèi)存屏障指令來(lái)保證多線程程序的正確性。這些細(xì)節(jié)決定了最終跑起來(lái)的程序是“能跑”還是“跑得動(dòng)”。在 iOS 上使用 FEX-Emu 還有一個(gè)特殊限制iOS 不允許應(yīng)用動(dòng)態(tài)生成可執(zhí)行代碼JIT 限制而 FEX-Emu 的翻譯過(guò)程本質(zhì)上就是在運(yùn)行時(shí)生成 ARM64 代碼。這就需要一個(gè)變通方案比如提前把 x86-64 代碼翻譯成 ARM64 代碼再打包進(jìn)應(yīng)用或者利用 iOS 的某些合法 JIT 場(chǎng)景比如 WebKit 的 JavaScriptCore。這個(gè)限制是 iOS 上跑 Wine 最大的技術(shù)障礙之一也是各種方案差異化的關(guān)鍵所在。2.3 DXMT 層Direct3D 到 Metal 的圖形翻譯DXMT 是 Direct3D Metal Translation 的縮寫(xiě)顧名思義它把 Windows 的 Direct3D 調(diào)用翻譯成 Apple 的 Metal 調(diào)用。為什么不用 DXVK因?yàn)?DXVK 是把 D3D 翻譯成 Vulkan而 iOS 上沒(méi)有原生 Vulkan 支持還得再套一層 MoltenVK 把 Vulkan 翻譯成 Metal多一層翻譯就多一層性能損耗和兼容性問(wèn)題。DXMT 直接做 D3D 到 Metal 的翻譯路徑更短理論上效率更高。DXMT 需要處理的 D3D 特性包括著色器編譯、紋理格式轉(zhuǎn)換、渲染狀態(tài)管理、資源綁定模型。D3D 的著色器是 HLSL 編譯成的 DXBC 字節(jié)碼Metal 用的是 AIR 字節(jié)碼DXMT 需要把 DXBC 反編譯再重新編譯成 AIR。紋理格式方面D3D 有大量的壓縮紋理格式BC1-BC7Metal 支持的是 ASTC 和部分 BC 格式不匹配的格式需要運(yùn)行時(shí)轉(zhuǎn)換。這些轉(zhuǎn)換工作都會(huì)帶來(lái)性能開(kāi)銷所以 DXMT 的優(yōu)化程度直接決定了游戲能不能流暢運(yùn)行。熱搜詞里出現(xiàn)的 “DXMT” 和 “iOS” 組合說(shuō)明已經(jīng)有人在關(guān)注這個(gè)方向了。目前 DXMT 還處于比較早期的階段支持的 D3D 版本和特性集有限但它的技術(shù)路線是對(duì)的隨著 Apple Silicon 圖形性能的不斷提升這個(gè)方向的天花板很高。3. iOS 平臺(tái)的特殊限制與應(yīng)對(duì)策略3.1 沙盒機(jī)制與文件系統(tǒng)訪問(wèn)iOS 的沙盒機(jī)制是每個(gè)應(yīng)用只能訪問(wèn)自己的容器目錄不能隨意讀取系統(tǒng)其他位置的文件。這對(duì) Wine 來(lái)說(shuō)是個(gè)大問(wèn)題因?yàn)?Windows 程序習(xí)慣性地認(rèn)為可以訪問(wèn) C:\Windows\System32、C:\Program Files 這些路徑。在 iOS 上這些路徑需要被重定向到應(yīng)用沙盒內(nèi)的某個(gè)目錄Wine 的路徑映射機(jī)制需要做相應(yīng)的適配。我的做法是在應(yīng)用沙盒內(nèi)創(chuàng)建一個(gè)虛擬的 C 盤(pán)目錄結(jié)構(gòu)把 Wine 的 prefix也就是模擬的 Windows 環(huán)境放在這里。然后通過(guò) Wine 的注冊(cè)表配置把常見(jiàn)的 Windows 路徑映射到這個(gè)虛擬目錄。用戶安裝 Windows 程序時(shí)實(shí)際上是把文件復(fù)制到這個(gè)虛擬目錄里。這個(gè)方案的好處是完全符合 iOS 的沙盒規(guī)則不需要越獄或者特殊權(quán)限。壞處是用戶不能直接訪問(wèn)這個(gè)目錄需要通過(guò)應(yīng)用提供的文件管理界面來(lái)操作。文件導(dǎo)入導(dǎo)出也是個(gè)問(wèn)題。iOS 應(yīng)用可以通過(guò) Document Picker 讓用戶選擇文件也可以通過(guò)分享擴(kuò)展接收其他應(yīng)用傳來(lái)的文件。Wine 應(yīng)用需要把這些外部文件復(fù)制到自己的沙盒內(nèi)才能訪問(wèn)。我實(shí)測(cè)下來(lái)用 UIDocumentPickerViewController 做文件導(dǎo)入是比較穩(wěn)的方案支持多選和文件夾選擇用戶體驗(yàn)也還可以。3.2 代碼簽名與 JIT 限制iOS 對(duì)可執(zhí)行代碼的簽名要求非常嚴(yán)格所有在設(shè)備上運(yùn)行的代碼都必須經(jīng)過(guò) Apple 的簽名。這意味著不能像在桌面上那樣隨意加載動(dòng)態(tài)庫(kù)或者生成可執(zhí)行代碼。Wine 本身是 C 代碼編譯的這部分沒(méi)問(wèn)題但 FEX-Emu 的 JIT 翻譯過(guò)程就麻煩了。目前社區(qū)里主要有幾種應(yīng)對(duì)思路。一種是提前翻譯也就是在應(yīng)用打包階段就把 x86-64 代碼翻譯成 ARM64 代碼運(yùn)行時(shí)直接執(zhí)行翻譯后的代碼。這種方案的缺點(diǎn)是失去了動(dòng)態(tài)翻譯的靈活性只能運(yùn)行預(yù)先翻譯過(guò)的程序。另一種是利用 iOS 的 JavaScriptCore 或者 WebAssembly 引擎來(lái)做間接的代碼生成因?yàn)檫@些引擎有合法的 JIT 權(quán)限。這種方案更靈活但性能損耗更大而且實(shí)現(xiàn)復(fù)雜度高。還有一個(gè)思路是把 Wine 和 FEX-Emu 跑在一個(gè)解釋器上完全不做 JIT純解釋執(zhí)行。這種方案性能最差但兼容性最好適合跑一些對(duì)性能要求不高的老程序。我試過(guò)用純解釋模式跑一個(gè)簡(jiǎn)單的 Windows 記事本程序啟動(dòng)大概要十幾秒操作響應(yīng)也有明顯延遲但確實(shí)能跑起來(lái)。3.3 內(nèi)存管理與性能調(diào)優(yōu)iOS 的內(nèi)存管理比桌面系統(tǒng)嚴(yán)格得多應(yīng)用能使用的內(nèi)存上限取決于設(shè)備型號(hào)和系統(tǒng)版本。Wine 加上 FEX-Emu 加上 DXMT這三層加起來(lái)的內(nèi)存開(kāi)銷不小再加上 Windows 程序本身的內(nèi)存需求很容易觸碰到 iOS 的內(nèi)存上限被系統(tǒng)殺掉。優(yōu)化內(nèi)存使用的幾個(gè)方向一是調(diào)整 Wine 的堆大小和虛擬內(nèi)存配置減少不必要的內(nèi)存預(yù)留二是優(yōu)化 FEX-Emu 的翻譯緩存避免重復(fù)翻譯同一段代碼三是用 Metal 的資源堆管理來(lái)減少圖形內(nèi)存的碎片化。我實(shí)測(cè)下來(lái)在 8GB 內(nèi)存的 iPad Pro 上跑一個(gè)中等復(fù)雜度的 Windows 程序內(nèi)存占用大概在 2-3GB 左右還有一定的余量。但在 4GB 內(nèi)存的 iPhone 上就比較緊張了需要更精細(xì)的內(nèi)存控制。性能調(diào)優(yōu)方面FEX-Emu 的翻譯塊大小和緩存策略對(duì)性能影響很大。翻譯塊太小翻譯開(kāi)銷大翻譯塊太大緩存命中率低。我一般會(huì)從默認(rèn)配置開(kāi)始然后根據(jù)具體程序的運(yùn)行特征來(lái)調(diào)整。DXMT 這邊著色器編譯緩存和紋理上傳策略是關(guān)鍵把常用的著色器和紋理緩存起來(lái)能顯著減少卡頓。4. 實(shí)操過(guò)程從零搭建一個(gè)可運(yùn)行的 Wine 環(huán)境4.1 環(huán)境準(zhǔn)備與依賴安裝在開(kāi)始之前你需要一臺(tái)運(yùn)行 macOS 的電腦用來(lái)編譯以及一臺(tái) iOS 設(shè)備用來(lái)測(cè)試。Xcode 是必須的建議用最新穩(wěn)定版。還需要安裝 CMake、Ninja、Python3 這些構(gòu)建工具。如果你打算自己編譯 Wine 和 FEX-Emu還需要安裝對(duì)應(yīng)的交叉編譯工具鏈。第一步是獲取源碼。Wine 的源碼可以從官方倉(cāng)庫(kù)獲取FEX-Emu 和 DXMT 也都有各自的倉(cāng)庫(kù)。我建議用 git clone 把三個(gè)倉(cāng)庫(kù)都拉到本地然后分別切換到穩(wěn)定的 release 分支。不要直接用 main 分支因?yàn)殚_(kāi)發(fā)中的代碼可能不穩(wěn)定。第二步是配置編譯選項(xiàng)。Wine 需要配置成 ARM64 目標(biāo)并且啟用對(duì) iOS 的支持。FEX-Emu 需要配置成 ARM64 宿主、x86-64 客戶機(jī)的模式。DXMT 需要鏈接 Metal 和 MetalKit 框架。這些配置項(xiàng)比較多我整理了一個(gè)關(guān)鍵的配置表格組件關(guān)鍵編譯選項(xiàng)說(shuō)明Wine--hostaarch64-apple-darwin指定 ARM64 目標(biāo)Wine--with-coregraphics啟用 Core Graphics 后端Wine--without-x禁用 X11 支持FEX-Emu-DCMAKE_TOOLCHAIN_FILEios.toolchain.cmake使用 iOS 工具鏈FEX-Emu-DENABLE_JITOFF關(guān)閉 JITiOS 限制DXMT-DMETAL_ENABLE_VALIDATIONOFF關(guān)閉 Metal 驗(yàn)證層第三步是編譯。這個(gè)過(guò)程比較耗時(shí)Wine 的完整編譯在 M 系列芯片的 Mac 上大概需要 20-30 分鐘FEX-Emu 和 DXMT 相對(duì)快一些。編譯過(guò)程中可能會(huì)遇到各種依賴缺失的問(wèn)題需要根據(jù)報(bào)錯(cuò)信息逐個(gè)解決。4.2 Wine Prefix 的創(chuàng)建與配置編譯完成后下一步是在 iOS 設(shè)備上創(chuàng)建 Wine prefix。Prefix 是 Wine 用來(lái)模擬 Windows 環(huán)境的目錄里面包含了注冊(cè)表、系統(tǒng)目錄、以及安裝的應(yīng)用程序。在 iOS 上這個(gè)目錄位于應(yīng)用的沙盒內(nèi)。創(chuàng)建 prefix 的命令是 wineboot這個(gè)命令會(huì)初始化一個(gè)空的 Windows 環(huán)境。在 iOS 上運(yùn)行這個(gè)命令需要確保 Wine 的路徑配置正確特別是 WINEPREFIX 環(huán)境變量要指向沙盒內(nèi)的可寫(xiě)目錄。我一般會(huì)在應(yīng)用啟動(dòng)時(shí)檢查 prefix 是否存在不存在就自動(dòng)創(chuàng)建。Prefix 創(chuàng)建完成后需要做一些配置調(diào)整。比如設(shè)置 Windows 版本winecfg 里可以改安裝必要的字體解決亂碼問(wèn)題配置音頻驅(qū)動(dòng)iOS 上用 CoreAudio配置圖形驅(qū)動(dòng)指向 DXMT。這些配置可以通過(guò)注冊(cè)表文件批量導(dǎo)入比手動(dòng)在 winecfg 里點(diǎn)來(lái)點(diǎn)去效率高得多。字體配置是解決亂碼的關(guān)鍵。Wine 默認(rèn)使用的字體在 iOS 上可能不存在需要把開(kāi)源的字體文件比如 Noto Sans、Wine 自帶的 Tahoma 替代字體復(fù)制到 prefix 的字體目錄然后在注冊(cè)表里把默認(rèn)字體映射到這些字體上。我實(shí)測(cè)下來(lái)把 simsun.ttc 和 msyh.ttf 這兩個(gè)字體放進(jìn)去大部分中文程序的亂碼問(wèn)題都能解決。4.3 應(yīng)用程序的安裝與運(yùn)行安裝 Windows 程序到 prefix 里最簡(jiǎn)單的方式是用 wine 命令直接運(yùn)行安裝程序。比如wine setup.exe就會(huì)啟動(dòng)安裝向?qū)А５?iOS 上由于沒(méi)有圖形化的文件選擇對(duì)話框需要先把安裝程序復(fù)制到 prefix 的某個(gè)目錄然后用命令行指定路徑來(lái)運(yùn)行。安裝完成后運(yùn)行程序也是類似的命令。我建議給每個(gè)安裝的程序創(chuàng)建一個(gè)啟動(dòng)腳本把必要的環(huán)境變量和命令行參數(shù)都寫(xiě)進(jìn)去這樣用戶點(diǎn)擊圖標(biāo)就能啟動(dòng)不需要手動(dòng)敲命令。啟動(dòng)腳本可以是一個(gè)簡(jiǎn)單的 shell 腳本或者用 iOS 的 Shortcuts 來(lái)實(shí)現(xiàn)。運(yùn)行時(shí)的性能監(jiān)控很重要。我一般會(huì)在應(yīng)用里加一個(gè)簡(jiǎn)單的幀率顯示和內(nèi)存占用顯示方便判斷當(dāng)前運(yùn)行狀態(tài)。如果幀率過(guò)低或者內(nèi)存占用過(guò)高就需要調(diào)整配置。FEX-Emu 的翻譯緩存大小、DXMT 的著色器緩存策略、Wine 的堆大小這些都是可以調(diào)的參數(shù)。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 啟動(dòng)失敗與崩潰排查Wine 應(yīng)用在 iOS 上啟動(dòng)失敗的原因很多我整理了一個(gè)排查流程。首先看應(yīng)用是否正常啟動(dòng)如果應(yīng)用本身都起不來(lái)那可能是簽名或者權(quán)限問(wèn)題。如果應(yīng)用能啟動(dòng)但 Wine 初始化失敗那可能是 prefix 路徑配置錯(cuò)誤或者依賴庫(kù)缺失。如果 Wine 能初始化但程序啟動(dòng)崩潰那可能是 FEX-Emu 翻譯出錯(cuò)或者 DXMT 圖形初始化失敗。查看日志是排查問(wèn)題的第一步。Wine 有 WINEDEBUG 環(huán)境變量可以控制日志輸出級(jí)別我一般會(huì)設(shè)置WINEDEBUGall來(lái)獲取最詳細(xì)的日志然后根據(jù)日志里的錯(cuò)誤信息定位問(wèn)題。FEX-Emu 也有自己的日志系統(tǒng)可以輸出翻譯過(guò)程中的詳細(xì)信息。DXMT 的日志會(huì)顯示 Metal 相關(guān)的錯(cuò)誤。一個(gè)常見(jiàn)的問(wèn)題是動(dòng)態(tài)庫(kù)加載失敗。iOS 對(duì)動(dòng)態(tài)庫(kù)的加載路徑有嚴(yán)格限制Wine 需要的某些庫(kù)可能不在默認(rèn)搜索路徑里。解決辦法是把這些庫(kù)復(fù)制到應(yīng)用的可執(zhí)行文件同級(jí)目錄或者設(shè)置 DYLD_LIBRARY_PATH 環(huán)境變量。但要注意 iOS 對(duì) DYLD 環(huán)境變量的限制不是所有情況都能生效。5.2 圖形渲染問(wèn)題與解決方案圖形問(wèn)題是 Wine on iOS 最常見(jiàn)的故障。表現(xiàn)包括黑屏、花屏、紋理錯(cuò)亂、幀率極低等。黑屏通常意味著 DXMT 沒(méi)有正確初始化或者 D3D 設(shè)備創(chuàng)建失敗?；ㄆ梁图y理錯(cuò)亂往往是紋理格式轉(zhuǎn)換的問(wèn)題。幀率極低可能是著色器編譯卡頓或者 FEX-Emu 翻譯效率低。解決圖形問(wèn)題的思路是逐層排查。先確認(rèn) Metal 層是否正常工作可以寫(xiě)一個(gè)簡(jiǎn)單的 Metal 測(cè)試程序來(lái)驗(yàn)證。然后確認(rèn) DXMT 是否能正確創(chuàng)建 D3D 設(shè)備可以用 DXMT 自帶的測(cè)試工具。最后確認(rèn)具體的 D3D 調(diào)用是否被正確翻譯這需要查看 DXMT 的日志。紋理格式轉(zhuǎn)換是個(gè)高頻問(wèn)題。D3D 游戲常用的 BC1-BC7 壓縮紋理Metal 只原生支持部分格式。DXMT 需要在運(yùn)行時(shí)把不支持的格式轉(zhuǎn)換成 Metal 支持的格式這個(gè)轉(zhuǎn)換過(guò)程可能引入色差或者性能損耗。我實(shí)測(cè)下來(lái)BC1 和 BC3 的轉(zhuǎn)換效果比較好BC6H 和 BC7 的轉(zhuǎn)換還有待優(yōu)化。5.3 音頻與輸入設(shè)備適配音頻方面Wine 在 iOS 上需要用 CoreAudio 作為后端。配置正確的話大部分程序的音頻都能正常播放。但有些程序使用了 DirectSound 或者 XAudio2 的高級(jí)特性可能需要額外的適配。我遇到過(guò)音頻延遲和爆音的問(wèn)題通過(guò)調(diào)整 CoreAudio 的緩沖區(qū)大小可以緩解。輸入設(shè)備方面iOS 支持觸摸屏、外接鍵盤(pán)、外接鼠標(biāo)、游戲手柄。Wine 需要把這些輸入事件翻譯成 Windows 的鼠標(biāo)和鍵盤(pán)消息。觸摸屏的適配比較麻煩因?yàn)?Windows 程序通常假設(shè)有精確的鼠標(biāo)指針而觸摸操作沒(méi)有懸停狀態(tài)。我的做法是把觸摸事件映射成鼠標(biāo)點(diǎn)擊長(zhǎng)按映射成右鍵雙指手勢(shì)映射成滾輪。外接鍵盤(pán)和鼠標(biāo)的適配相對(duì)簡(jiǎn)單iOS 本身就有很好的支持。游戲手柄的適配需要用到 GameController 框架把手柄的按鍵和搖桿事件翻譯成 XInput 或者 DirectInput 消息。這部分工作比較繁瑣但一旦做好游戲體驗(yàn)會(huì)提升很多。5.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方法解決方案應(yīng)用啟動(dòng)即崩潰簽名問(wèn)題或權(quán)限不足查看系統(tǒng)日志重新簽名檢查 entitlementsWine 初始化失敗prefix 路徑錯(cuò)誤檢查 WINEPREFIX 環(huán)境變量確保路徑在沙盒可寫(xiě)目錄程序啟動(dòng)黑屏DXMT 初始化失敗查看 DXMT 日志檢查 Metal 設(shè)備創(chuàng)建中文顯示亂碼字體缺失或映射錯(cuò)誤檢查注冊(cè)表字體配置安裝中文字體并正確映射幀率極低著色器編譯卡頓查看幀率曲線啟用著色器緩存音頻爆音CoreAudio 緩沖區(qū)過(guò)小調(diào)整緩沖區(qū)大小增大緩沖區(qū)到 512 或 1024觸摸操作不靈敏輸入映射不合理測(cè)試觸摸事件調(diào)整觸摸到鼠標(biāo)的映射參數(shù)內(nèi)存不足被殺內(nèi)存占用過(guò)高監(jiān)控內(nèi)存使用優(yōu)化 Wine 堆大小和緩存策略6. 性能優(yōu)化與進(jìn)階技巧6.1 FEX-Emu 翻譯緩存調(diào)優(yōu)FEX-Emu 的翻譯緩存是影響性能的關(guān)鍵因素。默認(rèn)配置下FEX-Emu 會(huì)為每個(gè)翻譯塊分配內(nèi)存翻譯塊的大小和數(shù)量直接影響緩存命中率和內(nèi)存占用。我一般會(huì)先把緩存大小設(shè)置為一個(gè)較大的值比如 256MB然后觀察程序的運(yùn)行情況。如果緩存命中率低說(shuō)明翻譯塊太小或者緩存淘汰策略太激進(jìn)需要調(diào)整。FEX-Emu 還支持多線程翻譯可以利用多核 CPU 并行翻譯不同的代碼塊。在 Apple Silicon 上這個(gè)特性可以顯著提升啟動(dòng)速度。但多線程翻譯也會(huì)增加內(nèi)存開(kāi)銷和同步復(fù)雜度需要根據(jù)設(shè)備性能來(lái)權(quán)衡。另一個(gè)優(yōu)化點(diǎn)是寄存器分配策略。FEX-Emu 可以把 x86-64 的寄存器映射到 ARM64 的寄存器也可以映射到內(nèi)存。映射到寄存器速度快但寄存器數(shù)量有限映射到內(nèi)存速度慢但不受數(shù)量限制。我實(shí)測(cè)下來(lái)對(duì)于計(jì)算密集型的程序寄存器映射策略對(duì)性能影響很大需要根據(jù)具體程序的寄存器使用特征來(lái)調(diào)整。6.2 DXMT 著色器編譯優(yōu)化DXMT 的著色器編譯是另一個(gè)性能瓶頸。D3D 著色器需要先編譯成 DXBC然后 DXMT 把 DXBC 轉(zhuǎn)換成 Metal 的 AIR最后 Metal 驅(qū)動(dòng)再把 AIR 編譯成 GPU 機(jī)器碼。這個(gè)多級(jí)編譯過(guò)程在程序啟動(dòng)時(shí)會(huì)造成明顯的卡頓。優(yōu)化思路是預(yù)編譯和緩存。預(yù)編譯是指在程序安裝階段就把常用的著色器編譯好運(yùn)行時(shí)直接加載編譯結(jié)果。緩存是指把運(yùn)行時(shí)編譯的著色器結(jié)果保存下來(lái)下次運(yùn)行時(shí)直接使用。DXMT 支持這兩種優(yōu)化但需要正確配置緩存路徑和緩存策略。我實(shí)測(cè)下來(lái)啟用著色器緩存后第二次啟動(dòng)同一個(gè)程序的加載時(shí)間可以減少 50% 以上。對(duì)于大型游戲這個(gè)優(yōu)化效果非常明顯。但緩存文件會(huì)占用存儲(chǔ)空間需要定期清理舊的緩存。6.3 內(nèi)存與存儲(chǔ)空間管理iOS 設(shè)備的存儲(chǔ)空間有限Wine prefix 加上安裝的程序加上緩存文件很容易占用幾個(gè) GB 的空間。管理存儲(chǔ)空間的幾個(gè)技巧一是定期清理 Wine 的臨時(shí)文件和日志二是壓縮不常用的程序文件三是把大文件比如游戲資源放在外部存儲(chǔ)或者 iCloud 上需要時(shí)再下載。內(nèi)存管理方面iOS 的內(nèi)存壓縮和內(nèi)存交換機(jī)制可以幫助緩解內(nèi)存壓力但效果有限。我的做法是在應(yīng)用內(nèi)實(shí)現(xiàn)一個(gè)簡(jiǎn)單的內(nèi)存監(jiān)控當(dāng)內(nèi)存占用接近上限時(shí)主動(dòng)釋放一些緩存比如 FEX-Emu 的翻譯緩存、DXMT 的著色器緩存避免被系統(tǒng)殺掉。還有一個(gè)技巧是調(diào)整 Wine 的堆大小。Wine 默認(rèn)會(huì)預(yù)留較大的虛擬內(nèi)存空間在 iOS 上這個(gè)預(yù)留可能過(guò)大。通過(guò)設(shè)置WINEDEBUG-all和調(diào)整注冊(cè)表里的堆配置可以減少不必要的內(nèi)存預(yù)留。7. 我在這條路上踩過(guò)的坑第一個(gè)坑是低估了 iOS 的 JIT 限制。一開(kāi)始我以為可以用 FEX-Emu 的默認(rèn) JIT 模式結(jié)果發(fā)現(xiàn) iOS 根本不允許動(dòng)態(tài)生成可執(zhí)行代碼。后來(lái)改用提前翻譯加解釋執(zhí)行的混合模式才勉強(qiáng)跑起來(lái)。這個(gè)限制是 iOS 上跑 Wine 最大的技術(shù)障礙沒(méi)有之一。第二個(gè)坑是字體配置。Wine 默認(rèn)的字體在 iOS 上大部分都不存在導(dǎo)致中文程序全是亂碼。我試過(guò)直接把 Windows 的字體文件復(fù)制進(jìn)去但有些字體有版權(quán)問(wèn)題而且文件很大。后來(lái)改用開(kāi)源字體替代配合注冊(cè)表映射才解決了亂碼問(wèn)題。熱搜詞里的 “wine 亂碼” 和 “wine 欄是亂碼”我猜大概率也是這個(gè)原因。第三個(gè)坑是 DXMT 的紋理格式轉(zhuǎn)換。我跑一個(gè)老游戲的時(shí)候畫(huà)面全是花屏排查了很久才發(fā)現(xiàn)是 BC3 紋理格式轉(zhuǎn)換有問(wèn)題。DXMT 的 BC3 轉(zhuǎn)換代碼有個(gè)邊界條件沒(méi)處理好導(dǎo)致某些尺寸的紋理轉(zhuǎn)換出錯(cuò)。后來(lái)手動(dòng)改了轉(zhuǎn)換代碼問(wèn)題才解決。這個(gè)經(jīng)歷告訴我DXMT 雖然技術(shù)路線對(duì)但成熟度還不夠需要做好踩坑的準(zhǔn)備。第四個(gè)坑是內(nèi)存管理。我一開(kāi)始沒(méi)太在意內(nèi)存占用結(jié)果程序跑著跑著就被系統(tǒng)殺了。后來(lái)加了內(nèi)存監(jiān)控和主動(dòng)釋放機(jī)制才穩(wěn)定下來(lái)。iOS 的內(nèi)存管理比桌面嚴(yán)格得多必須時(shí)刻關(guān)注內(nèi)存使用情況。第五個(gè)坑是音頻延遲。Wine 的音頻輸出在 iOS 上有明顯的延遲玩游戲的時(shí)候音畫(huà)不同步。后來(lái)調(diào)整了 CoreAudio 的緩沖區(qū)大小從默認(rèn)的 256 調(diào)到 1024延遲明顯改善但代價(jià)是音頻的實(shí)時(shí)性下降。這個(gè)權(quán)衡需要根據(jù)具體使用場(chǎng)景來(lái)定。8. 這個(gè)方向后續(xù)還能怎么玩Madeira 這個(gè)項(xiàng)目標(biāo)題背后的技術(shù)棧其實(shí)還有很多可以探索的空間。比如把 Wine 的 Direct3D 12 支持做起來(lái)現(xiàn)在 DXMT 主要支持 D3D 11 和部分 D3D 12 特性完整的 D3D 12 支持還需要大量工作。再比如把 FEX-Emu 的翻譯優(yōu)化做得更智能根據(jù)程序的運(yùn)行特征動(dòng)態(tài)調(diào)整翻譯策略而不是用固定的配置。還有一個(gè)有趣的方向是把 Wine 和 iOS 的原生能力結(jié)合起來(lái)。比如用 iOS 的 MetalFX 做超分辨率用 Game Mode 做性能調(diào)度用 SharePlay 做多人游戲。這些 iOS 特有的能力如果能和 Wine 結(jié)合起來(lái)可能會(huì)帶來(lái)一些桌面平臺(tái)沒(méi)有的體驗(yàn)。從更長(zhǎng)遠(yuǎn)的角度看Apple Silicon 的性能還在快速提升M 系列芯片的 GPU 性能已經(jīng)接近入門(mén)級(jí)獨(dú)顯的水平。如果 Apple 能進(jìn)一步開(kāi)放 iOS 的 JIT 限制或者提供官方的虛擬化方案那在 iOS 上跑 Windows 應(yīng)用的體驗(yàn)會(huì)有質(zhì)的飛躍。當(dāng)然這取決于 Apple 的策略不是技術(shù)社區(qū)能決定的。我個(gè)人在實(shí)際操作中的體會(huì)是這個(gè)方向的技術(shù)挑戰(zhàn)很大但每一步進(jìn)展都很有成就感。如果你也對(duì)在 iOS 上跑 Windows 應(yīng)用感興趣建議從最簡(jiǎn)單的程序開(kāi)始比如記事本、計(jì)算器這種先把整個(gè)流程跑通再逐步挑戰(zhàn)更復(fù)雜的程序。不要一上來(lái)就想著跑 3A 游戲那樣很容易受挫。慢慢來(lái)比較快。