1. 概述

Pluma 是一個用 C++ 開發(fā)的可用于管理插件的開源架構(gòu)。該架構(gòu)是個輕量級架構(gòu)，非常易于理解。

Pluma 架構(gòu)有以下基本概念：

1）插件的外在行為體現(xiàn)為一個純虛類，可以叫作插件接口；

2）繼承于同一個插件接口的若干派生類，被認(rèn)為屬于同一種插件，可以叫作插件類；

3）每一個插件接口或插件類都有個一一對應(yīng)的 Provider 類，其中，插件接口對應(yīng)的 Provider 類里會定義一個特殊字符串常量：PLUMA_PROVIDER_TYPE，表示這一類 “插件 Provider” 共同的類型名稱，而這個類型名稱其實就是插件接口的類名字符串。

4）多個插件類可以被放入一個插件動態(tài)庫中，而這個動態(tài)庫文件名（不包括后綴部分）可以叫作 “插件名”。

5）插件機(jī)制使用者可以在自己的架構(gòu)中包含一個 Pluma 管理類，該類支持從所指定的位置加載一個或多個插件動態(tài)庫，并將每個插件類對應(yīng)的 Provider，記錄進(jìn)內(nèi)部的表中。

6）插件機(jī)制使用者可以在合適時機(jī)，利用 Pluma 獲取內(nèi)含的插件 Provider，并調(diào)用某個插件 Provider 的 create () 函數(shù)，創(chuàng)建出對應(yīng)的插件對象。

7）使用完插件對象后，不要忘了 delete 它。

現(xiàn)在我們畫一張示意圖：

2. Pluma 管理類

我們剛剛也說了，插件機(jī)制使用者可以包含一個 Pluma 管理類。

該類繼承于 PluginManager 類。

【pluma-1.1/include/pluma/PluginManager.hpp】

從上面的 load () 函數(shù)和 loadFromFolder () 函數(shù)可以看出，插件管理器既允許用戶單獨加載某個插件動態(tài)庫，也允許批量性加載某個目錄下所有的插件動態(tài)庫。另外，值得注意的是，getProviders () 函數(shù)是 protected 的成員，也就是說，這套架構(gòu)是不希望用戶直接使用這個 PluginManager 類的，即便用了，你也拿不到 Provider。正確的做法是，使用 PluginManager 的子類：Pluma 管理類。 ?? 另外，上面的成員變量 libraries，就是記錄所有已加載的插件動態(tài)庫的映射表。而成員變量 host 則負(fù)責(zé)記錄每個插件類對應(yīng)的 Provider 信息。之所以被稱為 host（宿主），是針對插件而言的。也就是說插件本身實際上是沒資格知道其真實宿主的全貌的，它只能訪問和它相關(guān)的很小一部分?jǐn)?shù)據(jù)而已，因此 Pluma 將這一小部分?jǐn)?shù)據(jù)整理成一個 host 代理，供插件使用。?? ? Pluma 管理類的代碼截選如下： 【pluma-1.1/include/pluma/Pluma.hpp】

請大家注意上面代碼中最后一行，這個 Pluma.hpp 還真是有點手黑，偷偷摸摸 #include 了個 Pluma.inl 文件，其實展開來就是 acceptProviderType () 和 getProviders () 這兩個模板函數(shù)的實現(xiàn)。Pluma.inl 文件的內(nèi)容如下： 【pluma-1.1/include/pluma/Pluma.inl】

看到了吧，重新定義了個 getProviders ()，還搞成一個模板函數(shù)，在函數(shù)體內(nèi)會反過來通過模板參數(shù)，進(jìn)一步得到所涉及的插件 Provider 的 PLUMA_PROVIDER_TYPE 信息，這個技巧挺重要。也就是說，外界傳來的是 vector，而函數(shù)內(nèi)部可以推斷出 ProviderType::PLUMA_PROVIDER_TYPE。將 PLUMA_PROVIDER_TYPE 傳入父類的 PluginManager::getProviders () 函數(shù)，就可以拿到符合所指類型的所有 Provider。 我們畫一張 Pluma 簡圖，后面再細(xì)說相關(guān)細(xì)節(jié)： 同一類插件類，會對應(yīng)一個 ProviderInfo 節(jié)點，該節(jié)點內(nèi)部的 providers 列表，記錄著同屬一類的若干 Provider。

2.1 Host 代理 【pluma-1.1/include/pluma/Host.hpp】

正如前文所說，Host 代理是針對插件而言的。而 Host 只有一個 public 成員函數(shù) add ()，說明其主要對外行為就是讓插件將對應(yīng)的 provider 注冊進(jìn) Host。

3. 插件類和其對應(yīng)的 Provider 類

在說了一大堆插件管理類代碼后，現(xiàn)在終于要開始說插件部分了。前文已經(jīng)說過，插件的外在行為體現(xiàn)為一個純虛類，可以叫作插件接口。我們現(xiàn)在就以 Pluma 源碼中給出的例子為準(zhǔn)，來說明一些細(xì)節(jié)。

3.1 Warrior 接口和 WarriorProvider 類

Pluma 中的插件接口例子是 Warrior，其源碼截選如下： 【pluma-1.1/example/src/interface/Warrior.hpp】

這個接口里只象征性的寫了一個成員函數(shù) getDescription ()，大家明白意思即可。 ?? ? 需要注意的是類定義之后的那句 PLUMA_PROVIDER_HEADER，這個宏負(fù)責(zé)定義和插件接口對應(yīng)的 Provider 類。相關(guān)的宏定義如下： 【pluma-1.1/include/pluma/Pluma.hpp】

基于這些宏定義，我們可以將 PLUMA_PROVIDER_HEADER (Warrior) 展開為：

代碼很清晰，為 Warrior 接口聲明一個配套的 WarriorProvider 類。這個類里包含著重要的 PLUMA_PROVIDER_TYPE 常量，以及最關(guān)鍵的 create () 函數(shù)。 Warrior 的實現(xiàn)文件更加簡單： 【pluma-1.1/example/src/interface/Warrior.cpp】

也在使用宏，展開宏后可見：

因為 Warrior 本身是個純虛類，所以 WarriorProvider 里也不用實現(xiàn) create () 函數(shù)。

3.2 Warrior 派生類和派生 Provider

在 pluma 源碼的例子中，提供了三個 Warrior 派生類，SimpleWarrior、Eagle 和 Jaguar。默認(rèn)的是 SimpleWarrior，它被集成進(jìn) example/src/host 目錄。也就是說，即便我們一個額外的插件庫都不提供，示例至少還可以使用 SimpleWarrior。而 Eagle 和 Jaguar 則位于 example/src/plugin 目錄，可以打包進(jìn)一個插件動態(tài)庫。 【pluma-1.1/example/src/host/SimpleWarrior.hpp】

前文我們已經(jīng)看到，對于插件接口（Warrior）來說，用到的宏是PLUMA_PROVIDER_HEADER(Warrior)，現(xiàn)在針對實際插件類（SimpleWarrior），會用到另一個宏P(guān)LUMA_INHERIT_PROVIDER(SimpleWarrior, Warrior)。這個宏的定義如下： 【pluma-1.1/include/pluma/Pluma.hpp】

展開后可見：

很簡單，就是在完成 Provider 的核心使命，提供一個創(chuàng)建插件類對象的 create () 函數(shù)。與 SimpleWarriorProvider 類似，另外兩個 Warrior 派生類 Eagle 和 Jaguar 大體也是這么寫的。示意圖如下： 在研究 Pluma 所給示例時，我已事先將 Pluma 封裝成靜態(tài)庫了，現(xiàn)在要把 Eagle 和 Jaguar 編譯并封裝成一個動態(tài)庫，就需要鏈接 Pluma 靜態(tài)庫，除此之外，還需要編譯其他一些輔助文件，列舉如下： 1）Connector.cpp 2）dllmain.cpp 3）Eagle.hpp 4）Jaguar.hpp 5）Warrior.cpp 其中 Connector.cpp 文件，是插件動態(tài)庫向外界 Host 注冊自己所有 Provider 的地方。它必須實現(xiàn)一個 connect () 函數(shù)，代碼截選如下：

我們先不要著急分析上面的 connect () 動作，可以先跟著我看看插件的加載流程，后文我們就會知道，connect () 只是加載流程的一環(huán)而已。

4. 插件加載流程

我們看一下 Pluma 架構(gòu)所給例子的 main () 函數(shù)，就可以了解插件的加載流程了：

其中和加載插件相關(guān)的句子主要就是 pluma.acceptProviderType 和 pluma.load 兩句了。前者主要負(fù)責(zé)在 Host 的knownTypes映射表中添加一個 ProviderInfo 節(jié)點，后者負(fù)責(zé)加載插件動態(tài)庫，并將動態(tài)庫里匹配的 Provider 指針記入 ProviderInfo 節(jié)點。

4.1 pluma.acceptProviderType<>()

我們先說 pluma.acceptProviderType 一句。在前文介紹 Pluma.inl 文件的內(nèi)容時，我們已經(jīng)看到一個叫作 acceptProviderType 的模板函數(shù)了，當(dāng)時沒有細(xì)說，現(xiàn)在我把它的代碼再貼一下： 【pluma-1.1/include/pluma/Pluma.inl】

里面調(diào)用的是 PluginManager 基類的 registerType () 函數(shù)。 我們前文主要關(guān)心的是 PLUMA_PROVIDER_TYPE，現(xiàn)在再說一下后兩個參數(shù)。PLUMA_INTERFACE_VERSION 表示管理器當(dāng)前應(yīng)該使用的插件接口的版本，因為我們不能確定更高版本的插件接口會不會增加或刪除成員函數(shù)，所以這個值其實是個限定值，如果后續(xù)用戶嘗試加載更高版本的插件，那么是無法通過校驗的。 第三個參數(shù) PLUMA_INTERFACE_LOWEST_VERSION 則是限定最低值，如果嘗試加載比這個值更低版本的插件，肯定也是不會通過的。 在剛剛看到的 main () 函數(shù)里，是這樣寫的：

pluma.acceptProviderType();

也就是說，Pluma 插件管理器對 Warrior 接口對應(yīng)的 WarriorProvider 類感興趣。而當(dāng)初定義 Warrior 時，在 Warrior.cpp 文件里的確指明了 WarriorProvider 能限定的當(dāng)前版本號和最低版本號：

PLUMA_PROVIDER_SOURCE(Warrior, 1, 1);

這些類型信息、版本號限定信息都會被注冊在 Host 的 knownTypes 映射表中，每種接口類型對應(yīng)一個 ProviderInfo 節(jié)點。注冊動作的代碼如下：

【pluma-1.1/src/pluma/PluginManager.cpp】

【pluma-1.1/src/pluma/Host.cpp】

當(dāng)然，新加的 ProviderInfo 節(jié)點的 providers 列表是個空列表，待后續(xù)再添加 Provider * 內(nèi)容。

4.2 pluma.load()

接著，我們繼續(xù)看 main () 函數(shù)里調(diào)用的 pluma.load ()，其實調(diào)用的是其父類 PluginManager 的 load ()。相關(guān)代碼截選如下：

【pluma-1.1/src/pluma/PluginManager.cpp】

可以看到，一開始就在著手加載動態(tài)庫，并調(diào)用動態(tài)庫里的 connect () 函數(shù)。前文我們實際上已經(jīng)列舉過示例代碼里的 connect () 函數(shù)了，現(xiàn)在再貼一次：

前文在闡述到 connect () 時，暫時沒有細(xì)說 add () 動作，現(xiàn)在我們來看看它的代碼：

【pluma-1.1/src/pluma/Host.cpp】

上面代碼中那個 plumaGetType () 函數(shù)其實是 Provider 的私有成員，一般人訪問不了，但 Host 是它的友元類，所以可以訪問。代碼中會先校驗待添加的 Provider 是否合格，如果合格則以 plumaGetType () 返回值為 key 值，并向臨時映射表 addRequests 中添加該 Provider 指針。所謂合格是指，這個 Provider 的類型是 Host 感興趣的，并且其版本號也是合適的。

值得注意的是，待添加的 Provider*，只是臨時先放進(jìn)一個 addRequests 映射表中。addRequests 映射表的定義如下：

【pluma-1.1/include/pluma/Host.hpp】

那么這個臨時性的 addRequests 映射表的內(nèi)容會怎樣處理呢？說起來也簡單，會被 “搬移” 進(jìn) Host 的 knownTypes 映射表中某個 ProviderInfo 的內(nèi)部列表去。main () 在調(diào)用完 connect () 函數(shù)后，調(diào)用的 confirmAddictions () 就是做這個事情的：

【pluma-1.1/src/pluma/Host.cpp】

我們畫一張調(diào)用關(guān)系圖看看：


??

我們可以通過這張調(diào)用關(guān)系圖回顧一下，主要流程就是在加載插件動態(tài)庫，并執(zhí)行動態(tài)庫里的 connect () 函數(shù)。該函數(shù)會將動態(tài)庫里可用的所有 Provider * 記入 Host 的 knownTypes 映射表中。

同時，動態(tài)庫對應(yīng)的 DLibrary 對象，也會插入 Pluma 管理類內(nèi)部的 libraries 映射表中。

為了鞏固知識，我們把前文的兩張圖再整合一下。

5. 使用插件 Provider

5.1 pluma.getProviders()

在 Providers 都添加進(jìn) Pluma 管理類后，我們就可以在需要時獲取 provider 了，為此 Pluma 類提供了 getProviders () 函數(shù)：

【pluma-1.1/src/pluma/PluginManager.cpp】

【pluma-1.1/src/pluma/Host.cpp】

代碼很簡單，就是幫使用者把感興趣的某類插件 Provider 全部找出來。如果當(dāng)初我們已經(jīng)通過 acceptProviderType () 注冊了對應(yīng)的類型（PLUMA_PROVIDER_TYPE），那么至少可以拿到一個 list，否則就只能拿到 NULL 了。如果我們可以拿到若干 Provider，就可以調(diào)用其 create () 函數(shù)創(chuàng)建對應(yīng)的插件對象了。

當(dāng)工作做完后，用戶應(yīng)該及時 delete 掉之前創(chuàng)建出的插件對象。在程序退出之前，用戶應(yīng)該調(diào)用 pluma.unloadAll () 刪除所有插件 Provider 及 DLibrary 對象。DLibrary 對象析構(gòu)時，會自動關(guān)閉已經(jīng)打開的動態(tài)鏈接庫。

【pluma-1.1/src/pluma/PluginManager.cpp】

6. 結(jié)束

至此，Pluma 架構(gòu)的主體代碼就分析完畢了，希望對大家有所幫助。

?

審核編輯：劉清