企业官网建设流程全解析

在 iPhone 上跑 Windows 游戏遇到掉帧、被无提示杀掉、热降频？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 动态翻译（把 x86-64 指令实时编译成 ARM 指令）+ Wine 11.4（ARM64EC 原生）+ DXMT/Metal 图形栈。正因为它是"Windows 模拟环境"，性能问题从不按原生 iOS 应用的套路出牌——热节流、Jetsam 内存墙（iOS 按物理内存足迹无警告杀进程的那条红线）、JIT 翻译开销会交织在一起。这篇文章给出一套症状驱动的性能剖析方法：不教你"先第一步后第二步"，而是按你观察到的现象对号入座，用项目内置的 FPS 悬浮层、采样剖析器和诊断日志把模糊的"变卡了"拆成可归因的结论。

先说清一个前提：Madeira 的 JIT 只在调试器附加时生效，所以剖析必须在真机上进行，Xcode 的 iOS 模拟器跑不了（下文所有"模拟器"均指 Madeira 这个 Windows-on-iOS 模拟环境）。

同一个 iPhone，为什么 A 游戏流畅、B 游戏掉帧？

痛点长这样：同一台设备、同一套配置，A 游戏稳定 60 帧，B 游戏进图流畅、十几分钟后开始一顿一顿，或者干脆画面"消失"了——没有崩溃弹窗、日志里没有报错，进程就是没了。瓶颈到底在热节流、内存墙还是翻译开销？Madeira 内置了三件剖析仪器，配合起来就能闭环：

症状地图：你看到的现象对应什么信号

先用这张表对号入座，再进对应的诊断单元深读：

单元 1：游戏无提示消失——Jetsam 内存墙

现象：玩到一半画面直接没了，没有崩溃弹窗，日志里甚至没有一行 ERROR。项目注释里记录过真实案例：某次运行在 4080MB 处被 Jetsam 无声击杀，"日志里没有任何报错"——只有悬浮层能让"它消失了"变成"我们看着它爬上去的"（FPSOverlay.swift）。

取证：三处证据，都已在项目里：

1. 悬浮层内存数字。FPS 悬浮层每 250ms 读一次task_info(TASK_VM_INFO)的phys_footprint——这正是内核裁决 Jetsam 用的同一个计数器，不是近似值（FPSOverlay.swift）。颜色按"距 4096MB 红线的余量"告警：绿色余量 768MB 以上、黄色 384MB、橙色 128MB、红色不足 128MB（FPSOverlay.swift）。
2. 启动基线。日志开头的[device]行记录机型、OS、RAM、available=（jetsam 前可用量）、热状态（EntitlementChecker.swift）；每次游戏启动再来一行[device] launch:（EntitlementChecker.swift）。
3. JIT 池标记行。JIT 代码池理论上通过no-footprint标记不占 Jetsam 额度（JITAllocator.c），日志里的[jit]/[no-footprint]行记录标记成败，并附带 phys_footprint 前后采样（JITAllocator.c）。

判读：

• 悬浮层内存颜色在死前持续向红爬升 → Jetsam 无悬念；
• [no-footprint]行出现ALL ... variants refused — pool stays jetsam-counted→ JIT 池全额计费。注释里记过教训：896MB 池全额计费直接导致 "Terminated due to memory issue"（JITAllocator.c）。标记失败往往是内存意外爬升的元凶；
• 显存侧：vram-trim-mb（默认 1536）表示"距离内存杀线多远处开始裁剪显存"，调大能换帧率——项目实测雪景帧率翻倍，但 footprint 随之回升（ConfigCatalog.generated.swift）。这是典型的性能/内存权衡旋钮。

归因：进程消失 + 悬浮层红色 = Jetsam 内存墙。适用边界：悬浮层的颜色是"本进程视角"，若其它后台大户占满了系统内存，本进程 footprint 不高也可能被杀——此时用[device]行的available=对比历史运行判断整体额度是否缩水。修复后务必重跑同一场景，确认红色不再出现。

单元 2：帧率随时间下滑——热节流归因

现象：冷机开玩帧率正常，十几分钟后同场景逐渐掉帧。iPhone 上真正的帧率上限往往是热量：项目源码里反复出现同一句注释——"thermals are what cap ProMotion at 60"（WineProcessBridge.m）。

取证：在Documents/madeira.cfg里打开热状态心跳：

env.MADEIRA_DEVICE_STATS = 1

Wine 运行期间每 10 秒输出一行[device-load] thermal=... low-power=... capture=...（Library.swift）。热状态分四级：nominal → fair → serious → critical。开关的完整说明见 docs/LIBRARY.md 的 Switches 一节。

判读：

• 掉帧/滑坡的时间点与thermal=升级对齐 → 热节流归因成立；
• low-power=1→ 低电量模式同样封顶 60Hz，先关低电量模式再测；
• 做 A/B：同一场景冷机跑 vs 热机跑，差值就是节流成本。

归因：热量是 iPhone 上真实的帧率上限，但它是"预算"问题而非"缺陷"。抓手是省预算：悬浮层上的ECO开关让 guest 线程降到低 QoS 类跑（SoC 在约 250J CPU 能耗后会把时钟压下来，加载画面在全速下几乎吃光这份预算）——加载时开 ECO、进游戏后关掉，把预算留给主循环（FPSOverlay.swift）。适用边界：热节流只解释"随时间下滑"的掉帧；从头就卡的不属于这个单元，去单元 4。

单元 3：ProMotion 为什么从 120Hz 掉到 60Hz

现象：MAX(n)帧率胶囊里的 n 从 120 变成 60。n 是当前面板上限：120 = ProMotion 正常，60 = 已被热/低电量模式压住（FPSOverlay.swift）。

取证：两处。其一，[device]行里的max-fps=直接给出屏幕当前刷新上限（EntitlementChecker.swift）；其二，[promote]行标记 ProMotion 显示链接的挂起/释放（FPSOverlay.swift）。

判读：

• max-fps=60+ 热状态 fair 以上或low-power=1→ 系统侧封顶，回到单元 2 处理热量；
• max-fps=120但实测只有 60 → 不是面板上限问题，是节奏/吞吐问题，去单元 4；
• [device-load]行里capture=1表示屏幕正在被截屏/录屏，iOS 此时也会降帧——排查时先停掉录屏。

归因：区分"节流"与"上限"是这一单元的核心：MAX(n)的 n 是上限的诚实报告（FPSOverlay.swift），n=60 说明面板本身被压住了，游戏侧再怎么优化也回不到 120。适用边界：非 ProMotion 设备本来就只有 60Hz，此项不适用。

单元 4：热状态 nominal 却帧时长大——CPU 翻译开销定位

现象：热状态一直 nominal，帧率却上不去。此时时间烧在计算里：x86-64 翻译、Wine 系统调用、渲染栈。需要回答"每一帧的 ~1s 到底去哪了"。

取证：开启采样剖析器。默认构建运行在"安静模式"，跳过了重量级诊断——在 WineProcessBridge.m 第 961 行把setenv("MADEIRA_QUIET", "1", 1);注释掉再构建（源码注释原话：采样器每秒 suspend 游戏线程约 500 次，会偷走几个百分点的帧时间和热量，所以只在诊断会话开启）。

判读：wineserver 线程会以 ~500Hz 采样当前最忙游戏线程的 PC（每 2 秒重新选一次最忙线程），按 256 字节分桶，每 4096 次采样（约 10 秒）打印一次直方图，桶会归类到三类：JIT 池（客户代码块 / 调度器 / 模块副本）、app 二进制（Unix 侧）、其它（server_ios.c）。日志中搜三个标签：

• [PROF]：Top-10 热点桶。桶地址落在系统 dylib 范围（如某 wait 系统调用）时，说明是等待而非计算；
• [PROF-LR]：Top-8 调用方，对系统范围样本给出符号名，回答"谁在等"；
• [PROF-BT]：每 1024 样本抓一次 12 帧回溯，用于 pc+lr 无法归因的内核时间（server_ios.c 实际路径为 server_ios.c）。

计数每次打印减半，使直方图始终跟踪当前阶段而不是启动以来的累计值。同时用悬浮层切到RAW模式：游戏完全不限帧、面板按显示速率直出，此时 FPS 读数 = 图形栈的原始吞吐（FPSOverlay.swift）。RAW 下帧率正常而 60 下卡顿 → 问题在节奏控制而非性能；RAW 也上不去 → 吞吐本身不够，按[PROF]桶归因。

归因：桶落 JIT 池 → 翻译/客户代码开销；落 app 二进制 → Unix 侧开销；落系统 wait 调用 → 同步或锁问题。适用边界：采样器自身有成本（帧时间 + 热量），剖析完记得恢复MADEIRA_QUIET。附注：若日志出现[susp] TASK WAS SUSPENDED/STALLED for Ns（server_ios.c），说明整个任务被外部挂起（调试器/剖析器），这不是游戏卡顿，先检查工具链。

拉取日志、做修复前后对比

日志系统把所有 Wine/DXMT/FEX 输出落到Documents/madeira-log.txt，并且滚动保留：重启应用时旧日志移为madeira-log.prev.txt而不是丢弃——因为"这些运行往往昂贵且不可复现"（LogStore.swift）。用 Xcode 的 devicectl 命令分别拉取两个文件（把Documents/madeira-log.txt换成Documents/madeira-log.prev.txt即可取上一轮），然后按标签过滤：

更多开关（如MADEIRA_PROMOTE、MADEIRA_DEVICE_STATS）在 docs/LIBRARY.md 的 Switches 一节有完整清单；应用内的 Log 视图已按签名去重聚合，适合快速扫错，文件才是离线分析的权威数据源。

证据组合拳：把多条证据拼成结论

不是步骤清单，是决策表——按你的现象行选择，用第二列的证据确认：

这套流程的价值在于：它把"游戏在 iPhone 上变卡了"这类模糊现象，精确拆解为热节流、内存墙或翻译/渲染开销中的一类——这正是 Madeira 这类多层模拟环境里，性能剖析与普通 iOS 应用最不同的地方。

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