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