工作原理

WebAP 高效的秘诀在于其模块化和数学方法。该插件不会尝试“猜测”延迟的原因或盲目降低屏幕分辨率。

整个系统作为一个由三个主要层组成的精细调整的管道运行：跟踪器 (Tracker)、索引器 (Indexer) 和 缩放器 (Scalers)。

决策管道

插件架构严格分离了数据收集、决策和执行。

1. 跟踪器 (Observer)

每帧，跟踪器 (Tracker) 收集有关帧时间和纯 CPU 时间的原始数据。它计算指数移动平均线 (Exponential Moving Average) 以平滑由垃圾回收器 (GC) 或资产加载引起的随机峰值。
跟踪器不做出决定；它只回答两个问题：

• "我们是否跟上了 Target Min FPS？"
• "当前是哪个特定的子系统出现延迟（瓶颈）？"

2. 索引器 (Brain)

索引器 (Indexer) 接收来自跟踪器的数据并决定如何继续。它是系统的仲裁者。
如果 FPS 下降，索引器将：

1. 检查系统是否处于 冷却 (Cooldown) 状态。
2. 评估 Anti Yo-Yo 惩罚系统（有关详细信息，请参阅 Anti Yo-Yo 惩罚）。
3. 计算所有可用缩放器 (Scalers) 的成本。
4. 向能以最小视觉损伤产生最大性能的缩放器发出命令。

3. 缩放器 (Executors)

缩放器 (Scalers) 从索引器接收命令并执行繁重的工作。它们与 Unity API 交互并应用所需的设置（降低分辨率、剔除图层、禁用抗锯齿）。

瓶颈：无需温度计即可寻找约束

WebAP 如何在无法访问设备传感器的情况下准确了解是什么无法处理负载？我们分析引擎本身的计时比例。

• CPU 瓶颈： 跟踪器将纯处理器主线程时间除以总帧时间。如果该比率超过 85%，结论很明显。帧受逻辑或物理计算约束。降低屏幕分辨率或禁用阴影毫无用处。
• GPU 瓶颈： 如果整体 FPS 低于正常水平，但 CPU 份额不到 85%，则表明处理器处于空闲状态。显卡未能及时渲染帧（填充率瓶颈、复杂的着色器或过度绘制）。
• 目标帧速率： 如果平均 VSync 等待时间大于零，则表示处理器和显卡完成渲染的速度快于显示器的刷新率。系统运行有性能余量 (Performance Headroom)，索引器可以平滑地提高图形质量。

Zero-GC：性能第一

旨在将游戏从延迟中拯救出来的插件没有理由自身产生延迟。WebAP 核心的设计在热路径 (Hot Path) 上严格考虑了内存经济性 (Zero-GC)。

• O(1) 环形缓冲区： 跟踪器不使用 List<float> 和 Update 中的繁重循环，而是使用固定大小的数组（环形缓冲区）。平均 FPS 计算在固定时间内执行。
• Update 中零分配： 核心不包含 new 调用、装箱或 lambda。垃圾回收器 (GC) 根本不需要清理任何东西。
• 委托缓存： 即使对于复杂的任务（拦截 WebScaledPhysics2DRaycaster 中的点击），我们放弃了缓慢的反射 (MethodInfo.Invoke)，转而支持快速编译的委托。

隐形

归功于这些优化，整个 WebAP 管道的开销微乎其微。您的处理器甚至不会注意到它正在被监控。