在製作《Selfie Worm》的過程中，有個功能是隨著關卡推進，主角會拍下越來越多的照片。我設計了一個類似 Instagram 頁面的捲動列表，讓玩家可以滑動瀏覽這些自拍照。
當照片只有幾張時，一切都很流暢。但隨著照片數量增加到數十張、甚至上百張後，我發現滑動開始出現微小的頓挫感。這對於一個追求「順手」的物理冒險遊戲來說，是不能忽視的問題。
為什麼「直接顯示」會變慢？
在遊戲引擎的運作中，如果我們單純地把 100 張照片全部排進列表裡，電腦會試圖同時處理這 100 個物件。當你在滑動時，螢幕外那些看不見的照片依然在佔用資源；而如果換成是「滑到才產生，離開就刪除」的做法，電腦則會因為頻繁地「新建」與「拆除」物件，導致處理器瞬間負載過重，造成畫面卡頓。
這種不斷重複蓋房子又拆房子的過程，就是效能低下的主因。
引入「Pooler」：一種資源回收的邏輯
要顯示的照片有10張，實際只有生成5個物件，更多張照片也只需要5個物件
為了解決這個問題，我使用了 Pooler（物件池） 的原理。
可以想像一個情境：有一家餐廳（捲動列表）裡有 100 位客人（照片）在排隊，但店內只有 5 個座位（螢幕可見區域）。
一般的做法：每進來一位客人，我就現場蓋一張新椅子；客人吃完走人，我就把椅子拆掉，浪費了蓋椅子與拆椅子的資源。
Pooler 的做法：我只固定準備 6 張椅子。當第一位客人離開位置，這張椅子不會被拆掉，而是立刻被移到排隊隊伍的最前端，給下一位進來的客人坐，只是換了個名字和餐點內容。
在開發《Selfie Worm》時也是同樣的邏輯：無論玩家拍了幾百張照片，螢幕上其實永遠只有那幾個照片框架在循環利用。 當一張照片滑出螢幕上方，它就會被悄悄地移動到螢幕下方，並瞬間「換上」新照片的內容。
優化後的實際好處
透過這種方式，電腦不需要再去處理「生成」與「銷毀」的繁重工作，它只需要負責這幾個固定物件的位移與內容替換。
對玩家來說，最直觀的感受就是：
- 滑動絲滑：不管列表再長，滑動的順暢度始終如一。
- 不發燙：減少了 CPU 的負擔，手機或電腦的資源佔用大幅降低。
- 載入極快：不需要一次加載百張圖，進入頁面幾乎是瞬間完成。
雖然《Selfie Worm》是一款輕鬆的2D輕量遊戲，但在這些看不見的底層邏輯上，若是沒注意還是會出現擁腫、笨重的情況。
這就是我最近在遭遇效能問題時的一點心得分享。如果你在開發過程中也有遇到類似「物件太多」的困擾，或是對於這種資源循環的邏輯有不同的看法，歡迎留言跟我討論，我也很想了解更多不同的優化方式。
