暫時忘了那些過場動畫，有人在 Flutter 裡直接用原生效能蓋出一個 3D 方塊世界

當開發者打開編譯器，準備用寫外賣 App 或企業打卡系統的 Framework 寫出 3D 遊戲時，很多人腦海中浮現的第一個畫面可能是卡頓的破圖與糟糕的幀率。一直以來，主流行動開發圈都默認 Flutter 雖然能做出極度流暢的 2D 動畫與精美的使用者介面，但在真正的 3D 圖形運算面前，它終究只是個做表單的工具。然而，近期一篇發布於掘金平臺的技術文章，徹底打破了這道隱形天花板，讓非遊戲圈的工程師們集體沸騰。

這篇文章由技術部落客「戀貓de小郭」於 2026 年 7 月 23 日發布。文中展示了第三方開發者 bdero 所打造的 flutter_scene 套件。這不是那種把現成遊戲引擎包一層皮的空殼，開發者直接在 Flutter 框架內，跑出了一個極度類似《我的世界》的 3D 沙盒遊戲場景。沒有引入任何外部沈重的遊戲引擎，也沒有使用容易導致效能裂痕的 PlatformView。這項純粹基於 Flutter GPU 與 Impeller 底層實作的成果，猶如對技術界丟下一顆震撼彈，讓大眾看見應用程式框架跨界 3D 遊戲領域的真實潛力。

卸下介面框架的標籤

要理解這次展示為何令人震驚，必須先釐清過去 App 開發與遊戲開發之間的楚河漢界。在過去幾年，Flutter 憑藉其跨平臺特性、高效的 UI 渲染速度，成功佔據了行動應用市場的一席之地。但它始終被視為「介面框架」。如果一款應用程式需要嵌入 3D 模型、地圖或複雜的相機濾鏡，開發者通常得依賴 PlatformView 橋接原生的 OpenGL 或 Metal 畫面，這種做法常常會引發觸控事件延遲、記憶體暴增與合成層級衝突。

flutter_scene 的出現，直接撕掉了這張標籤。根據「戀貓de小郭」在掘金與 GitHub 上的公開資料解析，這套 3D 實現完全建構在 Flutter 原生的圖形引擎之上。

它沒有依賴 Unity 或 Unreal 這類龐然大物，而是自己從頭管理場景圖、材質貼圖、動畫系統、光照陰影計算、RenderGraph 與 GPU 資源調度。這意味著過去被視為只能拿來做按鈕點擊特效的工具，現在具備了獨立計算物理光照與空間深度掉期的能力。對於長期關注 Flutter 發展的開發者來說，看著一個由方塊組成的 3D 角色在場景中即時移動，且畫面能夠與底層的 Flutter 介面完美疊加，幾乎是見證了框架能力的一次質變。

塞進手機裡的 3D 電影工作室

如果只是畫出幾個會動的立方體，還不足以讓專業工程師驚嘆。flutter_scene 真正的破壞力，在於它支援了現代 3A 級遊戲大作才會使用的完整渲染管線。

在 bdero 的架構中，這套系統包含了六個層次分明的核心模組。從最頂層負責畫面幀循環與輸入事件的 Flutter 展示層，一路向下深入到負責陰影、深度、PBR 基於物理的材質渲染與後期處理的 RenderGraph。這是一套非常標準且完整的現代圖形學架構。

具體來說，這個專案展示了哪些超乎預期的視覺能力？根據原始文章的技術拆解，目前的成果包含：

• 完整的 PBR 與 IBL 支援，讓 3D 物體在不同光源下能呈現真實的材質反光。
• SSAO 螢幕空間環境光遮蔽與 SSR 螢幕空間反射，大幅提升場景的立體感與陰影細節。
• 景深效果與後期處理機制，讓畫面能產生類似電影鏡頭的模糊聚焦效果。
• 實作了 3D Gaussian Splatting 技術，這是一種近期在圖學界極為熱門的 3D 場景重建演算法。
• 內建了物理碰撞引擎與 LOD 細節級別調整，確保遊戲或複雜場景在不同設備上能流暢運行。

當這些名詞組合在一起，並在一個普遍被用來開發外送與購物 App 的框架中流暢運行時，它已經超越了一個單純的展示套件。它更像是一個塞進手機裡的迷你 3D 工作室，讓許多獨立開發者看見了擺脫龐大遊戲引擎束縛的可能性。

告別黏糊糊的跨平臺妥協

過去要在一個 App 裡放入 3D 場景，開發者通常得面對一種黏糊糊的技術妥協。PlatformView 機制就像是在一張平整的 Flutter 畫布上，硬生生剪開一個洞，然後把原生的 iOS 或 Android 視圖強行塞進去。這種做法在處理簡單的地圖或相機預覽時或許勉強堪用，一旦遇到需要大量運算的 3D 遊戲場景，效能往往會直線崩落。

flutter_scene 徹底改變了這個遊戲規則。透過 SceneView 這個入口，它並非疊加在 Flutter 上方的原生 Surface，而是直接參與 Flutter 的 Canvas 合成。這意味著 3D 場景可以像普通的按鈕或圖片一樣，與現有的 Flutter 介面進行任意的疊加、裁剪和佈局。

在程式碼的運作邏輯上，SceneView 內部擁有一個獨立的 Flutter Ticker 來驅動每一幀的更新。這套機制非常聰明，它在每一幀的渲染週期中，不會笨拙地重建整個 Widget 子樹，而是透過 ChangeNotifier 精準地只觸發繪製層的重繪。這不僅解決了效能問題，更確保了 3D 場景裡的物件可以無縫接軌 Flutter 既有的無障礙語意樹。這種把 3D 空間節點直接投影進 Semantics 樹的設計，展現了極高的工程品味，同時這也與我們先前探討過的騰訊 WorkBuddy 悄悄搬進鴻蒙電腦：當 AI 辦公助手成為科技巨頭的社交貨幣有著相似的跨平臺相容精神，同樣支援了 Custom embedders，甚至傳出能完美適配鴻蒙系統。

當應用程式與遊戲引擎的界線徹底融化

這起技術展示之所以能在短時間內於開發者社羣引發大量討論，除了視覺上的衝擊，更深層的原因在於它觸碰到了現代軟體開發的一條敏感界線：究竟什麼是 App，什麼又是遊戲？

回顧網路技術的演進，這種跨界並非毫無預兆。過去 Web 瀏覽器只能顯示簡單的純文字與圖片，後來 WebGL 出現，讓 Chrome 瀏覽器成功跑起了龐大的 3D 遊戲。如今，相似的劇本正在行動開發框架中重演。當 flutter_scene 連 MCP Agent 操作接口與獨立的編輯器都準備齊全時，它已經不再只是一個讓介面變漂亮的附屬品，而是一個具備完整生產力的遊戲引擎雛形。

過去，獨立開發者如果想做一款帶有豐富 3D 介面的電商 App，往往需要組合 Unity 與原生開發兩種截然不同的技術棧，團隊溝通成本與包體積大小都是夢魘。現在，界線融化了。或許在不久的將來，當我們在網購平臺上觀看一雙球鞋的 3D 模型，或者在新聞 App 中回顧一場歷史戰役的 3D 沙盒推演時，那細膩的光影與絲毫不卡的滑動體驗，不再是遊戲大廠的專利，而是由一羣曾經只負責寫表單的 Flutter 工程師所打造。

隨著硬體效能不斷攀升，未來的 App 介面，還會被限制在扁平的二維平面裡嗎？