本篇文章給大家介紹一下微信小程序云開發動態制作小程序碼的方法,希望對大家有所幫助!
一、前言
因為學業以及工作上的事情繁多,已經棄"耕"許久了。在這段時間里,學了很多東西,也做了大大小小將近10個項目,這個過程中,越發覺得記錄的重要性,所以才想著在忙碌之中,抽出時間來寫一下博客,記錄一下開發過程中的一些知識點。老生常談了,既是讓自己下次能夠回顧,也是希望能夠幫到有需要的人。
二、需求分析
在日常的微信小程序項目中,我們經常需要用到一些宣傳海報,邀請海報等功能,例如一個邀請好友的海報,生成之后讓用戶發朋友圈或者轉發好友邀請,那這時,我們就需要知道那些用戶是你邀請的,方便下發獎勵啥的。這都是很常見的需求。那該如何實現類似的需求呢?
三、思路分析
這些海報其實最關鍵的一個就是長按掃碼識別的帶參二維碼(小程序碼)。
通過查閱微信小程序開發文檔,我們可以知道,總的來說有兩種方式可以生成這種帶參二維碼(小程序碼),當這種帶參二維碼繪制在海報上時,就可以通過這個二維碼的參數來進行識別是哪個用戶生成的海報,當其他用戶掃碼進入小程序時就可將標識的id存進數據庫里,進而判斷到底是誰邀請的人了。
太久沒有碼字了,說得可能有點累贅。
總結一下:根據二維碼帶的參數來判斷是誰的海報,這個參數一定是能夠定位出來用戶的,一般來說,可以使用用戶的openid來作為這個標識參數。
舉個簡單的例子(云開發):
定義一個集合:user
有兩個用戶
U1
字段名 | 值 | 說明 |
---|---|---|
_id | 123456789 | 使用云數據庫自動生成的id即可,不用自己生成 |
_openid | 112233 | 插入數據時會自帶有,也是一個系統字段 |
superiorId | 445566 | 上級的openid字段 |
U2
字段名 | 值 | 說明 |
---|---|---|
_id | 987654321 | 使用云數據庫自動生成的id即可,不用自己生成 |
_openid | 556677 | 插入數據時會自帶有,也是一個系統字段 |
superiorId | 112233 | 上級的openid字段 |
上面的數據表中,很明顯,U2是掃了U1的二維碼(小程序碼)進來的,所以U2的superiorId字段的值是U1的openid
那么當我們需要統計U1邀請了多少人的時候,就可以通過查詢數據中有多少用戶的superiorId的值等于U1的openid即可。
四、兩大實現途徑
前面說到大致上有兩種方式可以實現這種需求,那么我們來分析一下這兩種實現方法各自的特點。方便我們在開發過程中選用適合的方法。
途徑一:小程序碼
微信對動態生成小程序碼提供了三種方式給我們,這里我只講云調用的方式,傳統服務器開發的,可根據文檔來操作,原理大致相同。
1、A接口: wxacode.createQRCode
2、C接口: wxacode.get
3、B接口: wxacode.getUnlimited
列個表格分析一下這三個接口,詳細的介紹可以點擊標題直達官文文檔查閱。
接口 | 生成數量限制 | 時效 | 攜帶參數長度 |
---|---|---|---|
接口A | AC接口加起來不超過10W | 長期 | 128字節 |
接口C | AC接口加起來不超過10W | 長期 | 128字節 |
接口B | 無限制 | 長期 | 32可見字符 |
可以看到,其實AC接口是一伙的,實際的使用方法也差不多,只是參數上會有所不同。
AC接口與B接口的區別在于生成的數量限制和攜帶參數的長度。所以在選用的時候,就要考慮這生成的數量和攜帶的參數長度這兩個條件了。
途徑二:普通二維碼
簡單對比完小程序碼的三個接口后,再來看看這普通二維碼的特點。如果是上面的三個接口都無法滿足業務需求,例如參數長、生成的數量還要特別多的場景,那可以試試通過這個普通二維碼的途徑實現。
這個二維碼跟接口相比,生成的數量無限制,參數理論可以很長(具體多長沒試過,但是肯定比128長),時效也是長期有效。這樣看來,似乎直接無論什么業務場景,直接選這種方式就對了?
當然不是,普通二維碼最少這兩個方面需要考慮。
一、開放范圍:企業、媒體、政府及其他組織類型小程序。 換句話說,就是不支持個人開發者賬號開通使用。
二、開發起來相對來說比較復雜,需要用到服務器和域名來進行配置。會踩不少坑。
由于這個這種途徑實現有點復雜,所以在這里不啰嗦了,有這方面需求的朋友可以私信我交流,互相學習。
還有最后一個需要注意的是:無論哪種途徑實現,小程序都必須在發布后才可以正常掃碼使用。
五、AC接口實現代碼示例(云開發)
B接口與AC接口使用起來差不多,可以直接去官網看代碼示例。應該是可以觸類旁通的。所以這里我只用一下AC其中一個接口。主要還是引出一些常見問題。
1、新建云函數后,在config.json文件中配置權限(以createQRCode例)
2、index.js代碼
const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV, }) exports.main = async (event) => { try { const result = await cloud.openapi.wxacode.createQRCode({ path: event.path, width: event.width }) return result } catch (err) { return err } }
3、調用(如果不是本地調試,記得提交云函數)
if (posterType == 1) { // 配置頁面路徑以及參數 path = "pages/indexStudent1/indexStudent1?superiorId1=" + superiorId1 + "&superiorId2=" + superiorId2 } else if (posterType == 2) { path = "pages/teacherSubmit/teacherSubmit?superiorId=" + superiorId2 } // 調用云函數,請求生成小程序碼 buffer 數據 const QRCodeObj = await wx.cloud.callFunction({ name: 'createQRCode', data: { path: path, width: 430 } }) // 需要注意的是返回來的數據是Buffer格式 // 需要轉換成為base64格式(為了方便存儲復用,畢竟次數有限) const base64 = "data:image/jpeg;base64," + wx.arrayBufferToBase64(QRCodeObj.result.buffer.data) // 將數據直接扔進image組件的src參數里面即可 this.setData({ imgUrl: base64 })
4、wxml
5、效果
六、說明與優化
只是截取了部分的關鍵代碼。小程序碼也做了處理。
觸發函數、實現復用的代碼都沒有貼出來(為了安全,不方便貼出來)。
優化的話,第一個肯定就是考慮復用了,即新用戶第一次調用云函數去生成,下次的話,就直接從數據庫里面讀出來生成。
當然前提是參數一致。
為什么要復用呢,主要是因為即使是同一個二維碼,參數什么都一致,你調用了十次函數生成,也算是十個碼,不是一個碼。所以在數量有限的情況下,盡可能考慮復用。