山東標梵小程序開發之分享小程序

對於一個產品來講，分享的重要性不言而喻。
前言
小程序的頂部有一個膠囊按鈕，點擊第一個按鈕便會在屏幕下方彈出菜單列表，其中變包含了分享相關的操做，以下圖所示：

null

當咱們建立一個小程序工程以後運行，進行如上操做以後會發現，此時底部菜單中的分享功能是被禁用的。

1、啓用分享功能
旁邊的掃地大爺微笑道：小朋友，這問題好解決，只要傳遞給Page的Object對象中提供了onShareAppMessage方法，那麼運行當前頁面即可點擊右上角菜單按鈕進行分享，而且若是要支持分享到朋友圈的話，只須要提供onShareTimeline方法便可！

Page({

//定義此方法以後，點擊右上角按鈕彈出的菜單中"發送給朋友"菜單變爲可點擊
onShareAppMessage: function (param) {

  },

//定義此方法以後，點擊右上角按鈕彈出的菜單中"分享到朋友圈"按鈕變爲可點擊
onShareTimeline:function(){

  }

})
這問題確實很簡單，連掃地的大爺都會，不過說的對也不全對，但總感受這大爺深藏不露，得好生招呼。

「哇塞，大爺您真棒，一看您就是深藏功與名，您能多說一點分享功能方面的嗎？」

「小夥子，看你人不錯，挺好學的，大爺我就多跟你嘮嗑幾句。」

一、發送給朋友（分享）
官方資料[1]

只有定義了onShareAppMessage處理函數，右上角菜單纔會顯示「轉發（發送給朋友）」按鈕

該函數接收一個Object對象參數,關於參數字段的介紹以下表：字段名 | 類型 | 說明 | |------|------------|------------| | from | String | 轉發事件來源。button：頁面內轉發按鈕；menu：右上角轉發菜單 | | target | Object | 若是 from 值是 button，則 target 是觸發此次轉發事件的 button，不然爲 undefined | | webViewUrl | String | 面中包含web-view組件時，返回當前web-view的url |

從from和target兩個字段中咱們能夠看到，除了經過右上角膠囊菜單入口處進行分享外，咱們還能夠經過頁面內的button進行分享操做。

能夠經過該事件處理函數返回一個對象，用於描述自定義的分享內容，從基礎庫2.8.1版本開始，分享圖片支持雲圖片；

關於返回的對象介紹以下表 字段名 | 說明 | 默認值 | |------|------------|------------| | title | 轉發標題 | 當前小程序名稱 | | path | 轉發路徑 | 當前頁面 path ，必須是以 / 開頭的完整路徑 | | imageUrl | 自定義圖片路徑，能夠是本地文件路徑、代碼包文件路徑或者網絡圖片路徑。支持PNG及JPG。顯示圖片長寬比是 5:4。| 使用默認截圖 |

如下示例代碼自定義了分享內容的標題和點擊以後打開的路徑：

`Page({
onShareAppMessage: function (res) {

if (res.from === 'button') {
  // 來自頁面內轉發按鈕
  console.log(res.target)
}
return {
  title: '自定義分享標題',
  path: '/page/user?id=123'
}

}
})`

運行截圖：

null

其中紅色框爲指定的自定義標題，藍色框封面圖因爲咱們沒有指定分享的圖片路徑，所以會根據當前界面進行截圖做爲分享內容的封面圖。

關於默認截圖:不自定義轉發圖片的狀況下，默認會取當前頁面，從頂部開始，高度爲 80% 屏幕寬度的圖像做爲轉發圖片。

二、分享到朋友圈
官方資料[2]

只有定義了onShareTimeline處理函數，右上角菜單纔會顯示「分享到朋友圈」按鈕

基礎庫2.11.3開始支持；Beta版本，暫只在Android平臺支持;

注意：若是要支持分享到朋友圈，則必須同時提供onShareAppMessage事件處理函數的定義，不然此功能無效。

能夠經過該事件處理函數返回一個對象，用於描述自定義的分享內容，不支持自定義頁面路徑，返回內容以下: 字段名 | 說明 | 默認值 | |------|------------|------------| | title | 轉發標題 | 當前小程序名稱 | | query | 自定義頁面路徑中攜帶的參數，如 path?a=1&b=2 的 「?」 後面部分 | 當前頁面路徑攜帶的參數 | | imageUrl | 自定義圖片路徑，能夠是本地文件或者網絡圖片。支持 PNG 及 JPG，顯示圖片長寬比是 1:1。| 默認使用小程序 Logo |

三、頁面內分享
官方介紹[3]

基礎庫 1.2.0 開始支持,經過給button組件設置屬性open-type="share"，能夠在用戶點擊按鈕後觸發Page.onShareAppMessage事件獲取自定義分享內容進行轉發。

示例代碼：

//index.wxml
<button open-type="share">點擊進行分享</button>
注意：

•只能使用button組件，而不能是其餘組件。
•經測試在Page中未提供onShareAppMessage事件也能執行頁面內轉發。
•只支持分享朋友而不容許分享到朋友圈

裝逼知識補充：小遊戲是沒有頁面的概念的，因此分享的時候大可能是分享不一樣的query參數而非路徑地址。

2、動態分享
前面使用分享的方式比較固化，也就是要嘛在頁面中定義好分享事件處理方法，要嘛經過指定的按鈕實現指定的分享行爲，沒法更靈活的處理一些場景；好比以下場景：

一、 某個界面A用戶能夠分享給朋友，B用戶能夠分享給朋友和分享到朋友圈

二、用戶須要達到必定條件以後纔可啓用分享特定內容（好比與用戶推廣業績掛勾的分享內容，好比用戶達到條件以後，當前界面分享出去的內容就是當前用戶綁定的分享海報，經過海報增加的用戶會給對應的用戶增長業績，而若是用戶沒有達到條件時，只是分享出去的是普通內容或者是不能分享）

三、分享動態內容：官方地址[4]

固然，以上場景爲杜撰，只是想表達分享的靈活性的需求，那麼若是真的有上述需求，有沒有辦法能夠實現呢？

答案是有的，只是我沒摸透，實際運行結果與我所猜想的結果產生了分歧，而且模擬器上運行的效果與真機預覽的效果也產生了差別，所以不敢妄自揣測這部份內容，因此只是作個記錄，待後面進一步理解，若是有對這一部分了解的朋友，也但願不吝賜教。

API官方地址[5]

3、分享內容的圖片解決方案探究
咱們先看一下以前我那個界面的分享內容：

null

這是一個沒有靈魂的分享，封面是整個分享內容的靈魂所在，分享內容在沒有設置自定義圖片路徑時，會採用頁面的默認截圖做爲封面，因此咱們頁面內容的好看與否，直接影響最終的默認截圖效果，可是即使當前的界面設計的再好看，做爲分享內容的封面圖也不必定恰當。

官方支持將分享圖片設置成網路圖片地址，那麼這一問題在某些層面上來說也獲得了很好的解決，可是是提供固定的雲端圖片地址，仍是提供專門用於分享封面的雲端服務，亦或者其餘方案，畢竟每一種封面圖方案都有其存在價值。

如今看來關於分享的圖片來源就兩個途徑，要嘛小程序內部解決，要嘛經過服務端提供分享的圖片來源；

一、本地方案
即不依賴服務器解決分享內容封面圖問題；

•默認截圖方案 即分享時不提供自定義圖片地址，默認會取當前頁面，從頂部開始，高度爲 80% 屏幕寬度的圖像做爲轉發圖片。此方案的弊端因爲是根據頁面內容進行生成，沒法進行定製化，比較適合對分享沒什麼要求或者頁面內容比較符合分享的內容場景。
•本地圖片方案 即便用本地文件路徑、代碼包文件路徑做爲分享的圖片地址，此方法的弊端在於沒法動態更新，只能提供有限的分享圖片資源，而且還會增長小程序體積。對於分享場景比較固化的自定義圖片場景比較適合。
•本地動態生成分享圖的方案 即本地生成所須要的分享圖片進行分享，也就是使用canvas繪圖並生成所需分享的圖片，此方案可以解決內容動態展現的問題，缺點就是技術要求高一些，而且也要解決生成的模板多樣性問題，不過此方案可以應對絕大部分場景，因此重點在於研究這個方案。

二、雲端方案
•雲端固定圖片地址 即服務器提供分享所需圖片內容地址，此方案相比於本地圖片方案來說更爲靈活，能夠更新分享的圖片源從而提供分享時更多的樣式。但此方案的缺點就是沒法對內容進行動態生成，即後端提供的是固定圖片地址，此方案比較適合固化分享場景，又略微會進行圖片更新的場景，好比中秋節提供的是與中秋節主題相關的圖片地址，春節提供的是春節相關的圖片地址，而若是是小程序本地圖片方案的話，要實現此效果就必須進行升級。
•雲端動態內容支持 即後端動態生成所需內容返回給前端使用，此方案理論上是可行的，畢竟有條件的公司徹底能夠建立獨立的多媒體庫支持，可是對服務端的開發人員和服務器的要求都頗高。

4、動態分享內容生成解決方案
在找這方面的輪子的時候，找到以下一些方案（具體還未進一步研究，整理本文內容已耗費不少時間）：

一、wxml-to-canvas
此方按是官方提供的方案（官方介紹[6]）

小程序內經過靜態模板和樣式繪製 canvas ，導出圖片，可用於生成分享圖等場景。

支持view、text、image三種標籤，經過class匹配style對象中的樣式。

雖然有人詬病說此方案支持的標籤種類太少，可是其實對於一個分享圖來講，組成的元素不外乎就是文本和圖片，因此理論上此方案已足夠應對大部分場景。至因而否有其餘什麼坑，還未探，不敢瞎說，後續會專門研究。

二、開源方案Painter
Github[7]

因爲掛載在github page上，打開速度會慢一些，請耐心等待或自行解決git網速問題。

若是嫌棄打開太慢，能夠先查看下微信小程序社區裏面的介紹地址[8]

聽說還有基於此方案的可視化海報生成方案;介紹地址[9],至於好用很差用，我還未體驗過。

社區有人介紹了用此方案實現的案例，想要學習的能夠參考一下;連接地址[10]。

三、第三方服務-快海報
實在懶得折騰的，花點錢使用第三方服務便可，聽說不貴，比本身搭建服務器來的划算。 附上官網地址，自行了解[11]

以上三種方案是目前關注的方案，其實方案到底是怎麼實現的我目前還不清楚，鑑於已經花去比較多的時間作這方面的瞭解，目前只想先儘快結束目前階段，調整一下，後續進一步作深刻研究。
文章編輯:Biaofun標梵互動