Flyweight 享元模式 | 實現與解說 | Android Framework Message

● 細粒度物件：物件的每個成員可以區分為 內部狀態 (intrinsic)、外部狀態 (extrinsic)

● 內部狀態 (intrinsic)：代表它是一個物件中的 可共享的成員

儲存在 享元對象 內部並且不會隨著環境改變而改變

● 外部狀態 (extrinsic)：代表它是一個物件中的 不可共享的成員，用來當作對象的唯一標誌（不可變更修改）

● 節省類的創建，也加快速度 (Java 創建類十分耗資源)

● 降低內存消耗、減少 JVM GC 回收導致的 Stop the world 造成的卡頓感

● 提高系統的複雜性（要分離出外部狀態、內部狀態），請判斷在必要的時候再使用，否則可能造成設計過度的問題！

// 建構函數有不可修改的外對象
abstract class Flyweight constructor(val extrinsic: String) {
    
    // 可修改的內部對象
    var intrinsic : Any? = null
    
    abstract fun operation()

}

// 實做 Flyweight
class ConcreteFlyweight constructor(extrinsic: String): 
    Flyweight(extrinsic) 

    override fun operation() {
        println("Show intrinsic date: $intrinsic")
    }

}

可以透過外部特徵（狀態）去判斷該物件是否共享

object FlyweightFactory {

    // 儲存共享物件
    private val pool = HashMap<String, Flyweight>()

    fun getFlyweightObject(extrinsic: String) : Flyweight {
        if (!pool.containsKey(extrinsic)) {
            pool[extrinsic] = ConcreteFlyweight(extrinsic)
        }

        return pool.getValue(extrinsic)
    }

}

fun main() {
    FlyweightFactory.run {
        
        // "Hello" 代表了外部狀態
        val instance1 = getFlyweightObject("Hello")
        val instance2 = getFlyweightObject("Hello")

        println("instance1 == instance2? ${instance1 == instance2}")

    }
}

A. 使用 @Synchronized 註解同步方法

object FlyweightFactory {

    private val pool = HashMap<String, Flyweight>()

    @Synchronized
    fun getFlyweightObject(extrinsic: String) : Flyweight {

        if (!pool.containsKey(extrinsic)) {
            pool[extrinsic] = ConcreteFlyweight(extrinsic)
        }

        return pool.getValue(extrinsic)
    }

}

B. 使用 ReentrantLock 同步方法

object FlyweightFactory {

    private val pool = HashMap<String, Flyweight>()

    private val lock = ReentrantLock()

    fun getFlyweightObject(extrinsic: String) : Flyweight {
        lock.lock()

        if (!pool.containsKey(extrinsic)) {
            pool[extrinsic] = ConcreteFlyweight(extrinsic)
        }

        lock.unlock()
        return pool.getValue(extrinsic)
    }

}

● 外部狀態

控制享元物件的創建重點是在 外部狀態，外部狀態過少過於簡單會導致物件的創建數量便少，從而更容易產生 Thread 問題

外部狀態控制了內部的物件數量

● 內部狀態

內部狀態是被管理的物件的特徵；與物件本身較有關係

● 如果要自己創建物件請務必複寫以下函數，這些函數主要是會影響到外部狀態的「比對」

class SelfObject(private val extrinsic1: String, private val extrinsic2: String) {

    var intrinsic : Any? = null
    override fun hashCode(): Int {
        return extrinsic1.hashCode() + extrinsic2.hashCode()
    }

    override fun equals(other: Any?): Boolean {
        if (other == null || other !is SelfObject) return false

        return other.extrinsic1.equals(extrinsic1) && 
                other.extrinsic2.equals(extrinsic2)
    }
}

Message 的覆用（從池中取值）入口函數為 obtain，接下來我們就從這裡開始分析

// Message.java

public static final Object sPoolSync = new Object();
private static Message sPool;
private static int sPoolSize = 0;

public static Message obtain() {
    synchronized (sPoolSync) {
        if (sPool != null) {
            Message m = sPool;
            sPool = m.next;
            m.next = null;
            m.flags = 0; // clear in-use flag
            sPoolSize--;
            return m;
        }
    }
    return new Message();
}

從以上程式，我們來抓取 Message 設計時的幾個重點

A. 同步鎖 sPoolSync 物件：Message 類中使用一個 靜態的 Object 物件 作為同步鎖的 Key，它表達的是對於 Pool 的執行序安全操作

// Message.java

public static final Object sPoolSync = new Object();

B. 物件池 sPool 物件：在上面的享元模式範例中，我們使用 Map 作為享元模式的池（用來保存已經使用過得物件），而 Android Message 的設計則更為特別

// Message.java

public static final Object sPoolSync = new Object();
private static Message sPool;
private static int sPoolSize = 0;

public static Message obtain() {
    synchronized (sPoolSync) {
        if (sPool != null) {
            // 將原先的指向暫存
            Message m = sPool;
            // 並將 sPool 賦予到原先 Message 的「前方」，也就是新 Message 會作為 Link Header
            sPool = m.next;        
            m.next = null;
            m.flags = 0; // clear in-use flag
            sPoolSize--;
            return m;
        }
    }
    return new Message();
}

graph LR
subgraph chain as pool
m1(新 Message)
m2(原先 Message)
m3(Message)
end
m1 --> |next| m2 --> |next| m3
subgraph Message object
sPool -.-> |當前指向| m1
end

使用該函數時有個條件，就是當 Messsage 物件已經呼叫過 recycle 代表它已經被放入池中，處於一個可使用的狀態（FLAG_IN_USE），不可以重複呼叫 recycle 否則會拋出 IllegalStateException 異常

// Message.java

public void recycle() {
    if (isInUse()) {
        if (gCheckRecycle) {
            throw new IllegalStateException("This message cannot be recycled because it "
                    + "is still in use.");
        }
        return;
    }
    recycleUnchecked();
}

@UnsupportedAppUsage
void recycleUnchecked() {
    flags = FLAG_IN_USE;        // 設定該物件是可用狀態
    
    // 清除物件內的共享資訊
    what = 0;
    arg1 = 0;
    arg2 = 0;
    obj = null;
    replyTo = null;
    sendingUid = UID_NONE;
    workSourceUid = UID_NONE;
    when = 0;
    target = null;
    callback = null;
    data = null;

    synchronized (sPoolSync) {
        if (sPoolSize < MAX_POOL_SIZE) {
            next = sPool;
            sPool = this;
            sPoolSize++;
        }
    }
}

我們同樣還看一下 recycleUnchecked 函數的重點：

A. 同步鎖 sPoolSync 物件：與上個小節介紹的相同，它表達的是對於 Pool 的執行序安全操作

// Message.java

public static final Object sPoolSync = new Object();

B. 池大小的控制 MAX_POOL_SIZE：

// Message.java

private static final int MAX_POOL_SIZE = 50;

void recycleUnchecked() {
    ... 省略部份

    synchronized (sPoolSync) {
        if (sPoolSize < MAX_POOL_SIZE) {
            ...
        }
    }
}

C. 將物件放入池（鏈表）中：

// Message.java

/*package*/ Message next;

void recycleUnchecked() {
    ... 省略部份

    synchronized (sPoolSync) {
        if (sPoolSize < MAX_POOL_SIZE) {
            // 1. 它會將當前指向的物件作為下一個物件
            next = sPool;
            
            // 2. 將自身（`this`）設定為當前物件 `sPool`
            sPool = this;
            sPoolSize++;
        }
    }
}

可以看到 Android 將 Flyweight UML 物件角色幾乎完全融入到一個 Message 中，這是由於它用了「靜態成員」、「鏈表操作池」的原因！

創建模式用於「物件的創建」，它關注於如何更靈活、更有效地創建物件。這些模式可以隱藏創建物件的細節，並提供創建物件的機制，例如單例模式、工廠模式… 等等，詳細解說請點擊以下連結

● Singleton 單例模式 | 解說實現 | Android Framework Context Service

● Abstract Factory 設計模式 | 實現解說 | Android MediaPlayer

● Factory 工廠方法模式 | 解說實現 | Java 集合設計

● Builder 建構者模式 | 實現與解說 | Android Framwrok Dialog 視窗

● Clone 原型模式 | 解說實現 | Android Framework Intent

● Object Pool 設計模式 | 實現與解說 | 利用 JVM

● Flyweight 享元模式 | 實現與解說 | 物件導向設計

行為模式關注物件之間的「通信」和「職責分配」。它們描述了一系列物件如何協作，以完成特定任務。這些模式專注於改進物件之間的通信，從而提高系統的靈活性。例如，策略模式、觀察者模式… 等等，詳細解說請點擊以下連結

● Stragety 策略模式 | 解說實現 | Android Framework 動畫

● Interpreter 解譯器模式 | 解說實現 | Android Framework PackageManagerService

● Chain 責任鏈模式 | 解說實現 | Android Framework View 事件傳遞

● State 狀態模式 | 實現解說 | 物件導向設計

● Specification 規格模式 | 解說實現 | Query 語句實做

● Command 命令、Servant 雇工模式 | 實現與解說 | 物件導向設計

● Memo 備忘錄模式 | 實現與解說 | Android Framwrok Activity 保存

● Visitor 設計模式 | 實現與解說 | 物件導向設計

● Template 設計模式 | 實現與解說 | 物件導向設計

● Mediator 模式設計 | 實現與解說 | 物件導向設計

● Composite 組合模式 | 實現與解說 | 物件導向設計

● Observer 觀察者模式 | JDK Observer | Android Framework Listview

結構模式專注於「物件之間的組成」，以形成更大的結構。這些模式可以幫助你確保當系統進行擴展或修改時，不會破壞其整體結構。例如，外觀模式、代理模式… 等等，詳細解說請點擊以下連結

● Bridge 橋接模式 | 解說實現 | 物件導向設計

● Decorate 裝飾模式 | 解說實現 | 物件導向設計

● Proxy 代理模式 | 解說實現 | 分析動態代理

● Iterator 迭代設計 | 解說實現 | 物件導向設計

● Facade 外觀、門面模式 | 解說實現 | 物件導向設計

● Adapter 設計模式 | 解說實現 | 物件導向設計