近距離觀察小程式的一把尖刀：外掛

摘要： 簡單介紹一下小程式的外掛 外掛？納尼？npm包麼？ 未接觸過小程式的外掛時，以為它與 npm 包類似，我們可以封裝各種各樣便捷的功能，提供給他人使用。 經過這幾天接觸，竟有了追攀更覺相逢晚的趕腳，發現小程式的外掛真真是個好東西。同時，也發現它與傳統意義上的外掛還是有很大差別的。...

簡單介紹一下小程式的外掛

外掛？納尼？npm包麼？

未接觸過小程式的外掛時，以為它與 npm 包類似，我們可以封裝各種各樣便捷的功能，提供給他人使用。

經過這幾天接觸，竟有了追攀更覺相逢晚的趕腳，發現小程式的外掛真真是個好東西。同時，也發現它與傳統意義上的外掛還是有很大差別的。小程式的外掛， 在一定程度上我們可以理解為是一個微服務。

微信小程式的外掛功能更偏向於一個具體的行業服務，例如快遞行業，如果我們有相關介面，我們可以開發一個快遞查詢外掛，這樣的話，一些電商服務的小程式或者其它對快遞查詢有需求的小程式就都可以接入我們的外掛了。

官網中對小程式外掛這樣介紹

外掛，是可被新增到小程式內直接使用的功能元件。開發者可以像開發小程式一樣開發一個外掛，供其他小程式使用。同時，小程式開發者可直接在小程式內使用外掛，無需重複開發，為使用者提供更豐富的服務。

小程式開發者可便捷地把外掛新增到自己的小程式內，豐富小程式的服務。當用戶在使用小程式時，將可以在小程式內使用外掛提供的服務。

外掛是對一組 js 介面、自定義元件或頁面的封裝，用於嵌入到小程式中使用。外掛不能獨立執行，必須嵌入在其他小程式中才能被使用者使用；而第三方小程式在使用外掛時，也無法看到外掛的程式碼。因此，外掛適合用來封裝自己的功能或服務，提供給第三方小程式進行展示和使用。

外掛開發者可以像開發小程式一樣編寫一個外掛並上傳程式碼，在外掛釋出之後，其他小程式方可呼叫。小程式平臺會託管外掛程式碼，其他小程式呼叫時，上傳的外掛程式碼會隨小程式一起下載執行。

相對於普通 js 檔案或自定義元件，外掛擁有更強的獨立性，擁有獨立的 API 介面、域名列表等，但同時會受到一些限制，如一些 API 無法呼叫或功能受限。對於一些特殊的介面，如 wx.login 和 wx.requestPayment ，雖然外掛不能直接呼叫，但可以使用 外掛功能頁 來間接實現。

有沒有好強大好邪惡的感覺～

外掛的使用

新增外掛

• 外掛的開發和使用自小程式基礎庫版本 1.9.6 開始支援。

• 每個小程式，最多可以新增5個外掛

• 在使用外掛前，首先要在小程式管理後臺的“設定-第三方服務-外掛管理”中新增外掛。開發者可登入小程式管理後臺，通過 appid 查詢外掛並新增。如果外掛無需申請，新增後可直接使用；否則需要等待外掛所有者同意申請後，方可在小程式中使用相應的外掛。

引入外掛程式碼包

使用外掛前，使用者要在 app.json 中宣告需要使用的外掛

{
"plugins": {
"myPlugin": {
"version": "1.0.0",
"provider": "wxidxxxxxxx"
}}}

如上例所示， plugins 定義段中可以包含多個外掛宣告，每個外掛宣告以一個使用者自定義的外掛引用名作為標識，並指明外掛的 appid 和需要使用的版本號。其中，引用名（如上例中的 myPlugin）由使用者自定義，無需和外掛開發者保持一致或與開發者協調。在後續的外掛使用中，該引用名將被用於表示該外掛。

使用外掛中的自定義元件

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

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

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

• 預設情況下，頁面中的 this.selectComponent 介面無法獲得外掛的自定義元件例項物件；

• wx.createSelectorQuery 等介面的 >>> 選擇器無法選入外掛內部。

• 使用外掛的頁面

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

• 外掛的頁面從小程式基礎庫版本 2.1.0 開始支援。

• 需要跳轉到外掛頁面時，url 使用 plugin:// 字首，形如 plugin://PLUGIN_NAME/PAGE , 如：

• 外掛js介面呼叫

  var myPluginInterface = requirePlugin('myPlugin');
  
  myPluginInterface.hello(); 
  var myWorld = myPluginInterface.world;

• 以上就是如何使用外掛了，是不是很簡單呢。不要以為開發一個外掛會有多難，那僅僅比使用起來，難了那麼一點點。

  

• 使用外掛的 js 介面時，可以使用 requirePlugin 方法。例如，外掛提供一個名為 hello 的方法和一個名為 world 的變數，則可以像下面這樣呼叫：

外掛的開發

開放範圍：

• 企業、媒體、政府及其他組織主體。

建立外掛專案

• 略。(官網相關介紹還是很棒的，此處就不多做贅述勉填篇幅了，多聊點有用的東西吧)

按照官網的步驟新建外掛專案，你會得到這樣一個目錄結構：

三個資料夾分別是doc、miniprogram、plugin和一個project.config.json檔案。

• doc ：這份開發文件將展示在外掛詳情頁，供其他開發者在瀏覽外掛和使用外掛時進行閱讀和參考。官網有提到。

• miniprogram ： 外掛是用在小程式上的，那開發的時候該如何測試呢。不用擔心，人家小程式團隊肯定會想到並給予相應的解決方法的。這不，miniprogram就是做這個用的。你可以把它看成是一個簡單的小程式，專門供本地測試外掛使用。

• plugin ：如你所想，這就是主角了。我們的外掛。

• project.config.json : 專案配置檔案。需要關注 compileType 欄位，compileType == ‘plugin’ 時才能正常的使用外掛專案。

用官方話講就是這樣的：

其中miniprogram 資料夾是一個普通小程式專案，用來編寫小程式外掛的使用 Demo，上傳外掛程式碼時這個 Demo 會一起上傳，並作為小程式外掛的釋出的稽核依據。

下面將重點介紹一下plugin檔案。

• 配置檔案plugin.json

  {
  "publicComponents": {
  "hello-component": "components/hello-component"
  },
  "pages": {
  "hello-page": "pages/hello-page"
  },
  "main": "index.js"}

• 這個配置檔案將向第三方小程式開放一個自定義元件 hello-component，一個頁面 hello-page 和 index.js 下匯出的所有 js 介面。

• 假設有這樣的一個場景，外掛內的某個頁面A，只能通過外掛的頁面B訪問，其他方式無法訪問，那麼是否在plugin.json內配置頁面B就可以，無需配置A頁面呢。答案是否定的，雖然在開發者工具中可以使用相對路徑來跳轉，但在真機上是無法實現的。所以我想說的是，外掛中的頁面，想要正常展示，必須在plugin.json檔案中註明。

• 向第三方小程式開放的所有自定義元件、頁面和 js 介面都必須在外掛配置檔案 plugin.json 列出，格式如下：

• 外掛呼叫API的限制

• 上文提到plugin目錄下的index.js檔案是匯出所有js介面的檔案。但外掛外掛可以呼叫的 API 與小程式不同，主要有兩個區別：

  1.外掛的請求域名列表與小程式相互獨立

  2.一些 API 不允許外掛呼叫（這些函式不存在於 wx 物件下外掛的自定義元件

• 外掛可以定義若干個自定義元件，這些自定義元件都可以在外掛內相互引用。但提供給第三方小程式使用的自定義元件必須在配置檔案中列出。

• 外掛的頁面元件

• 外掛從小程式基礎庫版本 2.1.0 開始支援頁面。外掛可以定義若干個外掛頁面，可以從本外掛的自定義元件、其他頁面中跳轉，或從第三方小程式中跳轉。其中，提供給第三方小程式跳轉的頁面必須在配置檔案中列出。

• 自基礎庫版本 2.2.2 開始，在外掛自身的頁面中，外掛還可以呼叫 wx.navigateTo 來進行頁面跳轉， url 格式與使用 navigator 元件時相仿。

• 外掛的介面

• 外掛可以在介面檔案（在配置檔案中指定，這裡是index.js檔案）中 export 一些 js 介面，供使用外掛的第三方小程式呼叫。

• 預覽、上傳和釋出

• 外掛可以像小程式一樣預覽和上傳，但外掛沒有體驗版。

• 外掛會同時有多個線上版本，由使用外掛的小程式決定具體使用的版本號。

• 手機預覽和提審外掛時，會使用一個特殊的小程式來套用專案中 miniprogram 資料夾下的小程式，從而預覽外掛。

• （建議的方式）如果當前開發者有測試號，則會使用這個測試號；在測試號的設定頁中可以看到測試號的 appid 、 appsecret 並設定域名列表。

• 否則，將使用“外掛開發助手”，它具有一個特定的 appid 。

• other

• 外掛在使用 wx.request 等 API 傳送網路請求時，將會額外攜帶一個簽名 HostSign ，用於驗證請求來源於小程式外掛。這個簽名位於請求頭中，形如：

  X-WECHAT-HOSTSIGN : {
  "noncestr": "NONCESTR",
  "timestamp": "TIMESTAMP",
  "signature": "SIGNATURE"
  }

外掛的未來

筆者認為首先外掛應該有獨立的功能，例如之前提到的快遞查詢，其次，外掛有很大一部分會被使用者資訊制約，所以，筆者認為外掛的功能也應該跟使用者是弱相關的。一個小程式現在是支援5個外掛的，在使用第三方的外掛的時候需要申請，只有對方通過後才能使用。綜上，外掛其實更適合獨立的小功能的場景，與主小程式也是獨立運營和管理的狀態。（祖哥，為啥要用筆者啊，我覺得這個“筆者”，額～，略顯風騷啊）

外掛總體上有兩大優勢：

1.通用性：在開發者處理和開發小程式特有的功能時，其他通用功能，可以直接拿別人的優秀外掛，接入自己的小程式，從而完善小程式的功能。而且，小程式的外掛是通用的，任何想用的企業都能申請使用。對於開發者而言，更是方便至極。

2.節約開發成本：對於開發者而言，外掛功能的出現，能縮短小程式開發週期，節約研發成本，給小程式開發人員帶來更多 的靈活性。小程式外掛功能可以說是為了降低開發者難度，減少開發週期。

那麼說起對外掛的未來，必定是瑕瑜互見的。極端點說，外掛發展到某一天，想要完成一個小程式，只需要找一些合適的外掛，拼裝一下就是一個小程式了。也是因為這樣，肯定會有許多低端開發者開發出大量質量粗糙的小程式版本出來。當然這是極端的說法，一個優秀的小程式，必定含有自己定製的內容，總的來說，外掛的出現是一個多方共贏的事情。外掛對於開發者來說，可以通過自己的技能+創意，實現一部分的變現；對於服務商來說，不用重複造輪子，可以用更少的費用、更少的時間做出更好的東西；對於微信來說，可以完善整個生態鏈，讓更多的開發者、創業者、服務者齊聚到小程式平臺，併為他們提供更好的服務和幫助。

其他

• 外掛大小限制和小程式本身一樣。但外掛使用方計算程式碼包大小時會合並計入引用的外掛大小。因此還是應該儘量小。 ——來自網路：小程式開發者回覆

• 小程式的 AppID 可以建立小程式外掛專案，外掛是獨立於小程式之外的，但是 AppID 是公用的，所以不要使用原有的小程式專案進行外掛開發；

• 外掛對標一個微服務，開發外掛必須有 appid，所以，一個小程式對應只能開發一個外掛；

• 開通外掛時的外掛名稱和頭像確定後是不允許修改的；會感覺外掛貌似就是一個更小的小程式~~

• 目前沒有外掛可供搜尋的地方，期待微信的外掛商城的出現；

• 外掛釋出需要通過微信稽核，而且貌似稽核更加嚴格，而且外掛支援多個線上版本的同時存在；

• 外掛的使用需要申請，外掛開發者同意後，使用方可以接入使用外掛。這裡多提一句，有一些外掛的作者並未設定使用許可權，自然使用者申請後就直接可以用了，否則在外掛列表裡會看到類似稽核中的字樣。

• 開發外掛時，在開發者工具中看似正常執行的程式碼，跑在真機上也許就會給你一個驚喜。

• 以上就是本文的全部內容了。目前尚未在實踐中使用小程式外掛，僅僅是後續工作有相關需要，算是技術儲備，估計如果真的在開發中使用，依舊會有不少坑要踩。古語有云，沒有過不去的坎，只有過不完的坎。。。

• 對本文的內容有異議，或對文中的疑問有新的思路，歡迎留言。