Flyweight Pattern — 蠅量級模式(享元模式)

本文在介紹 Flyweight Pattern 時採用 refactoring.guru 上的範例和情境。

Flyweight Pattern — 蠅量級模式(享元模式)

本文在介紹 Flyweight Pattern 時採用 refactoring.guru 上的範例和情境。

出處: https://refactoring.guru/design-patterns/flyweight

情境:

你寫了一個遊戲，是 FPS 型的，裡面有飛彈、子彈等飛行道具。還有各種酷炫的特效，這些特效和爆炸的聲光效果，都卓越超群。你把這個遊戲 push 上去，讓你和你的朋友玩。

但是、Shi ka shi、but 「在你的電腦上是好的」

在你朋友的電腦上，每玩幾分鐘，這個遊戲就閃退了! 遊戲體驗在你朋友的電腦上非常的差。你開始 debug，然後 de 了幾個小時，從 log 中翻找各種數據。你找到原因，是出在 RAM 上，error message 最後 trace 到 RAM 不足。因為你電腦的配置很強，但你的朋友電腦設備沒那麼好，所以 RAM 吃光了。

而 RAM 被吃光的原因，是在那個你寫出來的 particle system (專門處理粒子效果)。每個粒子，例如子彈、飛彈，還有各種會飛的物件，只要出現在玩家的螢幕，就會生出一個 particle 物件，最後，當 RAM 不足的時候，程式就崩潰了。

從下圖可見，每個粒子會佔掉 21 KB。當有 1,000,000 個粒子的時候，這時會需要 21 GB 的 RAM。

from refactoring.guru

我們來看個 Overwatch 畫面。

如何使用 Flyweight 模式，改善你的遊戲體驗?

Flyweight 如何減輕系統上的負擔

再回頭看一下 ”Particle” 這個類別，然後思考一下。

你應該會發現，有兩個 property 可以設計成不變的 (也就是剛剛講的內部資料)

color
sprite

而其他屬性，是會變化的 (也就是剛剛講的外部資料)

particle (粒子)
coords (座標)
vector (移動向量)
speed (移動速度)

再回來看這個系統

最吃資源的，仍然是 sprite，以上面同樣數量的粒子來看。1,000,000 個粒子，在不 init 新的內部資料狀況下，他需要的是 32MB RAM，對比沒有使用 design pattern 的狀況 — 21 GB，這樣的設計，讓你朋友的電腦上，也可以運作順利。

結束了嗎?這樣已經發揮了 design pattern 最佳的結果了嗎?

設計模式是可以進行疊加的!

再加上一個外部物件儲存池，可以更優化

在實務上，通常會再加上一個「池」(pool)，把生出來的「內部資訊」放在池子裡面。

在這個案例裡面，因為有一個最大的類別 Game，會在 Game 裡面用一個 property 去存 Particle，當螢幕需要 particle 的時候，系統會先從池子裡面找有沒有沒用過的 particle，有的話，就拿出來塞「外部資訊」(也就是向量、速度、座標)。如果池子裡面沒有所需要的 partile，就會 init 一個，然後塞外部資訊。