React程序員做小游戲，60幀下setState直接崩了

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為什么不用Canvas？

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

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

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

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

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

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

框架的渲染模型是契約。React的契約是「聲明式UI，我?guī)湍阃綘顟B(tài)和視圖」。但游戲循環(huán)的契約是「每幀直接寫屏，延遲必須低于16ms」。兩份契約沖突時(shí)，強(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ù)簡(jiǎn)單」的部分。這不是對(duì)React的否定，是對(duì)其適用域的清醒認(rèn)知。

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

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

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

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

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

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

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

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

給前端工程師的啟示

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

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

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

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

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

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

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