專案A 自動化效能分析報告

專案A · Unity 6000.3.10f1 · URP

效能結論以正式機實機數據為準

核心結論
正式機為 GPU BOUND
四份實機 capture 數據一致 · 優化主軸應聚焦 GPU，CPU 為次要
15.8
BOSS 戰 FPS
31
投幣頁 FPS
23.4
主戰鬥 FPS
74%
GPU 佔幀時間

一、環境與硬體對象

角色規格用途
開發機高階顯卡 / 16 核分析主機
正式/熱測機入門級 CPU / 入門級顯卡（3.9GB VRAM）/ 4 核優化真正目標
關鍵原則：效能結論一律以「正式機實機數據」為準。兩機算力差約 4.4 倍，瓶頸類型會反轉，開發機數據不能直接代表玩家實際體驗。

專案：專案A，Unity 6000.3.10f1，URP 管線。

二、使用的工具

三、Profiler 數據取得方式

方式 A · 手動 capture

正式機手動錄製 → 存 .data 至指定錄製目錄 → LoadProfile 分析。

方式 B · 遠端自動錄製（本次新建立）

開發機 Editor 透過遠端連線至正式機 player → 遠端錄製 → SaveProfile → 分析。

四、自動化流程（七步，已實測跑通）

建立遠端連線
確認 connectedProfiler != -1
偵測是否在主戰鬥
試錄 3 秒掃 marker，用 FightMainGame.Update() self-time 判斷（連續 2 次才進下一步，避免抓到載入/過場）
正式錄製 10 秒
SaveProfile 命名 battle_MMdd_HHmm.data
品質驗證
掃全部幀確認全程戰鬥、無載入汙染（本次 259 幀，73% 含戰鬥 marker，汙染 0 幀）
瓶頸分析
先判 CPU/GPU bound 再拆解
優化方案
分三層證據等級（見第六部分）
產出報告
彙整結論與建議
修正的偵測 bug：原用 UpdatePreloading 當載入訊號是錯的（每幀常駐），改用 FightMainGame self-time 才正確。

五、分析的指標

CPU

Frame time p50/p90/p99、FPS、main thread 各函式 self-time 熱點、GC

GPU

GPU time、DXGI.WaitOnSwapChain、GPUProfiler.EndQueries、CPU 渲染提交時間

CPU/GPU Bound 判定

GPU time vs main thread self-time 比較

記憶體

Total Reserved/Allocated、Texture Memory、VRAM 趨勢

資產

Addressable 重複資源、bundle 切分、Texture 格式、Mesh R/W、Material Zombie

Log

Debug.Log 頻率、stack trace 成本

六、主要產出結果（實測數據）

核心結論：正式機是 GPU BOUND

場景FPSGPU 時間GPU 佔比CPU 渲染提交
BOSS 戰15.846.6 ms74%3.5 ms
投幣頁3123.3 ms73%—
主戰鬥（自動錄）23.484 ms（p50=42.7ms）主導—
解讀：連空的投幣頁都是 GPU bound，代表存在全域 GPU 固定成本。優化方向必須降 GPU（render scale／後處理／overdraw／RenderTexture），CPU 為次要。

其他發現

發現項目數據說明
AutoTestManager.Update()4.43 ms/幀CPU 第一名，屬熱測工具，正式版應關閉
Debug.Log 頻率16.2 萬次/晚其中 ArtNumberFont 警告 11,802 次（資產設定錯誤）
Debug.Log 卡頓影響p99 1193→94 ms造成卡頓而非低 FPS，移除後 p99 大幅改善
VRAM 超標約 1080 MB入門級顯卡 VRAM 上限約 3935 MB
Addressable 重複資源576 個2358 份多餘複本

交付動作

  • 已啟用 F10 render scale 即時切換（GlobalCheatKey.cs 取消註解，編譯通過）
  • 遠端自動化錄製流程已驗證可行，可固化成 Skill/排程供無人值守收集

優化方案的三層證據等級

流程第 6 步中，優化方案一律分三層標註證據強度：

1
已量到熱點有實測 Profiler 數據支撐（最高信心）
2
已知架構問題從程式碼/架構可確定，但尚未量化
3
推測需驗證假設性方向，需進一步實測確認

七、技術限制（誠實標註）

專案A 自動化效能分析報告 · 內部技術文件