對於一個產品來講,分享的重要性不言而喻。
前言
小程序的頂部有一個膠囊按鈕,點擊第一個按鈕便會在屏幕下方彈出菜單列表,其中變包含了分享相關的操做,以下圖所示:前端
nullgit
當咱們建立一個小程序工程以後運行,進行如上操做以後會發現,此時底部菜單中的分享功能是被禁用的。github
1、啓用分享功能
旁邊的掃地大爺微笑道:小朋友,這問題好解決,只要傳遞給Page的Object對象中提供了onShareAppMessage方法,那麼運行當前頁面即可點擊右上角菜單按鈕進行分享,而且若是要支持分享到朋友圈的話,只須要提供onShareTimeline方法便可!web
Page({canvas
//定義此方法以後,點擊右上角按鈕彈出的菜單中"發送給朋友"菜單變爲可點擊 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標梵互動