小程式插件其實很簡單

插件，英文名可稱作“Plug-in、Plugin、add-in、addin、add-on、addon或extension”，是一個依附于主程式的輔助程式，透過和主程式的互動，用來代替主程式需要增加一些所需的特定功能。

更通俗的來講，就類似機器的零件，可以“插入”的形式添加到程式内使用，進而獲得一種特殊的能力，多個插件可以共用，最終開發程式像搭積木般友善。

插件本身的技術原理并不複雜。插件代碼由一些自定義元件和 JS 代碼檔案構成，插件開發者在釋出插件時，這些代碼被上傳到微信背景儲存起來。

當小程式使用插件時，使用者需填寫插件的 AppID 和版本号，以便從背景擷取相應的插件代碼。小程式代碼編譯時，插件代碼會被嵌入到小程式中，與小程式一起編譯運作。

插件是一種獨立封裝的軟體子產品，用來承載企業的能力或者服務，便于宿主小程式進行快捷內建。和普通元件不同的是，插件擁有獨立的應用和獨立的上下文，即資料、業務邏輯和服務端連接配接。當小程式應用需要使用插件的服務時，加載和運作插件，以使得插件通路自身的資料與服務端，完成對應的服務；而在小程式不需要使用插件的服務時，隻需要運作小程式應用本身，通路小程式應用自身的資料服務端。插件和宿主小程式上下文是互相隔離的，即小程式應用不能直接通路插件的資料，也不能獲得插件的權限，反之，插件也不能直接通路小程式的資料，也不能獲得小程式的權限。

另外插件非常靈活：

• 可以包含多個頁面，供宿主小程式跳轉。
• 可以向宿主小程式暴露多個接口，供宿主小程式調用
• 可以包含多個元件，供宿主小程式進行嵌入。

插件的這種特性，使得插件相比普通元件具備以下優勢：

• 由于插件具有獨立的應用，插件可以獨立進行發版，開發和更新更高效。
• 插件支援商業訂購和結算，便于開發者進行服務變現和商業化。
• 由于插件是獨立封裝的業務功能和服務，宿主小程式內建和使用插件更為便捷。
• 由于插件運作時架構提供上下文隔離機制，插件内部的資料安全性更有保障。

二、小程式插件情況介紹

1、希望小程式插件解決的問題

而随着小程式的普及，越來越多的路邊小攤、餐飲小店、夫妻店也希望接入小程式，許多商家會反映亟待解決的問題：

我隻會簡單開發，不會做複雜的功能怎麼辦？

我也想給餐館小程式做一個預約訂餐功能，要怎麼搞？

客戶可以在我的小程式裡查詢快遞資訊嗎？

我沒有資料，可以在小程式裡做地圖查找功能嗎？

……

總結小程式生态中遇到的三大難題：

開發技術有限，實作複雜功能難度大；

人力、裝置、資源有限，實作服務成本高；

缺乏某些類目的資質，如電商、打車。

而以上問題正好都可以通過小程式插件進行解決。

再通過“知曉程式”對218名使用者進行的線上調研結果可以看到：

想要開發插件為業務類型（包括視訊、音頻等）的報名者占總人數的 4.37%。

想要開發插件為公共接口類型（包括天氣、地理位置等）的報名者占總人數的 10.68%。

想要開發插件為封裝類型（包括圖像處理、留言、客服、營銷類等）的報名者占總人數的 22.33%。

想要開發插件為電商類型（包括購物券、抽獎等）的報名者占總人數的 8.74%。

想要開發插件為底層類型（包括搜尋、掃碼、登入、評論、支付等）的報名者占總人數的 11.65%。

想要開發插件為工具類型的報名者占總人數的 11.65%。

暫時不太明确開發類型的報名者占總人數的 4.37%。

從調研結果中也發現，大家希望小程式插件幫助解決的問題如下：

• 有技術開發背景的，都希望有封裝功能（UI 優化以及架構元件），以及能優化開發效率的插件早些出現；
• 選電商類的，都急切需要更多的抽獎、大轉盤等營銷插件、資料處理插件；
• 選擇底層類型，都是抱怨微信小程式某些功能不好用，希望有更好的解決方案插件出現；
• 暫時不太明确的人，大部分都不懂技術，但希望能直接獲得小程式模闆，實作獲利

2、市面中小程式插件種類

進一步對微信小程式及支付寶小程式插件市場中的插件進行統計分析，微信小程式插件市場内插件數量175個，支付寶小程式插件市場内插件數量115個，這些小程式插件大緻可以分為工具、營銷互動、城市服務、教育、餐飲、購物等幾大類别。

這些插件通過小程式調用的形式，用于包括政務大廳、資訊查詢、智能家居、團購、社交直播等上百個服務場景中。

以旅遊景區小程式為例，在旅遊景區的小程式可以使用地圖插件，開發者無需在小程式内獨立開發地圖内導航、出行指引、周邊服務推薦等能力，直接使用地圖插件即可為使用者提供導航服務。使用門票購買插件，使用者可在小程式内完成門票線上預訂、購買等流程，在到達景區後，通過插件服務提供商提供的移動終端或硬體裝置，可完成門票兌換、核銷。

而對于餐飲、零售等線下行業而言，插件更是極大降低了商家的成本，商家可以使用預訂、排隊、外賣等插件，由插件開發者提供線下服務，商家隻需在小程式内引用插件，即可使用由插件開發者提供的預訂、外賣等服務，節省了成本。

三、如何開發引入小程式插件

1、小程式插件開發

一般來講各個小程式開放平台對于插件開發的開放範圍有一定的限制，例如微信小程式平台開放了22個行業相關的插件開發，其中對醫療服務、金融業、文娛、社交等行業還有進一步的特殊限制。

在了解小程式插件的開發規範後，如何以正确的方式開始小程式插件的開發呢？其實各大平台都出了響應的開發工具和開發指南。

我們同樣以微信和支付寶為例，使用微信開發者工具和支付寶IDE工具即可高效率的完成一個小程式插件的建立和開發，具體的開發指南可通路：

微信小程式插件開發：​​https://developers.weixin.qq.com/miniprogram/dev/devtools/plugin.html​​

支付寶小程式插件開發：​​https://opendocs.alipay.com/mini/plugin/plugin-development​​

2、小程式插件引入

對于更多的使用者我們可能需要對插件進行引入，如何在小程式中引入插件呢？這裡我們以​​FinClip​​ 小程式為例進行實踐。

開發者可在小程式代碼中引入插件代碼的聲明，然後在使用 FIDE 開發工具進行編譯時， FIDE 會從服務端擷取插件代碼一起進行打包編譯。

請注意

插件功能需要在基礎庫版本≥2.11.1，SDK版本≥2.34.0的環境下才可使用

2.1 添加插件

在使用插件前，開發者可登入「小程式開放平台-小程式管理-小程式插件」，通過插件 ID 查找插件并添加。

2.2 引入插件代碼包

使用插件前，使用者要在 app.json 中聲明需要使用的插件，例如：

代碼示例

{
  "plugins": {
    "myPlugin": {
      "version": "1.0.0",
      "provider": "插件 id"
    }
  }
}      

如上例所示， plugins 定義段中可以包含多個插件聲明，每個插件聲明以一個使用者自定義的插件引用名作為辨別，并指明插件的 ID 和需要使用的版本号。

其中，引用名（如上例中的 myPlugin）由使用者自定義，無需和插件開發者保持一緻或與開發者協調。在後續的插件使用中，該引用名将被用于表示該插件。

2.3 在分包内引入插件代碼包

如果插件隻在一個分包内用到，可以将插件僅放在這個分包内，例如：

{
  "subpackages": [
    {
      "root": "packageA",
      "pages": [
        "pages/cat",
        "pages/dog"
      ],
      "plugins": {
        "myPlugin": {
          "version": "1.0.0",
          "provider": "插件 id"
        }
      }
    }
  ]
}      

在分包内使用插件有如下限制：

• 僅能在這個分包内使用該插件；
• 同一個插件不能被多個分包同時引用；

2.4 使用插件

使用插件時，插件的代碼對于使用者來說是不可見的。為了正确使用插件，使用者應檢視插件詳情頁面中的“開發文檔”一節，閱讀由插件開發者提供的插件開發文檔，通過文檔來明确插件提供的自定義元件、頁面名稱及提供的 js 接口規範等。

2.5 自定義元件

使用插件提供的自定義元件，和 使用普通自定義元件 的方式相仿。在 json 檔案定義需要引入的自定義元件時，使用 plugin:// 協定指明插件的引用名和自定義元件名，例如：

代碼示例

{
  "usingComponents": {
    "hello-component": "plugin://myPlugin/hello-component"
  }
}      

出于對插件的保護，插件提供的自定義元件在使用上有一定的限制：

• 預設情況下，頁面中的 this.selectComponent 接口無法獲得插件的自定義元件執行個體對象；
• ft.createSelectorQuery 等接口的 >>> 選擇器無法選入插件内部。

2.6 頁面

需要跳轉到插件頁面時，url 使用 plugin:// 字首，形如 ​​plugin://PLUGIN_NAME/PLUGIN_PAGE，​​ 如：

代碼示例

<navigator url="plugin://myPlugin/hello-page">
  Go to pages/hello-page!
</navigator>      

2.7 js 接口

使用插件的 js 接口時，可以使用 requirePlugin 方法。例如，插件提供一個名為 hello 的方法和一個名為 world 的變量，則可以像下面這樣調用：

var myPluginInterface = requirePlugin('myPlugin');

myPluginInterface.hello();
var myWorld = myPluginInterface.world;      

也可以通過插件的 id 來擷取接口，如：

var myPluginInterface = requirePlugin('插件 id');      

2.8 導出到插件

使用插件的小程式可以導出一些内容，供插件擷取。具體來說，在聲明使用插件時，可以通過 export 字段來指定一個檔案，如：

{
  "myPlugin": {
    "version": "1.0.0",
    "provider": "插件 id",
    "export": "index.js"
  }
}      

則該檔案（上面的例子裡是 index.js）導出的内容可以被這個插件用全局函數獲得。例如，在上面的檔案中，使用插件的小程式做了如下導出：

// index.js
module.exports = { whoami: 'MiniProgram' }      

那麼插件就可以獲得上面導出的内容：

// plugin
requireMiniProgram().whoami // 'MiniProgram'      

具體導出什麼内容，可以閱讀插件開發文檔，和插件的開發者做好約定。

當插件在分包中時，這個特性也可以使用，但指定的檔案的路徑是相對于分包的。例如在 root: packageA 的分包中指定了 export: exports/plugin.js，那麼被指定的檔案在檔案系統上應該是 /packageA/exports/plugin.js。

使用的多個插件的導出互不影響，兩個插件可以導出同一個檔案，也可以是不同的檔案。但導出同一個檔案時，如果一個插件對導出内容做了修改，那麼另一個插件也會被影響，請注意這一點。

2.9 為插件提供自定義元件

有時，插件可能會在頁面或者自定義元件中，将一部分區域交給使用的小程式來渲染，是以需要使用的小程式提供一個自定義元件。但由于插件中不能直接指定小程式的自定義元件路徑，是以需要通過為插件指定 抽象節點（generics） 的方式來提供。

如果是插件的自定義元件需要指定抽象節點實作，可以在引用時指定：

<!-- miniprogram/page/index.fxml -->
<plugin-view generic:mp-view="comp-from-miniprogram" />      

可以通過配置項為插件頁面指定抽象元件實作。例如，要給插件名為 plugin-index 的頁面中的抽象節點 mp-view 指定小程式的自定義元件 components/comp-from-miniprogram 作為實作的話：

{
  "myPlugin": {
    "provider": "插件 id",
    "version": "1.0.0",
    "genericsImplementation": {
      "plugin-index": {
        "mp-view": "components/comp-from-miniprogram"
      }
    }
  }
}