三口爐子上只有一鍋在滾，瓦斯費卻照三鍋收：Flutter 終於學會了這件事

2026 年 9 月 28 日，一篇技術文章記錄了 Flutter 的一次重要改動：編號 #179874 的 PR 正式合併進 master 主線，多視窗（Multi-View）渲染從此改變了工作方式。原本只要任何一個視窗需要更新一幀，所有視窗都得跟著重新合成一次；現在，哪個視窗真的「髒了」、真的有東西變動，才處理哪一個。

這句話聽起來很工程，但你家廚房早就懂這個道理。

想像你開了三口爐。左邊那鍋在滾一鍋粥，米粒翻騰，鍋蓋邊緣冒著白汽，咕嘟咕嘟的聲音沒停過。中間那鍋是燉了兩小時的蘿蔔牛腩，湯面只是偶爾冒一個泡。右邊那鍋根本還沒開火，是早上剩下的一鍋清湯，涼涼地擺著。

一個懂節省的廚師，眼睛會盯著左邊那鍋粥，適時攪一下底，怕它黏鍋。中間那鍋看一眼就好，右邊那鍋理都不用理。但以前的 Flutter 不是這樣。它像一個過分盡責的學徒，只要左邊的粥滾了一下，他就把三口爐的火全部關掉再重開一遍，把三個鍋蓋都掀起來檢查一次。粥沒問題，牛腩也沒問題，那鍋涼湯更沒問題，但他就是全部來一遍。

技術上，這叫每個視窗都要執行一次 compositeFrame()，把已經畫好的畫面重新走一遍合成與提交的流程。就算視窗 B 和 C 的畫面完全沒變，只要視窗 A 有動畫在跑，它們也得跟著陪跑。這在只有單一視窗的年代根本不存在，視窗一多，成本就疊上去了。這也與我們先前聊過的Flutter 開發工具補上邊界缺口是同一條路上的事：工具慢慢把該有的界線補齊。

這次的改動，用廚房的話說，就是給每口爐子裝了一個指示燈。鍋裡真的有動靜，燈才亮；燈亮了，學徒才走過去看。文章裡提到，新的程式碼讓每個視窗知道自己需不需要重新合成，而判斷的依據很樸素：這一幀裡，這個視窗有沒有真的畫過東西。有畫，才算數。

麻煩的地方在於，有些變化不會自動亮燈。就像湯在鍋裡慢慢變濃、味道在你不注意的時候收乾，質地（Texture）、平臺視圖、前後臺切換這類變化，原本不會把該處理的東西標記出來。所以這次合併的大量程式碼，其實都在補這套訊號，把那些「默默發生」的變化，也接到指示燈上。

這對正在推進的桌面多視窗應用是實際的好消息。視窗開得越多，省下的就越多。就像一個辦桌的廚房，爐子從三口變成十口，如果每口爐的動靜都要全部重查一遍，那個學徒會先累垮。讓每口爐自己報告狀態，廚房才轉得動。

回到你家餐桌，道理其實每天都上演。一頓飯裡，需要盯著的只有那一鍋滾著的湯，其他菜是涼是熱、要不要回溫，你看一眼就知道，不會把整桌菜全部倒掉重煮一遍。火候這件事，從來都是把注意力留給真正在變化的那一鍋。工程師花了一大段程式碼才教會框架的道理，廚房裡的人憑耳朵聽鍋裡的聲音，早就會了。

下次你在爐前顧一鍋粥，聽見左邊咕嘟作響、右邊一片安靜，不妨想一下：這就是最有效率的多工。該忙的忙，該靜的靜，一頓飯才煮得從容。