一個前端工程師用React寫游戲，幀率掉到個位數(shù)時，他意識到問題不在代碼，而在框架的「肌肉記憶」。

這是@nyaomaru的真實經(jīng)歷。他拿到了NVIDIA送的《生化危機(jī)9》，到現(xiàn)在還沒見到第一只僵尸——但他在瀏覽器里做的小游戲《Run Away From Work》，卻讓他對React有了完全不同的理解。

游戲看起來很簡單：一個打工魚逃跑，老板追，路上撿魚幣躲障礙。但當(dāng)他試圖用setState驅(qū)動每一幀動畫時，瀏覽器風(fēng)扇開始狂轉(zhuǎn)。

setState → 重渲染 → diff → DOM更新，這套流程在60fps下就是性能自殺。

他沒有換框架，而是換了一套架構(gòu)思路。React還在，但游戲循環(huán)（Game Loop）被徹底剝離出去。

React的渲染模型，和游戲循環(huán)是兩種生物

React的核心假設(shè)是：狀態(tài)變了，UI重新計算。這對表單、列表、儀表盤是完美的。

但游戲不一樣。游戲需要每16.6毫秒更新一次畫面，而且更新的往往不是整棵樹，是幾十個實體的坐標(biāo)。用React的diff算法處理這個，就像用Excel公式做實時渲染——能跑，但何必。

@nyaomaru的解法很直接：React只負(fù)責(zé)靜態(tài)結(jié)構(gòu)，動態(tài)實體直接操作DOM。

看這段代碼。游戲區(qū)域由React渲染，但玩家、老板、障礙物這些「活物」，全是原生DOM節(jié)點。

他用document.createElement生成障礙物，用appendChild塞進(jìn)游戲區(qū)域，用requestAnimationFrame驅(qū)動位置更新。React完全不知道這些節(jié)點存在。

這聽起來像「反模式」，但性能數(shù)據(jù)不會騙人。瀏覽器主線程從「喘不過氣」變成「游刃有余」，幀率穩(wěn)在60fps。

三層架構(gòu)：React當(dāng)骨架，原生DOM當(dāng)肌肉

具體實現(xiàn)分三層。最外層是React的領(lǐng)地：游戲容器、UI覆蓋層、分?jǐn)?shù)顯示。這些很少變動，React處理得干凈利落。

中間層是實體管理層。@nyaomaru用useRef保存所有動態(tài)元素的引用，但絕不把它們?nèi)M(jìn)state。障礙物數(shù)組存在ref里，React渲染周期永遠(yuǎn)看不到它們。

最內(nèi)層是動畫循環(huán)。requestAnimationFrame每幀直接修改DOM節(jié)點的style.transform，跳過React的調(diào)和（Reconciliation）全過程。

這種「混合模式」的關(guān)鍵是隔離。React管它的，原生DOM管它的，兩者通過ref建立單向聯(lián)系。React知道游戲區(qū)域在哪里，但不知道里面有多少個障礙物在飛。

一個細(xì)節(jié)：玩家和老板的精靈圖也是SVG，但位置更新不走React。sprite的transform屬性被直接賦值，瀏覽器合成層（Compositor）接手后續(xù)工作，主線程零負(fù)擔(dān)。

為什么不用Canvas？

讀到這你可能會問：都操作原生DOM了，為什么不直接用Canvas 2D或WebGL？

@nyaomaru考慮過，但拒絕了。他的理由是工具鏈和審美：所有視覺素材都是Adobe Illustrator手繪的SVG，保留DOM結(jié)構(gòu)意味著可以用CSS做響應(yīng)式、用瀏覽器開發(fā)者工具直接調(diào)試、用現(xiàn)成的無障礙支持。

更重要的是，這個游戲的復(fù)雜度還沒到Canvas的甜點區(qū)。幾十個移動元素，DOM+CSS transform完全吃得消。Canvas的優(yōu)勢在成千上萬個粒子，這里用不上。

這選擇里有產(chǎn)品經(jīng)理的權(quán)衡思維。技術(shù)選型不是選「最強(qiáng)」的，是選「剛剛好」的。為了10%的性能提升，犧牲50%的開發(fā)體驗和可維護(hù)性，這筆賬不劃算。

從游戲循環(huán)看框架邊界

這個案例的真正價值，是展示了如何在一個React應(yīng)用里「開天窗」。

框架的渲染模型是契約。React的契約是「聲明式UI，我?guī)湍阃綘顟B(tài)和視圖」。但游戲循環(huán)的契約是「每幀直接寫屏，延遲必須低于16ms」。兩份契約沖突時，強(qiáng)行套用一方就是災(zāi)難。

@nyaomaru的做法是承認(rèn)邊界：React負(fù)責(zé)「結(jié)構(gòu)穩(wěn)定但數(shù)據(jù)多變」的部分，原生DOM負(fù)責(zé)「結(jié)構(gòu)多變但數(shù)據(jù)簡單」的部分。這不是對React的否定，是對其適用域的清醒認(rèn)知。

他甚至在GitHub上開源了完整代碼。評論區(qū)最熱的反饋是：「原來useRef還能這么用」——很多人把ref當(dāng)成「避免重渲染的逃生艙」，卻忘了它本身就是通往DOM的合法通道。

另一個有趣的點是狀態(tài)管理。分?jǐn)?shù)、游戲階段這些「業(yè)務(wù)狀態(tài)」仍在React里，用useState完全沒問題。但實體的位置、速度、碰撞箱這些「物理狀態(tài)」，被隔離在React之外，用純JavaScript對象管理。

這種分層讓調(diào)試變得直觀。游戲邏輯bug看控制臺，UI bug看React DevTools，互不干擾。

性能數(shù)字背后的真相

沒有公開的benchmark，但@nyaomaru描述了一個典型場景：30個障礙物同時移動，純React方案幀率掉到15fps，混合方案穩(wěn)60fps。

差距來自哪里？React的調(diào)和算法在每次setState時要遍歷組件樹，計算最小更新。30個障礙物意味著30次狀態(tài)變更，或者1次批量變更但涉及30個組件。無論哪種，開銷都遠(yuǎn)高于直接修改30個DOM節(jié)點的transform。

更隱蔽的成本是垃圾回收。頻繁創(chuàng)建和銷毀React元素會產(chǎn)生大量臨時對象，觸發(fā)GC時幀率波動。原生DOM方案的對象生命周期簡單得多。

這些細(xì)節(jié)在普通應(yīng)用里無關(guān)緊要，但在幀時間預(yù)算只有16ms的游戲里，每一毫秒都是戰(zhàn)場。

給前端工程師的啟示

這個案例最實用的 takeaway 是：學(xué)會在React應(yīng)用里「作弊」。

useRef、createPortal、甚至直接操作DOM，這些「逃生艙」不是bug，是框架設(shè)計者預(yù)留的應(yīng)急通道。當(dāng)你確定某個場景不在React的甜點區(qū)時，果斷繞路比強(qiáng)行優(yōu)化更聰明。

另一個啟示是關(guān)于技術(shù)寫作的。@nyaomaru的文章結(jié)構(gòu)很典型：先展示問題（幀率崩潰），再展示解法（架構(gòu)分層），最后給可運行的代碼。沒有抽象的理論，全是具體的決策點和權(quán)衡。

這種寫法對25-40歲的技術(shù)讀者特別有效——他們經(jīng)歷過足夠多的項目，知道「最佳實踐」往往在邊界處失效，想看到的是別人怎么在真實約束下做取舍。

最后提一個產(chǎn)品細(xì)節(jié)。游戲里的「老板」角色有一個手臂動畫，用CSS關(guān)鍵幀實現(xiàn)。這個動畫完全獨立于游戲循環(huán)，由瀏覽器合成層處理，不占用主線程。

@nyaomaru在文章結(jié)尾說，他還沒通關(guān)《生化危機(jī)9》，因為「看到第一個僵尸就關(guān)了游戲」。但他的小游戲已經(jīng)讓幾百人摸魚時多了一種選擇——如果React的渲染模型沒有把他逼到墻角，這個解法可能永遠(yuǎn)不會被寫出來。

你現(xiàn)在手上有多少個「本該用React做」的場景，其實更適合直接操作DOM？