上機 60fps 判決書

證據鏈(四步,全部可重現)

1. 砍 CPU 沒反應。把骨骼計算砍掉 84–96%(預烘骨骼 A/B,三對同號)→ 幀時間 +0.26ms,零收益。
2. 剝光內容後的下界=16.95ms(終版,2 輪、指紋齊)。過程有兩次修正:最早的「19.4 雙路徑三角驗證」在內容指紋補齊後發現兩路徑場面不同、且重跑後兩路徑差 3.08ms 不收斂——「三角驗證的硬地板」整條撤回,那次收斂是內容沒釘死造成的巧合。站得住的是:剝到 9 draw call/6 千三角形仍要 16.95ms=預算 101%。教訓:三角驗證前提=內容指紋逐輪釘死,「條件字串相同≠場面相同」。
3. 主執行緒 14.5ms,三儀器互證,且定性完成。頁面內取樣器(JS 11.9)+系統排程(14.5,含瀏覽器內部 2.6);像素砍 16 倍它不動(−0.16)、但選單時只剩 2.85 ⇒ 它是遊戲每幀的工作,不是瀏覽器固定開銷——塗抹在數百條小路徑上,無單刀大戶。選單→戰鬥的差分同時排除了「卡系統合成」(surfaceflinger +0.32 不動),幀成長 92% 來自 CPU 工作變多、34% 伴隨 GPU 等待。
4. 像素側坐實 GPU 滿載。全解析度下每幀 GPU 阻塞等待 +4.4ms;系統合成端每幀處理一張固定 1920×984 的表面(平均 19.7ms)——遊戲內降解析度縮不到這一層,它在網頁權限之外。

整體:一幀 29.6ms 長什麼樣(總圖)

下面這條橫條就是一幀:從左到右是時間,從「開始畫這一幀」(0ms)走到「開始畫下一幀」(29.6ms)。紅色虛線是 60fps 的預算線(16.7ms)——一幀必須在虛線前結束才有 60fps,現在明顯超過:

同一條橫條,把兩段再切細(每小格是什麼,對應下面細分 A、B):

一幀的順序是這樣走的(為什麼兩塊要相加):

1. 做事(14.5ms):主執行緒跑遊戲程式——更新每隻怪的位置、算 UI、把「這幀要畫什麼」打包丟給顯示卡。
2. 等(15.1ms):丟出去之後,顯示卡在畫、佇列在排、螢幕在等換頁節拍——主執行緒想開始下一幀但還不能,只能等。
3. 等到了,才開始下一幀的「做事」。

所以「一幀多長」=做事+等待,兩段是接續發生在同一條時間軸上的,所以相加。(實際上兩者會交錯進行,但每幀的總量就是這兩個數字。)

比方:廚師做一道菜 15 分鐘,但出餐口塞住、每道要再等 15 分鐘才出得去——客人感受到的上菜間隔就是 30 分鐘。要縮短間隔只有兩招:廚師做快一點(①),或把出餐口疏通(②)。下面把兩塊各自拆開,最後一張圖是「哪些開關能省多少」。

細分 A:「①在做事」的 14.5ms 是什麼

重點:沒有一格大到「砍一刀就贏」——都是小錢加總。這 14.5 與解析度無關(像素砍 16 倍它不動),但與遊戲內容有關(回到選單只剩 2.9)。

細分 B:「②在等」的 15.1ms 在等什麼

系統追蹤看到的形狀:七條執行緒各自半忙(沒有一條滿載),一幀要依序走完每一站,時間耗在「交棒」上;佇列塞住(Buffer Stuffing 佔 50% 的幀)是這個的症狀。降解析度能縮「等顯示卡」那格(所以降到 1/4 省 6.8ms),但縮不掉接力本身。

細分 C:哪些開關能省多少(實測)

⚠️ 這些不可相加——大多在搶同一塊(像素池):

疊層數字說明:同一實驗跨 session 量到 −6.11 與 −7.20(差值在雜訊邊緣),故標區間;其內部拆分=繪製+raster 5.89/純合成≈0(同 session 一組)。全部一起拿掉(=幾乎空畫面)也只到 ~17.0ms——剛好卡在 60fps 預算的門檻上(101%)。搭配「主執行緒 14.5ms 與內容無關地存在」那條,就是「關功能到不了 60」的完整依據。

與 8/6 分析的對照(為什麼結論不一樣)

一句話:8/6 沒有量錯——它量的是三百多顆 commit 之前的另一個遊戲;而它的原始量測檔已滅失、部分結論的儀器視野有限。今天的每個數字都有雙份原始檔+指紋,之後不會再發生「說不清當時量的是什麼」。

三條路(可組合,選路是你的決定)

已實測排除,不要再投入的

• 一切 CPU 側優化(8 月優化批/多執行緒 Worker/WASM/姿勢共享/砍關節):單一槓桿都低於可測門檻——「不是因為 JS 便宜,是因為沒有一格是瓶頸」
• 遊戲內降解析度做為主策略(第一刀 −6.8ms 後即撞天花板;且縮不到系統合成層)
• 手把輪詢(遊戲每幀 getGamepads() 引起、每幀燒 6ms CPU,但在空核上、0 次搶佔主執行緒——「遊戲造成的」≠「砍掉會變快」;容器核滿後需重驗)
• 貼圖上傳(每幀僅 63KB)/draw call 清理(考古證實 70→23 的收益已入袋)

邊界與未涵蓋(誠實條款)

• 全部量測在 webview_shell,非最終容器——Unity 在底下跑只會讓 GPU 側更緊,判決方向不變、數字會更差
• 系統追蹤各條件單次抓取;GPU 阻塞未細分(等 GPU/等 fence/等 buffer)
• 被測物含量測探針(殘差低於 ±1.1ms 解析度;所有 A/B 差不受影響)
• 量測分支血統落後現行 main 11 顆;8/6 舊數據與今日矛盾已由「考古」實驗和解(兩份都對,量在 draw call 70 與 23 的兩個時代)

品質紀錄

本判決書的每個數字至少 2 輪實測+對象指紋。過程中 8 個數字被撤回(9fps/2.98MB 上傳/自動遊玩不殺怪/JS 2.1ms/選單取樣/容量假說/19.4 地板/三角驗證)——全部在團隊內部抓出(六次由量測自身的對照機制、兩次由審查者的質疑觸發),零次由團隊外部發現。後兩次的教訓比前六次深:自檢的覆蓋範圍有洞時,洞裡的錯誤自檢永遠抓不到——所以量測與審查必須是兩雙眼睛。撤回後存活的數字,才進了這份文件。