Skip to content

仕組み (How It Works)

WebAPの有効性の秘密は、そのモジュール性と数学的アプローチにあります。プラグインは遅延の原因を「推測」しようとしたり、盲目的に画面解像度を下げようとしたりしません。

システム全体は、トラッカー (Tracker)インデクサー (Indexer)、**スケーラー (Scalers)**という3つの主要なレイヤーで構成される、微調整されたパイプラインとして機能します。

決定パイプライン (Decision Pipeline)

プラグインのアーキテクチャは、データの収集、意思決定、そして実行を厳格に分離しています。

1. トラッカー (オブザーバー)

各フレームで、トラッカーはフレーム時間と純粋なCPU時間に関する生データを収集します。指数移動平均(Exponential Moving Average)を計算して、ガベージコレクタ(GC)やアセットの読み込みによって引き起こされるランダムなスパイクを平滑化します。
トラッカーは決定を下しません。2つの質問に答えるだけです:

  • "Target Min FPSに従っているか?"
  • "現在遅延している特定のサブシステム(ボトルネック)は何か?"

2. インデクサー (頭脳)

インデクサーはトラッカーからデータを受け取り、どのように進めるかを決定します。これはシステムの仲裁者です。
FPSが低下すると、インデクサーは以下を実行します:

  1. システムが Cooldown 状態にあるかどうかを確認します。
  2. アンチヨーヨー・ペナルティシステムを評価します(詳細はアンチヨーヨーペナルティを参照)。
  3. 利用可能なすべてのスケーラーのコストを計算します。
  4. 視覚的な損傷を最小限に抑えながら、最大のパフォーマンスをもたらすスケーラーにコマンドを発行します。

3. スケーラー (実行者)

スケーラーはインデクサーからコマンドを受け取り、重い作業を実行します。UnityのAPIとやり取りし、必要な設定(解像度の低下、レイヤーの非表示、アンチエイリアスの無効化)を適用します。

ボトルネック (Bottlenecks): 温度計なしで限界を見つける

WebAPは、デバイスのセンサーにアクセスすることなく、負荷の処理中に何が失敗しているかをどのようにして正確に特定するのでしょうか?それはエンジン自体の中のタイミングの比率(Timing Ratios)を分析することによって行われます。

  • CPUボトルネック: トラッカーは、メインプロセッサスレッドでの純粋な時間を総フレーム時間で割ります。この比率が 85% を超えると、結論は明白です:フレームはロジックまたは物理演算によって制限されています。画面の解像度を下げたりシャドウをオフにしたりしても無意味です。
  • GPUボトルネック: 全体的なFPSが正常よりも低いにもかかわらず、CPU比率が85%未満の場合、それはプロセッサがアイドル状態であることを示しています。ビデオカードが時間内にフレームをレンダリングできていません(フィルレートのボトルネック、重いシェーダー、またはオーバードロー)。
  • ターゲットフレームレート (Target Frame Rate): 平均VSync待機時間がゼロより大きい場合、プロセッサとビデオカードの両方がモニターのリフレッシュレートよりも速くレンダリングを終了していることを意味します。システムにはパフォーマンスの余裕(Performance Headroom)があり、インデクサーはグラフィック品質をスムーズに向上させることができます。

Zero-GC: パフォーマンス第一

ゲームを遅延から救うために設計されたプラグイン自体が、ラグを引き起こしてはなりません。WebAPコアは、ホットパス全体にわたって厳格なメモリ節約(Zero-GC)を念頭に置いて設計されています。

  • O(1) リングバッファ: List<float>Update での重いループの代わりに、トラッカーは固定サイズの配列(Ring Buffers)を利用します。平均FPSの計算は一定の時間で実行されます。
  • Updateでのゼロアロケーション: コア内には new の呼び出し、ボクシング、またはラムダは含まれていません。ガベージコレクタ(GC)が消去するものは全くありません。
  • デリゲートキャッシュ (Delegate Cache): 複雑なタスク(WebScaledPhysics2DRaycaster でのクリックの傍受など)においてさえ、遅いリフレクション(MethodInfo.Invoke)を放棄し、高速なコンパイル済みデリゲートを使用します。

不可視性 (Invisibility)

これらの最適化のおかげで、WebAPパイプライン全体のオーバーヘッドは最小限に抑えられます。プロセッサは監視されていることにさえ気づかないでしょう。