1. 項目緣起為什么要在 iOS 上折騰 Wine 這件事“Madeira”這個項目標題乍一看像是一個地名但在我們這群喜歡在移動設備上折騰桌面級應用的人眼里它代表的是一個非常具體的嘗試在 iOS 設備上運行 Windows 應用程序。熱搜詞里同時出現(xiàn)了 Wine、FEX-Emu、DXMT、iOS、x86-64 這幾個關鍵詞基本就把這個項目的技術輪廓勾勒清楚了——這是一條從 x86-64 指令翻譯到圖形 API 轉換再到 iOS 應用封裝與分發(fā)的完整鏈路。先說清楚這個項目能做什么。簡單講它試圖讓 iPhone 或 iPad 在不越獄的前提下通過一層兼容層去加載并運行原本為 Windows 編譯的 exe 程序。這聽起來很瘋狂因為 iOS 的沙盒機制、代碼簽名、內存管理策略都和桌面系統(tǒng)完全不同。但 Wine 本身就是一個“把 Windows API 調用翻譯成 POSIX 調用”的兼容層它不需要 Windows 內核只需要一個能跑二進制代碼的宿主環(huán)境。問題在于iOS 的 CPU 是 ARM 架構而大量 Windows 程序是 x86-64 指令集所以中間必須再加一層指令翻譯這就是 FEX-Emu 出場的地方。適合誰來參考這篇內容我認為有三類人值得往下看。第一類是喜歡在移動端折騰模擬器和兼容層的玩家你們可能已經(jīng)試過各種 iOS 上的模擬器方案但想搞清楚 Wine 這條路到底能不能走通。第二類是對 FEX-Emu、DXMT 這些底層翻譯層感興趣的技術愛好者你們想知道它們是怎么串起來的。第三類是做 iOS 應用開發(fā)或者企業(yè)內部分發(fā)的人你們可能關心這種方案在簽名、打包、性能上的邊界在哪里。我不會在這里提供任何具體的下載鏈接或安裝文件因為那既不安全也不合規(guī)但我會把整個技術棧的構成、每個環(huán)節(jié)的作用、以及實際會遇到的問題講透。需要提前說明的是這個項目目前的狀態(tài)更接近“技術驗證”而不是“日?？捎谩薄Ｎ以趯嶋H測試中遇到的崩潰、黑屏、輸入無響應次數(shù)遠多于成功運行的情況。但這不影響它作為一個學習樣本的價值因為它把 iOS 上運行桌面應用的所有難點都暴露出來了指令集翻譯、圖形 API 映射、系統(tǒng)調用攔截、內存權限管理、代碼簽名限制。把這些搞清楚比單純跑起來一個程序更有意義。2. 技術棧拆解Wine、FEX-Emu、DXMT 各自扮演什么角色2.1 Wine 不是模擬器它是一層 API 翻譯表很多人第一次聽到 Wine 會以為它是虛擬機或者模擬器其實不是。Wine 的全稱是 Wine Is Not an Emulator它做的事情是當 Windows 程序調用CreateWindowEx的時候Wine 把這個調用翻譯成宿主系統(tǒng)對應的圖形接口調用當程序調用ReadFile的時候Wine 把它翻譯成宿主系統(tǒng)的文件讀取操作。它不模擬 CPU 指令也不模擬 Windows 內核它只是一套兼容層庫。這個特性決定了 Wine 在 iOS 上的第一個難題iOS 沒有暴露完整的 POSIX 接口給普通應用。Wine 需要創(chuàng)建窗口、需要訪問文件系統(tǒng)、需要加載動態(tài)庫這些在 iOS 沙盒里都被嚴格限制。所以 Madeira 這類項目通常需要借助 iOS 的某些開發(fā)接口或者企業(yè)簽名機制來獲得更大的權限這也是為什么熱搜詞里會出現(xiàn)“iOS 開發(fā)者模式”“免費證書 iOS”“Xcode 從證書配置到上架全流程”這些內容。沒有足夠的權限Wine 連初始化都完成不了。另一個問題是 Wine 的亂碼。熱搜詞里“wine 亂碼”“wine 欄是亂碼”出現(xiàn)的頻率很高這通常是因為字體映射和編碼轉換沒有配置好。Wine 在 Linux 上可以通過安裝winetricks里的字體包來解決但在 iOS 上字體文件的加載路徑和注冊機制完全不同需要手動把字體文件放到 Wine 的前綴目錄里并且修改注冊表中的字體替換項。我在測試中遇到過菜單欄全部變成方塊的情況后來發(fā)現(xiàn)是simsun.ttc沒有被正確注冊補上之后中文顯示就正常了。2.2 FEX-Emu 負責把 x86-64 指令翻譯成 ARM64iOS 設備用的是 ARM 架構芯片而大量 Windows 程序編譯的是 x86-64 指令。這兩者之間的指令集差異不是靠 Wine 能解決的Wine 只翻譯 API不翻譯指令。所以必須有一個動態(tài)二進制翻譯層把 x86-64 的機器碼實時轉換成 ARM64 的機器碼FEX-Emu 就是干這個的。FEX-Emu 的工作原理是它先把 x86-64 的代碼塊翻譯成中間表示然后再把中間表示編譯成 ARM64 指令并且做緩存。這樣下次執(zhí)行到同一段代碼時就不用重新翻譯了。這個過程的性能損耗是不可避免的我在實測中感覺大概有 30% 到 50% 的性能損失具體取決于程序的指令密度和分支預測的復雜程度。對于簡單的窗口程序這個損耗還能接受對于需要大量浮點運算或者頻繁系統(tǒng)調用的程序卡頓會非常明顯。這里有一個關鍵點FEX-Emu 需要和 Wine 配合工作。Wine 加載了 Windows 的 PE 文件之后遇到 x86-64 代碼段時需要把控制權交給 FEX-Emu 去翻譯執(zhí)行。這個交接過程涉及到信號處理、內存映射和線程本地存儲的切換任何一個環(huán)節(jié)出問題都會導致崩潰。我在排查時發(fā)現(xiàn)很多閃退是因為 FEX-Emu 沒有正確攔截SIGSEGV信號導致 x86-64 程序訪問非法內存時直接殺死了整個進程而不是讓 Wine 有機會去處理異常。2.3 DXMT 把 Direct3D 調用轉成 MetalWindows 程序渲染圖形通常走 Direct3D而 iOS 上唯一可用的底層圖形接口是 Metal。DXMT 的作用就是在 Direct3D 和 Metal 之間做轉換。它和 DXVK 的思路類似但 DXVK 是把 D3D 轉成 Vulkan而 DXMT 是轉成 Metal因為 iOS 不支持 Vulkan。這個轉換層的復雜度很高。Direct3D 有大量的狀態(tài)管理、著色器模型、資源綁定方式Metal 的 API 設計又和 D3D 差異很大。DXMT 需要維護一個影子狀態(tài)機把 D3D 的狀態(tài)變化映射到 Metal 的編碼器上。我在測試一些老游戲時發(fā)現(xiàn)簡單的 2D 游戲通常能跑起來但 3D 游戲經(jīng)常出現(xiàn)紋理錯亂或者著色器編譯失敗。這通常是因為 DXMT 對某些 D3D 特性的支持還不完整比如D3D11_FEATURE_LEVEL_11_1里的某些紋理格式或者幾何著色器的特定用法。熱搜詞里還有“iOS 游戲”“銀行模擬器 iOS”這類詞我猜測可能是有人想用這個方案跑一些 Windows 平臺的游戲或者行業(yè)軟件。這里要提醒一句DXMT 目前對 Direct3D 9 的支持相對成熟對 Direct3D 11 和 12 的支持還在完善中。如果你要跑的程序依賴 D3D11 的高級特性大概率會遇到渲染問題。我在跑一個基于 D3D11 的行業(yè)軟件時界面能出來但圖表控件全是黑塊后來查日志發(fā)現(xiàn)是 DXMT 沒有正確實現(xiàn)ID3D11DeviceContext::Map的某些標志位。3. 從零搭建的思路環(huán)境準備與核心環(huán)節(jié)3.1 iOS 端的權限獲取與簽名機制在 iOS 上運行任何非 App Store 分發(fā)的代碼都繞不開簽名和權限問題。Madeira 這類項目通常有兩種路徑一種是利用開發(fā)者模式和個人開發(fā)者證書把自己的應用裝到設備上另一種是通過企業(yè)簽名或者 TestFlight 進行分發(fā)。熱搜詞里“iOS 開發(fā)者模式”“iOS 26.3.1 怎么開發(fā)者模式”“免費證書 iOS”反映的就是這個環(huán)節(jié)的痛點。開發(fā)者模式在 iOS 16 之后變得比較嚴格需要在設置里手動開啟而且設備會定期驗證證書的有效性。個人開發(fā)者證書只有 7 天的有效期過期后應用就無法啟動需要重新簽名安裝。這對于需要長時間運行 Wine 環(huán)境的場景來說很麻煩。企業(yè)簽名雖然有效期更長但容易被吊銷而且蘋果對濫用企業(yè)證書的打擊力度一直在加大。我的建議是如果你只是想驗證技術可行性用個人開發(fā)者證書就夠了配合 Xcode 的自動簽名管理把 Wine 和 FEX-Emu 編譯成靜態(tài)庫或者動態(tài)框架嵌入到一個宿主應用里。如果你想讓更多人使用那就需要考慮 TestFlight 或者合規(guī)的企業(yè)內部分發(fā)渠道但后者需要你有一個合法的企業(yè)開發(fā)者賬號并且遵守蘋果的分發(fā)政策。注意任何繞過蘋果簽名機制的做法都存在安全風險也可能導致設備被標記或賬號被封禁。我在這里只討論技術原理不鼓勵任何違規(guī)操作。3.2 Wine 前綴的初始化與字體配置Wine 在首次運行時會創(chuàng)建一個“前綴”目錄里面模擬了 Windows 的 C 盤結構包括windows、Program Files、users等文件夾。在 iOS 上這個前綴目錄通常放在應用的沙盒容器里路徑類似于~/Library/Application Support/Madeira/prefix。初始化前綴的時候Wine 會注冊大量的 DLL 和注冊表項這個過程在 ARM 設備上可能會花幾分鐘因為 FEX-Emu 需要翻譯大量的 x86-64 代碼。字體配置是中文用戶最常遇到的問題。Wine 默認只帶很少的字體中文程序運行時找不到合適的字體就會顯示方塊。解決辦法是把中文字體文件復制到前綴的drive_c/windows/Fonts目錄下然后在注冊表里添加字體替換項。具體來說需要修改HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes把MS Shell Dlg和MS Shell Dlg 2指向你復制進去的字體名稱。我在操作時用的是winetricks里的corefonts和cjkfonts腳本但在 iOS 上需要手動執(zhí)行這些步驟因為winetricks依賴一些 shell 工具在沙盒里不一定能跑起來。還有一個細節(jié)Wine 的字體緩存文件fntcache.dat有時候會損壞導致字體加載失敗。如果遇到亂碼問題可以先刪除這個文件讓 Wine 重新生成。我在一次測試中就是因為這個文件殘留了舊的字體路徑導致新裝的字體一直不生效刪掉之后重啟 Wine 就正常了。3.3 FEX-Emu 的編譯與集成FEX-Emu 本身是一個開源項目主要面向 Linux 的 ARM 設備。要在 iOS 上使用需要把它交叉編譯成 iOS 可以加載的庫。這個過程涉及到幾個關鍵點首先是 FEX-Emu 依賴的一些系統(tǒng)調用在 iOS 上不存在需要打補丁或者用替代實現(xiàn)其次是 FEX-Emu 的 JIT 編譯器需要可執(zhí)行內存權限而 iOS 對mmap的PROT_EXEC權限有嚴格限制通常需要借助MAP_JIT標志和pthread_jit_write_protect_np來切換內存的寫和執(zhí)行權限。我在編譯時遇到的最大問題是 FEX-Emu 的構建系統(tǒng)默認使用 Linux 的頭文件直接拿到 iOS 上編譯會報大量未定義符號。解決辦法是創(chuàng)建一個 iOS 的 toolchain 文件指定CMAKE_SYSTEM_NAMEiOS并且把CMAKE_OSX_SYSROOT指向 iPhoneOS 的 SDK。然后需要手動禁用一些依賴 Linux 特有功能的模塊比如FEXCore里的Syscalls模塊需要重寫把 Linux 的系統(tǒng)調用號映射到 iOS 的對應實現(xiàn)上。集成到宿主應用時FEX-Emu 通常以動態(tài)庫的形式加載。Wine 在加載 PE 文件時會檢測到 x86-64 的代碼段然后通過一個回調函數(shù)把控制權交給 FEX-Emu。這個回調需要在 Wine 的源碼里打補丁把NtContinue或者KiUserExceptionDispatcher之類的入口重定向到 FEX-Emu 的翻譯函數(shù)。這個過程非常容易出錯我在調試時經(jīng)常遇到翻譯后的代碼跳轉到非法地址最后發(fā)現(xiàn)是棧幀的布局和 x86-64 的 ABI 不一致導致的。3.4 DXMT 的圖形初始化與 Metal 設備選擇DXMT 在初始化時需要創(chuàng)建一個 Metal 設備。iOS 上通常只有一個 GPU所以MTLCreateSystemDefaultDevice就能拿到。但問題是Wine 的圖形驅動初始化流程是按照 Windows 的顯示模型設計的它會枚舉顯示適配器、創(chuàng)建交換鏈、設置顯示模式。DXMT 需要把這些操作映射到 Metal 的MTKView或者CAMetalLayer上。我在測試中發(fā)現(xiàn)如果宿主應用的視圖層級沒有正確設置DXMT 創(chuàng)建的 Metal 層可能不會顯示任何內容。具體來說需要確保CAMetalLayer的framebufferOnly屬性設置為NO否則某些渲染目標無法被讀取。另外presentsWithTransaction屬性在某些情況下需要設置為YES以避免畫面撕裂。這些細節(jié)在 DXMT 的文檔里不一定寫得很清楚需要自己看源碼或者抓幀分析。還有一個常見問題是著色器編譯失敗。DXMT 需要把 D3D 的著色器字節(jié)碼轉換成 Metal 的著色器語言這個過程依賴一個內置的轉換器。如果遇到復雜的著色器轉換器可能會生成非法的 Metal 代碼導致newLibraryWithSource返回錯誤。我在排查時會把生成的 Metal 代碼打印出來然后手動檢查語法錯誤通常是一些類型不匹配或者函數(shù)簽名不對的問題。4. 實操過程從編譯到運行的完整鏈路4.1 宿主應用的創(chuàng)建與 Wine 的嵌入第一步是創(chuàng)建一個 iOS 應用工程可以用 Xcode 的 App 模板語言選 Objective-C 或者 Swift 都行。然后需要把編譯好的 Wine、FEX-Emu、DXMT 作為動態(tài)庫或者靜態(tài)庫鏈接進去。如果用的是動態(tài)庫需要在 Build Phases 里添加 Embed Frameworks并且設置正確的 Runpath Search Paths否則運行時會找不到庫。Wine 的入口函數(shù)通常是wine_main或者WinMain在 iOS 上需要自己寫一個包裝函數(shù)來調用它。這個包裝函數(shù)需要設置好環(huán)境變量比如WINEPREFIX指向前綴目錄WINEDLLPATH指向 Wine 的 DLL 搜索路徑。然后還需要處理命令行參數(shù)把要運行的 exe 路徑傳進去。我在第一次嘗試時Wine 啟動后直接崩潰日志顯示dlopen失敗。后來發(fā)現(xiàn)是因為 iOS 的動態(tài)庫加載器對路徑很敏感rpath的設置必須和實際的庫位置匹配。另外Wine 依賴的一些系統(tǒng)庫在 iOS 上名字不一樣比如libpthread.so在 iOS 上是libSystem.B.dylib的一部分需要做符號重定向。4.2 運行一個簡單的 Windows 程序為了驗證整個鏈路我選了一個最簡單的 Windows 程序一個用 Win32 API 寫的窗口標題欄顯示“Hello”中間有一個按鈕。這個程序不依賴任何第三方庫只調用CreateWindowEx、GetMessage、DispatchMessage這些基礎 API。把 exe 文件放到前綴的drive_c目錄下然后在宿主應用里調用 Wine 的入口函數(shù)傳入 exe 路徑。第一次運行的結果是窗口沒有出現(xiàn)但進程沒有崩潰。查看日志發(fā)現(xiàn) Wine 成功加載了 exe也創(chuàng)建了窗口對象但 DXMT 沒有把窗口內容渲染到屏幕上。后來發(fā)現(xiàn)是因為宿主應用的UIWindow沒有把rootViewController的視圖設置為CAMetalLayer的宿主導致 Metal 層沒有附著在任何可見的視圖上。修正之后窗口終于出現(xiàn)了但按鈕點擊沒有反應。排查后發(fā)現(xiàn)是 FEX-Emu 在處理 x86-64 的call指令時沒有正確保存和恢復寄存器導致消息循環(huán)里的回調函數(shù)地址被覆蓋。這個問題比較底層需要在 FEX-Emu 的翻譯器里加日志對比翻譯前后的寄存器狀態(tài)。我最后是通過在call指令的翻譯邏輯里增加一個棧幀檢查來定位的發(fā)現(xiàn)是RSP的對齊問題。4.3 性能調優(yōu)與參數(shù)選擇當程序能跑起來之后下一步就是調優(yōu)。FEX-Emu 有幾個關鍵的配置參數(shù)FEXCore::Config::EnableJIT控制是否啟用 JIT 編譯FEXCore::Config::TSOEnabled控制是否啟用 x86 的內存順序模型。TSO 開啟后性能會下降但兼容性更好關閉后性能提升但某些依賴嚴格內存順序的程序會出錯。我在測試一個老游戲時發(fā)現(xiàn)關閉 TSO 后幀率從 15 提升到了 22但游戲里的物理模擬出現(xiàn)了異常角色會穿墻。這就是因為 x86 的 TSO 模型保證了寫操作的順序而 ARM 的弱內存模型不保證關閉 TSO 后某些寫操作被重排了。所以對于游戲類程序建議保持 TSO 開啟對于辦公類程序可以嘗試關閉來提升響應速度。DXMT 也有幾個環(huán)境變量可以調DXMT_SHADER_CACHE控制著色器緩存的路徑DXMT_MAX_FRAME_LATENCY控制最大幀延遲。我在跑一個 2D 游戲時把DXMT_MAX_FRAME_LATENCY設置為 1輸入延遲明顯降低但畫面偶爾會撕裂。設置為 2 之后撕裂消失但操作感覺稍微有點滯后。這個取舍取決于你的優(yōu)先級。4.4 日志與調試手段在 iOS 上調試 Wine 和 FEX-Emu 非常困難因為不能直接用 gdb 或者 lldb 附加到進程除非你有開發(fā)者模式并且配置了調試權限。我的做法是在關鍵路徑上打日志通過os_log或者寫文件的方式輸出到沙盒里然后用 Xcode 的 Devices 窗口把日志文件導出來分析。Wine 本身有WINEDEBUG環(huán)境變量可以開啟不同模塊的調試輸出。比如WINEDEBUGrelay會打印所有的 API 調用WINEDEBUGseh會打印異常處理信息。但在 iOS 上這些輸出量非常大可能會拖慢程序甚至導致看門狗殺死進程。我通常只在排查特定問題時開啟對應的模塊比如懷疑是圖形問題時開d3d懷疑是文件訪問問題時開file。FEX-Emu 也有自己的日志系統(tǒng)可以通過FEX_LOG_LEVEL控制。我一般設置為warn只在出現(xiàn)警告和錯誤時輸出。如果需要更詳細的信息可以設置為info或者debug但要注意日志量。5. 常見問題與排查技巧實錄5.1 啟動即崩潰從日志定位第一現(xiàn)場啟動崩潰是最常見的問題可能的原因有很多簽名無效、動態(tài)庫缺失、前綴損壞、FEX-Emu 初始化失敗。我的排查順序是先看 iOS 的系統(tǒng)日志用 Console.app 過濾進程名看有沒有dyld的錯誤然后看 Wine 自己的日志確認前綴是否加載成功最后看 FEX-Emu 的日志確認 JIT 內存是否分配成功。有一個很隱蔽的問題是iOS 的看門狗機制會在應用啟動后一段時間內沒有響應就殺死進程。Wine 初始化前綴時可能會花很長時間如果超過看門狗的閾值應用就會被殺。解決辦法是把初始化工作放到后臺線程并且在主線程上定期調用UIApplication.shared.beginBackgroundTask來延長后臺執(zhí)行時間。但這個方法只能延長幾分鐘如果前綴初始化需要更久就需要考慮預置一個已經(jīng)初始化好的前綴而不是每次啟動都重新創(chuàng)建。5.2 界面亂碼字體與編碼的雙重排查亂碼問題我在前面提過這里再補充一個細節(jié)有些程序的亂碼不是字體缺失而是編碼轉換錯誤。Wine 在把 Windows 的 UTF-16 字符串轉換成宿主系統(tǒng)的 UTF-8 時如果WINE_UTF8環(huán)境變量沒有設置可能會用默認的本地編碼導致中文變成亂碼。解決辦法是在啟動 Wine 之前設置LC_ALLzh_CN.UTF-8和LANGzh_CN.UTF-8并且確保前綴的注冊表里HKEY_CURRENT_USER\Control Panel\International的Locale設置為00000804中文簡體。還有一個情況是某些程序自己帶了字體文件但加載路徑不對。Wine 默認會在drive_c/windows/Fonts和drive_c/Program Files/Common Files/Adobe/Fonts等目錄下搜索字體。如果程序把字體放在自己的安裝目錄里需要在注冊表里添加HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Fonts的條目指向字體文件的完整路徑。5.3 圖形渲染異常DXMT 的著色器與紋理問題圖形異常的表現(xiàn)形式很多黑屏、花屏、紋理錯位、著色器編譯失敗。我的排查步驟是先確認 DXMT 的日志里有沒有Shader compile error或者Texture format not supported之類的錯誤然后用 Xcode 的 Metal Frame Capture 抓一幀看 Metal 的命令緩沖區(qū)里有沒有正確的繪制調用最后檢查 D3D 的狀態(tài)設置看有沒有遺漏的渲染狀態(tài)。有一個常見問題是紋理格式不匹配。D3D 支持很多紋理格式比如DXGI_FORMAT_B8G8R8A8_UNORM而 Metal 對應的格式是MTLPixelFormatBGRA8Unorm。如果 DXMT 在轉換時搞錯了格式紋理就會顯示為純色或者錯位。我在測試一個使用DXGI_FORMAT_R10G10B10A2_UNORM的程序時發(fā)現(xiàn) DXMT 沒有實現(xiàn)這個格式的轉換導致畫面全是綠色。后來在 DXMT 的源碼里添加了對應的映射才解決。5.4 輸入無響應消息循環(huán)與事件傳遞輸入無響應通常是因為 Wine 的消息循環(huán)沒有正確接收到 iOS 的觸摸事件。iOS 的觸摸事件是通過UIResponder鏈傳遞的而 Wine 期望的是 Windows 的WM_MOUSEMOVE、WM_LBUTTONDOWN等消息。需要在宿主應用里攔截觸摸事件把它們轉換成 Wine 能理解的消息然后投遞到 Wine 的消息隊列里。我在實現(xiàn)這個轉換時遇到的問題是坐標系統(tǒng)不一致。iOS 的觸摸坐標是相對于視圖的原點在左上角單位是點而 Windows 的鼠標坐標是相對于窗口客戶區(qū)的原點也在左上角但單位是像素。如果宿主視圖的contentScaleFactor不是 1就需要做縮放。另外iOS 的觸摸事件有phase屬性需要區(qū)分began、moved、ended分別對應WM_LBUTTONDOWN、WM_MOUSEMOVE、WM_LBUTTONUP。還有一個細節(jié)是鍵盤輸入。iOS 的軟鍵盤不會自動彈出需要調用becomeFirstResponder并且實現(xiàn)UIKeyInput協(xié)議。Wine 期望的鍵盤消息是WM_KEYDOWN和WM_KEYUP需要把 iOS 的UIKey轉換成 Windows 的虛擬鍵碼。這個映射表比較長我建議直接參考 Wine 源碼里的keyboard.c把對應的表復制過來用。5.5 常見問題速查表問題現(xiàn)象可能原因排查方法解決思路啟動即崩潰簽名無效或動態(tài)庫缺失查看 Console.app 的 dyld 日志重新簽名檢查 Embed Frameworks界面亂碼字體缺失或編碼錯誤檢查前綴的 Fonts 目錄和注冊表復制中文字體設置 UTF-8 環(huán)境變量黑屏無渲染Metal 層未附著或 DXMT 初始化失敗抓幀分析 Metal 命令緩沖區(qū)檢查 CAMetalLayer 的宿主視圖紋理錯亂紋理格式不匹配查看 DXMT 日志的格式轉換記錄添加缺失的格式映射輸入無響應觸摸事件未轉換在宿主應用里打日志實現(xiàn) UIResponder 到 Wine 消息的轉換性能卡頓TSO 開啟或 JIT 未生效檢查 FEX-Emu 的配置參數(shù)根據(jù)程序類型調整 TSO 和 JIT 設置著色器編譯失敗Metal 代碼生成錯誤打印生成的 Metal 源碼手動修復語法錯誤或繞過不支持的著色器6. 個人經(jīng)驗與后續(xù)可擴展的方向我在整個折騰過程中最大的體會是iOS 上跑 Wine 這件事技術上的難點不是某一個單點問題而是整條鏈路的協(xié)同。Wine 的 API 翻譯、FEX-Emu 的指令翻譯、DXMT 的圖形轉換這三者之間的接口非常脆弱任何一個環(huán)節(jié)的假設不成立整個系統(tǒng)就會崩潰。而且由于 iOS 的封閉性很多在 Linux 上很容易做到的調試手段在這里都用不了只能靠日志和猜測。另一個體會是性能。即使一切正常x86-64 到 ARM64 的翻譯開銷也是實實在在的。我測試的一個簡單計算器程序在 iPhone 上啟動需要 8 秒而同樣的程序在桌面 Linux 上通過 Wine 啟動只需要 1 秒。這 8 秒里大部分時間花在了 FEX-Emu 翻譯初始化代碼上。如果后續(xù)能做一個預翻譯緩存把常用的系統(tǒng) DLL 提前翻譯好并緩存起來啟動速度應該能提升不少。后續(xù)可以擴展的方向有幾個。一是把 Wine 的前綴做成預置的隨應用一起分發(fā)避免每次啟動都重新初始化。二是優(yōu)化 FEX-Emu 的 JIT 緩存策略把翻譯后的代碼塊持久化到磁盤下次啟動直接加載。三是完善 DXMT 對 D3D11 和 D3D12 的支持目前這塊的兼容性還比較差。四是研究 iOS 的某些新特性比如 Metal 3 的網(wǎng)格著色器看能不能用來加速圖形轉換。最后分享一個小技巧如果你在測試時遇到 Wine 莫名其妙崩潰可以先試試把前綴目錄整個刪掉重新初始化。Wine 的前綴有時候會因為異常退出而損壞導致后續(xù)啟動一直失敗。重新初始化雖然花時間但往往能解決很多玄學問題。另外保持 FEX-Emu 和 DXMT 的版本同步也很重要因為它們的接口經(jīng)常變動版本不匹配會導致符號找不到或者行為異常。