戰鬥陀螺 · 效能處理總報告 2026-08-20

一頁結論

barry 已在板子上證明 60fps 做得到 —— 條件是換一條渲染路徑（pipeline 模式＋HUD 改 HTML）並關掉一批視覺（特效、影子、outline、Cover、常駐動畫）。真戰鬥場面（24–34 隻怪＋4 顆 3D 陀螺）多輪 59.4–60.2。
帶碰撞特效還沒過：barry 團隊自己的報告標「未通過」—— 乾淨重啟 120 秒真實遊玩只有 50.74fps，且每輪出現 4.7–5.0 秒的 GPU 卡頓，原因未定位。目前的 60 是「精簡外觀的 60」，不是「完整外觀的 60」。
我們先前的量測沒有被推翻：我們量的是現行出貨路徑（compat），結論本來就是「這條路到不了 60，要換路徑」—— barry 做的正是換路徑，他的 60 是驗證了這個判斷，不是反例。
要拍板的 7 項在最後一節，每項標了誰能決定、卡在哪、大概多少工。

60 的成立條件（先講清楚，這格最重要）

板子 RK3576、正式版打包 —— 環境正確。但渲染路徑不同：renderMode=pipeline（不是出貨的 compat）＋ HUD 搬 HTML DOM（4Hz 更新）＋關掉：Cover、透明 Canvas 疊層、特效、影子、outline、常駐動畫、蓄力光暈。

在這個條件下：24–34 隻怪＋ 4 顆 3D 陀螺＋ HUD，多輪 59.4–60.2。是真戰鬥場面，不是待機。

🔴 帶特效（B6）未通過 —— 這格不能被略過

乾淨重啟 120 秒自主遊玩＝ 50.74fps，且每輪出現 4.7–5.0 秒的 GPU SwapBuffers 長幀，原因未定位。報告原文：「不能把 B6 標成穩定 60」。

沒有單一招數，是十來項各拿幾 fps 疊出來的。最大的兩項是移除 Cover 與粒子批次化。

barry 團隊在自己的報告裡撤回過三次自己的數字（量測網址被 shell 截斷造成的假 59fps、預熱無效、高效能模式 hint 無效），且量測腳本有「遊戲真的在打」的門檻（血量、移動率）。這是有紀律的量測，不是宣稱。

審查邊界

完整審過的是 6a929099（08-15，diff ＋報告全文＋錨點現查）。其後 4 顆未審（7f60979c、f33ed1b6、411da0da、8c0ea1bc）—— 其中兩顆在恢復特效與拖尾，B6 現況可能已比 50.74 好，未驗。

🔴 這條分支有一把沒有開關的刀

碰撞／死亡粒子的砍量（例：Boss 死亡爆炸約 120 顆 → 全域上限 24 顆、火花 20→6）直接改在正式玩法程式裡，沒有包在量測開關內 —— 一合併，所有玩家的特效密度立刻變。這是畫面品質取捨，見拍板清單第 3 項。

兩個數字都只對「現行 compat 出貨路徑」成立 —— 任何場合引用都要帶這個前綴。

拆帳實測：疊層成本裡瞄準虛線一群就佔 +6.00ms（run44，ABAB 兩輪）。搬到 WebGL 後板上 35 → 45fps（08-14 上線期間實證），畫質零損失。

🔴 但它目前不在線上

45fps 是 2026-08-14 短暫上線期間的實證，該版本已被後續部署覆蓋，目前不在線上。「已經有 45」和「曾經有過 45」是兩件事 —— 現在線上是 35fps 的版本。

2026-08-20 上午直接抓兩個站的線上產物驗證：玩家站 App-CxO0K4FX.js、開發站 App-B9V2U5Tw.js，兩邊都是 useWebGL2DOverlay:!1（關）。程式保存在分支上，恢復需要「合併＋開預設＋重新部署」。

項目	實測	成本／代價
關影子	−3.2ms	工程近零（翻預設），代價是畫面沒影子。⚠️ 正式版目前沒有關的路徑，這 3.2ms 玩家天天在付
overlayScale 0.5	先前 −5.43ms	⚠️ 那是虛線搬走前量的，殘值必須重量
怪數配額	0.19ms/隻，約 2ms 空間	玩法取捨

已撤回、不得再引用的數字

JS 2.1ms（有效值為 11.9）／19.3、19.4 地板／2.98MB 上傳（實際 63KB/幀）／8.87fps／25.4% resize 佔比。疊層族 5.89、6.1–7.2 是待機場面值，引用要帶負載註記。

判決書的原結論是「現路徑不可達 60，換路徑才可能」—— barry 等於把那條路做出來了，他的 60 是預測的兌現，不是反例。

而且他砍掉最有效的幾項（Cover、疊層合成），正好就是我們量到最貴的幾項 —— 兩份數據互相印證。

尚未和解的一格

在 barry 的 B3 條件下跑我們的 atrace 差分 —— 若主執行緒遠低於 14.5，就實證「14.5 是 compat 路徑成本、不是平台成本」，兩套量測完全閉環。這格還沒做。

#	事項	誰能決定	卡在什麼	工
1	目標定調：60fps（把 barry 路徑變成出貨路徑）還是先收穩 45	蔡	只缺這個決定；後面所有排程掛在這題	—
2	webgl2d 回線上（合併＋開預設＋重部署，恢復 35→45）	蔡點頭、負責人執行	08-14 被舊樹部署蓋掉後至今未恢復	小時級
3	碰撞粒子密度砍量（Boss 死亡 120→24 顆等，無開關）	只有蔡（畫面品質取捨）	接受＝直接合；不接受＝要求包進開關再合	加開關為小工
4	B6 特效未達標＋秒級 GPU 卡頓根因	工程（barry 線）	根因未定位；逐項排除已做完，下一步要 GPU 資源層追蹤	未知
5	影子／outline 回歸＋現路徑「關影子 −3.2ms」取捨	蔡（畫面取捨）	兩條線都在等同一個畫面決定	決定後小工
6	barry 分支與 main 的合併：同檔衝突＋ pipeline 視覺驗收（含實玩看刀片自轉）	我們	合併語意要人工對、驗收要真 GPU 截圖	天級
7	atrace 在 B3 條件的對照（兩套量測閉環的最後一格）	我們	只需板窗＋既有腳本	半天

所有板上數字皆為引用（出自 barry 團隊報告與我方實作者的量測紀錄），本報告作者未親自在板上跑過。兩邊的原始紀錄都有自我撤回與陽性對照，故採信。
barry 分支 08-15 之後的 4 顆 commit 未審 —— 不要把本報告的結論外推到它們。
線上狀態（webgl2d 不在任何站）是 2026-08-20 上午直接抓線上產物驗證的，不是推論。
報告中兩處自我更正並列：稽核 08-19 誤判「webgl2d 已進 main」、負責人 08-20 誤稱「45fps 在開發版線上」。兩者同族：「部署過／查過」的語氣蓋過了「哪一格沒驗」。