機台穩定 30 報告
卡尺 更新 2026-10-20 10:40 ・ 板子 RK3576 ・ 網頁分支 feat/perf-on-cabinet-20261018 @ 00501c4e9 ・ 量法：SurfaceFlinger frametimeline（螢幕實際換畫面）
約 93～95%
鎖 30 fps 時，每 100 張畫面約 93～95 張準時 33 ms，約 3 張晚一格（50 ms）。
剩下的卡頓約 7～8 成在「APK 把 WebView 畫面貼進自己視窗」那一步；遊戲本身交出畫面幾乎都準時。網頁和 IO 能改的都試過，量不到再往上的改善。
有效、已在用的
| 做法 | 效果（33 ms 準時） | 狀態 |
|---|---|---|
| APK 改正式版建置（除錯版 → 正式版） | 87% → 95% 最大的一個 | 測試 APK 已是正式版速度；出貨流程待負責人 |
| rwLatch：畫好後下一次刷新才交出 | +4 點（89.7 → 93.9%） | 預設開（022d5af91、7e0b662c8） |
| IO 回覆移出 APK 主執行緒 | 畫面量不到 主執行緒工作減半 | 實作者分支 |
| 合 Barry 優化＋虛線補回＋2D 跟 3D 同一張（甲） | 不變 94.9 vs 95.1% | 已推（79ecc48f3） |
| 開場不再退回舊畫法（Barry 修正） | 開場錯誤消失 | 已推（1ebc8e1a2） |
| 左上角 FPS 兩行（畫面＋主執行緒） | 現場可看 | 已推（00501c4e9），網址加 fps=1 |
試過、量不到或變差（都已撤回）
| 做法 | 結果 | 原因（實測） |
|---|---|---|
| 全部 140 條執行緒綁大核 | 量不到 90.5 vs 91.4% | 執行緒快 3～4 成，但連晚兩格變多 |
| APK 畫面改 OpenGL（統一） | 量不到 91.0 vs 90.3% | — |
| Barry 主迴圈每秒 60 次 | 變差 95.5 → 93.6% | 鎖 30 時主執行緒多做一倍 |
| 2D 回主執行緒（乙） | 變差 17～35% | 2D 和 3D 兩張畫布錯開刷新 |
| 每張固定 33 ms 才交出 | 變差 93.9 → 91.3% | 交出撞到下一張開畫，APK 貼圖搶 GPU |
| HUD 閃爍不整份重算 | 量不到 94.3 vs 94.0% | 電腦上重算 82→0，機台不影響節奏 |
| 改用 Chromium 顯示（拿掉 APK 貼圖） | 變差 93.3 → 90.9% | 晚一格變少，但多出太快一格／連晚兩格 |
| IO 輪詢 5 → 10 ms | 畫面量不到 93.5 vs 93.1% | IO 反而變慢（讀輸入 +2～5 ms、來回 +3 ms） |
一格畫面怎麼走到螢幕（紅色＝卡頓主因）
遊戲算好（主執行緒）→背景畫 3D＋2D→GPU 執行緒畫完→APK 把畫面貼進自己視窗→系統交給螢幕
WebView 不能自己上螢幕，一定要 APK 再貼一次（GPU 多畫一整張 1920×1080）。Chromium／Unity 沒有這一步。
每一次 50 ms 卡頓當時發生什麼（4 段 × 10 秒錄影）
遊戲背景晚交出：0 次。背景交出距刷新中位約 4 ms，晚過 16.7 ms 的只有 1～2% 張數。
還能試的
系統「要效能」開關（ADPF）
板子支援但目前沒人用。開了讓 APK 貼圖的執行緒跟系統要效能。改一個系統設定、量完改回，約 15 分鐘。等你同意。
要接近 100%
只剩換架構：遊戲有自己的圖層＋節拍器（像 Unity 的 Swappy，可指定每張在哪次刷新顯示）。WebView 沒有這個功能，成本大。
更正過的說法
- 「主迴圈約 3 成跑到 11 ms」：開程式取樣工具量的，工具本身拖慢。實際中位約 6 ms、超過 9 ms 約 3～7%。
- 「卡頓一半是遊戲晚開始畫」：估太高，實際遊戲交出晚只有約 1～2%。
- 「刷新信號要經主執行緒轉交」：沒有證據，背景是直接收到。
- 面板黑塊：是開發伺服器沒真的重開，不是程式問題。
證據：F:\tmp\spin-evidence-20260812\board\runs\20261018-hudseq\RESULT.md（各節）、20261019-iofix、20261019-chromium、20261020-poll10