如何给 Madeira 做性能排查从热节流到内存墙的完整指南【免费下载链接】MadeiraRun x86-64 Windows PC games on jailed iOS via FEX-Emu Wine DXMT项目地址: https://gitcode.com/GitHub_Trending/mad/MadeiraMadeira 是一个在越狱前的 iOS 26 上直接运行 x86-64 Windows PC 游戏的项目FEX-Emu 动态翻译 Wine 11.4 DXMT/Metal 图形栈。正因为它是Windows 模拟环境套在 iOS 上性能排查没法照搬原生应用的直觉——热节流、Jetsam 内存墙、JIT 翻译开销三者会互相纠缠。这份性能排查指南带你用项目自带的诊断工具走完定位 → 归因 → 验证的闭环。先给一个 30 秒总览。四个高频症状各有一条最短排查路径进程没声没息消失——看 FPS 悬浮层上的物理内存足迹离 4096MB 的 Jetsam 上限还剩多少帧率滑坡——对齐 10 秒一次的热状态心跳确认是热节流还是别的CPU 时间烧在哪——关一次静默模式让采样剖析器输出 [PROF] 热点直方图改完怎么验证——拉取当前和上一轮两份日志做 A/B。全文就围绕这四个问题展开。 有一个前提要先说清Madeira 的 JIT 只在调试器附加时生效所以剖析必须在真机上跑Xcode 模拟器里看不到任何东西。下文所有模拟器都指 Madeira 这个 Windows-on-iOS 模拟环境。进程为什么会被没声没息地杀掉4096MB 内存墙与足迹读数Jetsam 内存墙是 iOS 给单个进程划定的内存上限Madeira 面对的是恰好 4096MB 的那条线。iOS 按 phys_footprint物理内存足迹task_info(TASK_VM_INFO)上报的正是内核裁决用的那个计数器精确到 MB 执行这条线——踩线即杀且不会给你任何报错。所以第一现场是游戏画面上的 FPS 悬浮层它每 250ms 刷新一次直接展示 phys_footprint 和 Present 帧计数实现见 FPSOverlay.swift。盯那个数字的颜色绿色表示离上限还有 768MB 以上余量黄色 384MB 以上橙色 128MB 以上红色则说明余量不足 128MB随时可能被杀掉。项目里真实发生过在 4080MB 处被无声击杀的运行——日志干净得像什么都没发生只有悬浮层的爬升曲线能还原它是怎么没的。谁在悄悄吃额度JIT 池与显存裁剪两条最容易漏掉的归因路径。第一条是 JIT 代码池的不计费技巧代码池通过 no-footprint 标记不占用 Jetsam 额度见 JITAllocator.c。标记失败时池子会全额计费这往往是足迹意外爬升的元凶——去日志里翻[jit]和[no-footprint]行看标记成功还是失败。第二条是显存裁剪旋钮vram-trim-mb默认 1536含义是离内存杀线多远处开始裁剪显存调大能换来帧率项目实测某雪景帧率直接翻倍代价是 footprint 回升。这是典型的性能/内存权衡动它之前先记住这个代价。帧率为什么会滑坡区分节流和上限先看悬浮层上的帧率策略胶囊它有 60 / MAX / RAW / 30 几档。MAX(n) 里的 n 是当前面板刷新上限120 说明 ProMotion 链路正常60 说明已经被热状态或低电量模式压住。源码里反复出现同一句注释thermals are what cap ProMotion at 60——在 iPhone 上热量就是帧率的天花板。低电量模式同样封顶 60Hz可以用[device-load]行里的low-power1确认。10 秒热心跳怎么读热状态分四级nominal → fair → serious → critical。开启 10 秒心跳后每次心跳都会把当时的热状态打进日志# Documents/madeira.cfg env.MADEIRA_DEVICE_STATS 1之后 Wine 运行期间每 10 秒会输出一行[device-load] thermal... low-power... capture...见 Library.swift。读法很简单在帧率曲线上标出滑坡的时间点再回日志对齐那一行的thermal字段——如果看到状态升到 serious 且帧率同步下滑即可确认是热节流不用再看别的方向。另外SoC 在大额 CPU 能耗约 250J 量级之后会压时钟加载画面时开 ECO 省电模式等于把电量预算省给游戏主循环。冷机对热机做一轮 A/B同一场景冷机跑一轮、热机跑一轮全程切到 RAW 模式。RAW 会解除节奏控制测出图形栈的原始吞吐上限两轮帧率的差值就是节流成本。反过来也成立如果 RAW 下帧率正常、切回 60 模式才卡那问题在节奏控制而不是性能方向完全不同。悬浮层上还有一个 CAP 按钮可以顺手用上抓取下一帧的全部渲染通道附件到Documents/capture/排查渲染状态时用。CPU 时间到底烧在哪采样剖析器的开关默认情况下 Madeira 跑在安静模式MADEIRA_QUIET1重量级诊断全部跳过。要做 CPU 热点定位需要临时关掉它——在 WineProcessBridge.m 中// setenv(MADEIRA_QUIET, 1, 1); ← 注释掉这一行再构建为什么平时不开因为采样器会偷走几个百分点的帧时间还会带来额外热量——只在诊断会话使用这是项目注释里写明的取舍。[PROF] 直方图怎么读安静模式关闭后wineserver 线程会以约 500Hz 的速率采样当前最忙游戏线程的 PC按 256 字节分桶每 4096 次采样约 10 秒打印一次直方图。日志里搜[PROF]即可。每个热点桶会归类到三个区域之一JIT 池翻译后的客户代码/调度器、app 二进制Unix 侧、其它。计数在每次打印后减半所以直方图始终跟踪的是当前这一阶段在干什么而不是历史均值。读法上热点落在 JIT 池说明每帧时间被翻译后的游戏代码吃掉优化或回退配置从这里下手落在 Unix 侧说明瓶颈在宿主侧的 app 二进制方向完全不同。改完怎么验证拉两份日志做 A/B日志系统把所有 Wine/DXMT/FEX 输出落到Documents/madeira-log.txt并且滚动保留重启应用时旧日志会移成madeira-log.prev.txt而不是丢弃——因为这些运行往往昂贵且不可复现。修复前后各留一轮用 Xcode 的 devicectl 把两份文件都拉下来# 当前轮 devicectl device copy from --device UDID --source Documents/madeira-log.txt # 上一轮把 source 换成 Documents/madeira-log.prev.txt按标签过滤看三组对照在拉下来的文本里按标签过滤标签内容[device]启动基线机型、OS、RAM、thermal、low-power、刷新上限[device-load]每 10 秒的热状态心跳[PROF]采样剖析器热点直方图[jit]JIT 池与 no-footprint 标记成败拿到一份新日志先翻开头的[device]行它由每次启动的 DeviceDiagnostics 写入见 EntitlementChecker.swift告诉你这份日志出自什么设备、什么状态。对照两组帧率曲线是否回升、thermal序列是否停在更低档位、[PROF]热点是否从 JIT 池回落。三项都改善才算修掉了问题而不只是掩盖了症状。更多日志开关MADEIRA_QUIET、MADEIRA_DEVICE_STATS等的完整清单在 docs/LIBRARY.md 的 Switches 一节。 排到这儿把MADEIRA_QUIET恢复原样、关掉诊断开关让游戏回到安静状态——下次症状再来你手里已经有全套读数了。【免费下载链接】MadeiraRun x86-64 Windows PC games on jailed iOS via FEX-Emu Wine DXMT项目地址: https://gitcode.com/GitHub_Trending/mad/Madeira创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考