如何给 Madeira 做性能排查：从热节流到内存墙的完整指南

如何给 Madeira 做性能排查：从热节流到内存墙的完整指南

【免费下载链接】MadeiraRun x86-64 Windows PC games on jailed iOS via FEX-Emu + Wine + DXMT项目地址: https://gitcode.com/GitHub_Trending/mad/Madeira

Madeira 是一个在越狱前的 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-power=1确认。

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_QUIET=1），重量级诊断全部跳过。要做 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]行，它由每次启动的 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